Method and system for generating instruction signals for performing interventions in a communication network, and corresponding computer-program product

Field of the invention [0001] The present invention relates to techniques that allow generating instruction signals and performing interventions (or, more generally, operations) based on said instruction signals in distributed networks, such as in the devices of a network of communications. [0002] The invention has been developed with particular attention to its possible use in the context of distributed platforms to manage and support the operations of employees and customers. Description of the related technique [0003] The costs of operational processes, such as those that provide new services to clients or eliminate failures and errors, represent a significant percentage of the costs that telecommunications companies must face each year. Hence the importance of procedures / systems aimed at reducing these costs through tools that support activities of both company employees and customers, which may therefore be directly involved in eliminating equipment related problems in the customer facilities. [0004] Support to employees and customers, who are directly involved in fault / error repair actions, It can be provided using two main tools: knowledge management systems (KMs, Knowledge Management Systems), or operational knowledge management systems (OKMs, Operational Knowledge Management Systems), and advanced management platforms, not considered as distinct entities but as components of an integrated and complete solution. [0005] "Knowledge management (KM)" means the activity that allows the creation, dissemination and use of knowledge of an organization. Among the various approaches to KM, companies generally prefer the local approach, which focuses on the management of part of the knowledge and specific objectives (for example, decision making, problem solving, etc.). Operational Knowledge Management (OKM) is a local approach to knowledge management focused on operational knowledge management. This type of knowledge includes procedures and techniques (operational practices) necessary to carry out a particular task or a specific activity. Typical users of an OKMS are onsite assistance engineers of a company and consultants for a call center. [0006] KM / OKM systems that represent the current level of development of these techniques are described, for example, in US-A-2004/0044542 and in the article by G. Valente and A. Rigallo: "Remoter: an Operational Knowledge Management System for Telecommunication Operators ”, workshop on knowledge management and organizational memories, 16th European Conference on Artificial Intelligence (ECAI, European Conference on Artificial Intelligente), 2004. [0007] The solutions described in the previous documents are proposed as tools to support troubleshooting tasks such as those that can be carried out by employees of a telecommunications company (to handle customer complaints

or to satisfy the requests of clients that demand new services) or even by the client himself, directly involved in activities related to the autonomous care of the equipment in his facilities. [0008] In particular, document US-A-2004/0044542 describes a procedure and system for acquiring and sharing knowledge among the technical personnel of a given company, between said personnel and users and between users and technical personnel of other companies. . This procedure and system can be applied to several domains, which also include the domain of telecommunications services, and provide support for problem-solving tasks, using case-based and model-based reasoning approaches. [0009] On the other hand, in the article by Valente and Rigallo, an operational knowledge management system (OKM), called Remoter, is defined, said system being used in a telecommunications context to support the technicians of a telecommunications company during your daily activities. In particular, Remoter has been used and tested in the context of the ADSL service supply and warranty processes, in which technicians must react in a short period of time and choose the best solution. The purpose of the system is to allow technicians to share, acquire and apply their operational knowledge to make optimal decisions in real time. This system uses the case-based conversational reasoning approach to support problem solving. [0010] Document WO-A-2005/018249 describes a system architecture based on an agent paradigm and with a high degree of flexibility and scalability for distributed management of a telecommunications network and the supported services. The key points of this architecture are: - a platform for network and service management based on distributed agents, associated with workflow engines and rule engines, and organized on three hierarchical levels;

-process engines (workflow engines and rule engines) used not only for the coordination of components (of applications), but also for a flexible implementation of all functional and behavioral aspects of the platform;

-a centralized model inventory (model database, MDB) for the definition, master storage (master database) and administration of all process descriptions and network resource information models to be distributed through of the platform to be used in process engines;

-a distributed network inventory layer that decouples the network from the OSS management functions and provides a database aligned in real time with the network;

-Using code mobility techniques that allow a practical distribution of applications, including aspects of load balancing and fault tolerance.

[0011] The article by 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] January 2001, pages 1 to 92, XP002343307, obtained through the Internet address: URL: http: //www.eurescom.de/-pub-deliverables/P800series/P815/D1/p815d1vo12.pdf, describes a framework for a workflow management system Agent oriented. The inter-domain coordination architecture (that is, in a local business organization) comprises a business process repository, a domain representative, resource provider agents, personal user agents and workflow provider agents. Workflow provider agents contain workflow engines and are responsible for cross-domain workflow. The personal user agent (PUA) provides an intelligent interface to the user of a workflow management system, and can be a GUA PUA or an intelligent PUA. In the first case, when a user requests a workflow control operation, the GUI forwards the request to the PUA agent, and the PUA communicates with the WPA to satisfy the request. In the second case, the PUA has the capacity to detect changes in its environment and act on them according to a plan that it defines to achieve some objectives. This agent has reasoning, planning and learning capabilities. The actions are implemented as procedures and Java objects. [0012] Document US 5,826,239 refers to a system and procedure for managing distributed resources in a computer network that operates under the control of a workflow management software system to manage a plurality of resources to perform a process of Workflow that includes multiple process activities. A federal OpenPM system for resource management is described (see Fig. 12), which includes workflow process management system software, resource managers, resource data, event handlers and resource proxies. [0013] W.'s article Sull “A Distributed Environment for Enabling Lightweight Flexible Workflows”, 1998, records of the thirty-first annual Hawaii International Conference on Systems Science, pages 355 to 364, XP010263096, unveils a set of domain-distributed distributed architecture components for applications workflows Components are responsible for isolating applications from the communication task with the workflow manager and support greater flexibility and scalability by separately defining independent domain components and domain specific components. With the proposed components, applications distributed in a workflow can be used without prior knowledge of them, so introducing a new application into a set of collaborative applications will be easier. Object and summary of the invention [0014] It has been observed that the procedures used in the systems described in the first two documents referred to above (US-A2004 / 0044542 and the article by Valente and Rigallo) have limits on as regards [0015] the functions offered, due to three deficiencies. [0016] First, they do not provide a direct interaction with the systems / platforms responsible for the management of the network and services, which would allow a significant reduction in the execution times of problem-solving activities using the related advantages with, for example, real-time verification of the correct execution of the tasks performed by the technical staff, Proactive provision of necessary network data and automatic execution of standard commands on the network. [0017] Secondly, they do not represent the knowledge to be shared using formal tools (such as workflows) that would allow a reduction in technicians' working times through a clear and easily understandable description of the activities that they have of being carried out. Such formal representation would also avoid any possible difficulty of interpretation or any misinterpretation, by the technicians, of the indications provided, which may lead to the execution of useless activities.

or even harmful to the network in which they are taking place. [0018] Finally, the systems in question do not guide the technical personnel in a complete, integrated and exhaustive way through all the steps that must be followed to carry out the problem-solving activities: they provide specific suggestions for individual activities that have to be be made or of specific documents to be consulted, which are obtained using procedures such as case-based conversational reasoning. A complete guide will allow both a reduction in the working times of technicians and a faster insertion of technicians who are added to the task. [0019] Regarding the article by Corley et al. and to document US 5,826,239, it is pointed out that these documents describe solutions for managing business processes and not for managing operational knowledge. Therefore, workflows are used to represent and execute business models and are not intended to represent the operational knowledge required to carry out a particular task or specific activity, offering it for interactive use by operators and users. [0020] Also, in the framework of systems / platforms for network / service management, advanced solutions are provided that include distributed architectures based on agents. [0021] In this regard, the architecture described in document WO-A-2005/018249 mentioned above is extremely effective and efficient in network management, but does not contemplate that any KM / OKM function supports activities of employees of a company of telecommunications [0022] Consequently, there is a clear need for innovative solutions for the management of operational activities that, overcoming the intrinsic disadvantages set forth above, present some important functional characteristics. [0023] A first of these characteristics is the possibility of an automatic and assisted interaction with the systems / platforms responsible for network / service management, which aims to allow: -a real-time check, in the network / services

managed, of the correct execution of the suggestions provided, returning an immediate feedback to the system user;

- an automatic supply, synchronized with the activities carried out, of the data (configuration data, measurement data, etc.) required to proceed with said activities;

-An automatic execution of the stages, considered standard, of the activity of an operator / engineer of on-site assistance: for example, the configuration of a network card according to predefined parameters to eliminate any possibility of error and reduce the required times.

[0024] A second desirable feature is that the suggestions given to employees must be represented by formal tools (such as workflows) that have the following advantages: -description of the activities to be carried out

in order to satisfactorily carry out a given intervention or to effectively treat a customer request in a clear and easily intelligible manner;

- immediate indication (for example, by

appropriate results) of best practices; and - enabling easier management of

knowledge related to the activities of

upgrade and upgrade possibly supported

also through automatic mechanisms. [0025] Another important additional feature that is certainly desirable is that the system must be able to indicate autonomously and completely all the specific steps required to carry out a given intervention (on-site assistance engineers) or to respond to a given customer request ( consultants of a call center): they provide specific suggestions for individual activities to be carried out or for specific documents to be consulted, which are obtained using procedures such as case-based conversational reasoning. [0026] It should be specifically stated that current management platforms, despite being at the forefront in terms of management aspects, do not offer adequate tools to support employees, who are still entrusted with carrying out important stages of a company's business processes, and are not integrated with OKM systems. [0027] Therefore, there is a need for solutions that can overcome these limitations. Specifically, there is a need for a complete solution to support employees who, starting from advanced flexible and scalable management architectures, introduce innovative OKM functions, based on a formal representation of operational practices, and ensure integration between operation and network / service management. [0028] Thus, The object of the invention is to provide a completely satisfactory response to the above needs, in particular to provide an effective technique that supports human intervention services in distributed systems, such as a network of devices distributed in a given territory. [0029] It has been found that the above object is achieved by providing a distributed architecture of operations management that includes a plurality of intervention management proxy agents associated with respective operator or user terminal devices, each intervention management proxy agent comprising a suitable process engine to process workflows or rules that define the instructions for performing the interventions, and a system for managing and controlling the operation of the terminal devices that includes a centralized resource suitable to provide the proxy agents of these devices with different workflows or rules depending on the type of intervention. [0030] According to one aspect of the present invention, a distributed architecture of intervention management proxy agents associated with respective operator or user terminal devices is provided, said intervention management proxy agents being configured to interact with management means (preferably comprising resource proxy agents) associated with additional devices (such as network equipment) to generate instructional signals (in the form of workflows or rules ) to perform interventions on the devices, therefore, the instruction signals are a function of the status of the devices that require intervention. [0031] The terminal device is preferably a portable device such as a cell phone, a personal digital assistant (PDA) or a laptop, comprising an intervention management proxy provided with a process engine based on workflows or in rules and a personal interface (PI, Personal Interface) to allow interaction with an operator or a user, and which is preferably configured to download workflows or rules from a remote resource. The proxy agent is also preferably provided with an interface for communicating with a software application on another computer, device or device in order to exchange information with it during the execution of the workflow or the rules. [0032] It has been discovered that the above architecture and terminal device can be applied to perform interventions on devices of a distributed network, such as a telecommunications network or an energy distribution network. However, the invention can be widely applied in all scenarios in which its operation is requested (for example, to solve faults) in devices, equipment or devices of predefined characteristics, in a systematic manner, using predefined processes in a flexible and preferably interactive and maintaining centralized control and management of operations. [0033] Thus, the term "intervention" should be interpreted in a generic way to include, for example, the interactions between the terminal devices and the external devices, diagnostic devices or equipment, hardware / software modifications or checking operations. [0034] The invention also relates to a corresponding computer program product that can be loaded into the memory of at least one computer and that includes portions of software code to perform the steps of the process of the invention when the product is run on a computer. As used herein, the reference to such a computer program product is understood as equivalent to the reference to a computer readable medium containing instructions for controlling a computer system in order to coordinate the execution of the method according to the invention. . The expression "at least one computer" is used to highlight the possibility that the present invention is implemented in a distributed and / or modular manner. The claims form an integral part of the description of the invention provided herein. [0035] A particular embodiment of the solution described in this document is a procedure for generating instructional signals arranged in workflows to perform interventions on network equipment included in a communication network in which said equipment is associated with proxy agents. of resources, each one being responsible for managing a single team in said network, including the procedure the stages of: -providing a distributed architecture of first

proxy agents; -generate said instruction signals by means of said

first proxy agents in an interactive way with

said resource proxy agents, so those

instructional signals are a function of the state of the

equipment in said network in which said

interventions [0036] According to a first aspect thereof, the present invention therefore relates to a distributed operating system according to claim 1. [0037] In particular, process engines can be workflow based engines, rule based engines or a combination of both types. The choice may depend on the type of operations to be performed. For example, support functions related to an operator's on-site intervention are best represented as a flowchart, while diagnostic support functions related to complaints, in the context of a call center, are best represented. through a set of rules. However, whenever possible and advisable, The use of workflows is preferred as they avoid the complexity of dealing with conflict of rules and rule management. [0038] The proxy agent preferably comprises an interconnection interface for exchanging information with a software application of an additional device during the processing of said workflows or rules. [0039] Said software application of said additional device preferably comprises a process engine based on flows of work or rule-based, and said process engine of said terminal device is configured to interact with the process engine of said additional device through said interconnection interface. [0040] In addition, the system also preferably comprises an operational manager having management and control functions of said operational agents. [0041] The operational agents and / or the operational manager may include respective process engines based on workflows or based on rules. [0042] The proxy agents of the terminal devices can be configured to interact directly with each other in an interworking relationship. [0043] The system may also include a repository of processes defined by workflows or rules. In addition, the system may include a repository of data models. [0044] The system may also include control agents to distribute workflows or rules to terminal devices. [0045] The system can also include a performance database for storing performance data related to workflow processing

or the rules. [0046] The system may also include an operational record for storing processes carried out by proxy agents. [0047] The system can be configured to manage interventions on network equipment. In this case, workflows or rules are preferably a function of the state of the network equipment in which the interventions are performed. [0048] At least one of the plurality of terminal devices can advantageously be a portable device to allow, for example, on-site interventions. [0049] Said software application may comprise a proxy agent. In this case, the proxy agent of each said terminal device can be configured to automatically activate a communications session with the proxy agent of the software application of said additional device. [0050] The user interface preferably manages a graphical interface. [0051] Each terminal device can be configured for activation of the proxy agent by a user. [0052] According to an additional aspect of it, The present invention relates to a method for managing interventions in user or network equipment according to claim 21. [0053] The management resource may comprise a second proxy agent associated with said user or network equipment and comprising a workflow-based or rule-based process engine. [0054] Each first proxy agent can be associated with a single terminal device and can include a single engine based on workflows or based on rules. [0055] The procedure preferably includes the step of associating said first proxy agents with personal interfaces to represent at least part of said instructions and to interact with the workflow or rule executed. [0056] The hierarchical layers may include a layer comprising an operational manager that has management and control functions and that oversees the operation of said operational agents. [0057] Further, the procedure may include the step of assigning said operational agents the distributed execution of interventions on a plurality of said first proxy agents. [0058] The procedure may include the step of assigning, to each said first proxy agents, the task of supporting a single operator or client, so that the execution of said interventions is decoupled with respect to said management and control functions. [0059] Preferably, the procedure also includes the step of providing process engines to said first proxy agents. [0060] The method may also include the step of providing process engines to all such layers in said distributed architecture. [0061] Such process engines are preferably based on workflows or rules. [0062] The method preferably includes the step of including in said layers components adapted to perform respective functions based on respective instructional information provided to them. [0063] The procedure may also include the step of providing in said instructional information at least one of the following elements: -a process definition, which includes at least one

of a workflow and a rule; and -a definition of data models. [0064] Preferably, the method includes the step of configuring said first proxy agents to interact directly with each other in an interworking relationship, whereby at least one of said instruction signals is produced by interaction between first proxy agents. ] The procedure may also include the step of configuring said first proxy agents for a peer-to-peer interaction with said resource proxy agents. [0066] The method may include the additional step of providing control agents associated with at least one layer of said distributed architecture to perform at least one stage selected from the group consisting of: - distributing process definitions to said layers of

said distributed architecture; -distribute data model definitions to said layers of said distributed architecture; and -supervise the status of said layers of said

distributed architecture. [0067] The procedure may also include the step of providing a remote management resource to perform at least one stage selected from the group consisting of: - managing the distribution of process definitions

to said layers of said architecture distributed by said control agents;

- manage the distribution of data model definitions to said layers of said distributed architecture by means of said control agents; and

-supervise the state of said layers of said

architecture distributed by said agents of

control. [0068] The present invention also relates to a computer program product that can be loaded into the memory of at least one computer and that includes portions of software code to perform the above procedure. Brief description of the attached drawings [0069] The invention will now be described, by way of example only, with reference to the set of attached drawings, in which:

Figure 1. Functional block diagram illustrating a possible embodiment of a platform described in this document. Figure 2. Another functional block diagram representing the management of operations on the platform of Figure 1. Figure 3. Flowchart of a first procedure performed on the solution described in this document. Figure 4. Example of a workflow generated by the solution described in this document. Figures 5 to 7. Flowcharts of additional procedures performed on the solution described in this document. Figure 8. Schematically illustrates a portable device that will be used on the platform of Figures 1 and 2.

Detailed description of preferred embodiments of the invention [0070] In order to facilitate a correct understanding of the underlying principles of the invention, a glossary explaining some terms / acronyms used in this description and in the appended claims is presented below.

[0071] WFM (employee management, Work Force Management): in the context of a telecommunications company, it is the software application / software application suite (s) responsible for managing the employees of that company. In the specific context of interest it is understood as the application / set of applications used to manage both mobile employees (onsite assistance engineers) and employees of a call center. [0072] Operator: a member of the company's staff that is part of the workforce, which is classified as a mobile employee (on-site assistance engineer), as a specialized employee (internal services staff) and as a center advisor Telephone support [0073] -MM management module: is a software application that runs on a central computer that communicates with distributed agents for various coordination activities, such as the distribution of workflow descriptions, calls from agents distributed to invoke an operation, administrative controls, etc .; It can include an appropriate and specialized graphical user interface (GUI). [0074] Agent: it is an autonomous process with a possible persistent state and that requires communication (for example, in a collaborative and / or competitive way) with other agents in order to fulfill their tasks. This communication can be implemented through an asynchronous message exchange and using widely known languages ​​(for example, the language of communication between agents, ACL) with a well-defined and commonly agreed semantics. [0075] Proxy: is a component (agent) through which it is possible to control or intervene in another managed object, for example a network equipment or a GUI in the context of supporting an operation. [0076] Rule: A rule is a scheme to generate valid inferences. These schemes establish syntactic relations of the form "if <x> then <y> if not <z>" between a set of formulas called premises, which form the "yes" part, and an assertion called as a conclusion, which forms the part “then.” The part “if not” is optional These syntactic relations are used in the inference process, so that new true assertions are reached from others already known. [0077] Rule engine (or rule-based engine): it is a system to separate process rules (logically and / or physically) from control logic and share them through data memories, user interfaces and applications . A rule engine is basically a very sophisticated interpreter of "yes / then" sentences. A rule engine is used to decide, at runtime, what rules to apply and how to execute them. [0078] Workflow: can be defined as the automation of a process, in whole or in part, during which documents, information or tasks are transmitted from one participant to another to perform an action according to a set of procedural rules (Terminology & Glossary , WFMC-TC-1011, February 1999, 3.0). A workflow can be represented through a flowchart with a sequence of tasks and temporal and logical dependencies, tasks that include parallel or alternative branches. There are ad hoc languages, such as XPDL (XML process description language, XML), which allow a formal description of workflows. [0079] Workflow engine (or workflow based engine): it is the component that has all the information related to the procedures (workflows), stages in a procedure and the rules for each stage. The workflow engine determines if the process is ready to move on to the next stage. In other words, a workflow engine is a component for executing workflows. [0080] The block diagram of Figure 1 represents a preferred embodiment of an integrated platform comprising a platform for the distributed management of a telecommunications network and related services, as described in WO-A-2005/018249, and a platform for distributed operations management. [0081] The illustrated architecture (which defines, in its upper layers, an operations support system (OSS)) interacts with three basic entities comprising other operations support systems (OSS), support systems business (BSS, Business Support Systems) and an employee management system (WFM) (or possibly more than one WFM). With regard to management aspects, OSS and BSS interact via a bus (for example, a TIBCO bus) with the master application, designated as MA1. This application manages the distribution of processes and related data models, stored in the model database (MDB, Model Data Base), to several agent applications, one of which is shown and designated as AA1, and proxy agents of resources RP1, ..., RPn. Each agent application depends on one or more proxy agents of RP1, ..., RPn resources that interact with an N communications network using Protocol adapters (Protocol Adapters). The NI Network Inventory corresponds to the usual concept of a network inventory component and is the collection of all virtualizations (images) of the resource on the N network; it is updated periodically retrieving information from the PRs. Additional details related to the network / service management platform can be obtained from document WO-A-2005/018249. [0082] As introduced in Figure 1 and presented in greater detail in Figure 2, the operations management platform comprises an operational manager OM (Operational Manager) that interacts with the bus and acts in conjunction with an inventory of skills ( EI, Expertise Inventory) and with an operation log file (OL, Operation Log). The operational manager OM supervises the operation of the operational agents OA1, ..., OAk. Each operational agent depends on one or more personal proxies PP1, ..., PPn, which interact with a plurality of virtual machines VT1, ..., VTn through personal PI interfaces. Each VT is formed, for example, by onsite assistance engineers, internal service personnel, telephone service center consultants or customers. [0083] The personal proxies, PP1, PP2, ..., PPn, each of which is equipped with a personal PI interface, are connected to the upper hierarchical layer of the architecture that includes either a set of OA1, OA2 operations agents ,…, OAk, or directly an OM operational manager. If OA are present, they are connected to the upper hierarchical layer that includes the OM. This layered architecture guarantees the flexibility and scalability of functions, as described below. [0084] In a preferred embodiment, the PPs communicate with each other and are also advantageously connected to the RP resource proxies (using the ACL language), as indicated schematically by the two-way arrow PTP in the Figure. 1. This normally represents a peer-to-peer relationship between personal proxies and resource proxies. This relationship allows the possibility that the architecture described in this document generates instructional signals by means of intervention management proxies (that is, personal proxies) in an interactive way with resource proxies, so these instructional signals depend of the state of the equipment in which an intervention is executed. Those skilled in the art will readily appreciate that the reference to the possible presence of n proxies of resources RP1 to RPn, of n personal proxies PP1 to PPn and of n virtual equipment is completely and merely indicative, and that it can be conceived that each of these entities may be present in any number. [0085] Each PR is responsible for the creation, maintenance and management of the so-called "image" of an individual team (located on the network or at the customer's premises). The image is a representation of the equipment configuration according to a defined data model. [0086] Each operational agent OA1, ..., OAk coordinates a set of personal proxies; OA1, ..., OAk operational agents can interact with each other, as well as with personal proxies and the OM operational manager. [0087] Each agent running on a central computer (i.e., each agent for network / service management and each new agent such as personal proxies, operational agents and operational manager) preferably includes one or more CA control agents, which are the software modules responsible for controlling and managing the platform. [0088] As noted, the platform also includes a set of databases (DB, data bases) that support the activities carried out by the various components. The operational database ODB (operational data base) is the only (logical) point of definition and storage of all functional aspects and management / support aspects of employees and customers, in relation to the platform. The ODB is the repository of process descriptions (where a process description is a workflow or a rule) and the definitions of data models that are used by platform components to manage operations (PP, OA and OM). [0089] An MM management module (Manager Module) distributes process definitions and data model definitions to operations management components using CA control agents. First, this allows offering the most effective and effective operational practices (best practices) to all employees and customers. In addition, through the dissemination of data model definitions, coordination between employees is allowed, thus allowing a simple and quick identification of the experts that will be used to obtain support on a specific issue. Associated with the ODB database is a GUI provided intentionally to allow it to be filled in. [0090] The MDB (Model Data Base) model database stores all process descriptions (workflows and rules) and models of the processed data (including models of network equipment) that are used by the components of the platform for network / services management (RP, AA and MA, as shown in Figure 1). [0091] The MDB provides users with a single point at which to define and manage the functions of the platform in regard to aspects of network management / services. [0092] In a preferred embodiment, in order to define the data models stored in the ODB and MDB databases, the SID model (shared information data model, set of documents of the TeleManagementForum GB922, version 4.0, is used, August 2004 and version 4.5 in member evaluation, December 2004). [0093] The PDB (Performance Data Base) performance database is a single (logical) storage point for all performance data related to platform components and is used both to optimize resource utilization and to identify best practice. [0094] Finally, on the platform they are also present: the operational record (OL), which is a single (logical) storage point for all records of the activities carried out by the operators and by the customers; and the inventory of EI skills, which contains the data of the operator profiles and customer profiles managed by the various PPs. [0095] In a preferred embodiment, the operational processes of the platform are segmented into three layers with specific functions. This option is intended to meet two needs: keep the number of layers as low as possible (thus avoiding the complexity of conventional architectures), and allow the free allocation of processes between a distributed mode and a centralized mode. This implies the presence of a centralized layer 1 (or higher layer, which corresponds to the operational manager OM) and a fully distributed layer 2 (or intermediate layer, which corresponds to the operational agents OA1, ..., OAk), plus a layer 3 of independent proxies (or lower layer, corresponding to the personal PP proxies) that decouples the operation with respect to the management and control functions. This segmentation also provides different service views, for example a product view for the end customer in layer 1, a service view in layer 2 and an operational view in layer 3. As will be explained later, the PP, OA and OM components are adapted to perform respective functions based on respective instructional information provided thereto, information comprising process definitions, such as workflows or rules, or model definitions. of data. [0096] Each personal proxy PP (hereinafter, for reasons of brevity, it will be omitted to repeat the sequence of suffixes 1 to N each time, for example, in PP1, ..., PPn, and a similar approach will also be taken with reference to other entities present in multiple ways in the diagrams of Figures 1 and 2) is responsible for supporting the activities of a specific operator or of a specific customer, both as regards guided in the various operational activities such as support for cooperation (between different operators or between operators and customers). In particular, support for cooperation is based on operator profiles and customer profiles, these profiles being represented in the data model. The instantiation of the profiles with the actual and updated data is carried out by the OM operational manager with the information that comes from external WFM systems, in the case of operator profiles, or from business support systems, in the case of profiles client, and communicates to the personal proxy. [0097] In other words, each personal proxy has the role of an intervention management proxy agent. Each personal proxy (PP) executes typical processes of the corresponding PP level using a PE process engine: these processes are referred to as layer 3 processes and can be structured in sub-layers (for example, for the definition of macro-operations). The processes of the upper layer of layer 3 constitute the services that the PP offers to the upper layer (usually the operational agent, and possibly other external applications) through the invocation of said processes. They represent the operations that correspond to a single activity carried out by the operator / client to which the PP is associated. Hence the term, already introduced above, of proxy agent of "intervention management". Examples of services (and, therefore, interventions) provided by a personal proxy are: interconnect, install and configure a modem, repair a device failure (router, DSLAM, etc.), etc .; each of them can include sequences of activities that are carried out in one or more teams. The processes in the lower layer of layer 3 use the services offered by the personal PI interfaces. [0098] Operator profiles and client profiles managed by a personal PP proxy are represented in the data model. This model, defined by an intentionally provided GUI, is stored in the ODB database and distributed through the MM management module, through CA control agents, to personal PP proxies, which load and instantiate it with the values ​​sent by the OM operational manager and acquired through external systems (WFM and BSS). Again, instantiation is performed in a flexible manner using a proxy engine PE (Proxy Engine). In this way, changes and additions of data models (such as the update of the operator / client profile, the introduction of new types of operator, etc.) do not require any appreciable software changes in the components of the platform, achieving a high degree of flexibility. [0099] Data from operator profiles and customer profiles are stored in the EI skills inventory, which is periodically updated by OM using information acquired from external systems (WFM systems for the operator profile and business support systems for the client profile). As mentioned above, changes in profile data are also communicated to the relevant personal PP proxies. [0100] Therefore, operators can be logically grouped into virtual machines VT1, ..., VTn: a virtual team includes a set of operators that share a given knowledge and / or deal with common problems. Virtual teams can, in general, be organized according to a geographical subdivision of employees in order to improve the effectiveness of problem solving and to optimize interventions in situ. [0101] PP personal proxies can interact directly with each other to support cooperation between operators or between operators and customers, for example, to repair a complicated failure. Preferably, the personal PP proxies also communicate with the RP resource proxies associated with the different network resources; therefore, PPs can interact with RPs to send commands, collect configuration data, measurement results or results of satisfactory execution checks, on the equipment, or some actions given by the operator / client, and provide access remote to possible command line interfaces. In contrast, personal IP interfaces are responsible for managing interactions between personal proxies and operators (employees) or customers, regardless of the type of terminal device they use to support their work activities. [0102] The terminal device can be of different types, depending on the particular use for which it is designed. Figure 8 schematically shows a TD terminal device according to the present invention, comprising a personal proxy PP, which in turn comprises a workflow based or rule based PE process engine. The PI personal interface is also schematically represented, consisting of a plurality of WI objects (graphic components with which a user interacts) that allow interaction between a user or operator and the workflows or rules executed by the PE process engine. The workflow or rule executed by the process engine (PE) is responsible for displaying the objects with the correct data. In this way, interaction with users is completely controlled by workflows or rules executed on the terminal device. [0103] The terminal device also includes an interconnection interface IN (interconnection interface) provided by the personal proxy PP for interconnection with a software application of a network device NA (network apparatus) to exchange information with it. Preferably, the software application is a proxy of RP resources endowed with a process-based or rule-based PE process engine. According to one aspect of the present invention, the terminal device is a portable device, such as a PDA, a laptop or a cell phone, so it is particularly suitable for on-site interventions by on-site assistance engineers. Alternatively, the terminal device may be a fixed device, such as a desktop computer, such as is normally used by employees of a call center. [0104] Each PI offers, as services for personal proxies, the management of the GUI towards the operator / client, including the automatic configuration of the GUI depending on the type of device available. [0105] Each OA operational agent is responsible for coordinating a set of PP and executing typical Layer 2 processes using a proxy engine. These processes are related to the distributed execution of operational interventions and can be structured in sub-layers. The processes of the upper layer of layer 2 can be invoked externally; therefore, they are services offered by the operational agent OA to the operational manager OM or other external systems. The processes in the lower layer of layer 2 use the services (that is, they invoke processes) offered by the personal proxy PP. [0106] An OA operational agent does not require software update to support new operational practices. This is due to the flexibility of processes (based on workflows or based on rules) that are received from the MM management module, through the CA, loaded and executed by the OA layer. OA operational agents can interact by means of a community protocol (an interworking mechanism based on the exchange of messages) to support the distributed execution of correlated operational activities such as, for example, the creation of a circuit that needs equipment located in geographically distributed locations. [0107] The OM operational manager is responsible for the first level coordination of the execution of the typical processes of a management level. Layer 1 processes can be structured in sub-layers and are characterized to provide functions that require interaction with entities external to the platform (for example, WFM systems or business support systems) and / or coordination between OA operational agents, which cannot achieved in a simple or effective way only by the OA operational agents. The great flexibility of the architecture also allows a uniform evolution; for example, an improvement of the community protocol may allow the migration of a process from layer 1 to layer 2. [0108] PE process engines for any layer are intended to be a workflow engine (that is, a flow chart), a rule engine, or a combination of the two. For example, support functions related to an operator's on-site intervention are best represented as a flowchart, while diagnostic support functions related to complaints, in the context of a call center, are best represented by A set of rules. Whenever possible and advisable, the use of workflows is preferred as they avoid the complexity of dealing with rule conflicts and rule management. [0109] According to the present invention, each PP personal proxy comprises a process engine. Preferably, the OA operational agents also comprise process engines. More preferably, the operational manager OM also comprises a process engine. Therefore, the process engines are preferably used for each component of the hierarchical layers of the platform and, if possible, are assigned to the same central computer where the component itself resides in order to improve performance levels: the operational manager OM, the operational agents OA and the personal proxies PP have a behavior that is both reactive and proactive, reacting to events but also initiating processes spontaneously. [0110] CA control agents are responsible for the distribution of workflows and data models in the various agents of the platform, for measuring the use of resources and the performance of local agents (i.e. those that run on the central computer) and, finally, the local optimization of resource management. The measurements are sent to the MM management module and other CA control agents. [0111] The mobility between central computers, managed by the MM management module or by an CA control agent of the OA operational agents and of the personal proxies PP makes the procedures for implementation, load balancing and fault tolerance more efficient and automatic If for any reason an agent "descends", the solution may be to clone or take the agent to another running host. The MM management module, through the CA control agent, periodically controls the operational status of the OA operational agents and the personal PP proxies for these purposes. In order to monitor performance, the platform components must also be able to monitor the execution of the various processes. In the case of the PP personal proxy, the supervision of the execution of the various processes is also useful in a perspective of identification of the best practice. [0112] As mentioned above, the solution described in this document aims to manage and support the operations of employees and customers. This is achieved through a set of services offered to operators / customers. [0113] With reference to the eTOM framework (documents: TeleManagementForum GB921 and GB921D, version 4.0, March 2004, and version 5.0 in member evaluation, April 2005), a first embodiment of the solution described in the present invention provides support to operators and customers carrying out activities related to the following groups of vertical end-to-end processes of level 1: - management of the infrastructure life cycle (area of

processes: strategy, infrastructure and product);

-support and availability of operations (area of

processes: operations); -compliance (process area: operations); -security (process area: operations); [0114] Now considering the horizontal dimension of the eTOM framework, the horizontal functional groups of level 1 in which the activities of operators and customers are: -development and management of resources: (process area:

strategy, infrastructure and product); -management of customer relationship (process area: operations; -management and service operations (process area: operations); and -management and resource operations (process areas:

operations). [0115] The management and sharing of operational knowledge with experts and clients may, in turn, be in the area of ​​processes known as company management and, in particular, in the group of level 1 processes known as knowledge and research management. [0116] The flowchart of Figure 3 shows, by way of example, a procedure to support onsite assistance engineers. [0117] First, The platform described above guides the operator, who is entrusted with the performance of a given activity, showing the specific activities to be performed; the operational ways in which the platform offers such service with reference to onsite assistance engineers are presented in Figure 3 and described below. [0118] After the on-site assistance engineer has selected the intervention to be carried out (step 100), the personal proxy associated with it shows (step 110) on the terminal device of the on-site assistance engineer, using the PI interface correspondent, instructional signals organized as workflows intended to repair a fault or execute a task order related, for example, to supply or operation activities (such as database updates, etc.). In the device of the engineer of assistance in situ a specific selection of workflows is shown that guide him in the execution of the intervention according to practices that are alternatives to each other. The individual workflows contain all the information necessary for the on-site assistance engineer to carry out the specific intervention, including possible specific data related to the intervention itself, such as those required to identify the component of a team on which it is to act. : for example, if a stage of a workflow guides the on-site assistance engineer in the activity of changing a card of a team, that stage also contains the indication that allows the on-site assistance engineer to identify in a simple and unique way The card to be changed. Each workflow is presented indicating in addition the result that has been assigned to it and that reflects a proven evaluation of the effectiveness and efficiency of the workflow itself in order to best achieve the objective of the intervention. This result also determines the order of presentation of workflows (listed from the one with the highest result). [0119] Before deciding whether to select one of the indicated workflows, the on-site assistance engineer may request the personal proxy PP to collect measurement data or provide information on the configuration of the equipment. The request involves an exchange of information between the personal PP proxy and the RP resource proxy, where the request of the on-site assistance engineer is forwarded from the personal PP proxy to the RP resource proxy and the corresponding response is sent by the proxy of RP resources to the personal proxy PP, being presented on the terminal device of the on-site assistance engineer using the PI interface (all activity corresponds to step 120). [0120] Further, The onsite assistance engineer can also request that one or more of the proposed workflows (step 130) be displayed for more information before deciding how to proceed. Then, the onsite assistance engineer can decide (step 140) to select one or none of the workflows presented; in case of selection, the chosen workflow is activated in the PP (step 150). [0121] After the activation of a workflow, a process of registering all the activities carried out by the on-site assistance engineer is initiated (step 160). The information collected is stored in the OL operational record and can then be processed to refine existing workflows or to generate and validate new workflows. [0122] In parallel to the activation of the workflow in the personal proxy PP, a cooperative workflow that acts in conjunction with that of the personal proxy can be activated in the resource proxy RP that manages the equipment on which the site assistance engineer must act (step 170). It is the workflow in the personal PP proxy itself that, as a first stage, activates a specific 'cooperative' workflow in the RP resource proxy. The two workflows are executed independently, except for coordination at some points where they can use mutual waiting mechanisms to exchange processing results. Below are some examples of

Information exchanges

[0123] Therefore there may be exchanges of information

(stage 180) between personal proxies PP and proxies of

RP resources to send from the RP resource proxies to

PP personal proxies:

-possible data on the configuration of the equipment, or results of measurements on the equipment, in which the on-site assistance engineer is intervening, which are required to execute the later stages of the workflow. This data is sent automatically, without any request by the on-site assistance engineer, since the RP resource proxy is synchronized with the activities that are being carried out and knows both the times involved and the type of information required;

- the indication that the configuration activities carried out autonomously by the proxy of RP resources at appropriate points in the workflow have actually been carried out;

-the results of the verification, carried out autonomously by the RP resource proxy, of the satisfactory execution of the intervention by the on-site assistance engineer (in case of failure, verification of its repair, in case of task order of supply, verification of the correct execution of the requested configuration activities).

[0124] After the onsite assistance engineer

You have received the indication via the personal proxy PP,

that comes from the RP, from the satisfactory conclusion of the

intervention (stage 190), the intervention is considered

closed (stage 200), and the onsite assistance engineer

You can select a subsequent intervention.

[0125] In the event that an onsite assistance engineer decides not to select any of the workflows proposed for him, or if there is no workflow associated with the intervention to be performed, the onsite assistance engineer may request in any case, through the personal proxy PP that, in turn, interacts with the appropriate resource proxy RP, information, measurements or execution of commands on the computer on which it should act, also providing remote access to the communication line interface (CLI) of the equipment. This is done as support for the execution of the intervention (step 220) and / or as verification of the correct execution of the intervention (step 230), before closing the intervention (step 200). In addition, all activities performed by the onsite assistance engineer are recorded (step 210), and the information collected is stored in the operational record and can be further processed in order to generate and validate new workflows or to refine existing workflows. [0126] The technician who has chosen to follow the stages indicated by a specific workflow can interrupt the execution of the workflow at any point and continue without being guided, interacting with the team (through the chain between personal proxies PP and proxies of RP resources) to obtain information and / or to carry out actions on the equipment itself. [0127] Figure 4 presents an example of a cooperative workflow for the replacement of a card of a team. In particular, Figure 4 in question presents an example of a cooperative workflow that aims to guide the onsite assistance engineer in a replacement activity for a card of a team. [0128] The on-site assistance engineer, having chosen the workflow to be activated according to the criteria described above, requires activation, via the PI interface, of the workflow selected in the personal proxy PP (step 1100). [0129] The workflow at the PP personal proxy end starts (step 300) and, as a first action, activates the related cooperative workflow at the RP resource proxy (steps 310 and 500). An on-site assistance engineer is sent a message on his terminal device, using the IP, to wait for the activation of the RP workflow (step 1110). [0130] The PP personal proxy workflow proceeds with the preliminary activities to replace the card, indicating to the on-site assistance engineer the instructions to open the equipment (step 320) by describing the on-site assistance engineer's terminal device , using the PI interface, of the manual operations to be performed (step 1120) and the indications to identify the card inside the equipment (step 330), once again through the display of the terminal device of the on-site assistance engineer, using the PI interface (step 1130), and also through the help of schemes that facilitate the identification of the card. [0131] At the same time, The workflow of the RP resource proxy proceeds with the introductory management activities to the replacement of the card (step 510) such as, for example, the deactivation or change of services still active therein or to pass the card to a card. non-operational status When these activities have been performed, the RP resource proxy workflow notifies the PP personal proxy workflow that it can continue (step 520). [0132] The PP personal proxy workflow informs the on-site assistance engineer to disconnect the wiring from the card being replaced (step 340), presenting useful information for manual activity on the terminal device of the on-site assistance engineer, using the PI interface (step 1140), while informing the RP resource proxy workflow to continue with the next stage of activity monitoring (step 530) such as, for example, checking whether the physical ports involved signal the disconnected wiring status. When all the wiring of the card to be replaced has been disconnected, the RP resource proxy workflow informs the PP workflow (step 530). [0133] The PP personal proxy workflow proceeds with checking if the card is ready to be removed from the equipment (step 350), by advancing the RP resource proxy workflow to the card release activity (step 540) and instructing the on-site assistance engineer to verify the released card signal (step 1150). [0134] When the RP resource proxy workflow completes the card release activities, such as disconnecting the card, it informs the PP personal proxy workflow (step 540), which proceeds with the action of the actual physical removal of the card (step 360), indicating to the onsite assistance engineer the manual activities to be performed (step 1160), such as release levers to be activated and indications of the actions to remove the card. [0135] The RP resource proxy workflow monitors manual activity, checking the status and signals that come from the equipment (step 550) such as, for example, the free slot status, and informs the workflow of the personal PP proxy when the card is no longer present. [0136] The PP personal proxy workflow, after receiving the completion messages of the activities of both the PP personal proxy workflow and the on-site assistance engineer through the PI interface, proceeds with the insertion action of the new card (step 370), sending the necessary information to the PI interface (step 1170) and informing proxy resource workflow of RP resources. The latter supervises the insertion of the new card (step 560), for example, checking if the slot has moved from the free state to the busy state, until informing the PP personal proxy workflow of the correct insertion of the new card (stage 570). [0137] The RP resource proxy workflow proceeds with the checks and configuration of the new card (step 580), while the PP personal proxy workflow awaits the completion of the last activity (step 380) and informs the on-site assistance engineer, through the PI interface, about the ongoing check (step 1180). [0138] At the end of the configuration of the new card, the RP resource proxy workflow informs the personal proxy workflow PP (step 580) to proceed with the wiring connection (step 390), by presenting to the on-site assistance engineer on your terminal device, using the PI interface, of the manual activities to be performed (step 1190) with the help of schemes related to the type of card and wiring. [0139] During the wiring connection, the RP resource proxy workflow monitors the card's ports (step 590), for example controlling the status of the ports that indicates that the wiring is connected. Only when all planned wiring has been reconnected, the RP resource proxy workflow informs the PP personal proxy workflow (step 590) and proceeds with the verification and configuration of the ports (step 600) such as , for example, the reactivation of the services or their transition from the temporary configuration previously executed (step 510). [0140] The PP personal proxy workflow awaits the completion of the new card's port configurations (step 400) and informs the on-site assistance engineer through the PI interface (step 1200) that such activity is still in progress. course. Once the port configuration is complete (step 600), the RP resource proxy workflow informs the PP personal proxy workflow and ends (step 610), while the personal proxy workflow PP guides the on-site assistance engineer to perform the closing of the equipment housing (step 410) by providing appropriate information on the terminal device of the on-site assistance engineer using the PI interface ( step 1210). [0141] Finally, The PP personal proxy workflow completes its execution (step 420) informing the on-site assistance engineer that he is waiting for the completion of the workflows (step 1220) and awaiting the completion of the proxy resource workflow of RP resources. The workflows end, synchronizing in the last action of the PP workflow (step 430), with information for the on-site assistance engineer that the intervention has been satisfactorily completed (step 1230). [0142] Instead, Figure 5 illustrates an example of a procedure to support consultants for a call center: In fact, the solution described in this document also allows you to apply the guidance service to consultants of a call center. [0143] After the call center has received a complaint from a customer (hereinafter referred to as a problem notification: TR (Trouble Report)) or a request for a new service (hereinafter referred to as a customer order: CO (Customer Order)) (step 1300), The personal PP proxy associated with the call center advisor opens a session with the RP resource proxy (s) associated with the network equipment of interest for the client request and collects information required for interaction with the customer (in case of a problem notification it is checked if there are failures in the equipment involved in the offer of customer services) (step 1310). [0144] After collecting the network data, If the personal proxy PP does not require any additional information (verification made in step 1320) and is dealing with a customer's complaint (verification made in step 1330), the collected data is processed in order to carry out a first diagnosis (step 1380). On the other hand, if the personal PP proxy does not require additional information (check performed in step 1320) and is dealing with a request for a new service (check made in step 1330), the next stage is the creation of a task order (WO, Work Order) (step 1420). [0145] After collecting the network data, if the personal PP proxy requires additional information (check performed in step 1320), shows a sequence of questions on the customer's adviser device (step 1340), using the corresponding PI interface, to acquire additional details about the client's TR / OC. In case of a problem notification, these questions can also be requests for the client to carry out punctual checks / actions that can lead to the resolution of the problem that is the cause of the problem notification, for example, requests to verify whether everything the wiring of a device at the customer's premises (CPE, Customer Premise Equipment) is properly connected and proceed with the correct wiring connection in which connection failures have been detected. [0146] The call center advisor, interacting with the client, provides the PP personal proxy with appropriate answers to the questions asked (step 1350). In the event that the client cannot provide the requested data or in order to integrate the data provided by him, the call center advisor can ask the personal proxy PP to collect measurement data or provide him with the configuration information related to the part of the network that the specific customer is interested in. This implies an exchange of information between the personal PP proxies and the RP resource proxies that control said network part, with the request of the call center advisor forwarded by the personal proxy PP to the proxy of RP resources and the corresponding responses sent by the proxy of RP resources to the personal proxy PP and shown by the latter to the operator through the PI interface ( all activity corresponds to step 1360). [0147] At the end of the sequence of questions or in case of a problem notification, After the solution of the problem notification itself based on a customer check / action (check performed in step 1370), the next stage is step 1420. [0148] In the case of a problem notification (check made in step 1370) of the client, at the end of the guided data collection stage (of the client and / or the network), the personal proxy PP, using a system based on rules, formulates a first hypothesis about the main cause of the problem notification (step 1380). [0149] If the client can repair the fault (check made in step 1390), the personal PP proxy of the call center consultant opens a session with the personal PP proxy of the client, asking him to execute a specific workflow to solve the notification of problem (step 1400). Then, the consultant of the call center can start to carry out other activities, being informed at the same time about the result of the execution of the work flow by the client. [0150] After receiving the result of the workflow (step 1410), an appropriate problem receipt (TT, Trouble Ticket) is created that will take into account the result of the workflow (if the workflow has been executed successfully, the TT will record the solution of the problem notification; otherwise, it will contain useful information to create one or more WR (Work Request) tasks for on-site support engineers). [0151] If the client cannot resolve the fault (check made in step 1390), the next stage is the creation of a problem shelter (step 1420). After collecting the problem notification / customer order data and, in case of a problem notification, after the first level diagnosis and / or the solution of the problem notification, the personal proxy PP provides the advisor of the call center all the data required to create a problem receipt or a task order that, in case of a customer request not yet satisfied, generate one or more requests for WR tasks for onsite assistance engineers (step 1420). After the creation of the TT / WO, the activity of the call center consultant ends (step 1430).

[0152] Instead, the flowchart of Figure 6 refers to a procedure to support customers; The support for the execution of operational activities described in this document also applies to the client. [0153] After a customer has detected a fault (step 700), the client itself activates on its device (usually a PC or PDA) the personal PP proxy associated with it (step 710). [0154] The personal proxy PP opens a session with the proxy (s) of RP resources associated with the equipment located at the client's premises in order to identify any possible failure in said equipment (step 720). In the event that there are no equipment failures at the customer's premises (check performed in step 730), the personal proxy PP shows on the client's device (step 740), using the corresponding PI interface, a sequence of questions intended to acquire more details about the fault detected. The client provides the PP personal proxy with the appropriate answers to the questions asked (step 750). [0155] At the end of the sequence of questions, the personal proxy PP checks if the cause of the error has been identified and if said cause can be repaired by the client (verification performed in step 760) and, if so, activates an appropriate workflow (step 770) that guides the client in solving the problem. The personal proxy PP also activates a process for registering customer activities (step 780): the information collected is stored in the operational log and can be subsequently processed to refine existing workflows or to generate and validate new workflows. [0156] At the end of the workflow the client performs a check on the repair of the fault (step 790); If said check has a positive result, the customer activity ends (step 810). On the other hand, if the check has a negative result, the personal proxy PP informs the client to contact the call center (step 800); After notification by the PP personal proxy, the client activity ends (step 810). If the cause of the failure has not been identified or if the client cannot solve it (verification carried out by step 760), the personal proxy PP informs the client to contact the call center (step 800). After said notification by the personal proxy PP, the client activity ends (step 810). [0157] In the event that there are equipment failures at the customer's premises (check performed in step 730), the personal proxy PP performs an additional check to verify if the customer can repair these failures (check made in step 820). In case of a negative result, the personal proxy PP informs the client to contact the call center (step 800). In the case of a positive result, the personal PP proxy activates an appropriate workflow (step 770) that guides the client in solving the problem. [0158] After the activation of the appropriate workflow, the personal proxy PP also activates a process of recording the client's activities (step 780): The information collected is stored in the operational record and, as mentioned above, can be processed in order to refine existing workflows or to generate and validate new workflows. At the end of the workflow flow, the client checks if the fault has been repaired (step 790); If said check has a positive result, the customer activity ends (step 810). On the other hand, if the check has a negative result, the personal proxy PP informs the client to contact the call center (step 800); after notification by the personal proxy PP, the client activity ends (step 810). [0159] The workflows executed in the client's personal PP proxy normally provide that the client is also informed about possible actions carried out automatically by the RP resource proxies and that an explicit consent to their execution can be granted. [0160 ] The flowchart in Figure 7 illustrates a cooperation procedure between operators. In fact, the platform described in this document provides an additional service to support the operator, who is entrusted with the performance of a given activity (for example an on-site intervention or the processing of a customer request), managing interactions with

<dl><dt>others </dt><dd>possible operators or between a operator and a </dd></dl>

<dl><dt>client. </dt>&lt;dd /&gt;</dl>

<dl><dt>[0161] </dt><dd>TO continuation he describe the practices </dd></dl>

operational measures adopted for interaction between operators. [0162] The PP personal proxy decides autonomously (for example, after the detection of an intervention that has not been satisfactory in the case of on-site assistance engineers) or after an operator notification, activate a session with the other personal PP proxies of others. operators (step 1500). [0163] In case of an automatic activation (check made in step 1510), the personal proxy PP, Based on the knowledge of the type of activity that the operator is performing (inferred from the available data or obtained from an explicit indication of the operator) and on the macro skills required to carry it out, try to activate a session using an ordered list of names of operators to contact, organized according to macro skills (step 1600). [0164] If the activation is not successful (check performed in step 1610), the personal proxy PP checks with the operator (step 1640) whether to continue with his attempt to activate a session or stop. If the operator decides to continue, the personal proxy PP makes another attempt to activate a session with the next name in the list (step 1600) and continues iteratively until it manages to activate a session or until the operator decides to interrupt the procedure. In the second case, the personal proxy PP terminates the session activation procedure (step 1590). [0165] If the activation is successful (verification carried out in step 1610), a session between the operators is initiated, in which the personal proxy PP offers a set of tools for cooperative work, such as making all data on the activity to be carried out and on the stages already carried out visible to both operators or for sharing possible network data that the operator, who has requested the support, has already acquired (step 1620). [0166] Upon notification of the operator, the personal proxy PP then proceeds with the closing of the session (step 1570). [0167] In case of activation on request by the operator (check made in step 1510), The personal proxy PP, based on the knowledge of the type of activity that the operator is carrying out (inferred from the available data or obtained from an explicit indication of the operator) and on the macro-skills required to carry it out, presents (step 1520) an ordered list of names (the order is what the personal PP proxy would follow if it had to activate the session automatically), among which the operator selects the desired name (step 1530). [0168] After the operator has selected the name, the PP personal proxy attempts to establish a session with the PP personal proxy associated with that name (step 1540). If the activation is not successful (check performed in step 1550), the personal proxy PP checks with the operator (step 1580) whether to proceed with the attempt to activate a session or stop. If the operator decides to continue, the personal proxy PP once again displays the list of names, properly updated to take into account the unsatisfactory attempt (s) (step 1520) and continues iteratively until it succeeds activate a session or until the operator decides to interrupt the procedure. In the second case, the personal proxy PP ends the session activation procedure (step 590). [0169] If the activation is successful (verification carried out in step 1550), a session between the operators is initiated, in which the personal proxy PP offers a set of tools for a cooperative work of the type already considered previously (step 1560). Upon notification of the operator, the personal proxy then proceeds with the closing of the session (step 1570). [0170] The interaction between customers and operators uses mechanisms similar to those mentioned above for the interaction between operators; In this case, it is possible to assume that the cooperation will normally involve the client and an advisor of a call center and that it will be the personal PP proxy of the client that, upon request of the client itself or autonomously, establishes a session. Also in this case, the client may decide to interrupt the attempt to establish a session with an operator at any time. In the case of a client request, the personal proxy PP presents to the client an ordered list of the names of consultants of a call center and allows the client to select the advisor to contact. [0171] In order to offer the services exemplified above, the platform described maintains a set of data for operators, customers and workflows, and performs a dynamic management of processes to adapt to both operational changes (introduction of new workflows after the introduction of new equipment, deletion of workflows related to activities in equipment that are no longer in the network, etc.) as to changes in the characteristics and in the number of employees (introduction of new operators, update of the data of the operator profiles, etc.) and of clients (introduction of new clients, update of customer profile data, etc.). [0172] Operator profiles are defined based on a small number of standard basic profiles; These profiles specify the macro skills (for example, network domains / services in which the operator can carry out activities: switching, transmission, ADSL access, etc.) of the operators and, for each macrohability, the corresponding degree (indicates the operator skill level in a given field). The profile also indicates whether the operator is an on-site assistance engineer or an internal service operator, or a call center consultant indicates which virtual equipment it belongs to and provides its authentication credentials. The data in these profiles are dynamically updated to take into account, for example, new macro-abilities or grade changes; The profile model is stored in the ODB database. The dynamic update of macro skills is carried out in a timely manner to allow all platform services (for example, the interaction between operators) to use updated data. Regarding the loading of operator profile data, each PP personal proxy maintains only the profile of the operator with which it is associated (each PP personal proxy is associated with a specific operator): OM acquires the data of said profile interacting with appropriate external systems (WFM systems); Therefore, the platform includes a centralized inventory (EI skills inventory), in which the profiles data of all operators (downloaded from the WFM) are stored. Upon activation of each personal PP proxy, the operator profile data associated with said personal PP proxy is automatically downloaded from the inventory of skills EI, via the operational manager OM, to the personal PP proxy itself. The EI inventory is updated periodically and, with each update of the inventory data itself, the data is sent to the corresponding personal proxy PP. [0173] Customer profiles are defined based on a small number of standard basic profiles; These profiles specify the service (s) for which the customer can carry out repair activities (for example, ADSL service, ISDN service, etc.) and the client's authentication credentials. Profile data is dynamically updated to take into account, for example, new services that have been agreed upon; The profile model is stored in the ODB database. The dynamic update of client profile data is carried out at the appropriate time to allow all platform services to use updated data. With regard to the loading of client profile data, each PP personal proxy maintains only the client profile with which it is associated (each PP personal proxy is associated with a specific client): the OM operational manager acquires the data of said profile interacting with appropriate external systems (business support systems); therefore, the platform includes a centralized inventory (inventory of EI skills), in which the data of the profiles of all the clients (downloaded from the business support systems) are stored. Upon activation of each PP personal proxy, the client profile data associated with said PP personal proxy is automatically downloaded from the EI inventory, via the OM operational manager, to the PP personal proxy itself. The EI inventory is periodically updated and, with each update of the inventory data itself, the data is sent to the corresponding personal proxy PP. [0174] With regard to workflows that support the operations of on-site support engineers, the ODB database maintains, for each workflow, a set of features such as the workflow identifier (this can be a progressive numerical identifier automatically generated by the platform), the workflow version, the workflow result, the type of intervention to which the workflow (for example, failure, supply activities, operating activities, etc.), the identifier of the specific intervention to be performed (for example, in case of failure, it is possible to indicate a link failure, a user card failure, etc.), the degree of macro skills required to carry out the intervention, if applicable (for example, expert on-site assistance engineer and on-site assistance engineer rookie), etc. These features are provided when the workflow is created / modified; The result is updated dynamically, according to what is mentioned later. The creation / modification of the workflows that support the operations, stored in the OBD database, and the corresponding cooperative workflows, stored in the MDB database, It is done through an appropriate graphical interface that allows parallel editing of the two correlated workflows in order to facilitate congruence checks on what has been processed. [0175] Similar considerations apply with regard to workflows that support customer operations: The ODB database maintains, for each workflow that supports the client, a set of characteristics similar to those of the workflows for the on-site assistance engineer and also applicable to the client's case. [0176] For the workflows that support on-site support engineers, two management functions are contemplated. [0177] Regarding the workflow load, The download of the workflow in the personal proxy PP will be carried out by the CA control agent associated with it. Upon activation of the personal PP proxy, no workflow is downloaded; Workflows are downloaded to the PP personal proxy only after an explicit request from the PP personal proxy itself: After the assumption of an activity given by an on-site assistance engineer and the selection made by it of a workflow to be carried out or displayed on your device, the personal proxy PP checks if it can Directly access this workflow to the extent that it is already present in the local memory area and if it is updated (using the version indicator associated with workflows). If the workflow is not present or not updated, it is downloaded from the ODB database through the CA control agent; The workflow will remain stored in the personal PP proxy for any possible future use. [0178] Similarly, after the activation of the RP resource proxy, no workflow is downloaded; Workflows are downloaded to the RP resource proxy only after an explicit request from the RP resource proxy itself: at the moment when the RP resource proxy receives from the PP personal proxy the request to activate a workflow since it supports an operation, the PP personal proxy checks if it is directly accessible as long as it is already present in the local memory area and if it is updated (using the version indicator associated with workflows). If the workflow is not present or not updated, the RP resource proxy downloads it from the MDB database; The workflow will remain stored in the RP resource proxy for possible future uses. [0179] Therefore, a procedure is contemplated to dynamically manage the “result” of workflows. The result of the workflow is based on both the time / cost data (related to the activities carried out by the on-site assistance engineer and the cost of the materials used to perform these activities) and the assistance engineer's preferences in situ for a given workflow. In order to acquire this data, at each execution of a workflow, a set of parameters related to that execution is collected (the collection of workflow parameters is carried out by the personal PP proxies) and is updated .

Examples of such parameters are the total execution time of the workflow in the personal proxy PP, the CPU utilization, the number of operators that have chosen the workflow, etc. The data collected / updated is stored in the PDB performance database. Periodically (for example, at fixed intervals of time), it is necessary to analyze and process these parameters to obtain a new value of the result of each workflow. Then, the new result of the workflows is communicated to the various personal PP proxies. [0180] Similar management functions are provided for workflows that support customers: Workflows are downloaded to the PP personal proxy after a request from the PP personal proxy itself, after the identification of the fault / problem to be dealt with by said workflows, or upon receipt of a request to activate a flow of specific work that comes from the personal PP proxy of an advisor of a call center. In particular, in the event that a plurality of workflows can be used to guide the client, only the workflow having the highest result at that time is downloaded to the personal proxy PP. Also for the workflows for the client, a dynamic result management mechanism is provided, appropriately calibrated based on the parameters that can be identified in the client part. [0181] As noted, the interaction between the personal proxy PP and the operator or the client is carried out using an appropriate personal PI interface. The PI interface is created using technologies that depend on the type and computational power of the device used by the operator / client (cell phone, PDA, laptop, desktop computer, etc.), such as, for example, client technologies. web-based server (HTML pages, Java applets, stand-alone Java applications) or standalone agent technologies. The PI interface is designed in a manner consistent with the principles of management in order to allow the operator / client to achieve the objective set with the best effectiveness, efficiency and satisfaction in all specific contexts of use. In the development of the PI interface, great attention has been paid both to code optimization, in order to make more effective the interactions and activities that PP personal proxies have to perform in cooperation with RP resource proxies, as well as the management and user-friendliness aspects of the GUI in order to greatly improve the operator / client's ability to carry out the task assigned to it. [0182] In the case of an operator, following an activity request (on-site intervention or notification of problem / customer order), the WFM sends to the OM operational manager the name of the operator chosen and the details of the activity to be performed . The OM operational manager forwards said data to the personal proxy PP associated with the chosen operator, through the operational agent OA that coordinates said personal proxy PP; in turn, the personal proxy PP informs through the corresponding PI interface that an activity must be performed. [0183] Once the operator has received information on his PI interface that an activity must be carried out, he proceeds as follows: -starts, from the initial page of the PI interface, the

system entry procedure and of

authentication; depending on the operator profile

sections dedicated to functions may or may not be displayed

"privileged"; authentication data is

verify with those stored in the inventory of EI skills for the operator associated with said personal proxy PP;

- observes the data of the activity assigned to it and executes the procedure for assuming said activity (for example, on-site intervention or notification of problem / customer order); at this point, the operator can access, through the PI interface, graphic and navigation environments to aid operation; The functions provided by these environments are partly available to and used by all types of operators (for example, onsite assistance engineers and call center consultants) and in part are specific to a particular type of operator.

[0184] These functions allow:

-show the location of the equipment (for example, in an exchange) in which to carry out the intervention (onsite assistance engineers);

-show the equipment interface and the graphic identification of the hardware component (rack, card, port, device, etc.) on which it is necessary to intervene (on-site assistance engineers);

-present the workflow (with a possible previous operation of selection between different workflows) in an interactive way in order to guide, step by step, the operations of the engineer (onsite assistance engineers);

-present a sequence of questions in an interactive way in order to acquire, step by step, the information required to detail a client's request (telephone service center consultants);

- Suggest actions that the client must carry out in order to resolve a problem notification submitted by the client (telephone service center advisors);

-present hypotheses made on the clause of the notification of problem of a client (advisers of call centers);

-show the configuration of the connections between the personal PP proxy and the RP resource proxy, and present the proxy "answers"

[0185] of RP resources to configuration actions,

adjustments, measurement, tests, etc. carried out by the RP

either autonomously or upon request of the proxy

PP staff (all operators);

-access remotely, through the RP, to a CLI (command line interface) on the equipment where the intervention is being carried out (onsite assistance engineers);

-show as much online documentation as possible to support the activity (all operators); and

-access to the "traditional" functions of communication with other operators (virtual equipment operators, administration staff, internal service operators, call center consultants): voice call, email, conversion, shared whiteboard, etc. (all operators).

[0186] In the case of a client, the client himself, after the

activation of your personal PP proxy, run the

system entry and authentication procedure and

receive all the data on your device (questions,

guidance workflows, etc.) required to

Fix a bug detected by him.

[0187] The functions offered allow:

-present the workflow in an interactive way in order to guide, step by step, the client's activities;

-present a sequence of questions in an interactive way in order to acquire, step by step, the information required to identify the cause of the failure detected by the customer;

-present the hypothesis of the main cause of a failure;

- show the configuration of the connections between the personal proxy PP and the proxy of RP resources, and present the "answers" of the proxy of RP resources;

-report the need to contact an operator to solve the fault; -access communication functions with a

operator. [0188] The components that support the operations described above can also be applied in management contexts based on more traditional technological approaches (client-server paradigm). [0189] If, for example, management solutions that adopt a hierarchical approach based on client-server technology are examined (as exemplified, for example, in US-A-2004/0196794), the functions that support the operations (of operators and clients) described above are still effective and can be offered using a platform that, for the functional part, does not change with respect to what has been presented in Figure 2 of this document, while for the network and services management part, it is based on a different architecture, such as the architecture described in Figure 2 of document US-A-2004/0196794. In particular, in this case, if the objective is to adopt a conservative approach that does not include the modification of the management resource (lower layer network management station / unit) that directly manages the network devices, the personal proxy PP will interact directly with the corresponding lower layer network management station to carry out all interactions from / to the network (which, in the embodiment described above, they were carried out through the RP resource proxy), using communication modalities similar to those adopted between lower layer and upper layer network management stations. Alternatively, the personal proxy PP may interact with an upper layer network management station, to which the topological information of the lower layer network management solutions belongs, thereby avoiding having to deal with such information directly. In any case, except for the modifications of the management component, there will be no cooperative workflow in the corresponding network management station; however, this does not jeopardize in any way the validity and effectiveness of the function to support operations, to the extent that this only represents a possible alternative to the preferred embodiment of the present invention. [0190] It should be noted that although the procedure that guides the onsite assistance engineers in carrying out a given intervention, as described in relation to Figure 3, It refers to the selection of the intervention that will be carried out by an on-site assistance engineer, the modalities with which said selection is made are diverse and depend on the operational paradigm adopted and the functions performed by the WFM system. In one embodiment of the present invention, the on-site assistance engineer is only responsible for the intervention shown by the personal PP proxy on its PI interface and downloaded to the personal PP proxy itself via the WFM-OM chain. [0191] In an alternative embodiment, the onsite assistance engineer selects an activity from which it can be carried out on a computer at a given location; In this case, the only indication received by the on-site assistance engineer, through the personal proxy PP that received it from the WFMOM chain, is related to the location to which it has to go (the WFM only manages the shifts Newspapers from onsite assistance engineers between the various locations, without telling them what to do). [0192] The procedure described above in relation to Figure 3 indicates that appropriate workflows are proposed to the onsite assistance engineer. This is done through the interaction between the personal proxy PP and the operational manager OM. When an on-site assistance engineer selects an intervention, the personal proxy PP asks the OM operational manager to list all workflows to support that intervention. The OM operational manager creates this list dynamically, based on the workflow information available in the ODB database, and sends it to the personal proxy PP, which presents it to the on-site assistance engineer. [0193] In a first possible embodiment of the present invention, given a specific intervention, all the onsite assistance engineers are presented with the same workflows, regardless of their particular skill level. [0194] In an alternative embodiment, given a specific intervention, the workflows presented to an onsite assistance engineer depend on their own degree of skill. If the on-site assistance engineer is an expert, you are presented with higher level workflows; otherwise, the proposed workflows are more detailed or, in any case, allow access to documents and technical standards useful for the on-site assistance engineer. In the first case, the selection of the OM operational manager about the workflows that will be put on the list is, therefore, considering only the type of intervention to be carried out, while in the second case it is also It takes into account the profile of the onsite assistance engineer and, in particular, his skill level with reference to the skill required to carry out the intervention in question. [0195] Again, in an alternative embodiment of the present invention, the activation of the workflow in the personal proxy PP does not require the activation of a cooperative workflow in the resource proxy RP: the workflow in the personal PP proxy only interactively activates specific workflows in the RP resource proxy in order to collect some given data / measurements, request the execution of certain activities on the equipment or offer remote access to possible command line interfaces. Workflows execute what is requested and return the result to the personal proxy PP. In this case, the RP resource proxy does not know what the operator is doing, guided by the personal PP proxy. This means that, as a last step, the workflow in the personal proxy PP must ask the RP resource proxy to verify the result of the intervention carried out by the on-site assistance engineer, before considering that such innervation has been carried out satisfactorily. [0196] As noted, the procedure to support an advisor of a call center allows you to activate, whenever necessary, a workflow on the client's personal PP proxy. This requires that the personal PP proxy be active. The activation of the personal PP proxy can be carried out automatically, with a request for activation by the personal PP proxy of the operator or, otherwise, manually with the activation of the personal PP proxy by the client. In the second case, the personal PP proxy itself may already be on the client's device and must be activated only or, otherwise, the client can download it from a remote location, in particular from an intentionally provided Internet site. In an alternative embodiment, said procedure does not contemplate the activation of a workflow in the client's personal proxy PP: The advisor of a call center only interacts with the client through a paradigm of questions and answers, asking him at most to carry out some particular actions. [0197] In addition, the procedure to support the customer contemplates an alternative embodiment in which, once the personal PP proxy has detected the need to contact an advisor of a call center to solve the failure notified by the customer, Instead of suggesting the client to contact the call center, directly activate a session with the personal proxy PP of an advisor of a call center. [0198] With regard to cooperation between operators, again what is described below can be observed. The procedure described with reference to Figure 7 contemplates the preparation of an ordered list of names of operators to contact, used by the PP to open a session between operators or, if not, presented to the operator: said list is created in a manner dynamic. When the PP personal proxy must open a cooperative session, ask the OM operational manager to create the list of operators to contact, providing the required indications (for example, indication of the activity performed by the operator and of the skill required for said activity); the OM operational manager consults the inventory of EI skills and, based on the information obtained, creates the required list (introducing operators of the same virtual equipment or other equipment). The list is sorted according to the skills of the operators and, in the case of different teams, according to the teams [0199] (first the operators of the same virtual team are introduced, according to the decreasing degree of skill, and then the operators of other teams, again in decreasing degree of ability). Finally, the OM operational manager sends the created list to the personal proxy PP. [0200] In an alternative embodiment to the one presented above, the personal proxy PP can open sessions between an operator and two or more other operators, which can interact with each other through various tools, including tools to support cooperative tasks. [0201] Also in the case of cooperation between customers and operators, the same dynamic creation modalities apply, through the OM operational manager, from the list of operators to contact, used by the personal proxy PP to open a session between clients and operators or, if not, presented to the client. [0202] Taking into account the management of the operator profiles in the personal proxy PP in an alternative embodiment to the one presented above, each PP maintains, in addition to the profile of the operator with which it is associated, data from other operator profiles (this is done for performance reasons: this reduces the time to access data from other operators to contact). In particular, a first alternative contemplates that said data must refer to all operators of the same virtual equipment as that of the operator with which the personal proxy PP is associated. A second alternative is also possible, according to which the data of the operator profiles stored in the personal proxy PP refer to a subset of the virtual equipment operators of interest and, in particular, to operators with a high degree of macro-abilities. required for the equipment: for each macrohability one or more profiles are selected; These profiles are the profiles of operators who are experts in regards to a specific macrohability (that is, whose ability is the highest among those of a given virtual team). The ways in which such data is downloaded for the first time and updated subsequently do not vary with respect to what has been described for the operator profile associated with the personal proxy PP; however, in this case, the data forwarded to the PP personal proxy also indicates those that refer to the operator profile associated with the PP personal proxy itself. [0203] The management of the operator profiles in an additional embodiment is completely dynamic, in the sense that the personal proxy PP is not associated a priori to any specific operator: the association with a given operator is performed when the operator is authenticated. In this case, after the authentication by the operator, the PP proxy forwards the authentication data supplied by the operator to the operational manager OM and asks it to download the profile data related to said operator. The operational manager OM, after checking the validity of the credentials provided, downloads the profile data in question in the PP. Also in this case, it is possible to contemplate an alternative embodiment in which the operational manager OM sends to the personal proxy PP not only the data of the operator profile with which it is associated, but also the data of other operator profiles, with the same options shown above (data related to all operators of the operator's virtual equipment or with a subset of the operators of the virtual equipment). [0204] As regards the workflow management procedure to support operators, with respect to what has been mentioned above, it is possible to contemplate alternative embodiments of the modalities to be adopted to download workflows. [0205] A first embodiment contemplates that in the activation of the personal proxy PP, all workflows to guide the operator are downloaded therein. [0206] Instead, according to a second embodiment, in the activation of the personal PP proxy or after the authentication of the operator (depending on whether the personal PP proxy is associated with an operator in a static or dynamic way) all workflows to guide the operator are downloaded in it excluding the possible workflows that can only be applied to specific virtual machines. It is possible to define workflows that apply only to specific virtual teams, depending on the characteristics of the equipment managed by these teams and / or depending on the particular skills of the team members. [0207] Finally, according to a third embodiment, in the activation of the personal PP proxy or after the authentication of the operator, only workflows that are compatible with the skills of the operator with which the PP is associated are downloaded. [0208] Depending on the possible alternative embodiments adopted, the functions of the PI interface may also change: in particular, only if the indication received by the on-site assistance engineer at the PI interface is that related to the location to which it should be directed, will the PI interface present to the on-site assistance engineer the set of interventions to be carried out in a given location (in a manner consistent with the engineer profile of

5 on-site assistance), and it will be the on-site assistance engineer himself who selects the intervention he will perform and which he will take care of. [0209] Therefore, without prejudice to the underlying principles of the invention, the details and

10 Embodiments may vary, even appreciably, with respect to what has been described herein simply by way of example, without departing from the scope of the invention defined by the appended claims.

15

REFERENCES CITED IN THE DESCRIPTION

This list of references cited by the applicant is intended only to help

to the reader and not part of the European patent document. Although he has put on

maximum care in its realization, errors or omissions cannot be excluded and the EPO

declines any responsibility in this regard.

Patent documents cited in the description

<dl><dt>• </dt><dd>US 20040044542 A [0006] [0008] [0014] </dd></dl>

<dl><dt>• </dt><dd>WO 2005018249 A [0010] [0021] [0082] [0083] </dd></dl>

<dl><dt>• </dt><dd>US 5826239 A [0012] [0019] </dd></dl>

<dl><dt>• </dt><dd>US 20040196794 A [0191] </dd></dl>

Patent documents not cited in the description

<dl><dt>•</dt><dd> G. Valente; A. Rigallo. Remoter: an Operational Knowledge Management System for Telecommunication Operators. Workshop on Knowledge Management and Organizational Memories, 16th European Conference on Artificial Intelligence, 2004 [0006]</dd></dl>

<dl><dt>• </dt><dd>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, January 2001, 1-92, http: // www.eurescom.de/-pub-deliverables/P800-series/ P815 / D1 / p815d1vo12.pdf [0011]</dd></dl>

<dl><dt>•</dt><dd> W. Sull A Distributed Environment for Enabling Lightweight Flexible Workflows. Proceedings of the 31st Annual Hawaii International Conference on System</dd></dl>

Sciences, 1998, 355-364 [0013]