ES2950039T3

ES2950039T3 - Identificación automatizada del estado de un dispositivo y modificación dinámica resultante de las operaciones del dispositivo

Info

Publication number: ES2950039T3
Application number: ES19205869T
Authority: ES
Inventors: Luca Cazzanti; Oliver B Downs; Matthew G Danielson
Original assignee: Curinos Inc
Current assignee: Curinos Inc
Priority date: 2018-11-08
Filing date: 2019-10-29
Publication date: 2023-10-04
Anticipated expiration: 2039-10-29
Also published as: CA3060877A1; AU2019253894B1; CA3060877C; US10353764B1; EP3654186B1; EP3654186C0; EP3654186A1

Abstract

Se describen técnicas para modificar automática y dinámicamente las operaciones en curso de dispositivos informáticos de maneras específicas del dispositivo, como por ejemplo basándose en una identificación automatizada del estado de un dispositivo informático (por ejemplo, identificando una posible falla continua o inminente de un teléfono inteligente u otro dispositivo informático basado en en una serie de estados de hardware observados del dispositivo informático y tomar acciones correctivas automatizadas para prevenir o mitigar dicho fallo del dispositivo, como por ejemplo modificando los ajustes de configuración en el dispositivo informático o en los sistemas asociados). Las técnicas pueden incluir, para cada uno de los múltiples resultados de interés del estado del dispositivo (por ejemplo, falla del dispositivo versus no falla del dispositivo), generar un modelo de resultados de espacio de estado que represente los dispositivos que alcanzan ese resultado de estado dentro de un período de tiempo de interés. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Identificación automatizada del estado de un dispositivo y modificación dinámica resultante de las operaciones del dispositivo

CAMPO TÉCNICO

[0001] La siguiente descripción se refiere, en general, a la identificación automática del estado de dispositivos informáticos y la n dinámica de sus operaciones en curso de maneras resultantes, como mitigar dinámicamente un fallo del dispositivo informático que se predice a partir de una serie de estados de hardware del dispositivo informático. ANTECEDENTES

[0002] Las operaciones de los dispositivos informáticos son cada vez más complejas, con una variedad de componentes de hardware que pueden fallar o experimentar un rendimiento reducido en distintas condiciones y a frecuencias variables, y una variedad de ajustes de configuración que afectan a las operaciones del dispositivo. Por ejemplo, es habitual experimentar problemas con la duración de la batería, la pantalla (por ejemplo, grietas, píxeles inservibles, etc.), conexión de datos intermitente o interrupciones del suministro eléctrico, etc. Además, los teléfonos inteligentes y otros dispositivos informáticos móviles suelen tener ajustes que afectan a las operaciones del dispositivo (por ejemplo, el uso de la batería, como en proporción inversa a otras actividades que afectan al rendimiento del dispositivo), y las actividades de los proveedores de servicios correspondientes (por ejemplo, proveedores de servicios de telecomunicaciones u otro servicio de comunicación de red) también pueden afectar a dichas operaciones del dispositivo (por ejemplo, con respecto a cómo se gestionan las comunicaciones de red hacia y desde dichos dispositivos). Además, las aplicaciones que se ejecutan en un dispositivo informático pueden afectar a diversos aspectos de la fiabilidad del dispositivo y otras operaciones.

[0003] Aunque los intentos de gestionar las operaciones del dispositivo pueden aumentar la eficacia de los dispositivos en algunas situaciones si se realizan correctamente, existen problemas con las técnicas existentes para dicha gestión de las operaciones del dispositivo, incluidos los intentos de maximizar la vida útil del dispositivo y de otro modo mitigar los fallos del dispositivo y otros problemas. Souza e Silva et a. "Performance evaluation with Hidden Markov Models discloses hidden Markov models applied to the performance evaluation of computer systems and networks". El documento EP3206153 describe un procedimiento para su uso en la detección de un comportamiento anormal de un grupo de una pluralidad de entidades de un sistema informático. El documento EP2785009 describe un procedimiento y aparato para determinar el comportamiento de un sistema a partir de datos observados, en particular para detectar un evento con varias etapas. El documento US20150142384 describe un procedimiento para supervisar una condición de un sistema o proceso que incluye la adquisición de datos de sensores a partir de una pluralidad de sensores dispuestos dentro del sistema. El documento WO2016183332 describe un procedimiento para el modelado de pronósticos que incluye la obtención de valores de probabilidad para posibles estados de salud de un sistema o componente utilizando uno o más modelos basados en datos y uno o más modelos de física de fallos. BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0004]

La figura 1 es un diagrama de red que ilustra un entorno ejemplar en el que se proporciona y utiliza un sistema para la identificación automática del estado actual de dispositivos informáticos y la modificación dinámica de sus operaciones en curso, incluida la ilustración de sistemas informáticos ejemplares adecuados para ejecutar una realización de dicho sistema.

Las Figuras 2A-2F son diagramas que ilustran ejemplos de generación y uso de estructuras de datos para modelos de resultados de espacio de estados para la identificación automática del estado actual de dispositivos informáticos y la modificación dinámica de sus operaciones en curso.

La Figura 3 ilustra un diagrama de flujo de una realización ejemplar de una rutina de determinación de relaciones entre las operaciones de un dispositivo de gestión automatizada de operaciones (AOM, por sus siglas en inglés). La Figura 4 ilustra un diagrama de flujo de una realización ejemplar de una rutina de determinación de modificación de las operaciones de un dispositivo AOM.

DESCRIPCIÓN DETALLADA

[0005] Se describen técnicas para la identificación automática y dinámica de las operaciones en curso de dispositivos informáticos de maneras específicas para el dispositivo, como la identificación automática de un estado de un dispositivo informático y la modificación dinámica de sus operaciones en curso de manera resultante. La invención se expone en las reivindicaciones independientes. Las reivindicaciones dependientes definen otras realizaciones de la invención. En al menos algunas realizaciones, las técnicas incluyen la identificación de un probable fallo actual o inminente de un teléfono inteligente u otro dispositivo informático basándose en una serie de estados de atributos de hardware anteriormente observados del dispositivo informático, y la adopción de acciones correctivas automatizadas para prevenir o de otro modo mitigar dicho fallo del dispositivo (por ejemplo, mediante la modificación de los ajustes de configuración del dispositivo informático o de los sistemas correspondientes en comunicación con el dispositivo informático). Las técnicas pueden incluir, para cada uno de los múltiples resultados de estado del dispositivo de interés (por ejemplo, fallo de dispositivo frente a no fallo de dispositivo), la generación de un modelo de resultado de espacio de estados que representa los dispositivos que alcanzan ese resultado de estado en un período de tiempo de interés, con base, en parte, en datos sobre series de estados de atributos de dispositivo anteriormente observados para esos dispositivos durante múltiples períodos de tiempo antes de que se alcancen esos resultados de estado de dispositivo. Tales modelos de resultados generados incluyen un modelo de fallos que representa los dispositivos que alcanzan un estado de fallo (por ejemplo, que experimentan un fallo parcial o completo del dispositivo) en ese período de tiempo, y un modelo de no-fallo que representa otros dispositivos que no alcanzan tal estado de fallo en ese período de tiempo. Una vez generados tales modelos de resultados, pueden utilizarse para determinar en qué medida sus datos coinciden con una serie de estados observados de atributos del dispositivo de un dispositivo actual adicional de interés, seleccionándose opcionalmente el modelo de resultados que mejor coincida (o «se ajuste») y utilizándose para identificar un probable resultado actual o inminente de ese dispositivo actual (por ejemplo, fallo o no fallo del dispositivo). Posteriormente, pueden tomarse las acciones correctivas automatizadas correspondientes basándose en el probable resultado actual o inminente identificado. En al menos algunas realizaciones, las técnicas descritas se llevan a cabo mediante operaciones automatizadas de un sistema de gestión automatizada de operaciones (AOM) implementado por ordenador, como se explica con más detalle a continuación.En al menos algunas realizaciones, las técnicas descritas se realizan mediante operaciones automatizadas de un sistema de Gestor de Operaciones Automatizado (AOM) implementado por ordenador, como se analiza con mayor detalle a continuación.

[0006] Como se indicó anteriormente, al menos en algunas realizaciones, los modelos de resultados se generan para representar cada uno de los múltiples resultados de estado del dispositivo de interés, como para generar un modelo de resultados de espacio de estados para un resultado de estado que represente los dispositivos cliente que alcancen ese resultado de estado en un período de tiempo de interés . En realizaciones en las que los resultados de estado de interés sean fallo del dispositivo o no fallo del dispositivo, se pueden generar modelos de resultados de fallo y no fallo, mientras que en otras realizaciones, se pueden utilizar otros tipos de resultados de estado (por ejemplo, no fallo del dispositivo, fallo de la pantalla del dispositivo, fallo del puerto de datos del dispositivo, fallo de la antena del dispositivo, etc.) y cada uno puede tener un modelo de resultados generado asociado. La generación de dichos modelos de resultados puede incluir el seguimiento y almacenamiento de información de estado para cada uno de los dispositivos durante múltiples periodos de tiempo (por ejemplo, el estado de cada uno de los atributos de hardware del dispositivo u otros atributos del dispositivo, también denominados en esta solicitud estados de atributos del dispositivo), incluido si un dispositivo tiene un resultado de estado de interés y cuándo. En al menos algunas realizaciones, los múltiples resultados de estado pueden ser mutuamente excluyentes en un momento dado, de modo que un dispositivo solo puede encontrarse en un resultado de estado a la vez y, opcionalmente, siempre se encuentra en uno de los resultados de estado (por ejemplo, en un resultado de estado de no fallo si no se ha producido ninguno de los resultados de fallo). A continuación, los distintos dispositivos pueden agruparse en función de los múltiples resultados de estado, de modo que cada resultado de estado tenga un grupo asociado que incluya los dispositivos que alcanzan ese resultado de estado.

[0007] Posteriormente, los datos de un grupo de dispositivos asociado a un resultado de estado pueden analizarse para generar un modelo de resultados para ese resultado de estado. El análisis y la generación del modelo pueden, al menos en algunas realizaciones, incluir la generación de nodos para representar múltiples atributos no observables (u «ocultos») de un dispositivo cuyos datos no se observan automáticamente, pero que afectan a las operaciones en curso del dispositivo, como para tener un efecto causal o de otro modo correlacionado sobre los atributos de dispositivo observables. En al menos algunas realizaciones, los múltiples atributos de dispositivo observables pueden ser mutuamente excluyentes en un momento dado y/o los múltiples atributos no observables pueden ser mutuamente excluyentes en un momento dado. Posteriormente, los datos de estado observados agregados para los dispositivos del grupo pueden analizarse para determinar lo siguiente para cada atributo no observable: una probabilidad inicial u otra probabilidad de que cada uno de los atributos de dispositivo observables esté presente para un dispositivo cliente si ese atributo no observable está presente (por ejemplo, con un total del 100 % de probabilidad en todos los atributos de dispositivo observables para ese atributo no observable de dispositivo), lo que en ocasiones también se denomina matriz de emisión. Como ejemplo no exclusivo, si un fallo de antena es un atributo no observable, puede causar un atributo observable como una llamada interrumpida y/o un problema de velocidad de transmisión de datos; una probabilidad inicial u otra probabilidad de que el atributo no observable esté presente para un dispositivo cliente en ausencia de otra evidencia o información (por ejemplo, con una probabilidad total del 100 % en todos los atributos de dispositivo no observables), lo que en ocasiones también se denomina parte de una matriz de estados iniciales; y una probabilidad inicial u otra probabilidad de que un dispositivo cliente que tenga ese atributo no observable de dispositivo tenga, en un próximo período de tiempo, cada uno de los atributos de dispositivo no observables (por ejemplo, con una probabilidad total del 100 % en todos los atributos de dispositivo no observables para ese atributo no observable de dispositivo), lo que en ocasiones también se denomina parte de una matriz de transmisión. En algunas realizaciones, puede generarse un modelo de resultados utilizando una o más estructuras de datos de filtro de Kalman mediante un algoritmo de estimación lineal cuadrática (LQE), como se expone con mayor detalle a continuación, mientras que en otras realizaciones los modelos de resultados pueden generarse y representarse de otras maneras. Más adelante, se incluyen detalles adicionales relativos a ejemplos no exclusivos de generación de tales modelos de resultados con respecto a las Figuras 2A-2F.

[0008] Como también se ha señalado anteriormente, en al menos algunas realizaciones, los modelos de resultados generados se utilizan para identificar un probable estado de resultado actual o futuro para un dispositivo cliente adicional de interés con base, al menos en parte, en una serie de estados de atributos de dispositivo observados de ese dispositivo actual adicional. Por ejemplo, la serie de estados de atributos de dispositivo observados de ese dispositivo actual adicional puede compararse con la información de cada uno de los modelos de resultados para identificar el modelo de resultados que mejor se ajuste (o, en términos más generales, con un ajuste que supere un umbral definido), y el estado de resultados correspondiente para ese modelo de resultados puede identificarse como un probable estado de resultado actual o futuro para el dispositivo cliente adicional. En algunas realizaciones, la determinación de un ajuste o coincidencia para los estados de atributo de dispositivo observados del dispositivo cliente adicional con un modelo de resultados puede incluir comenzar con la matriz de estados iniciales, la matriz de emisión y la matriz de transmisión para ese modelo de resultado, y posteriormente ajustar las probabilidades para el dispositivo cliente adicional en función de sus estados de atributo de dispositivo observados. El ajuste puede incluir, para cada momento en el que estén disponibles los valores de estado de atributo de dispositivo observados, la estimación de cuáles serían sus valores actuales dada la información de probabilidad actual para los estados no observables de atributo de dispositivo (opcionalmente, junto con incertidumbres para los valores actuales estimados de los estados de atributo de dispositivo observados) y posteriormente, actualizar esas estimaciones basadas en los valores reales de estado de atributo de dispositivo observados para el siguiente momento (por ejemplo, utilizando una media ponderada y, opcionalmente, dando más peso a las estimaciones con mayor certeza). De esta forma, aunque los valores de estado de atributo de dispositivo observados del dispositivo cliente adicional contengan algunas imprecisiones (por ejemplo, ruido estadístico), las estimaciones actualizadas a lo largo del tiempo aumentan en precisión en relación con las mediciones realizadas en un solo momento, lo que permite combinar información cambiante, tanto histórica como actual. Más adelante, se incluyen detalles adicionales relativos a ejemplos no exclusivos de uso de tales modelos de resultados con respecto a las Figuras 2A-2F.

[0009] Una vez que se identifica un probable estado de resultado actual o futuro para un dispositivo cliente adicional de interés basándose en uno o más modelos de resultados generados, se toman diversos tipos de acciones correctivas automatizadas correspondientes para prevenir o de otro modo mitigar al menos algunos tipos de estados de resultado (por ejemplo, un próximo fallo de dispositivo predicho, mientras que no se toma ninguna acción correctiva si no se predice un fallo). Tales acciones correctivas para un dispositivo informático teléfono inteligente u otro dispositivo cliente incluyen la modificación de las operaciones del dispositivo cliente, como por ejemplo modificando los ajustes de configuración que afectan al uso de una o más baterías, la memoria, el almacenamiento y las comunicaciones de red del dispositivo, con el fin de sustituir o complementar, temporal o permanentemente, un tipo de capacidad fallida del dispositivo con otra capacidad complementaria (por ejemplo, utilizar una conexión móvil en lugar de un fallo de atributo Wi-Fi; utilizar la transferencia de datos inalámbrica si falla un puerto de datos físico; etc.), para reducir el uso de las capacidades del dispositivo asociadas a un próximo fallo del mismo (por ejemplo, para reducir el uso de memoria o almacenamiento si se prevé un fallo asociado), etc. Tales acciones correctivas pueden, por ejemplo, prolongar el intervalo de tiempo antes de que se produzca el correspondiente tipo de fallo del dispositivo o, en algunos casos, prevenir el fallo del dispositivo. En otras realizaciones y situaciones, se pueden llevar a cabo otros tipos de acciones correctivas, incluidos la modificación de las operaciones de otros dispositivos que interactúen con el dispositivo cliente adicional, el inicio de una sustitución del dispositivo cliente adicional si el fallo de dispositivo previsto no se puede mitigar eficazmente, etc.

[0010] En términos más generales, ejemplos no exclusivos de la modificación de operaciones de un dispositivo informático de teléfono inteligente pueden incluir acciones correctivas para alterar los ajustes de configuración que afectan al uso de uno o más de los componentes de hardware del dispositivo (por ejemplo, batería, memoria, interfaz de red de almacenamiento, etc.), que afectan al uso de una funcionalidad del sistema operativo del dispositivo (por ejemplo, uso de virtualización, tamaño del espacio de búfer, etc.), que afectan al uso de los programas en ejecución del dispositivo (por ejemplo, para apagar, iniciar, cambiar la versión o actualizar, cambiar la prioridad o de otro modo cambiar el funcionamiento), etc. De forma análoga, los atributos del dispositivo pueden incluir cualquier aspecto medible de un dispositivo cliente que refleje su rendimiento o de otro modo refleje su funcionamiento, incluido con respecto a uno o más componentes de hardware, ajustes de configuración (por ejemplo, con respecto al uso de componentes de hardware, uso de un sistema operativo, uso de uno o más programas de aplicación, etc.). Además, en al menos algunas realizaciones, los atributos de un dispositivo pueden incluir aspectos de uno o más usuarios del dispositivo si estos pueden alterar el rendimiento del dispositivo cliente (por ejemplo, correspondientes a patrones de uso u otras interacciones del usuario con el dispositivo). Las acciones correctivas o tipos de acciones correctivas particulares que realizar para los correspondientes probables resultados de estado predichos pueden determinarse de diversas maneras en diversas realizaciones, incluidos su predefinición por parte de un operador del sistema AOM, su aprendizaje automático (por ejemplo, basándose en acciones observadas tomadas para dispositivos que tienen un resultado de estado particular, opcionalmente combinadas con un efecto medido de la acción), su sugerencia dinámica en un momento del probable resultado de estado predicho por parte de un usuario asociado, etc. Aunque en esta solicitud se incluyen diversos ejemplos de atributos de dispositivo, atributos de acción y medidas/efectos de rendimiento, se apreciará que las técnicas descritas no se limitan a estos detalles ejemplares. Más adelante, se incluyen detalles adicionales relativos a ejemplos no exclusivos de realización de acciones correctivas para prevenir o mitigar un probable resultado de estado actual o futuro identificado, incluido con respecto a los ejemplos de las Figuras 2A-2F.

[0011] Las técnicas descritas pueden proporcionar una variedad de beneficios y ventajas. Algunos ejemplos no exclusivos de tales beneficios y ventajas incluyen los siguientes: la mejora de las operaciones de dispositivos informáticos cliente individuales y/o de flotas u otros grupos de dispositivos cliente relacionados; la realización de análisis automatizados de datos de formación para generar y/o adaptar/actualizar modelos de resultados de dispositivos, incluido para reflejar el rendimiento real supervisado y el estado de dispositivos cliente con distintos resultados de dispositivos de interés; la gestión de conjuntos de datos de rendimiento real de gran volumen, potencialmente para millones o más dispositivos cliente y para múltiples resultados de dispositivos; etc.

[0012] Con fines ilustrativos, a continuación se describen algunas realizaciones en las que se llevan a cabo tipos específicos de operaciones, incluido con respecto al uso de las técnicas descritas con tipos particulares de dispositivos cliente, atributos de dispositivos y/o la prevención resultante u otras acciones de mitigación. Estos ejemplos se proporcionan con fines ilustrativos y se simplifican en aras de la brevedad, y las técnicas inventivas pueden utilizarse en una amplia variedad de otras situaciones, incluido con otros tipos de análisis automatizados de probables resultados de estado en curso o futuros. Por lo tanto, se apreciará que las técnicas descritas no se limitan a su uso con las realizaciones ejemplares que se exponen a continuación.

[0013] La figura 1 es un diagrama de red que ilustra un entorno ejemplar en el que se proporciona y utiliza un sistema para la identificación automática del estado actual de dispositivos informáticos y la modificación dinámica de sus operaciones en curso, incluida la ilustración de sistemas informáticos ejemplares adecuados para ejecutar una realización de dicho sistema.

[0014] En particular, la Figura 1 ilustra ejemplos de usuarios 105, cada uno de los cuales tiene un dispositivo informático cliente que tiene uno o más tipos de capacidades de comunicación inalámbrica, como dispositivos informáticos de teléfono inteligente u otros dispositivos informáticos móviles (por ejemplo, una tableta, un ordenador portátil, etc.), aunque en otras realizaciones algunos o todos estos dispositivos cliente pueden ser dispositivos de ubicación fija y/o pueden no soportar comunicaciones inalámbricas. El dispositivo informático cliente portátil 145 del usuario ejemplar 105a se ilustra con más detalle, por ejemplo, para incluir un dispositivo de teléfono inteligente o un dispositivo tableta con una pantalla sensible al tacto. En este ejemplo, la pantalla está separada en las secciones 145a y 145b por una interfaz gráfica de usuario («GUI») que se muestra en el dispositivo 145, utilizándose en este ejemplo la parte 145b para proporcionar controles de funcionalidad seleccionables por el usuario (por ejemplo, botones o iconos), y utilizándose la parte separada 145a para mostrar o de otro modo presentar diversa información al usuario. Se apreciará que, en otras realizaciones, un dispositivo puede tener otros tipos de GUI (o ninguna GUI).

[0015] En la realización ilustrada, se muestran detalles adicionales con respecto a los componentes internos ejemplares del dispositivo cliente 145. En particular, en este ejemplo, el dispositivo cliente 145 es apto para realizar al menos algunas de las técnicas descritas, como la ejecución de una realización de un sistema de gestión automatizada de operaciones (AOM) 140a. El dispositivo ejemplar 145 incluye uno o más procesadores de unidad central de procesamiento («CPU») de hardware 105, diversos componentes de entrada/salida («E/S») de hardware 110, almacenamiento 120, memoria 130, una o más baterías 107 y una o más IMU (unidades de medición inercial). Los componentes de E/S ilustrados en este ejemplo de realización incluyen una pantalla 111 (para proporcionar el área de visualización 145a y 145b), una interfaz de conexión de red 112, una unidad de medios legibles por ordenador 113 y otros dispositivos de E/S 115 (por ejemplo, teclados inalámbricos o conectados, ratones u otros dispositivos señaladores, micrófonos, altavoces, cámaras, otros sensores, etc.). Otros tipos de componentes de hardware pueden estar presentes adicionalmente (por ejemplo, otros procesadores, como una GPU o unidad de procesamiento gráfico; etc.), pero no se ilustran en este ejemplo.

[0016] También se ilustran un sistema informático de servidor opcional 100 y otros sistemas informáticos accesibles en red 165 y 180, cada uno de los cuales puede tener componentes internos similares a los del dispositivo cliente 145, aunque los detalles correspondientes no se ilustran en este ejemplo en aras de la brevedad. En las realizaciones en las que el dispositivo 145 incluye capacidades de comunicaciones inalámbricas (por ejemplo, Wi-Fi, una conexión móvil, etc.), el dispositivo 145 puede comunicarse con algunos o todos los demás sistemas informáticos 100 y 180 a través de una o más redes intermedias 190 mediante comunicaciones 161 con uno o más puntos de acceso de red 163 (por ejemplo, routers Wi-Fi, torres de telefonía y/o estaciones base móviles, etc.) como para realizar otras interacciones 162 con el sistema informático de servidor 100 (por ejemplo, para proporcionar información sobre el rendimiento del dispositivo 145) y/o con el resto de sistemas informáticos 180. Del mismo modo, si un dispositivo cliente particular (por ejemplo, el dispositivo cliente del usuario 105n) está cerca de un sistema informático local como el sistema 165 y tiene capacidades de comunicaciones inalámbricas de corta distancia (por ejemplo, Bluetooth, infrarrojos, RFID, NFC, etc.) soportadas por dicho sistema informático local, el dispositivo cliente puede comunicarse del mismo modo con dicho sistema informático local a través de las comunicaciones 164 y, opcionalmente, a través de dicho sistema informático local con otros sistemas informáticos (por ejemplo, los sistemas informáticos 100 y 180) a través de la red 190. En otras realizaciones, tales interacciones pueden producirse de maneras distintas a las comunicaciones inalámbricas, como para realizar dichas interacciones en un momento posterior a través de una conexión por cable (por ejemplo, si el sistema informático cliente 145 no incluye comunicaciones inalámbricas, y/o si el sistema AOM opcional 140b del sistema informático de servidor 100 realiza posteriormente sus operaciones en modo fuera de línea o por lotes).

[0017] En el ejemplo ilustrado, una o más realizaciones del sistema AOM 140 pueden estar en uso para llevar a cabo algunas o todas las técnicas descritas, como una copia del sistema AOM 140a que se está ejecutando en la memoria 130 del dispositivo cliente 145, y/o una copia del sistema AOM 140b en el sistema informático de servidor 100. El sistema AOM 140a y/o 140b puede identificar, de manera automática y dinámica, un probable estado de resultado actual o futuro del dispositivo cliente 145 y modificar dinámicamente sus operaciones en curso o de otro modo tomar acciones correctivas de forma resultante basándose en dicho estado identificado, como en tiempo real o casi real. Como se expone con mayor detalle en otra parte, tal identificación del probable estado de resultado actual o futuro de un dispositivo cliente puede incluir el uso de una o más estructuras de operaciones AOM almacenadas 127 (por ejemplo, modelos de resultados de dispositivo) previamente generadas basándose en datos sobre otros numerosos dispositivos cliente. En otra parte de la presente solicitud se incluyen detalles adicionales relativos a la generación y uso de tales estructuras de decisión, incluido con respecto a los ejemplos de las Figuras 2A-2F.

[0018] Además, tales acciones correctivas automatizadas pueden llevarse a cabo para prevenir o de otro modo mitigar un probable estado de resultado indeseable actual o futuro del dispositivo cliente 145, incluidas, en algunos casos, la modificación de uno o más ajustes de configuración almacenados u otra información 125 en el dispositivo cliente 145 que afecte a las operaciones en curso, mientras que en otras realizaciones, pueden incluir interacciones con otros sistemas o dispositivos (por ejemplo, con otros dispositivos o sistemas 100, 163, 165 y/o 180 para alterar sus interacciones con el dispositivo cliente 145, por ejemplo, para cambiar la prioridad de los paquetes u otras comunicaciones que se envían a y/o desde el dispositivo cliente 145, o para de otro modo alterar cómo y cuándo se gestionan dichas comunicaciones; para iniciar la sustitución del dispositivo cliente 145 por otro dispositivo si es probable que se produzca un fallo en el dispositivo cliente 145, opcionalmente previa notificación y/o aprobación por parte del usuario que posea, controle o de otro modo utilice el dispositivo cliente 145; etc.). Tales acciones de modificación del dispositivo cliente 145 pueden incluir, por ejemplo, una o más de las siguientes: cambiar el uso de un área de búfer de la memoria (por ejemplo, utilizada para almacenar temporalmente la información que se transmite al dispositivo cliente, como para habilitar o deshabilitar el uso del área de búfer, aumentar o disminuir el tamaño del área de búfer, etc.), como para reducir errores o problemas relacionados con las comunicaciones entre dispositivos y/o mejorar el uso de la batería; para cambiar el uso de la virtualización opcional en el dispositivo cliente (por ejemplo, utilizada para proporcionar una o más máquinas virtuales 143, cada una de las cuales simulan una máquina física para su uso en la ejecución de uno o más programas por separado de otros programas, como para habilitar o deshabilitar el uso de dicha máquina o máquinas virtuales, para aumentar o reducir el tamaño y/o la cantidad de máquinas virtuales, etc.), como para mejorar el rendimiento de la o las CPU, el almacenamiento, la memoria, la batería, etc; para modificar la ejecución de uno o más programas opcionales 135a (por ejemplo, para iniciar, detener o modificar la ejecución de uno o más programas, incluido para cambiar las prioridades asociadas de los otros programas; para actualizar o de otro modo modificar las versiones de uno o más programas del sistema operativo y/o programas de aplicación; etc.), como para mejorar el rendimiento de la o las CPU, el almacenamiento, la memoria y/o la batería; etc.

[0019] En al menos algunas realizaciones en las que una copia del sistema AOM se ejecuta en un dispositivo cliente como el dispositivo cliente 145, dicho sistema AOM puede funcionar para prevenir o mitigar probables problemas actuales o futuros con las operaciones de dicho dispositivo cliente de manera específica para dicho dispositivo cliente. En otras realizaciones en las que se ejecuta una copia del sistema AOM 140 en uno de los otros sistemas informáticos, como el sistema AOM 140b en el sistema informático de servidor 100, el sistema AOM 140b puede interactuar con numerosos dispositivos cliente (por ejemplo, dispositivos cliente de algunos o todos los usuarios 105a-105n) para, del mismo modo, prevenir o mitigar probables problemas actuales o futuros con operaciones en cada uno de dichos dispositivos cliente de manera específica para el dispositivo, el número de dispositivos cliente pudiendo ser de millones, decenas de millones, cientos de millones, etc. Tal sistema informático de servidor opcional 100 puede ejecutar, además. uno o más otros programas opcionales 135b, como para proporcionar información a o de otro modo interactuar con los dispositivos cliente de los usuarios 105. A continuación, se incluyen detalles adicionales relativos a las operaciones de las realizaciones del sistema AOM.

[0020] Se apreciará que los sistemas y dispositivos informáticos ilustrados son meramente ilustrativos y no pretenden limitar el alcance de la presente invención. Por ejemplo, la red 190 puede incluir partes de Internet, una red privada (por ejemplo, una red corporativa), una red móvil, o cualquier otra red, incluidas combinaciones de una o más de dichas redes. Además, el sistema informático 100 y/o el dispositivo cliente 145 pueden estar conectados a otros dispositivos que no se ilustran, incluido a través de una o más redes como Internet o a través de la Web. En términos más generales, un sistema o dispositivo informático «cliente» o «de servidor» puede comprender cualquier combinación de hardware que pueda interactuar y realizar los tipos de funcionalidad descritos, como cuando se programa o de otro modo se configura con software, incluidos, entre otros, ordenadores de sobremesa, ordenadores portátiles, ordenadores tipo slate, tabletas, ordenadores integrados, hardware especializado como ASIC («circuito integrado para aplicaciones específicas») u otros ordenadores, dispositivos informáticos de teléfonos inteligentes y otros teléfonos móviles, dispositivos de Internet, PDA y otros organizadores electrónicos, servidores de bases de datos, dispositivos de almacenamiento en red y otros dispositivos de red, teléfonos inalámbricos, buscapersonas, sistemas basados en televisión (por ejemplo, utilizando decodificadores y/o grabadores de vídeo personales/digitales y/o consolas de juegos y/o servidores multimedia), y otros productos de consumo que incluyan capacidades de intercomunicación apropiadas. Por ejemplo, el sistema ilustrado 140 y/o sus componentes pueden incluir instrucciones de software ejecutables y/o estructuras de datos en al menos algunas realizaciones, que, cuando se cargan y/o ejecutan mediante sistemas o dispositivos informáticos particulares, pueden usarse para programar o de otro modo configurar dichos sistemas o dispositivos, como para configurar procesadores de hardware de dichos sistemas o dispositivos. Alternativamente, en otras realizaciones, algunos o todos los componentes y/o sistemas de software pueden ejecutarse en la memoria de otro dispositivo y comunicarse con el sistema/dispositivo informático ilustrado mediante comunicación entre ordenadores. Además, aunque varios elementos se ilustran como almacenados en memoria o en almacenamiento en distintos momentos (por ejemplo, mientras se utilizan), dichos elementos o partes de los mismos pueden transferirse entre la memoria y el almacenamiento y/o entre dispositivos de almacenamiento (por ejemplo, en distintas ubicaciones) con fines de gestión de memoria y/o integridad de datos. Además, la funcionalidad proporcionada por los componentes del sistema ilustrados puede, en algunas realizaciones, combinarse en menos componentes o distribuirse en componentes adicionales. Del mismo modo, en algunas realizaciones, puede no proporcionarse la funcionalidad de algunos de los componentes ilustrados y/o puede estar disponible otra funcionalidad adicional.

[0021] Por lo tanto, en al menos algunas realizaciones, los componentes y/o sistemas ilustrados son componentes/sistemas basados en software que incluyen instrucciones de software que, al ser ejecutadas por la o las CPU 105 y/o la o las CPU del sistema 100 y/u otros medios procesadores de hardware, programan el procesador o los procesadores para realizar automáticamente las operaciones descritas para dicho componente/sistema, incluidos el uso y la ejecución de rutinas y otros algoritmos como se describe en esta solicitud. Además, en algunas realizaciones, algunos o todos los componentes y/o sistemas pueden implementarse o proporcionarse de otras maneras, como al menos parcialmente en firmware y/o medios de hardware, incluidos, sin limitación, uno o más circuitos integrados para aplicaciones específicas (ASIC), circuitos integrados estándar, controladores (por ejemplo, mediante la ejecución de instrucciones apropiadas, e incluidos microcontroladores y/o controladores integrados), matrices de puertas lógicas programables en campo (FPGA), dispositivos lógicos programables complejos (CPLD), etc. Algunos o todos los sistemas, componentes o estructuras de datos también pueden almacenarse (por ejemplo, como contenidos de instrucciones de software o contenidos de datos estructurados) en un medio de almacenamiento no transitorio legible por ordenador, como un disco duro o una unidad flash u otro dispositivo de almacenamiento no volátil, una memoria volátil o no volátil (por ejemplo, RAM), un dispositivo de almacenamiento en red o un artículo multimedia portátil (por ejemplo, un disco DVD, un disco CD, un disco óptico, un dispositivo de memoria flash, etc.) para su lectura por parte de una unidad apropiada o a través de una conexión apropiada. En algunas realizaciones, los sistemas, componentes y estructuras de datos también pueden transmitirse como señales de datos generadas (por ejemplo, como parte de una onda portadora u otra señal propagada analógica o digital) en una variedad de medios de transmisión legibles por ordenador, incluidos medios inalámbricos y por cable, y pueden adoptar diversas formas (por ejemplo, como parte de una señal analógica única o multiplexada, o como múltiples paquetes o tramas digitales discretos). Tales productos de programas de ordenador también adoptar tomar otras formas en otras realizaciones. Por lo tanto, la presente invención puede ponerse en práctica con otras configuraciones de sistemas informáticos.

[0022] Las Figuras 2A-2F son diagramas que ilustran ejemplos de generación y uso de estructuras de datos para modelos de resultados de espacio de estados para la identificación automática del estado actual de dispositivos informáticos y la modificación dinámica de sus operaciones en curso.

[0023] En particular, la Figura 2A ilustra el seguimiento y almacenamiento de información sobre una serie de estados de atributos de dispositivo previamente observados 205 de un dispositivo informático cliente ejemplar XXX (por ejemplo, un teléfono inteligente, que no se muestra en la figura) para cada uno de una serie de períodos de tiempo (que se muestran en este ejemplo como los tiempos T-4, T-3, T-2 y T-1, como cada milisegundo, cada segundo, cada minuto, cada hora, cada día, etc.), junto con un estado de resultado de estado observado resultante 212. Los posibles estados de resultado de estado 212 son un fallo de dispositivo o un no fallo de dispositivo, y los estados de atributo de dispositivo observados 205 reflejan atributos de dispositivo observables que corresponden a componentes de hardware del dispositivo y son determinados automáticamente por sensores en el dispositivo, como pérdida de paquetes, reinicios (o restablecimientos) del dispositivo, tiempo de carga de las aplicaciones, fallos de las aplicaciones, velocidad de conexión, llamadas interrumpidas, capacitancia de pantalla, datos de acelerómetro (por ejemplo, para indicar una rápida desaceleración compatible con una caída del dispositivo), etc. En otras realizaciones, pueden rastrearse y utilizarse una variedad de otros atributos del dispositivo, ya sea en lugar de o además de los atributos de dispositivo observados ilustrados, con ejemplos no excluyentes que incluyen la frecuencia y los tipos de diferentes conexiones de comunicación (por ejemplo, a través de Wi-Fi frente a una conexión móvil), versiones de programas, tipo de sistema operativo, información acerca de los desplazamientos o swipes de pantalla (por ejemplo, continuidad de los gestos), etc.

[0024] En este ejemplo ilustrado, no se observan valores de estado de atributo de dispositivo anómalos en el tiempo T-4 (por ejemplo, cada uno de los atributos de dispositivo ilustrados tiene un valor, que no se muestra, en un rango normal), como se ilustra mediante los nodos correspondientes a los valores de estado de atributo de dispositivo que se muestran sin una línea exterior en negrita. Sin embargo, se observa un valor anómalo de atributo de dispositivo de pérdida de paquetes en el tiempo T-3 (por ejemplo, pérdida de paquetes por encima de un umbral definido), se observa un valor anómalo de atributo de dispositivo de interrupción de llamadas en el tiempo T-2 (por ejemplo, una cantidad de llamadas interrumpidas por encima de un umbral definido), y se observa un valor anómalo de atributo de dispositivo de reinicios del dispositivo en el tiempo T-1 (por ejemplo, una cantidad de reinicios del dispositivo por encima de un umbral definido). Cada uno de los nodos correspondientes se ilustran con una línea exterior en negrita. Además, los estados de resultado de estado observados en los tiempos T-4, T-3, T-2 y T-1 son no fallo del dispositivo, no fallo del dispositivo, no fallo del dispositivo, seguido fallo del dispositivo, respectivamente. Los nodos correspondientes a dichos estados de resultado de estado observados se muestran con una línea exterior en negrita. En este ejemplo, los estados de resultado de estado son mutuamente excluyentes (es decir, fallo del dispositivo o no fallo del dispositivo, pero no ambos), al igual que los estados de atributo de dispositivo observados (por ejemplo, con un atributo de «pérdida de paquetes» que representa un problema de pérdida de paquetes, pero no un problema con ninguno de los otros atributos de dispositivo observados), aunque en otras realizaciones, los estados de resultado de estado y/o los estados de atributo de dispositivo observados pueden adoptar otras formas (por ejemplo, estar superpuestos, para permitir que se observen múltiples simultáneamente).

[0025] La figura 2A ilustra, además, que existen otros atributos 210 del dispositivo que no son automáticamente observables por los sensores del dispositivo, pero que pueden tener un efecto causal o de otro modo correlativo sobre los atributos 205 de estado observados, mostrándose en la figura 2A ejemplos de una pantalla agrietada, un fallo del puerto de datos, un fallo de la antena, etc. En este ejemplo, ninguno de los atributos de dispositivo no observables 210 es anómalo en el momento T-4, pero se produce (pero no se observa automáticamente) un fallo de antena anómalo (ya sea intermitente o permanente) en el momento T-3 que contribuye al valor anómalo de atributo del dispositivo de pérdida de paquetes observado en ese momento, continuando dicho fallo anómalo de antena en los tiempos T-2 y T-1 para contribuir al valor anómalo de atributo del dispositivo de interrupción de llamadas observado en el tiempo T-2 y al valor anómalo de atributo observado de reinicios del dispositivo en el tiempo T-1, y estando causado el eventual resultado de estado de fallo del dispositivo observado en el tiempo T-1, al menos en parte, por el fallo de antena (por ejemplo, por un fallo de antena intermitente que finalmente empeora hasta el punto de que el dispositivo falla por completo o de otro modo se vuelve efectivamente inutilizable). Al igual que con los otros nodos, los nodos ilustrados para el estado anómalo no observable de atributo del dispositivo de fallo de antena en los tiempos T-3, T-2 y T-2 se muestran con una línea exterior en negrita. Dado que el dispositivo informático XXX eventualmente falla durante el período de tiempo que está siendo supervisado, formará parte de un grupo de numerosos dispositivos informáticos que se utilizan para generar un modelo de resultados para el resultado de estado de fallo. Se apreciará que la supervisión para tal ejemplo de dispositivo informático puede producirse durante un número mucho mayor de períodos de tiempo (por ejemplo, durante días, semanas, meses, años), y que tal información puede recopilarse para numerosos dispositivos informáticos (por ejemplo, cientos, miles, millones, etc.), como por parte de un proveedor de servicios de telecomunicaciones que proporciona servicios de telecomunicaciones a los dispositivos.

[0026] La figura 2B continúa el ejemplo de la figura 2A, e ilustra cómo los datos observados para el dispositivo informático XXX pueden analizarse posteriormente, normalmente junto con los datos observados para otros numerosos dispositivos informáticos que fallan de forma similar, como parte de la generación de un modelo de resultado de fallo para representar dichos dispositivos. En particular, como parte de la generación del modelo de resultados, una serie de estados no observables de atributos de dispositivo se modelan para corresponder a factores ocultos que afectan al funcionamiento del dispositivo. En este ejemplo, los estados no observables de atributos de dispositivo 210 que se muestran se etiquetan con fines ilustrativos, pero en al menos algunas realizaciones y situaciones, los estados no observables de atributos de dispositivo representarán, en cambio, una cantidad de factores desconocidos (por ejemplo, «Estado oculto 1», «Estado oculto 2», etc.). Como se ilustra con las grandes flechas negras que apuntan de los estados de atributo no observables del dispositivo 210 a los valores de atributo observados de dispositivo 205, dichos valores de atributo observados de dispositivo 205 en un momento dado son causados, en parte o en su totalidad, por los estados de atributo no observables de dispositivo 210. Además, las flechas situadas entre períodos de tiempo ilustran que los valores en un período de tiempo se modelan como si estuviesen directamente influenciados únicamente por el período de tiempo anterior. Por lo tanto, el estado de los estados de atributo de dispositivo no observables 210 en el tiempo T-2 dependen únicamente del estado de esos mismos estados de atributo de dispositivo no observables 210 en el tiempo anterior T-3 y de los valores de los valores de atributo de dispositivo observados 205 en el tiempo anterior T-3. Dado que la Figura 2B ilustra parte de la generación de un modelo de resultado de fallos, solo se muestra el estado de resultado de fallo de dispositivo observado 215, aunque se realizará un análisis similar para generar un modelo de resultados de no fallo utilizando datos observados de otros dispositivos informáticos que no fallen.

[0027] La Figura 2C continúa los ejemplos de las Figuras 2A-2B, e ilustra información de relación probabilística que se determina para el estado de resultado de fallo generado basándose en el análisis de los datos observados para los numerosos dispositivos informáticos que fallan. En particular, la información ilustrada incluye una matriz de estados iniciales 225 que incluye, para cada uno de los estados de atributo de dispositivo no observable, una probabilidad inicial u otra probabilidad de que el atributo no observable esté presente para un dispositivo cliente en ausencia de otra evidencia o información (por ejemplo, con una probabilidad total del 100 % en todos los atributos de dispositivo no observables). La información ilustrada también incluye una matriz de estados iniciales 220 que incluye, para cada uno de los estados de atributos de dispositivo no observables, una probabilidad inicial u otra probabilidad de que el atributo no observable esté presente para un dispositivo cliente en ausencia de otra evidencia o información (por ejemplo, con un total de 100 % de probabilidad en todos los atributos de dispositivo no observables). La información ilustrada incluye, además, una matriz de transición que incluye, para cada uno de los estados de atributos de dispositivo no observables, una probabilidad inicial u otra probabilidad de que un dispositivo cliente que renga ese atributo de dispositivo no observable tenga, en un siguiente período de tiempo, cada uno de los atributos de dispositivo no observables (por ejemplo, con una probabilidad total del 100 % en todos los atributos de dispositivo no observables para cada atributo de dispositivo no observable). Se apreciará que se generará información similar para el modelo de resultados de no fallo, pero con diferente información de probabilidad determinada basada en el uso de distintos datos observados de otros dispositivos informáticos que no fallan.

[0028] La Figura 2D continúa los ejemplos de las Figuras 2A-2C y, en particular, muestra el uso del modelo de resultados de fallos generado para predecir si un dispositivo informático cliente adicional YYY fallará inminentemente. En este ejemplo, se observan diversos varios valores de atributos de dispositivo observados 235d para el dispositivo informático YYY en múltiples momentos (aunque solo se muestran datos observados para dos períodos de tiempo ejemplares T-2 y T-1, normalmente la predicción se realizaría utilizando datos observados para más períodos de tiempo), así como los estados de resultados de estados de no fallo observados 245d en los momentos T-2 y T-1. Utilizando la información de relación probabilística determinada para el modelo de resultados de fallo generado (que no se muestra en la figura), la serie de valores de estado de atributo de dispositivo observados a lo largo del tiempo se utilizan para determinar una probabilidad predicha u otra probabilidad de que el dispositivo informático YYY también falle en un momento futuro (por ejemplo, en uno o más períodos de tiempo siguientes posteriores a las observaciones). En este ejemplo, el atributo de pérdida de paquetes observado en el tiempo T-2 y el atributo de reinicios del dispositivo observado en el tiempo T-1 pueden estar causados, al menos en parte, por un problema de fallo de antena 240d no observado, pero existente en esos periodos de tiempo, y la predicción resultante del modelo de resultados de fallo para el tiempo T es un futuro fallo de dispositivo 250d (por ejemplo, una probabilidad predicha u otra probabilidad por encima de un umbral definido), así como un fallo de antena continuo no observado 255d en el tiempo T. Como se señaló anteriormente, en al menos algunas realizaciones y situaciones, los estados de atributo de dispositivo no observables representarán una cantidad de factores desconocidos que no están etiquetados a la manera del ejemplo.

[0029] La Figura 2E continúa los ejemplos de las Figuras 2A-2D y, en particular, muestra el uso de un modelo de resultados de no fallo generado correspondiente para predecir si el mismo dispositivo informático adicional YYY permanecerá en un resultado de estado de no fallo sin fallar. En este ejemplo, los diversos valores de atributo de dispositivo observados 235e y los estados de atributo de dispositivo no observados 240e son los mismos que en la Figura 2D, pero los estados de resultados de estado de no fallo observados 247e en los tiempos T-2 y T-1 muestran el estado observado de no fallo para el modelo de resultados de no fallo. Utilizando la información de relación probabilística diferente determinada para el modelo de resultados de no fallo generado (que no se muestra en la figura), la serie de valores de estado de atributo de dispositivo observados a lo largo del tiempo se utilizan para determinar una probabilidad predicha u otra probabilidad de que el dispositivo informático YYY seguirá sin fallar en un momento futuro (por ejemplo, en uno o más períodos de tiempo posteriores a las observaciones). En este ejemplo, la predicción resultante del modelo de resultados de no fallo para el tiempo T es la ausencia de un estado de resultado de no fallo 250e en el tiempo T (por ejemplo, una probabilidad predicha u otra probabilidad de fallo que esté por debajo de un umbral definido), aunque se predice un fallo de antena no observado continuo 255e en el tiempo T.

[0030] Por lo tanto, mediante la generación y el uso de múltiples modelos de resultados para cada uno de los múltiples resultados de estado, como se expone con respecto a las Figuras 2D y 2E para los modelos de resultados de fallo y no fallo generados, puede hacerse una determinación en cuanto al resultado de estado futuro predicho más probable para un dispositivo cliente particular que esté siendo evaluado. Los resultados de los múltiples modelos de resultados pueden utilizarse de varias maneras, como combinar los resultados de los múltiples modelos de resultados (por ejemplo, de manera ponderada, como para reflejar las certezas asociadas generadas para cada una de las predicciones por su correspondiente modelo de resultados), comparar los resultados y seleccionar uno para su uso (por ejemplo, uno con la mayor certeza, la mayor probabilidad predicha, etc.), etc.

[0031] La Figura 2F continúa los ejemplos de las Figuras 2A-2E y en este ejemplo, ilustra cómo el mismo modelo de resultados de no fallo generado puede utilizarse para predecir que un dispositivo informático cliente ZZZ diferente continuará teniendo un futuro resultado de estado de no fallo en un momento futuro T basándose en información diferente de estado de atributo de dispositivo observada para períodos de tiempo anteriores T-2 y T-1. En particular, utilizando la información de relación probabilística determinada para el modelo de resultados de no fallo generado (que no se muestra en la figura), la serie de valores de estado de atributo de dispositivo observados a lo largo del tiempo 235f se utilizan para determinar una probabilidad predicha u otra probabilidad de que el dispositivo informático ZZZ no falle en un momento futuro (por ejemplo, en uno o más períodos de tiempo siguientes posteriores a las observaciones). En este ejemplo, el atributo de pérdida de paquetes observado en el tiempo T-2 puede estar causado, al menos en parte, por un problema de fallo de antena intermitente 240f no observado, pero existente en ese período de tiempo, pero el problema de fallo de antena y el atributo de pérdida de paquetes observado resultante no se repiten en el tiempo T-1, y la predicción resultante del modelo de resultados de no fallo para el tiempo T es un futuro no fallo del dispositivo 250f (por ejemplo, una probabilidad predicha u otra probabilidad de fallo que esté por debajo de un umbral definido), aunque en este ejemplo, se predice que volverá el fallo de antena intermitente no observado 255f. Como se señaló anteriormente, en al menos algunas realizaciones y situaciones, los estados de atributo de dispositivo no observables representarán una cantidad de factores desconocidos que no están etiquetados a la manera del ejemplo.

[0032] Aunque se muestra un número limitado de atributos y dispositivos e información correspondiente con respecto a las Figuras 2A-2F, se apreciará que los modelos de resultados generados en otras realizaciones y situaciones pueden tener un número mucho mayor de atributos y nodos correspondientes y pueden utilizar otros tipos de atributos de dispositivo y usuario, así como almacenar y representar información de relación determinada de otras maneras (incluidas maneras que no empleen probabilidades). Además, aunque en los ejemplos de las Figuras 2A-2F se prevén diversos detalles, las técnicas descritas no se limitan a estos detalles ejemplares.

[0033] Los modelos de resultados se generan para incluir, cada uno, uno o más modelos de Markov ocultos, como uno o más filtros de Kalman. Por ejemplo, en las realizaciones que utilizan tales modelos ocultos de Markov para predecir el probable fallo o no fallo del dispositivo, se pueden emplear dos modelos ocultos de Markov, uno de los cuales produce la probabilidad de fallo y el otro, la probabilidad de no fallo. Los dos modelos ocultos de Markov pueden tener estructuras idénticas de valores de atributos observados y estados de atributos no observables, pero se entrenan con dos conjuntos de datos distintos: uno contiene datos de dispositivos que se sabe que han fallado; el otro, de dispositivos que no han fallado. A continuación, dados los datos de un dispositivo de estado desconocido de fallo/no fallo, los modelos ocultos de Markov producen una probabilidad de fallo y una probabilidad de no fallo. La determinación final de fallo/no fallo puede hacerse tomando el máximo de estas probabilidades, posiblemente ponderadas según la regla de Bayes o algún otro esquema de ponderación. En otras realizaciones de este tipo, pueden generarse y utilizarse más de dos modelos de resultados, por ejemplo, si el grupo de dispositivos que fallan se segmenta en múltiples subgrupos que comparten características distintas (y el grupo de dispositivos que no fallan se segmenta del mismo modo en múltiples subgrupos que comparten características distintas) y se genera un modelo de resultados independiente para cada subgrupo, eligiéndose subgrupos particulares para un dispositivo cliente que se esté evaluando y sus correspondientes modelos de resultados utilizados para la evaluación.

[0034] Con respecto a las realizaciones que utilizan modelos ocultos de Markov y/o filtros de Kalman, un modelo de Markov oculto es un modelo estadístico de Markov en el que se supone que el sistema que se está modelando es un proceso de Markov con estados no observados (es decir, ocultos), y describe la probabilidad conjunta de una colección de variables aleatorias discretas «ocultas» y observadas, utilizando el supuesto de que la i-ésima variable oculta dada la (i - 1)-ésima variable oculta es independiente de las variables ocultas anteriores, y las variables de observación actuales dependen únicamente del estado oculto actual. En el modelo de Markov oculto, el estado no es directamente visible, pero sí lo es la salida (en forma de datos o «token» en lo sucesivo), que depende del estado. Cada estado tiene una distribución de probabilidad sobre los posibles tokens de salida. Por lo tanto, la secuencia de tokens generada por un modelo de Markov oculto proporciona cierta información sobre la secuencia de estados; lo que también se conoce como teoría de patrones, un tema tratado por la inducción gramatical. El algoritmo de Baum-Welch puede utilizarse para calcular la estimación de máxima probabilidad de los parámetros de un modelo de Markov oculto dado un conjunto de vectores de características observados. En al menos algunos modelos de Markov ocultos, el espacio de estados de las variables ocultas es discreto, mientras que las propias observaciones pueden ser discretas (normalmente generadas a partir de una distribución categórica) o continuas (normalmente, a partir de una distribución gaussiana). Se puede suponer que el espacio de estado oculto consiste en uno de los N valores posibles, modelado como una distribución categórica. Esto significa que, para cada uno de los N estados posibles en los que puede encontrarse una variable oculta en el tiempo t, existe una probabilidad de transición desde este estado a cada uno de los N estados posibles de la variable oculta en el tiempo t+1, para un total de N₂probabilidades de transición, sumando 1 el conjunto de probabilidades de transición para las transiciones desde cualquier estado dado. Además, para cada uno de los N estados posibles, existe un conjunto de probabilidades de emisión que rigen la distribución de la variable observada en un momento determinado dado el estado de la variable oculta en ese momento. Por lo tanto, los parámetros de un modelo de Markov oculto son de dos tipos: probabilidades de transición y probabilidades de emisión (también conocidas como probabilidades de salida), que pueden reflejarse en una matriz de transición y una matriz de emisión, respectivamente. Las probabilidades de transición controlan la forma en que se elige el estado oculto en el tiempo t dado el estado oculto en el tiempo t-1.

[0035] Los modelos de filtro de Kalman pueden utilizar un algoritmo de estimación lineal cuadrática (LQE) que analiza una serie de mediciones observadas a lo largo del tiempo, que contienen ruido estadístico y otras imprecisiones, y produce estimaciones de variables desconocidas que tienden a ser más precisas que las basadas en una sola medición, mediante la estimación de una distribución de probabilidad conjunta sobre las variables para cada marco temporal. El algoritmo funciona en dos etapas. En la etapa de predicción, el modelo de filtro de Kalman produce estimaciones de las variables de estado actuales, junto con sus incertidumbres. Una vez que se observa el resultado de la siguiente medición (necesariamente corrompida con algún error, incluido el ruido aleatorio), estas estimaciones se actualizan utilizando una media ponderada, dando más peso a las estimaciones con mayor certidumbre. Como ejemplo de aplicación, consideremos el problema de determinar la ubicación exacta de un camión equipado con una unidad GPS que proporciona una estimación de la posición con una precisión de unos pocos metros (que probablemente contendrá ruido; las lecturas «saltan» rápidamente, aunque se mantienen a pocos metros de la posición real). Además, dado que se espera que el camión siga las leyes de la física, su posición también puede estimarse por cálculo aproximado integrando su velocidad en el tiempo, que se determina mediante el seguimiento de las revoluciones de las ruedas y el ángulo del volante, lo que normalmente proporcionará una estimación muy fluida de la posición del camión, pero se irá desviado con el tiempo a medida que se acumulen pequeños errores. En una fase de predicción, la posición anterior del camión se modificará de acuerdo con las leyes físicas del movimiento (el modelo dinámico o de «transición de estado»), calculándose una nueva estimación de la posición y una nueva covarianza. Posteriormente, en una fase de actualización, se toma una medición de la posición del camión desde la unidad GPS. Esta medición viene acompañada de cierta incertidumbre, y su covarianza en relación a la de la predicción de la fase anterior determina en qué medida la nueva medición afectará a la predicción actualizada. Idealmente, como las estimaciones a estima tienden a alejarse de la posición real, la medición del GPS debería volver a acercar la estimación de la posición a la posición real, pero sin perturbarla hasta el punto de que se convierta en un salto rápido y ruidoso.

[0036] Aunque las técnicas descritas se utilizan en algunas realizaciones para evaluar y predecir el probable estado del dispositivo informático y, opcionalmente, tomar las acciones correctivas correspondientes, las técnicas descritas se pueden utilizar de otras maneras en otras realizaciones. Algunos ejemplos no exclusivos de tales otros usos incluyen los siguientes: para predecir un probable aumento del riesgo o amenaza a la seguridad (por ejemplo, para un dispositivo informático cliente), como basándose en una secuencia de valores de estado de atributos observados para uno o más dispositivos u otras entidades (por ejemplo, usuarios de dispositivos) y opcionalmente, tomar las acciones correctivas correspondientes (por ejemplo, instituir la autenticación de 2 factores u otras medidas de seguridad mejoradas); predecir una probable acción futura de un dispositivo o de su usuario en un entorno comercial, como una tienda física, con base, por ejemplo, en una secuencia de valores de estado de atributos observados para el dispositivo y/o por el usuario y, opcionalmente, tomar las medidas correspondientes (por ejemplo, proporcionar información al dispositivo y/o al usuario para reforzar o inhibir la futura acción probable, activar o desactivar la funcionalidad o las capacidades disponibles para el dispositivo y/o el usuario, etc.); predecir una probable afección médica o u otro estado de un paciente, por ejemplo, basándose en una secuencia de valores de estado de atributos observados para el paciente y/o uno o más dispositivos relacionados con la salud utilizados por el paciente y, opcionalmente, tomar las acciones correctivas correspondientes (por ejemplo, informar a un profesional médico, proporcionar asesoramiento médico o relacionado con la salud u otra información, iniciar un procedimiento médico automatizado o relacionado con la salud, etc.); etc. El análisis de los valores de estado de los atributos observados para generar modelos de resultados para los resultados de estado relacionados con la seguridad puede incluir, por ejemplo, la observación del estado de los atributos de los dispositivos relacionados con posibles actividades relacionadas con la seguridad (como la ejecución de programas, las comunicaciones recibidas y/o enviadas, las descargas, las ubicaciones geográficas, las versiones y actualizaciones de programas, etc.) y/o la observación del estado de los atributos de los usuarios de los dispositivos relacionados con posibles actividades relacionadas con la seguridad (como los intentos de inicio de sesión, los cambios de contraseña, los sitios en línea visitados, etc.), y el análisis de tales valores de estado de atributo observados para grupos de dispositivos/usuarios con distintos tipos de resultados de estado, incluidos para determinar información de relación probabilística entre los valores de estado de atributo observados y múltiples estados de atributo no observados que afectan a dichos valores de estado de atributo observados. El análisis de los valores de estado de atributo observados para generar modelos de resultados para resultados de estado relacionados con futuras acciones de un dispositivo y/o usuario en un entorno comercial puede incluir, por ejemplo, la observación del estado de los atributos de dispositivo y/o usuario relacionados con actividades anteriores (como ubicaciones geográficas, sitios en línea visitados, comunicaciones recibidas y/o enviadas, descargas, ejecución de programas, versiones y actualizaciones de programas, compras de o indicaciones de interés en productos y/o servicios particulares, etc.) y el análisis de tales valores de estado de atributo observados para grupos de dispositivos/usuarios con distintos tipos de resultados de estado, incluida la determinación de información de relación probabilística entre los valores de estado de atributo observados y múltiples estados de atributo no observados que afecten a dichos valores de estado de atributo observados. El análisis de los valores de estado de atributo observados para generar modelos de resultados para los resultados de estado relacionados con la salud puede incluir, por ejemplo, la observación del estado de los atributos del dispositivo y/o paciente relacionados con actividades previas y otra información de salud (como ubicaciones geográficas, actividad física realizada, medicamentos que toma, síntomas observados, etc.) y el análisis de tales valores de estado de atributo observados para grupos de dispositivos/pacientes con distintos tipos de resultados de estado, incluida la determinación de información de relación probabilística entre los valores de estado de atributo observados y múltiples estados de atributo no observados que afectan a dichos valores de estado de atributo observados. Se apreciará que las técnicas descritas pueden emplearse para otros usos y de otras maneras en otras realizaciones.

[0037] La Figura 3 ilustra un diagrama de flujo de una realización ejemplar de una rutina de determinación de relaciones entre las operaciones de un dispositivo de gestión automatizada de operaciones (AOM) 300. La rutina puede realizarse, por ejemplo, mediante la ejecución del sistema AOM 140a y/o el sistema AOM 140b de la Figura 1 y/o un sistema utilizado para realizar las técnicas descritas con respecto a las Figuras 2A-2F, o como se expone en otra parte del documento. Aunque la realización ilustrada de la rutina corresponde a la generación de estructuras de datos de modelo de resultados para un único grupo de resultados de estado, se apreciará que, en otras situaciones y realizaciones, la rutina puede funcionar de otras maneras, incluida la generación de tales estructuras para múltiples grupos y tipos distintos de resultados de estado para un grupo de dispositivos cliente para los que está disponible información de entrenamiento, puede generar tales estructuras para otros tipos de resultados de estado (incluidos aquellos no relacionados con dispositivos cliente o fallos de dispositivo) en otros entornos, etc.

[0038] En la realización ilustrada, la rutina comienza en el bloque 310, donde se reciben instrucciones o información. La rutina continúa en el bloque 315 para determinar si las instrucciones o la información recibidas en el bloque 310 está destinada a generar modelos de resultados con estructuras de datos correspondientes para múltiples resultados de estado para un grupo de dispositivos informáticos cliente y resultados de estado que incluyen un resultado de estado de no fallo y uno o más resultados de estado de fallo y, en caso afirmativo, continúa en el bloque 320. En el bloque 320, se obtienen datos de entrenamiento para uno o más tipos de dispositivos informáticos cliente, incluidos datos sobre secuencias de valores de estado de atributo de dispositivo observados a lo largo del tiempo para dispositivos que posteriormente, alcanzan uno de los resultados de estado de fallo, y datos sobre secuencias de valores de estado de atributo de dispositivo a lo largo del tiempo para dispositivos que mantienen el resultado de estado de no fallo. Tales datos de entrenamiento pueden recibirse inicialmente en el bloque 310, o en cambio, la rutina del bloque 320 puede recuperar información almacenada o de otro modo interactuar con uno o más sistemas informáticos sobre los que estén disponibles tales datos de entrenamiento.

[0039] Después del bloque 320, la rutina continúa en el bloque 325 para analizar los datos de entrenamiento con el fin de determinar diversos tipos de información de relación probabilística para modelos de resultados para cada uno de los posibles resultados de estado, incluida la división del grupo de dispositivos informáticos cliente en un subgrupo para cada uno de los resultados de estado con dispositivos que alcanzan ese resultado de estado. El análisis incluye, para cada uno de los resultados de estado y su subgrupo asociado de dispositivos, un análisis de las secuencias de valores de estado de atributo de dispositivo observados a lo largo del tiempo para esos dispositivos a fin de determinar los efectos probabilísticos que tienen múltiples estados de atributo de dispositivo no observables en esos valores de estado de atributo de dispositivo observados, como para generar una matriz de emisión que proporcione estimaciones de probabilidades iniciales de la aparición de valores de estado de atributo de dispositivo observados particulares para cada estado de atributo de dispositivo no observable. El análisis incluye, además, la determinación de la probabilidad probabilística de que cada uno de los estados de atributo de dispositivo no observable esté presente en ausencia de otra información (por ejemplo, como estado inicial), como para generar una matriz de estado inicial, y, para cada uno de los estados de atributo de dispositivo no observable, de que ese estado de atributo de dispositivo no observable dé lugar a cada uno de los estados de atributo de dispositivo no observable en un momento posterior, como para generar una matriz de transición.

[0040] Después del bloque 325, la rutina continúa en el bloque 380 para almacenar la información de relación probabilística determinada para cada uno de los modelos de resultados, como en una o más estructuras de datos generadas, para su uso posterior en la identificación y predicción de estados de funcionamiento probables de otros dispositivos cliente.

[0041] Si, en cambio, se determina en el bloque 315 que las instrucciones o la información recibidas en el bloque 310 no están destinadas a generar modelos de resultados, la rutina continúa, en su lugar, en el bloque 390 para realizar una o más operaciones indicadas según corresponda. Tales otras operaciones pueden incluir, por ejemplo, la modificación o adaptación de un modelo de resultado previamente generado basándose en nuevos datos de entrenamiento, como ajustar la información probabilística a modelos de resultado existentes, o, en su lugar, para cambiar los modelos de resultado (por ejemplo, añadir uno o más nuevos modelos de resultado para nuevos resultados de estado) si procede. Además, otros tipos de operaciones indicadas pueden incluir la recepción y respuesta a diversos tipos de peticiones, como una petición para proporcionar un modelo de resultados generado o su información a uno o más solicitantes.

[0042] Después de los bloques 380 o 390, la rutina continúa en el bloque 395 para determinar si continuar, como hasta que se reciba una indicación explícita de terminar. Si se determina continuar, la rutina vuelve al bloque 310 y, en caso contrario, continúa en el bloque 399 y finaliza.

[0043] La Figura 4 ilustra un diagrama de flujo de una realización ejemplar de una rutina de determinación de modificación de operaciones de un dispositivo AOM 400. La rutina puede proporcionarse, por ejemplo, mediante la ejecución del sistema AOM 140a y/o el sistema AOM 140b de la Figura 1 y/o un sistema utilizado para realizar las técnicas descritas con respecto a las Figuras 2A-2F, o como se expone en otra parte del documento. Aunque la realización ilustrada de la rutina se realiza con respecto a un solo dispositivo cliente, en otras realizaciones puede realizarse, además, para múltiples dispositivos cliente.

[0044] La realización ilustrada de la rutina comienza en el bloque 405, donde se recuperan los modelos de resultados generados y su información de modelado probabilístico, cada uno de los cuales representa dispositivos que tienen un tipo indicado de resultado de estado. Posteriormente, la rutina continúa en el bloque 410 para obtener información sobre un dispositivo informático cliente para el que se pueden realizar una o más acciones de modificación, incluida la obtención de información sobre una secuencia de valores de atributos de dispositivo observados para el dispositivo cliente a lo largo del tiempo.

[0045] Posteriormente, la rutina continúa en el bloque 420 para utilizar, para cada uno de uno o más posibles resultados de estado de fallo, el modelo de resultados generado asociado a fin de evaluar la secuencia de valores de atributo de dispositivo observados para el dispositivo cliente y utilizarla para determinar una probabilidad de que el dispositivo cliente tenga ese tipo de resultado de estado de fallo, opcionalmente con una o más medidas indicadas de certeza o incertidumbre. A continuación, en el bloque 425, la rutina utiliza el modelo de resultados generado para el resultado de estado de no fallo a fin de evaluar la secuencia de valores de atributo de dispositivo observados para el dispositivo cliente y utilizarla para determinar una probabilidad de que el dispositivo cliente tenga ese tipo de resultado de estado de no fallo, opcionalmente con una o más medidas indicadas de certeza o incertidumbre. En el bloque 430, se comparan las probabilidades determinadas para los diversos resultados de estado con el fin de identificar y predecir al menos un probable resultado de estado próximo para el dispositivo cliente. La rutina selecciona, además, si la predicción de al menos un probable resultado de estado próximo para el dispositivo cliente implica un tipo de resultado de estado de fallo, al menos una acción de modificación que realizar en el dispositivo cliente en un intento de prevenir o de otro modo mitigar el probable resultado de estado próximo predicho, aunque en otras realizaciones, tales acciones de modificación pueden no realizarse (por ejemplo, si la información sobre el probable resultado de estado próximo predicho se proporciona, en cambio, a uno o más otros sistemas u otros destinatarios para que, opcionalmente, tomen las acciones correspondientes), y/o las acciones correspondientes pueden seleccionarse y realizarse aunque el probable resultado de estado próximo predicho sea un resultado de estado de no fallo.

[0046] Después del bloque 430, la rutina continúa en el bloque 450 para realizar una o más acciones de modificación seleccionadas en el dispositivo cliente, como la modificación de los ajustes de configuración del dispositivo cliente y/o de otros dispositivos asociados que realicen acciones que afecten al rendimiento del dispositivo cliente, el envío de comunicaciones a y/o desde el dispositivo cliente, etc. Además, en el bloque 450, la rutina puede medir opcionalmente los efectos (ya sean inmediatos o durante un período de tiempo, como minutos, u horas, o días, o semanas, o meses) en el dispositivo cliente de la realización de una o todas las acciones de modificación realizadas, como para su uso en la adaptación o actualización posterior de la información almacenada que coincida con qué acción o acciones de modificación realizar para qué resultados de estado similares predichos, etc.

[0047] Después del bloque 450, la rutina continúa en el bloque 495 para determinar si continuar, como hasta que se reciba una indicación explícita de terminar. Si se determina continuar, la rutina vuelve al bloque 410 para obtener información sobre el siguiente dispositivo informático cliente que evaluar y, de lo contrario, continúa en el bloque 499 y finaliza. Aunque no se ilustra, los cambios en el modelo de resultados (ya se trate de nuevos modelos de resultados y/o de cambios en los modelos de resultados existentes) también pueden obtenerse durante la operación de la rutina y utilizarse para la posterior evaluación de los dispositivos cliente.

[0048] Además, en al menos algunas realizaciones, la predicción de un probable resultado de estado para un dispositivo cliente y, opcionalmente, la posterior ejecución de una acción relacionada puede realizarse, en parte o en su totalidad, en respuesta a una solicitud, como una solicitud del dispositivo cliente (o de un usuario del dispositivo cliente), de otro dispositivo que interactúe con el dispositivo cliente, etc. En al menos algunas de tales realizaciones, la predicción y/o la acción resultante pueden realizarse en tiempo real o casi real o de otro modo sustancialmente inmediatamente después de la solicitud (por ejemplo, en milisegundos, en un segundo, en segundos, en minutos, etc.). Además, la predicción y/o ejecución de la acción resultante pueden, en algunas realizaciones, realizarse basándose, al menos en parte, en información específica del dispositivo cliente (incluido, opcionalmente, un usuario del dispositivo cliente), como para personalizar y/o adaptar la predicción y/o ejecución de la acción resultante al dispositivo cliente (incluido, opcionalmente, al usuario). Dicha adaptación y/o personalización puede realizarse de varias maneras, como para ponderar el estado de resultado predicho para un dispositivo cliente a fin de reflejar información específica del dispositivo (por ejemplo, para aumentar o reducir la probabilidad de un resultado de estado particular, para modificar cómo se ejecuta una acción resultante, etc.) y como para utilizar la configuración existente del dispositivo u otra información específica del dispositivo (por ejemplo, preferencias especificadas para el dispositivo y/o el usuario del dispositivo) para la ponderación. Además, en al menos algunas realizaciones, la predicción y/o ejecución de la acción resultante pueden producirse antes o después de que se proporcione una notificación correspondiente (por ejemplo, al dispositivo cliente, a un usuario del dispositivo cliente, a otro destinatario especificado, etc.), incluidas algunas realizaciones en las que la notificación se realiza antes de la acción, en las que el sistema AOM espera a realizar la acción hasta que se reciba una confirmación correspondiente u otra afirmación de la acción (por ejemplo, del dispositivo, del usuario del dispositivo, etc.).

[0049] Como se señaló anteriormente, un modelo de resultados puede generarse y utilizarse de diversas maneras, incluido basándose en una variedad de atributos del dispositivo, y con respecto a diversos tipos de acciones resultantes. A continuación, se incluyen ejemplos no exclusivos de generación y uso de modelos de resultados con la inclusión de diversos detalles incluidos a título de ejemplo, incluidos los modelos de resultados en ocasiones denominados modelos de churn o tasa de abandono. Cualquiera de las técnicas descritas en los siguientes ejemplos puede utilizarse de forma similar para otros tipos de modelos de resultados anteriormente descritos. No obstante, se apreciará que las técnicas descritas no se limitan a los detalles que se exponen a continuación, a menos que se indique lo contrario.

[0050] En general, el churn indica un abonado que ha dejado de utilizar el servicio por completo y es poco probable que vuelva: la pérdida de un abonado. Por lo tanto, las innovaciones objeto de esta solicitud están dirigidas a predecir si un abonado tiene probabilidades de abandonar, pero aún no ha dejado de utilizar el producto o servicio.

Como se expone en la presente solicitud, determinar el abandono de un cliente una vez que el abonado ha alcanzado el punto de no retorno tiene poco valor: por lo tanto, los modelos objeto de esta solicitud están dirigidos a interactuar con dicho abonado antes de que deje de utilizar el producto o servicio del operador y, con suerte, retenerlo. Así pues, el churn puede definirse como una reducción de la actividad a largo plazo. La definición específica de lo que constituye «a largo plazo» y «reducción» puede variar en distintas realizaciones. Para determinar si la actividad ha disminuido, se calcula el nivel de actividad de un abonado durante un plazo de tiempo anterior a una fecha dada y, de nuevo, durante un plazo posterior a esta fecha. Si el nivel de actividad en el primer período cumple ciertos criterios (por ejemplo, excede un cierto umbral o contiene un evento distintivo, como una recarga considerable), se determina que el abonado ha estado activo recientemente y, si el nivel de actividad en el segundo período cumple otros criterios (por ejemplo, está por debajo de otro umbral o contiene un evento distintivo, como la realización del proceso de portabilidad del número de teléfono para sacarlo de la red del operador), se determina que la actividad ha disminuido y se dice que el abonado ha abandonado.

[0051] Una de las realizaciones del modelo de churn que se describe en esta solicitud es un modelo dinámico de espacio de estados realizado en el marco de un modelo de Markov oculto (HMM, por sus siglas en inglés). Un HMM es un modelo para producir secuencias con determinadas propiedades estadísticas. Esta realización del modelo de churn se basa en producir un par de HMM, uno que produzca secuencias típicas de los sucriptores que abandonan y otro, de los que no abandonan. Para determinar si un abonado corre riesgo de abandonar, se construye una secuencia de comportamiento para dicho abonado, que se evalúa con respecto a ambos HMM para determinar cuál es el generador más probable de la secuencia.

[0052] Una realización puede incluir, además, más de un par de HMM si los pares de churn/no churn se entrenan para distintos segmentos disjuntos de la población global. Las definiciones de segmento pueden, por ejemplo, adoptar la forma de criterios sobre los abonados, por ejemplo, un intervalo de permanencia, en lugar de una lista estática de abonados, ya que la propia base de usuarios es dinámica: los abonados entran o salen de un segmento simplemente debido a la creación de nuevas cuentas y a la cancelación de cuentas existentes con un operador. Además, pueden existir múltiples variantes de los pares de churn/no-churn para cualquier segmento dado de la base de abonados porque los modelos de churn pueden estar altamente parametrizados, por ejemplo, permitiendo múltiples definiciones de churn. En tales casos, un abonado recibiría múltiples puntuaciones de churn, una de cada variante. Además, puede resultar útil ejecutar múltiples variantes de los modelos de churn en producción, ya que existen múltiples usos para sus resultados. En cualquier caso, la jerarquía de modelos de churn puede utilizarse para rastrear pares HMM individuales de churn/no-churn para múltiples segmentos de la base total de abonados de un proveedor de telecomunicaciones. La segmentación (también conocida como partición, ya que, normalmente, sería completa y desunida) puede lograrse mediante métodos de aprendizaje no supervisados (por ejemplo, agrupación en clústeres K-means) utilizando datos contextuales estáticos (o que cambian lentamente) (por ejemplo, información demográfica) o datos de comportamiento (es decir, datos similares, pero quizás distintos, de los datos utilizados para construir los HMM), o cualquiera de una variedad de otros mecanismos. Una única instancia del «modelo de churn» puede ser, en realidad, una instancia de la jerarquía de modelos de churn e incluir definiciones de segmentos y pares HMM de churn/no churn asociados. Esta instancia jerárquica del modelo de churn produce una única puntuación de churn para cada abonado, ya que la asignación de segmento del abonado determina de forma única el par HMM que produce la puntuación. También pueden configurarse múltiples modelos de churn para su aplicación a abonados de un mismo segmento introduciendo variantes en la configuración de los parámetros. Esto permite, por ejemplo, evaluar por separado el riesgo de abandono a corto y a largo plazo. En este caso, múltiples variantes del modelo pueden generar puntuaciones de churn independientes para cada abonado (una por variante). Además, los modelos de churn pueden utilizarse para rastrear pares HMM individuales de churn/no churn para múltiples versiones del mismo (o casi el mismo) segmento y configuración de parámetros. Por lo tanto, en una realización, las versiones anteriores de un modelo de churn pueden mantenerse para garantizar un despliegue fluido y permitir un retroceso cuando sea necesario. En este caso, múltiples variantes del modelo pueden generar puntuaciones de churn independientes para cada abonado (una por variante).

[0053] Los modelos de churn descritos se basan en una secuencia de acciones realizadas por un abonado. En una realización, la secuencia incluye mediciones diarias de las acciones de los abonados durante un plazo de tiempo predeterminado. Las acciones del abonado se definen mediante un conjunto selecto de atributos extraídos directamente del esquema común o de valores derivados de mediciones básicas del esquema común. Los datos se representan diariamente, en una realización, para proporcionar una alta resolución para la que suele estar disponible toda la gama de datos comunicados por el operador. No obstante, también podrían utilizarse representaciones de mayor resolución (por ejemplo, cada 5 minutos) o de menor resolución (por ejemplo, semanales) (aunque en el límite, un engrosamiento significativo reduce el enfoque del modelado del espacio de estados a uno equivalente a las técnicas estándar).

[0054] Un nivel de actividad es una medida del uso que un abonado hace del producto y/o servicio de un operador. Para calcular el nivel de actividad pueden utilizarse muchas fuentes de datos y métodos distintos. Algunas de las medidas de actividad pueden basarse en el estado comunicado por un operador. No obstante, se observa que al menos algunos estados comunicados por los operadores se retrasan significativamente con respecto al momento en que un abonado realmente reduce la actividad. Incluso en estos casos en los que el estado comunicado por el operador se retrasa, el modelo de churn puede emplear datos alternativos de baja latencia.

- Definición de nivel de actividad 1: Umbral de promedio temporal del estado comunicado por el operador Tal y como se utiliza en esta solicitud, este nivel de actividad se define como un porcentaje de días en los que un abonado se encuentra en estado ACTIVO durante un plazo histórico determinado. Por ejemplo, para considerarse un abonado activo, un abonado podría necesitar tener el estado ACTIVO durante el 80 % de los días durante las seis semanas anteriores. Cabe señalar, no obstante, que también pueden utilizarse otros valores.

- Definición de nivel de actividad 2: Tendencia decreciente en el promedio temporal del estado comunicado por el operador Este nivel de actividad se define como la tasa (o aproximación apropiada) a la que cambia el estado comunicado por el operador durante un plazo histórico determinado. En este caso, un abonado activo es aquel cuya tasa supera un umbral. Por ejemplo, supongamos que un abonado ha estado activo al 50 % durante tres semanas y al 100 % durante tres semanas. La tasa de actividad está aumentando y el abonado se consideraría activo. Compárese lo dicho con la definición de nivel de actividad 1, según la cual el abonado estaría por debajo del nivel del 80 % durante el período de seis semanas y, por lo tanto, inactivo. Cabe señalar que esta definición no equivale a un nuevo umbral del 75 % durante seis semanas, ya que el orden de los acontecimientos también es relevante: primero baja actividad y luego, alta. Por lo tanto, los mismos valores de este ejemplo, pero en orden inverso, podrían indicar una actividad decreciente y un abonado potencialmente inactivo.

- Definición de nivel de actividad 3: Umbral de promedio temporal de los datos de uso y cuenta Este nivel de actividad se define como el porcentaje de días que un abonado cumple determinados objetivos de uso de la cuenta o del servicio durante un plazo histórico determinado. Por ejemplo, para considerarse un abonado activo, un abonado debería haber recargado la cuenta el 10 % de los días del plazo y haber utilizado el servicio de voz en un dispositivo móvil durante el 90 % de los días del mismo plazo. Puede seleccionarse cualquier combinación de atributos de esquema comunes, y la duración del plazo puede ajustarse para cada operador. Además, en lugar de un porcentaje de días en que se utilizó un servicio, podría establecerse un umbral de cantidad de uso (por ejemplo, un total de 20 o más mensajes SMS durante todo el plazo histórico).

- Definición de nivel de actividad 4: Agrupación de estados comunicados por el operador filtrados mediante wavelets de paso bajo La agrupación basada en coeficientes wavelet de baja frecuencia produce resultados de calidad similar al enfoque de umbral de la definición 1, pero tiene la ventaja de la detección automática y eficaz de umbrales. Una serie temporal del estado comunicado por el operador puede ser una función constante a trozos, ya que el estado puede, en algunas realizaciones, cambiar como máximo diariamente, y puede adoptar uno de unos pocos valores finitos. Además, cambia con poca frecuencia cuando se representa como un valor diario. Por lo tanto, en una realización, puede representarse exactamente con wavelets de Haar. En primer lugar, la transformada wavelet se realiza sobre la serie temporal diaria del estado comunicado por el operador. Los componentes de alta frecuencia se ponen a cero (es decir, se aplica un filtro de paso bajo). Dado que, en una realización, puede ser deseable agrupar las series temporales basándose en los componentes de baja frecuencia, no es necesario aplicar la transformada inversa. El puñado de coeficientes wavelet restantes puede utilizarse para representar la secuencia y puede aplicarse la agrupación en clústeres K-means a las secuencias de un conjunto representativo de abonados. En algunas realizaciones, puede haber cuatro agrupaciones cualitativamente distintas de abonados que puedan describirse cualitativa (o informalmente) como: siempre activo, parcialmente activo, siempre inactivo y en abandono progresivo. Establecer el número de centroides en valores superiores a cuatro tiende a refinar los grupos dentro de estos conglomerados, pero podría no producir agrupaciones cualitativamente nuevas.

- Definición de nivel de actividad 5: Definiciones de actividad basadas en reglas Las definiciones anteriores se han basado en una medida de actividad que supera un determinado umbral; sin embargo, también puede resultar útil emplear definiciones basadas en reglas que determinen la actividad en función de determinados acontecimientos o criterios. Muchos operadores emplean este tipo de definiciones para determinar el estado comunicado por el operador utilizado en la anterior Definición de nivel de actividad 1, por ejemplo, definiendo a un abonado como activo si ha recargado su cuenta con un importe determinado en los últimos días (donde, además, el número de días depende del importe). Otros ejemplos incluyen marcar a un abonado inmediatamente como inactivo en caso de que el abonado realice el proceso de portabilidad de una línea a otro operador, independientemente de otra actividad reciente en la cuenta. También son posibles muchas otras variaciones.

- Definición de nivel de actividad 6: Combinación de niveles de actividad básicos

Otra forma de determinar el nivel de actividad es combinar dos o más de las definiciones anteriores. Por ejemplo, utilizar un umbral de tasa junto con un umbral de actividad: para considerarse activo, un abonado debe tener un nivel de actividad básico del 25 % y una tasa de actividad constante o creciente. También pueden emplearse otros enfoques.

[0055] En una realización, el modelo de churn sólo se aplica a los abonados activos. No es necesario aplicar el modelo a los abonados que no tienen ninguna actividad de cuenta reciente. Además, si se retuviese a los abonados inactivos durante el entrenamiento del modelo, disminuiría la calidad esperada del modelo. En cualquier caso, añadir un número significativo de datos con poca información al conjunto de entrenamiento aumentaría innecesariamente el gasto computacional (medido en tiempo o recursos computacionales) necesario para entrenar el modelo. Por lo tanto, se aplica un filtro de suscriptores activos basado en las definiciones de nivel de actividad. Un ejemplo típico es el uso de la definición de nivel de actividad 1: El umbral se realiza sobre el promedio temporal del estado comunicado por el operador con las últimas cuatro a seis semanas de actividad y un umbral entre el 70 % y el 90 %. El nivel de actividad se calcula para los abonados con una secuencia de comportamiento completa. Si un abonado se une a o abandona la red durante el intervalo que define la secuencia de comportamiento, dicho abonado será excluido por el filtro. En particular, esto se indica cuando un abonado entra en los estados preactivo o de enfriamiento en cualquier momento durante el intervalo de la secuencia de comportamiento. Por ejemplo, supongamos la definición de nivel de actividad 1: Se utiliza el umbral de promedio temporal del estado comunicado por el operador con un plazo de 30 días y un umbral del 80 %. Si un abonado está ACTIVO durante los primeros 29 días, pero posteriormente entra en estado de ENFRIAMIENTO el día 30, dicho abonado es rechazado por el filtro aunque cumpla el criterio del 80 %. Los patrones de este tipo (sin periodo de inactividad antes del enfriamiento) se producen y son un indicador de churn activo: por ejemplo, si el abonado ha realizado la portabiliad de su número a otra red y se lo ha comunicado al operador.

[0056] El uso de modelos de espacio de estados ofrece ventajas sobre los intentos de representar el comportamiento del abonado como un conjunto no secuencial de características, representando el modelo de espacio de estados explícitamente una secuencia de acontecimientos. Por ejemplo, si un abonado solo realiza llamadas poco después de recargar, un modelo de espacio de estados captaría este orden de acontecimientos y su importante relación por diseño. Al construir un modelo de espacio de estados, el estado del abonado no suele ser algo que pueda medirse directamente. No se recoge explícitamente en los datos de un operador. En cambio, se espera observar los efectos secundarios del estado de un abonado, por ejemplo, las llamadas realizadas o la actividad de recarga. Por lo tanto, el estado del abonado se considera «oculto» y se deduce de su comportamiento. Como ya se ha mencionado, los modelos de churn que se exponen en esta solicitud se basan en el marco del modelo de Markov oculto (HMM). Este enfoque aplica determinados supuestos al conjunto más general de modelos de espacio de estados. En particular, un supuesto del marco HMM consiste en que las transiciones de estado forman un proceso de Markov y las secuencias de observaciones representan acontecimientos generados por un abonado en un estado determinado. Utilizando las secuencias observadas de muchos abonados, se puede deducir el conjunto más probable de parámetros del modelo que han generado las observaciones (es decir, entrenar el modelo). Una vez identificado un modelo, se puede calcular la probabilidad de que genere una determinada secuencia observada. A partir de modelos distintos, uno construido para reconocer a los churners y otro para los no churners, se puede determinar si la actividad reciente de un abonado es más representativa de uno u otro grupo (es decir, utilizar el modelo en producción). Se puede emplear cualquiera de una variedad de mecanismos para derivar el HMM.

[0057] A continuación, se ofrece un ejemplo para su uso con un modelo de Markov oculto, en el que la siguiente notación se utiliza para representar los elementos de un HMM:

N, el número de estados

M, el número de símbolos observables distintos

qt, el estado oculto en el tiempo t

S = {Si}, el conjunto discreto de estados

V = {vk}, el conjunto discreto de observables

A = {ay}, matriz de probabilidad de transición de estado. Los elementos de la matriz de probabilidad de transición se definen de la siguiente manera en la Ecuación (1):

B = {bj(k)}, es la distribución de símbolos observables para un estado dado, cuyos elementos vienen dados por la Ecuación (2):

n, la distribución inicial de estados, viene dada de la siguiente manera por la Ecuación (3):

A, el conjunto completo de parámetros que especifican un HMM concreto, alternativamente denominado «modelo». Incluye A, B y n, como se definió anteriormente.

[0058] Para emplear el modelo de churn, es necesario realizar las siguientes tareas básicas para cada HMM:

- Dados una secuencia observada y un HMM completamente especificado, calcular la probabilidad de la secuencia según el HMM, como parte de la generación de una predicción.

- Dado un conjunto de secuencias observadas, determinar los parámetros del modelo que maximicen la probabilidad de las observaciones. El entrenamiento del modelo emplea este enfoque para especificar por completo cada HMM.

[0059] Un proceso para entrenar modelos de Markov ocultos (HMM) de churn y no churn puede comenzar con la recepción de datos de clientes/abonados. Los datos de abonados pueden extraerse de un conjunto representativo de datos de un proveedor de servicios. En una realización, los datos recibidos son datos sin procesar del conjunto de datos del proveedor de servicios (aunque los datos también pueden recibirse de otras fuentes, por ejemplo, los datos de comportamiento suministrados por el proveedor podrían aumentarse con publicaciones de redes sociales de acceso público). Pueden realizarse diversos procesamientos front-end de los datos, en los que los datos sin procesar pueden analizarse y asignarse a un esquema común. El procesamiento front-end también puede incluir la asignación de abonados a segmentos de la base de abonados si la base de abonados se ha dividido. Antes de realizar el entrenamiento con los datos, se realizan una serie de etapas de preparación de los datos. Se realizan las mismas etapas de preparación de datos (incluido el filtrado de abonados activos) tanto para el entrenamiento del modelo como para el uso del modelo en funcionamiento. La preparación de los datos incluye 1) la selección de abonados activos con el filtro de abonados activos, 2) la construcción de secuencias de observaciones de comportamiento para los abonados activos y 3) la determinación de una etiqueta de churn para el entrenamiento del modelo y (una vez transcurrido el tiempo suficiente para que esté disponible) la supervisión del rendimiento operativo del modelo. Para el entrenamiento y calibración del modelo, los datos preparados se dividen en conjuntos independientes para entrenamiento, prueba y validación. Además, los conjuntos de entrenamiento y prueba pueden ser, en realidad, un único conjunto de entrenamiento/prueba para su uso con un enfoque de validación cruzada para la determinación del modelo. La validación cruzada es un proceso en el que se eligen repetidamente al azar conjuntos separados de entrenamiento y prueba de un conjunto unido de entrenamiento y prueba y se entrenan muchos modelos candidatos para proporcionar información sobre (y, además, reducir) el sesgo inducido por una elección particular de conjuntos de entrenamiento y prueba.

[0060] A continuación, se aplica el filtro de abonados activos con el fin de identificar a todos los abonados que se ajustan a la definición de activo elegida basándose en uno de los métodos anteriormente detallados para determinar los niveles de actividad. Para el entrenamiento del modelo, las fechas no solo se encuentran en el pasado, sino en un pasado lo suficientemente lejano como para disponer de un registro histórico de la sección de «futuro», es decir, un plazo de tiempo posterior al plazo de abonado activo durante el cual se determina que han abandonado los abonados con baja actividad. Esto permite conocer los resultados de churn/no churn de los individuos en el momento del entrenamiento. Se realizan otras acciones de preparación de datos, incluida la construcción de secuencias de comportamiento, y se construyen series temporales diarias de comportamiento de los abonados a partir de atributos de esquemas comunes. A la hora de construir las secuencias, se tienen en cuenta varias consideraciones. Una de ellas es la selección de las características de interés. Para mejorar la calidad y solidez del modelo (en parte equilibrando la cantidad de datos de entrenamiento disponibles y la complejidad del modelo y en parte, basándose principalmente en datos que se espera que estén disponibles en una amplia gama de operadores), solo se utilizan unos pocos atributos de esquema comunes seleccionados. Para determinar qué características utilizar, se construyen y prueban muchos modelos potenciales. Se seleccionan los modelos con el mejor rendimiento y las características asociadas a ellos. La determinación de «mejor» no implica simplemente seleccionar las características que aparecen en el candidato único con mejores resultados, sino seleccionar características comunes a varios de los modelos con mejores resultados. Es decir, las características se seleccionan tanto por su rendimiento absoluto como por su solidez. A continuación, se enumeran los métodos para medir la calidad de los modelos.

[0061] Dependiendo de la característica en cuestión, puede ser deseable agregar varios acontecimientos discretos para asignar los datos a una secuencia diaria utilizada por el modelo. Por ejemplo, una serie temporal de acontecimientos individuales de duración de llamadas puede transformarse en una variable diaria sumando todas las duraciones de llamadas que se produzcan para obtener una duración total diaria para cada día de la secuencia de días en cuestión. Las variables también pueden agregarse por recuento y por cantidad (por ejemplo, el número de llamadas en un día frente al tiempo total al teléfono en un día). Si no hay actividad en un día determinado, una de dos acciones es típica. Para los atributos de uso, como la duración de la llamada o el importe de la recarga, el valor agregado diario puede ponerse a cero. Para los atributos de cambio de estado, como la serie temporal de actualizaciones de estado comunicada por el operador, el valor del atributo persiste entre los acontecimientos de la serie temporal: si un abonado pasó a ser ACTIVO el lunes y a INACTIVO el viernes, el valor del abonado el miércoles sería ACTIVO, aunque no se comuniquen datos el miércoles en el esquema común (es decir, «sin datos» implica «sin cambios»).

[0062] Algunas características pueden derivarse de los datos del esquema común. La más destacada es la que mide la actividad total generadora de ingresos. La actividad generadora de ingresos representa la suma total de todas las acciones generadoras de ingresos realizadas por un abonado. Normalmente, consiste en de llamadas salientes y SMS, además de todo el uso de datos. También pueden existir otras acciones generadoras de ingresos (por ejemplo, la compra de un tono de llamada). Para agregar actividades de distintos tipos, en particular llamadas a SMS a datos (y así sucesivamente), cada tipo de acción se mide por la cantidad de ingresos que genera (por ejemplo, los importes reales en dólares asociadas a cada acción). Otra característica derivada podría incluir una actividad aproximada generadora de ingresos. Es decir, también puede resultar eficaz utilizar importes aproximados en dólares en lugar de importes precisos en dólares. Por ejemplo, se establece una unidad artificial según la cual 10 SMS = 1 minuto de llamada = 10kb de datos.

[0063] A continuación, se ofrece una lista no limitativa ni exhaustiva de características típicas que pueden ser de interés para su uso dentro de los modelos de churn:

- Estado comunicado por el operador

- Actividad de recarga

- Actividad generadora de ingresos (exacta o aproximada)

- Atributos de redes sociales (en una realización, derivados de registros de datos de llamadas para interacciones de voz y SMS). Algunos ejemplos son el tamaño de una red de ego o los atributos individuales del abonado promediados sobre la red de ego (por ejemplo, ARPU medio, nivel medio de actividad, actividad media generadora de ingresos). Cuando se calculan los valores sobre la red de ego, resulta útil identificar y filtrar los números automáticos (por ejemplo, centros de llamadas, números 800). Estos se identifican directamente a partir de una lista de números conocidos o se descubren mediante el análisis de la red (por ejemplo, tales números suelen conectar con cientos de miles o millones de abonados, muchos más de los que una persona podría contactar físicamente).

[0064] Muchos atributos comunes del esquema pueden adoptar un continuo de valores, por ejemplo, la duración diaria de las llamadas de voz. El modelo de churn, en una realización, se basa en un HMM discreto en el que se supone que los valores observados en la secuencia diaria proceden de un conjunto discreto. Por lo tanto, las características continuas pueden discretizarse para utilizar un HMM discreto (otras realizaciones pueden basarse en HMM continuos). En muchos casos, las variables continuas se asignan a uno de dos intervalos: cero o distinto de cero. Esto se utiliza para variables relacionadas con el consumo, como la duración de las llamadas o el importe diario de recarga. También puede aplicarse a características discretas que pueden adoptar muchos valores, como el recuento de SMS. Este esquema de discretización indica, diariamente, si un abonado ha utilizado o no un determinado servicio. En ocasiones, resulta útil cuantificar mejor los valores distintos de cero añadiendo más intervalos al esquema de discretización. Se puede reservar un intervalo para el uso cero (que posiblemente incluya los datos que faltan o se puede reservar un segundo intervalo para los datos que faltan si los datos que faltan no se asignan a un valor estándar) y los intervalos restantes se determinan calculando los cuantiles sobre los datos restantes (después de eliminar todos los ceros). Por ejemplo, si se especifican tres intervalos, uno está destinado a los valores cero, otro, a los valores distintos de cero por debajo de la mediana de los datos restantes y el tercero, a los valores por encima de la mediana. Esto caracteriza el uso de los abonados como cero, bajo o alto. La determinación del mejor esquema de discretización forma parte del proceso de selección de características anteriormente descrito y dependerá en parte del tamaño del conjunto de entrenamiento (para obtener resultados sólidos a partir de un conjunto de datos más pequeño, se necesita un modelo más sencillo y, por tanto, menos intervalos).

[0065] Para determinar los cuantiles de los datos distintos de cero, puede utilizarse uno de los dos enfoques siguientes: normalización individual y normalización de grupo. En la normalización individual, los cuantiles se calculan para cada abonado. Supongamos que se utiliza el esquema de tres intervalos anteriormente descrito. Al normalizar sobre una base individual, una actividad alta significa alta para el individuo; un importe fijo puede corresponder a una actividad alta para un abonado y baja para otro. En cambio, cuando se utiliza la normalización por grupos, los cuantiles se calculan para toda la población; una alta actividad es una actividad elevada para todos los abonados. La normalización individual puede utilizarse junto con la normalización de grupo cuando interesa crear una secuencia que sea representativa del comportamiento de un individuo: una persona que gasta mucho y reduce el gasto total puede suponer un mayor riesgo de churn que una persona que gasta poco, pero de forma constante.

[0066] En los casos en los que faltan datos que deberían estar disponibles, los datos que faltan pueden tratarse de diversas maneras. Por ejemplo, lo normal es que solo se registren los valores de los atributos cuando cambia el valor, por lo que, para un abonado determinado en un día determinado, puede no haber registro de un atributo específico. Para tratar los datos ausentes, se pueden interpolar los valores para crear una secuencia diaria como se detalló anteriormente. En otro caso, la ausencia de un valor indica que no se ha producido ninguna actividad (por ejemplo, ninguna recarga en un día concreto). Una posible causa de la ausencia de datos es una interrupción en la ingesta de datos del operador. Este tipo de interrupción puede indicarse por un amplio vacío en los datos recogidos durante la interrupción. Supongamos que hay una interrupción del servicio de un día. Dado que los valores utilizados son discretos, un procedimiento que puede emplearse (y que suele utilizarse como solución alternativa cuando fallan otros) es la introducción de un nuevo valor para la variable que indica la falta (por ejemplo, añadir un cuarto intervalo al ejemplo anterior para obtener: falta, cero, bajo y alto). Puede que también sea posible hacer estimaciones razonables de otros valores en estos casos, pero esto se decide característica por característica. Por ejemplo, en los datos de series temporales activadas por acontecimientos, como las actualizaciones de estado, es posible que se haya producido un cambio de estado en el día que falta, pero que no se haya registrado (esto podría dar lugar a incoherencias en la serie temporal, como dos valores ACTIVOS consecutivos, cuando debería haberse registrado un valor INACTIVO en el día que falta). No obstante, los cambios de estado son relativamente poco comunes, por lo que, en general, resulta razonable conservar el último valor registrado en estos casos (es decir, suponer que las incoherencias debidas a una breve interrupción del servicio son de corta duración y, por lo tanto, tienen una repercusión demasiado limitada sobre el rendimiento como para justificar una corrección adicional).

[0067] Para el entrenamiento y supervisión del modelo, se desea determinar qué abonados son churners y cuáles no. Esto es posible una vez transcurrida una cantidad suficiente de tiempo tras el intervalo para el que se determinó la secuencia de comportamiento. El modelo de churn es una herramienta de comparación de patrones. Los modelos HMM resultantes no se utilizan para calcular directamente las acciones futuras de los abonados, sino que se calculan HMM independientes para dos grupos: los abonados que posteriormente abandonaron y los que no. La secuencia de etiquetas se utiliza para determinar qué abonados pertenecen a cada grupo. Para determinar qué abonados son churners en los datos históricos, el nivel de actividad se calcula a partir de la secuencia de etiquetas de forma similar a la utilizada en el filtro de abonados activos (posiblemente se utilicen diferentes definiciones de nivel de actividad). Los churners son aquellos abonados cuyo nivel de actividad cumple ciertos criterios, por ejemplo, está por debajo de un umbral establecido, o abonados que entran en estado preactivo o de enfriamiento durante el intervalo de la secuencia de etiquetas. Por lo tanto, los churners son abonados anteriormente activos (que pasaron por el filtro de abonados activos), pero que ya no lo están.

[0068] Se incluyen detalles adicionales relativos a la generación y el uso de modelos de resultados, incluido con respecto a otros tipos de dispositivos y/u otros tipos de resultados de estado (por ejemplo, el envío de mensajes a los dispositivos para provocar cambios en el comportamiento del dispositivo y/o en el comportamiento de los usuarios de los dispositivos) en la solicitud de EE. UU. N.° 15/649,393, depositada el 13 de julio de 2017 y titulada «Dynamic State-Space Modeling Based On Contextual And Behavioral Factors», que es una continuación de la solicitud de EE. UU. N.° 14/596,764, depositada el 14 de enero de 2015. Además, en algunas realizaciones, los términos «proveedor de servicios de red», «telecomunicaciones», «telecom», «proveedor», «operador» y «operadora» pueden utilizarse indistintamente para referirse a un proveedor de cualquier medio, producto, servicio, contenido y/o aplicación de telecomunicaciones basados en red, ya incluya o sea independiente del medio de transporte físico que puedan emplear los medios, productos, servicios, contenidos y/o aplicaciones de telecomunicaciones. Por lo tanto, las referencias a «productos/servicios» o similares pretenden incluir productos, servicios, contenidos y/o aplicaciones, y no debe interpretarse que se limitan meramente a «productos y/o servicios». Además, en algunas realizaciones, los términos «optimizado» y «óptimo» se refieren a una solución que se determina para proporcionar un resultado que se considera más cercano a un criterio o límite definido dadas una o más restricciones a la solución.

Por lo tanto, una solución se considera óptima si proporciona el resultado más favorable o deseable, dada alguna restricción, en comparación con otras soluciones determinadas, siendo por tanto una solución óptima una solución seleccionada de entre un conjunto de soluciones determinadas. Además, en algunas realizaciones, el término «mensaje» se refiere a un mecanismo de transmisión de datos que puede incluir información sobre una opción disponible, que normalmente está incrustada dentro de un mensaje con una variedad de atributos (por ejemplo, cómo se presenta el mensaje; cuándo se presenta el mensaje; el mecanismo por el que se presenta la opción disponible, por ejemplo, basándose en un tipo de red o servicio de comunicaciones; grupos o colecciones de otros atributos; un tono de voz; una urgencia; etc.). En tales realizaciones, la opción disponible puede referirse, además, a un producto, servicio, contenido y/o aplicación de un proveedor de servicios de red, y puede proporcionarse y/o presentarse utilizando cualquiera de una variedad de mecanismos (y, opcionalmente, ser independiente del mecanismo). Además, en algunas realizaciones, el término «medida de característica» se refiere a un resultado de una acción (o no acción) que debe medirse y/o afectarse basándose en alguna entrada. Además, en algunas realizaciones, el término «usuario» puede utilizarse para referirse a una entidad que ha tomado o se prevé que, en el futuro, tome una decisión con respecto a un producto, servicio, contenido y/o aplicación de otra entidad y, en algunas situaciones, puede incluir no solo a un individuo, sino también a empresas, organizaciones o similares.

Los expertos en la materia apreciarán que, en algunas realizaciones, cada uno de los diversos sistemas y módulos descritos pueden realizar funcionalidades que pueden expresarse en una o más rutinas, como la realización de diversas etapas u operaciones de diversas maneras (por ejemplo, en serie o en paralelo, de forma sincrónica o asincrónica, en un orden particular, etc.). Los expertos en la materia también apreciarán que las estructuras de datos anteriormente expuestas pueden estructurarse de diferentes maneras, como tener una única estructura de datos dividida en múltiples estructuras de datos o tener múltiples estructuras de datos consolidadas en una única estructura de datos. Del mismo modo, en algunas realizaciones las estructuras de datos ilustradas pueden almacenar más o menos información que la descrita, como cuando otras estructuras de datos ilustradas carecen o incluyen dicha información respectivamente, o cuando se altera la cantidad o los tipos de información almacenada.

[0069] De lo anterior se apreciará que, aunque en esta solicitud se han descrito realizaciones específicas con fines ilustrativos, pueden efectuarse diversas modificaciones sin apartarse del alcance de la invención, como se define únicamente en las reivindicaciones. Por consiguiente, la invención no está limitada excepto por las reivindicaciones correspondientes y los elementos que en ellas se enumeran. Además, aunque determinados aspectos se han expuesto en términos específicos, como para ser descritos como procesos y/o sistemas y/o en ocasiones puedan presentarse en ciertas formas de reivindicación, los inventores contemplan los diversos aspectos de la invención en cualquier forma de reivindicación disponible, incluidos procedimientos, sistemas, medios legibles por ordenador en los que se almacenan instrucciones ejecutables u otros contenidos para hacer que se realice un método y/o en los que se almacenan una o más estructuras de datos para permitir la realización de dicho procedimiento, etc.

Claims

REIVINDICACIONES

1. Un procedimiento implementado por ordenador para mitigar un futuro estado de fallo de un dispositivo informático que comprende:

la obtención, mediante un sistema informático configurado (100), de un modelo de fallo que representa una primera pluralidad de dispositivos informáticos que experimentan un estado de fallo tras un período de tiempo, y un modelo de no fallo que representa una segunda pluralidad de dispositivos informáticos que no experimentan un estado de fallo tras dicho período de tiempo, en el que el modelo de fallo se genera utilizando primeras secuencias de estados de atributos observados del dispositivo (205), que corresponden a componentes de hardware del dispositivo y son automáticamente observables por sensores en el dispositivo, de la primera pluralidad de dispositivos informáticos durante el período de tiempo e incluye información que relaciona los estados de atributos de dispositivo observados de las primeras secuencias con unos primeros atributos de dispositivo no observables (210), que no son automáticamente observables por los sensores del dispositivo, asociados con el estado de fallo, y en el que el modelo de no fallo se genera utilizando segundas secuencias de estados de atributos de dispositivo observados de la segunda pluralidad de dispositivos informáticos durante el período de tiempo e incluye información que relaciona los estados de atributos de dispositivo observados de las segundas secuencias con segundos atributos de dispositivo no observables asociados con el estado de no fallo, en el que el modelo de fallo y el modelo de no fallo son modelos de Markov ocultos y/o filtros de Kalman;

el uso, por parte del sistema informático configurado, del modelo de fallo y el modelo de no fallo para predecir un futuro estado de fallo de un dispositivo informático adicional, incluida la determinación de que una tercera secuencia de estados de atributos de dispositivo observados (235) del dispositivo informático adicional durante múltiples momentos coincide con los primeros atributos de dispositivo no observables (210) del modelo de fallo, para correlacionar la tercera secuencia de estados de atributos de dispositivo observados con el futuro estado de fallo; y

el control, por parte del sistema informático configurado, de las operaciones en curso del dispositivo informático adicional con el fin de mitigar el futuro estado de fallo del dispositivo informático adicional, incluida la modificación de la configuración del dispositivo informático adicional para alterar los futuros estados de atributos de dispositivo del dispositivo informático adicional.

2. El procedimiento implementado por ordenador según la reivindicación 1, que comprende, además el uso, por parte del sistema informático configurado, del modelo de fallo y el modelo de no fallo para predecir un futuro estado de no fallo de un dispositivo informático adicional, incluida la determinación de que una cuarta secuencia de estados de atributos de dispositivo observados del dispositivo adicional coincide con los segundos atributos de dispositivo no observables del modelo de no fallo y no coincide con los primeros atributos de dispositivo no observables del modelo de fallo, para correlacionar la cuarta secuencia de estados de atributos de dispositivo observados con el futuro estado de no fallo, y en el que las operaciones en curso del dispositivo adicional no se modifican en función del futuro estado de no fallo predicho.

3. El procedimiento implementado por ordenador según la reivindicación 1, en el que la obtención del modelo de fallo y del modelo de no fallo incluye el seguimiento de las primeras secuencias de estados de atributos de dispositivo observados y de las segundas secuencias de estados de atributos de dispositivo observados, e incluye la generación del modelo de fallo y del modelo de no fallo basándose en dicho seguimiento, y en el que el control de las operaciones en curso del dispositivo informático adicional para mitigar el futuro estado de fallo del dispositivo informático adicional incluye al menos uno de:

la alteración de los futuros estados de atributos de dispositivo del dispositivo informático adicional para que coincidan con los segundos atributos de dispositivo no observables del modelo de no fallo; o

la modificación de uno o más ajustes de configuración del dispositivo informático adicional que provocan la alteración de los futuros estados de atributos de dispositivo del dispositivo informático adicional; o

la modificación de uno o más tipos de interacciones realizadas por uno o más dispositivos informáticos con el dispositivo informático adicional; o

la modificación del uso futuro de la memoria del dispositivo informático adicional; o

la modificación del uso futuro de las capacidades de comunicación del dispositivo informático adicional.

4. El procedimiento implementado por ordenador según la reivindicación 3, en el que la primera y segunda secuencias de estados de atributos de dispositivo observados incluyen, en cada uno de los múltiples momentos comprendidos en el período de tiempo y para cada uno de al menos algunos dispositivos de la primera y segunda pluralidad de dispositivos informáticos, uno de:

información de atributos sobre uno o más estados de atributos que incluyen el estado de pérdida de paquetes, el estado de reinicios del dispositivo, el estado de tiempo de carga de las aplicaciones, el estado de fallos de las aplicaciones, el estado de velocidad de conexión, el estado de llamadas interrumpidas, el estado de capacitancia de la pantalla y el estado de datos del acelerómetro, y en el que la generación del modelo de fallo y del modelo de no fallo basado en el seguimiento incluye el uso de la información de atributos; o

información de atributos para uno o más estados de atributos que incluyen el uso de distintos tipos de capacidades de comunicación, versiones de software en ejecución, un sistema operativo en uso y características de las interacciones del usuario con uno o más dispositivos de entrada, y en el que la generación del modelo de fallos y del modelo de no fallos basado en el seguimiento incluye el uso de la información de atributos.

5. El procedimiento implementado por ordenador según la reivindicación 1, en el que el modelo de fallo obtenido se segmenta en múltiples submodelos de fallo que se asocian con distintos grupos de características de dispositivo que corresponden a subconjuntos de la primera pluralidad de dispositivos informáticos, y en el que el uso del modelo de fallo y el modelo de no fallo para predecir el futuro estado de fallo del dispositivo informático adicional incluye la selección, por parte del sistema informático configurado, de uno de los múltiples submodelos de fallo que utilizar basándose, al menos en parte, en las características de dispositivo asociadas del submodelo de fallo seleccionado que coincidan con las características de dispositivo del dispositivo informático adicional, y hacer coincidir los estados de atributo de dispositivo observados de la tercera secuencia con un subconjunto de los estados de atributo de dispositivo observados de las primeras secuencias que forman parte del submodelo de fallo seleccionado.

6. El procedimiento implementado por ordenador según la reivindicación 1, en el que el futuro estado de fallo predicho del dispositivo informático adicional incluye un fallo de seguridad para el dispositivo informático adicional, y en el que el control de las operaciones en curso incluye el inicio de la aplicación de medidas de seguridad adicionales en el dispositivo informático adicional.

7. El procedimiento implementado por ordenador según la reivindicación 1, que comprende, además, la realización de otro tipo de acción correctiva iniciando el uso de un dispositivo informático adicional para sustituir el dispositivo informático adicional si no puede mitigarse eficazmente un fallo de dispositivo predicho del dispositivo informático adicional.

8. El procedimiento implementado por ordenador según la reivindicación 1, en el que el sistema informático configurado es al menos uno de:

un sistema de servidor separado del dispositivo informático adicional por una o más redes informáticas, y en el que el uso del modelo de fallo y del modelo de no fallo para predecir un futuro estado de fallo de un dispositivo informático adicional se realiza para cada dispositivo de una pluralidad de dispositivos informáticos adicionales; o el dispositivo informático adicional, y en el que el uso del modelo de fallo y del modelo de no fallo para predecir el futuro estado de fallo incluye la ejecución de un sistema automatizado de gestión de operaciones en el dispositivo informático adicional para realizar el control de las operaciones en curso para el dispositivo informático adicional.

9. El procedimiento implementado por ordenador según la reivindicación 1, en el que la modificación de la configuración del dispositivo informático adicional incluye al menos uno de:

la selección de una o más acciones de modificación que realizar basándose en al menos una de información específica del dispositivo informático adicional para personalizar la selección al dispositivo informático adicional o información específica de un usuario del dispositivo informático adicional para personalizar la selección al usuario; o

el uso, para su modificación, de una respuesta de un usuario a la notificación al usuario, por parte de al menos uno del sistema informático configurado o del dispositivo informático adicional, de una o más modificaciones de configuración para el dispositivo informático adicional.

10. El procedimiento implementado por ordenador según la reivindicación 1, en el que el dispositivo informático adicional es al menos uno de un teléfono inteligente, un dispositivo de juego portátil, una tableta o un ordenador portátil, en el que el modelo de fallo incluye, además, información sobre probabilidades determinadas de ocurrencias de los estados de atributos de dispositivo observados de las primeras secuencias y de los primeros atributos de dispositivo no observables, y en el que el uso del modelo de fallo y del modelo de no fallo para predecir el futuro estado de fallo del dispositivo informático adicional incluye la determinación de que la tercera secuencia de estados de atributos de dispositivo observados se ajusta a los primeros atributos de dispositivo no observables del modelo de fallo que superan un umbral definido y no se ajusta a los segundos atributos de dispositivo no observables del modelo de no fallo que superan el umbral definido, e incluye el uso de las probabilidades determinadas para la tercera secuencia de estados de atributos de dispositivo observados para determinar que una probabilidad de que el dispositivo informático adicional falle en un tiempo especificado supera un umbral definido.

11. Un medio legible por ordenador no transitorio que tiene contenidos almacenados que hacen que uno o más sistemas informáticos realicen operaciones automatizadas para mitigar un futuro estado de fallo de un dispositivo informático, incluyendo dichas operaciones automatizadas al menos:

la obtención, por parte de uno o más sistemas informáticos, de un modelo de fallo generado utilizando primeras secuencias de estados de atributos de dispositivo observados en el tiempo (205), que son automáticamente observables por sensores en el dispositivo, de una primera pluralidad de dispositivos informáticos, cada uno de los cuales tiene un estado de fallo después de las primeras secuencias, y de un modelo de no fallo generado utilizando segundas secuencias de estados de atributos de dispositivo observados en el tiempo de una segunda pluralidad de dispositivos informáticos, cada uno de los cuales tiene un estado de no fallo después de las segundas secuencias, en el que el modelo de fallo incluye información que relaciona los estados de atributo de dispositivo observados de las primeras secuencias con primeros atributos de dispositivo no observables (210), que no son automáticamente observables por los sensores del dispositivo, asociados con el estado de fallo, y en el que el modelo de no fallo incluye información que relaciona los estados de atributo de dispositivo observados de las segundas secuencias con segundos atributos de dispositivo no observables asociados con el estado de no fallo, en el que el modelo de fallo y el modelo de no fallo son modelos de Markov ocultos y/o filtros de Kalman; el uso, por parte de uno o más sistemas informáticos configurados, del modelo de fallo y el modelo de no fallo para predecir un futuro estado de fallo de un dispositivo informático adicional, incluida la determinación de que una tercera secuencia de estados de atributos de dispositivo observados (235) del dispositivo informático adicional durante múltiples momentos coincide con los primeros atributos de dispositivo no observables (210) del modelo de fallo, para correlacionar la tercera secuencia de estados de atributos de dispositivo observados con el futuro estado de fallo; y

el control, por parte de uno o más sistemas informáticos, de operaciones en curso para mitigar el futuro estado de fallo del dispositivo informático adicional.

12. El medio legible por ordenador no transitorio según la reivindicación 11, en el que el dispositivo informático adicional es un dispositivo móvil, en el que las operaciones automatizadas incluyen el inicio del uso de un dispositivo informático adicional para sustituir al dispositivo informático adicional si no puede mitigarse eficazmente un fallo de dispositivo previsto del dispositivo móvil adicional, en el que el uso del modelo de fallo y el modelo de no fallo para predecir el futuro estado de fallo del dispositivo informático adicional incluye, además, la determinación de que la tercera secuencia de estados de atributos de dispositivo observados se ajusta a los primeros atributos de dispositivo no observables del modelo de fallo que superan un umbral definido y no se ajusta a los segundos atributos de dispositivo no observables del modelo de no fallo que superan el umbral definido, y en el que los contenidos almacenados incluyen instrucciones de software que, cuando se ejecutan, programan el uno o más sistemas informáticos para que realicen las operaciones automatizadas.

13. Un sistema para mitigar un futuro estado de fallo de un dispositivo informático que comprende:

uno o más procesadores de hardware de uno o más sistemas informáticos (100); y

una o más memorias con instrucciones almacenadas que, cuando se ejecutan, hacen que el sistema realice operaciones

operaciones automatizadas que incluyen, al menos:

la obtención de un modelo de fallo generado utilizando primeras secuencias de estados de atributos de dispositivo observados en el tiempo (205), que son automáticamente observables por sensores en el dispositivo, de una primera pluralidad de dispositivos informáticos, cada uno de los cuales tiene un estado de fallo después de las primeras secuencias, y de un modelo de no fallo generado utilizando segundas secuencias de estados de atributos de dispositivo observados en el tiempo de una segunda pluralidad de dispositivos informáticos, cada uno de los cuales tiene un estado de no fallo después de las segundas secuencias, en el que el modelo de fallo incluye información que relaciona los estados de atributo de dispositivo observados de las primeras secuencias con primeros atributos de dispositivo no observables (210), que no son automáticamente observables por los sensores del dispositivo, asociados con el estado de fallo, y en el que el modelo de no fallo incluye información que relaciona los estados de atributo de dispositivo observados de las segundas secuencias con segundos atributos de dispositivo no observables asociados con el estado de no fallo, en el que el modelo de fallo y el modelo de no fallo son modelos de Markov ocultos y/o filtros de Kalman; el uso del modelo de fallo y el modelo de no fallo para predecir un futuro estado de fallo de un dispositivo informático adicional, incluida la determinación de que una tercera secuencia de estados de atributos de dispositivo observados del dispositivo informático adicional durante múltiples momentos coincide con los primeros atributos de dispositivo no observables del modelo de fallo, para correlacionar la tercera secuencia de estados de atributos de dispositivo observados con el futuro estado de fallo; y

el control de las operaciones en curso del dispositivo informático adicional para mitigar el futuro estado de fallo del dispositivo informático adicional.

14. El sistema según la reivindicación 13, en el que el dispositivo informático adicional es un dispositivo móvil, en el que el futuro estado de fallo predicho del dispositivo informático adicional incluye un fallo de seguridad para el dispositivo informático adicional, en el que el control de las operaciones en curso incluye el inicio de la aplicación de medidas de seguridad adicionales en el dispositivo informático adicional, en el que el uso del modelo de fallo y el modelo de no fallo para predecir el futuro estado de fallo del dispositivo informático adicional incluye, además, la determinación de que la tercera secuencia de estados de atributos de dispositivo observados se ajusta a los primeros atributos de dispositivo no observables del modelo de fallo que superan un umbral definido y no se ajusta a los segundos atributos de dispositivo no observables del modelo de no fallo que superan el umbral definido, y en el que las instrucciones almacenadas incluyen instrucciones de software que, cuando se ejecutan, programan el uno o más sistemas informáticos para que realicen las operaciones automatizadas.