PROCEDIMIENTO Y SISTEMA PARA GESTIONAR OPERACIONES EN RECURSOS DE UNA RED DISTRIBUIDA, EN PARTICULAR DE UNA RED DE COMUNICACIONES, Y PRODUCTO DE PROGRAMA INFORMÁTICO CORRESPONDIENTE.

Un sistema de operaciones distribuido, que comprende: - una pluralidad de dispositivos terminales (TD),

comprendiendo cada dispositivo terminal un agente proxy (PP), comprendiendo el agente proxy un motor de procesos (PE) basado en flujos de trabajo o basado en reglas para procesar flujos de trabajo o reglas, y una interfaz de usuario (PI) para representar al menos parte de dichos flujos de trabajo o reglas; y - al menos un recurso de gestión remoto (MM) configurado para gestionar la transmisión de dichos flujos de trabajo o reglas a dichos dispositivos terminales, - agentes operacionales (OA) configurados para coordinar operaciones de dichos agentes proxy

Campo de la invención[0001] La presente invención se refiere a técnicas que permiten generar señales de instrucciones y realizar intervenciones (o, más generalmente, operaciones) en función de dichas señales de instrucciones en redes distribuidas, tales como en los aparatos de una red de comunicaciones. [0002] La invención se ha desarrollado prestando particular atención a su posible utilización en el contexto de plataformas distribuidas para gestionar y dar soporte a las operaciones de empleados y clientes. Descripción de la técnica relacionada[0003] Los costes de los procesos operacionales, tales como los que proporcionan nuevos servicios a clientes o eliminan fallos y errores, representan un porcentaje importante de los costes que las empresas de telecomunicaciones deben afrontar cada año. De ahí la importancia de procedimientos/sistemas destinados a reducir dichos costes a través de herramientas que den soporte a actividades tanto de los empleados de la empresa como de los clientes, que puedan implicarse por tanto directamente en eliminar los problemas relacionados con los equipos en las instalaciones del cliente.[0004] El soporte a los empleados y a los clientes, quienes están directamente implicados en acciones de reparación de fallos/errores, puede proporcionarse utilizando dos herramientas principales: sistemas de gestión de conocimiento (KMs, Knowledge Management Systems), o sistemas de gestión de conocimiento operacional (OKMs, Operational Knowledge Management Systems), y plataformas de gestión avanzadas, no considerados como entidades distintas sino como componentes de una solución integrada y completa.[0005] Por “gestión de conocimiento (KM)” se entiende la actividad que permite la creación, diseminación y utilización del conocimiento de una organización. Entre los diversos enfoques a KM, las compañías prefieren generalmente el enfoque local, el cual se centra en la gestión de una parte del conocimiento y en objetivos específicos (por ejemplo, toma de decisiones, resolución de problemas, etc.). La gestión de conocimiento operacional (OKM, Operational Knowledge Management) es un enfoque local a la gestión de conocimiento enfocado a la gestión del conocimiento operacional. Este tipo de conocimiento incluye procedimientos y técnicas (prácticas operacionales) necesarios para llevar a cabo una tarea particular o una actividad específica. Usuarios típicos de un OKMS son ingenieros de asistencia in situ de una compañía y asesores de un centro de atención telefónica.[0006] Los sistemas KM/OKM que representan el nivel actual de desarrollo de estas técnicas se describen, por ejemplo, en el documento US-A-2004/0044542 y en el artículo de G. Valente y A. Rigallo: “Remoter: an Operational Knowledge Management System for Telecommunication Operators”, taller sobre gestión de conocimiento y memorias organizativas, décimo sexta Conferencia Europea sobre Inteligencia Artificial (ECAI, European Conference on Artificial Intelligente), 2004.[0007] Las soluciones descritas en los anteriores documentos se proponen como herramientas para dar soporte a tareas de resolución de problemas tales como las que pueden llevarse a cabo por los empleados de una empresa de telecomunicaciones (para tratar las quejas de los clientes

o satisfacer las peticiones de clientes que demandan nuevos servicios) o incluso por el propio cliente, directamente implicado en actividades relacionadas con el cuidado autónomo de los equipos en sus instalaciones.[0008] En particular, el documento US-A-2004/0044542 describe un procedimiento y un sistema para adquirir y compartir el conocimiento entre el personal técnico de una compañía dada, entre dicho personal y los usuarios y entre los usuarios y el personal técnico de otras compañías. Dicho procedimiento y sistema puede aplicarse a varios dominios, entre los cuales también se incluye el dominio de los servicios de telecomunicaciones, y proporcionar soporte a tareas de resolución de problemas, utilizando enfoques de razonamiento basado en casos y de razonamiento basado en modelos. [0009] En cambio, en el artículo de Valente y Rigallo, se define un sistema de gestión de conocimiento operacional (OKM), denominado como Remoter, utilizándose dicho sistema en un contexto de telecomunicaciones para dar soporte a los técnicos de una empresa de telecomunicaciones durante sus actividades diarias. En particular, Remoter se ha utilizado y probado en el contexto de los procesos de suministro y garantía de servicios ADSL, en los que los técnicos deben reaccionar en un corto periodo de tiempo y elegir la mejor solución. La finalidad del sistema es permitir que los técnicos compartan, adquieran y apliquen su conocimiento operacional para tomar decisiones óptimas en tiempo real. Dicho sistema utiliza el enfoque de razonamiento conversacional basado en casos para dar soporte a la resolución de problemas.[0010] El documento WO-A-2005/018249 describe una arquitectura de sistema basada en un paradigma agente y con un alto grado de flexibilidad y escalabilidad para una gestión distribuida de una red de telecomunicaciones y de los servicios soportados. Los puntos clave de dicha arquitectura son: -una plataforma para una gestión de red y de servicios basada en agentes distribuidos, asociada con motores de flujos de trabajo y motores de reglas, y organizada en tres niveles jerárquicos;

- motores de procesos (motores de flujo de trabajo y motores de reglas) utilizados no solamente para la coordinación de los componentes (de las aplicaciones), sino también para una implementación flexible de todos los aspectos funcionales y de comportamiento de la plataforma;

- un inventario de modelos centralizado (base de datos de modelos, MDB) para la definición, almacenamiento maestro (base de datos maestra) y administración de todas las descripciones de proceso y los modelos de información de recursos de red que van a distribuirse a través de la plataforma para utilizarse en los motores de procesos;

- una capa de inventario de red distribuida que desacopla la red con respecto a las funciones de gestión del OSS y proporciona una base de datos alineada en tiempo real con la red;

- utilización de técnicas de movilidad de código que permiten una distribución práctica de las aplicaciones, incluyendo los aspectos de equilibrio de carga y de tolerancia a fallos.

El artículo de Stephen Corley et al., “Communications Management Process Integration Using Software Agents: A Specification of a Framework for Agent Oriented Workflow Management Systems”, EURESCOM PROJECT P815, [Online] enero de 2001, páginas 1 a 92, XP002343307, obtenido a través de la dirección de Internet: URL: http: //www.eurescom.de/-pub-deliverables/P800series/P815/D1/p815d1vo12.pdf, describe un marco para un sistema de gestión de flujos de trabajo orientado a agentes. La arquitectura de coordinación entre dominios (es decir, en una organización empresarial local) comprende un repositorio de procesos de negocio, un representante de dominio, agentes proveedores de recursos, agentes de usuario personales y agentes proveedores de flujos de trabajo. Los agentes proveedores de flujos de trabajo contienen motores de flujos de trabajo y son responsables del flujo de trabajo entre dominios. El agente de usuario personal (PUA) proporciona una interfaz inteligente al usuario de un sistema de gestión de flujos de trabajo, y puede ser un PUA GUI o un PUA inteligente. En el primer caso, cuando un usuario solicita una operación de control de flujo de trabajo, la GUI reenvía la solicitud al agente PUA, y el PUA se comunica con el WPA para satisfacer la solicitud. En el segundo caso, el PUA tiene capacidades para detectar cambios en su entorno y actuar sobre los mismos según un plan que define para conseguir algunos objetivos. Este agente tiene capacidades de razonamiento, planificación y aprendizaje. Las acciones están implementadas como procedimientos y objetos Java.[0012] El documento US 5.826.239 se refiere a un sistema y procedimiento para una gestión de recursos distribuidos en una red informática que funciona bajo el control de un sistema de software de gestión de flujos de trabajo para gestionar una pluralidad de recursos para realizar un proceso de flujo de trabajo que incluye múltiples actividades de proceso. Se describe un sistema OpenPM federal para la gestión de recursos (véase la Fig. 12), que incluye un software de sistema de gestión de procesos de flujo de trabajo, gestores de recursos, datos de recurso, manejadores de eventos y proxys de recursos.[0013] El artículo de W. Sull “A Distributed Environment for Enabling Lightweight Flexible Workflows”, 1998, actas de la trigésimo primera Conferencia Internacional Anual de...

1. Un sistema de operaciones distribuido, que comprende:

- una pluralidad de dispositivos terminales (TD), comprendiendo cada dispositivo terminal un agente proxy (PP), comprendiendo el agente proxy un motor de procesos (PE) basado en flujos de trabajo o basado en reglas para procesar flujos de trabajo o reglas, y una interfaz de usuario (PI) para representar al menos parte de dichos flujos de trabajo o reglas; y

- al menos un recurso de gestión remoto (MM) configurado para gestionar la transmisión de dichos flujos de trabajo o reglas a dichos dispositivos terminales,

- agentes operacionales (OA) configurados para coordinar operaciones de dichos agentes proxy.

2. El sistema según la reivindicación 1, en el que dicho agente proxy comprende una interfaz de interconexión para el intercambio de información con una aplicación software (RP) de un dispositivo (NA) adicional durante el procesamiento de dichos flujos de trabajo o reglas.

3. El sistema según la reivindicación 2, en el que dicha aplicación software de dicho dispositivo adicional comprende un motor de proceso (PE) basado en flujos de trabajo o basado en reglas y en el que dicho motor de procesos de dicho dispositivo terminal está configurado para interactuar con el motor de procesos de dicho dispositivo adicional mediante dicha interfaz de interconexión.

4. El sistema según la reivindicación 1, en el que

dicha interfaz de usuario es una interfaz interactiva.

5. El sistema según la reivindicación 1, que comprende además un gestor operacional (OM) que tiene funciones de gestión y de control de dichos agentes operacionales.

6. El sistema según la reivindicación 1, en el que dichos agentes operacionales incluyen respectivos motores de procesos (PE) basados en flujos de trabajo o basados en reglas.

7. El sistema según la reivindicación 5, en el que dicho gestor operacional incluye un motor de procesos (PE) basado en flujos de trabajos o basado en reglas.

8. El sistema según la reivindicación 1, en el que dichos agentes proxy de dichos dispositivos terminales están configurados para interactuar directamente entre sí en una relación de interfuncionamiento.

9. El sistema según la reivindicación 1, que incluye además un repositorio de procesos definidos mediante flujos de trabajo o reglas (ODB).

10. El sistema según la reivindicación 1, que incluye además un repositorio de modelos de datos (ODB).

11. El sistema según la reivindicación 1, que comprende además agentes de control (CA) para distribuir dichos flujos de trabajo o reglas a dichos dispositivos terminales.

12. El sistema según la reivindicación 1, que incluye además una base de datos de rendimiento (PDB) para

almacenar datos de rendimiento relacionados con el procesamiento de dichos flujos de trabajo o reglas.

13. El sistema según la reivindicación 1, que incluye además un registro operacional (OL) para almacenar procesos realizados por dichos agentes proxy.

14. El sistema según cualquiera de las reivindicaciones anteriores, caracterizado por el hecho de que está configurado para gestionar intervenciones en equipos de usuario o de red.

15. El sistema según la reivindicación 14, en el que dichos flujos de trabajo o reglas son una función del estado de los equipos de usuario o de red en los que se realizan dichas intervenciones.

16. El sistema según la reivindicación 1, en el que al menos uno de la pluralidad de dispositivos terminales es un dispositivo portátil.

17. El sistema según la reivindicación 2, en el que dicha aplicación software comprende un agente proxy (RP).

18. El sistema según la reivindicación 17, en el que dicho agente proxy de cada dicho dispositivo terminal está configurado para activar automáticamente una sesión de comunicaciones con dicho agente proxy de dicha aplicación software de dicho dispositivo adicional.

19. El sistema según la reivindicación 1, en el que dicha interfaz de usuario gestiona una interfaz gráfica (GUI).

20. El sistema según la reivindicación 1, en el que

cada dicho dispositivo terminal está configurado para la activación del agente proxy mediante un usuario.

21. Un procedimiento para gestionar intervenciones en equipos de usuario o de red, incluyendo el procedimiento las etapas de:

- proporcionar una arquitectura distribuida de primeros agentes proxy (PP) para gestionar intervenciones en los equipos de usuario o de red, estando asociados dichos primeros agentes proxy a dispositivos terminales y comprendiendo motores de procesos basados en flujos de trabajo o basados en reglas;

- disponer dicha arquitectura distribuida en capas jerárquicas que incluyen una capa de agentes operacionales (OA) que coordinan el funcionamiento de dichos primeros agentes proxy (PP); y

- generar señales de instrucción para realizar una intervención en al menos un equipo de usuario o de red mediante uno de dichos primeros agentes proxy de una manera interactiva (PTP) con al menos un recurso de gestión asociado con dicho equipo de usuario o de red, por lo que dichas señales de instrucción son una función del estado de dicho equipo de usuario o de red.

22. El procedimiento según la reivindicación 21, en el que dicho recurso de gestión comprende un segundo agente proxy (RP) asociado con dicho equipo de usuario o de red y que comprende un motor de procesos basado en flujos de trabajo o basado en reglas.

23. El procedimiento según la reivindicación 21 ó 22, caracterizado por el hecho de que cada uno de dichos primeros agentes proxy está asociado con un único

dispositivo terminal e incluye un único motor de procesos basado en flujos de trabajo o basado en reglas.

24. El procedimiento según la reivindicación 23, caracterizado por el hecho de que incluye la etapa de asociar con dichos primeros agentes proxy (PP) interfaces personales (PI) para representar al menos parte de dichas instrucciones y para interactuar con el flujo de trabajo o regla ejecutados.

25. El procedimiento según la reivindicación 21, caracterizado por el hecho de que dichas capas jerárquicas de dicha arquitectura distribuida incluyen una capa que comprende un gestor operacional (OM) que tiene funciones de gestión y de control y que supervisa el funcionamiento de dichos agentes operacionales (OA).

26. El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de asignar a dichos agentes operacionales (OA) la ejecución distribuida de intervenciones sobre una pluralidad de dichos primeros agentes proxy (PP).

27. El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de asignar a cada uno de dichos agentes proxy (PP) la tarea de dar soporte a un único operador o cliente, por lo que la ejecución de dichas intervenciones está desacoplada con respecto a dichas funciones de gestión y de control.

28. El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de proporcionar motores de procesos (PE) a dichos primeros agentes proxy (PP).

29. El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de proporcionar motores de procesos (PE) a todas dichas capas en dicha arquitectura distribuida.

30. El procedimiento según la reivindicación 28 ó 29, caracterizado por el hecho de que dichos motores de procesos (PE) están basados en flujos de trabajo o están basados en reglas.

31. El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de incluir en dichas capas componentes (PP, OA, OM) adaptados para realizar funciones respectivas basadas en información de instrucción respectiva proporcionada a los mismos.

32. El procedimiento según la reivindicación 31, caracterizado por el hecho de que incluye la etapa de proporcionar en dicha información de instrucción al menos uno de lo siguiente:

- una definición de procesos, que incluye al menos uno de un flujo de trabajo y una regla; y -una definición de modelos de datos.

33. El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de configurar dichos primeros agentes proxy (PP) para que interactúen directamente entre sí en una relación de interfuncionamiento, por lo que al menos una de dichas señales de instrucción se produce mediante la interacción entre los primeros agentes proxy (PP).

34. El procedimiento según la reivindicación 21, caracterizado por el hecho de que incluye la etapa de configurar dichos primeros agentes proxy (PP) para una

interacción de igual a igual (PTP) con dichos agentes proxy de recursos (RP).

35. El procedimiento según la reivindicación 25, caracterizado por el hecho de que incluye la etapa de proporcionar agentes de control (CA) asociados a al menos una capa de dicha arquitectura distribuida para realizar al menos una etapa seleccionada del grupo que consiste en:

- distribuir definiciones de procesos a dichas capas de dicha arquitectura distribuida;

- distribuir definiciones de modelos de datos a dichas capas de dicha arquitectura distribuida; y

- supervisar el estado de dichas capas de dicha

arquitectura distribuida.

36. El procedimiento según la reivindicación 35, caracterizado por el hecho de que incluye la etapa de proporcionar un recurso de gestión remoto (MM) para realizar al menos una etapa seleccionada del grupo que consiste en:

- gestionar la distribución de definiciones de procesos a dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA);

- gestionar la distribución de definiciones de modelos de datos a dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA); y

- supervisar el estado de dichas capas de dicha arquitectura distribuida mediante dichos agentes de control (CA).

37. Un producto de programa informático que puede cargarse en la memoria de al menos un ordenador y que incluye partes de código de software para realizar, cuando se ejecutan, todas las etapas del procedimiento según cualquiera de las reivindicaciones 21 a 36.