MXPA00002978A - Integrated customer interface for web based communications network management - Google Patents

Abstract

A web-based, integrated customer interface system (30) for enabling customer management of their communication network assets. A web-based GUI (20) enables a customer to interact with one or more network management resources and telecommunication services. The integrated interface system (30) includes:1) a customer's network report management;2) a centralized in-box system for online notifications to client workstation;3) a real-time network services monitoring system;4) broadband system for presenting physical and logical views of data networks and performance information;5) a toll-free network management system enabling customization of 800/8xx toll free number routing;6) Outbound Network Management (ONM);7) packet-switched events monitoring;8) a trouble ticket tool;9) web-based invoice reporting for access to billing information;10) web-based call manager;11) on-line order entry and administrative service;12) system for handling security and authentication.

Description

INTEGRATED CUSTOMER INTERFACE FOR ADMINISTRATION OF THE COMMUNICATIONS NETWORK WEB-BASED • 5 The present invention relates in general to systems for supplying information on the public Internet, and in particular, to a data management service based on WWW / Internet for customers of suppliers of telecommunications services. In conventional systems of administration of • reports and data enabled for clients, a connection is made to a large legacy system via a dial-up connection from the personal computer belonging to the client or to the workstation. This connection frequently, though not always, emulates a steerable terminal by the legacy system. Dial-up access requires client software at the client's workstation to provide dial-up services, communication services, emulation and / or translation services and generally some form of adaptation to the resident client so that the legacy application connects with the mid-range computer or main computer running the legacy system. There are several problems associated with this approach: First, the aforementioned software is very hardware specific, and customers generally have a wide range of workstation vendors, which requires extensive inventory for distribution, and generally, intense waiting of the client through the connection e • initial installation before reliable and safe 5 sessions are possible. If the client's hardware platform changes through an improvement, most of these elements need renegotiation. Second, dial-up, modem, and communications software interact with each other in different ways that are not always predictable for a client application, requiring extensive problem-finding and problem-solving for a company that wishes to make available to the client. customer the legacy system, particularly when several telephone exchanges, dialing standards or signal standards 15 are involved. Third, when a company wants to make more than one system available to the customer, the customer application for a legacy system can not connect to a different legacy system, and the customer usually has to say goodbye and 20 to say hello again to change one. the other. The delivery technology used by the two legacy systems may be different, requiring different standards of interfaces, and different machine-level languages may be used by the two systems, such as the 96-character EBCDIC language used by IBM, and 127-character ASCII language used by contemporary personal computers. Finally, the security and rights features of various legacy systems can be completely • different and may vary from system to system and from platform to platform. In the context of telecommunication services and products offered by the large telecommunication network service providers for their customers, the assignee of the present invention, MCI, has deployed a platform for View of ServiceView MCI Services ("MSV") comprising several independent legacy systems that allow dial-up connectivity for customers who wish to obtain the next network management service and report data pertaining to their telecommunications networks: data from detail calls with price and report, - call routing data "number 800" and free network administrator; network administrator data out of limit; ticket information problem; fault management alarms. The control of • Limited interactive free network is additionally supported through which customers can change the configuration of their free networks and "virtual" networks, ie Vnet networks. In addition to the MSV platform, the present assignee has implemented a variety of independent applications that include: a traffic view system that enables clients to perform real time network traffic monitoring of their free networks, and obtain detailed data and reports of calls in near real time, and a "Hyperscope" reporting system to provide reports on the performance of the band networks wide (of data) of the clients. More particularly, the MCI Services Viewing Platform ("MSV") provides the generation of free network management data, call detail data with price ("Perspective") for analysis and usage trend, each of the which requires different reporting mechanisms due to the nature of the data that is being presented. These reporting systems typically do not provide any tailor-made reporting option or representation for the client, and any -adapt to the report client is provided by a specific application program that runs on the client's workstation. Furthermore, these systems do not easily provide the programming of periodic reports or "one shot" ad hoc. Thus, what is needed is a comprehensive system that facilitates and simplifies the access of customers to, and the administration of, all their telecommunications network values and company telecommunications management products and services to which they have subscribed. The rapid adoption and use of the Internet for data exchange has prompted a desire on the part of customers to access their data on the Internet. The popularity of the public Internet provides a measure of platform independence for the client, since the client can run their own Internet network browser and use their own platform connection to the Internet to enable the service. This solves many of the hardware and platform connectivity problems in favor of the customer, and allows the customer to choose their own platform and operating system. Network-based programs can minimize the need for training and support because they use existing client software that the user already has installed and already knows how to use it, that is, the search engine. Also, if the client then changes that platform then, once the new platform is enabled for the Internet, the service is restored for the client. The loading of connectivity and communications software is thus resolved in favor of standard and easily available hardware and the search and marking software used to obtain and establish a public Internet connection. A paradigm delivered by the Internet solves many of the installation and configuration problems involved with the initial establishment and configuration of a client workstation, since the client application required to connect to the legacy system can be delivered via the Internet public and run within a standard network browser, reducing the compatibility problems of applications to search engine compatibility problems. For the company, the use of instantaneous 5 network search engines by the client significantly simplifies the burden of the company limiting the development side of the client to analyze projects and data presentation tools that use a common interface enabled by the network browser. Software development and support resources are like this available for delivery by business legacy services • and are not consumed by a need for customer support at the workstation level. It would be very desirable to provide an integrated system that provides secure connectivity to legacy systems of telecommunications companies on the public Internet. The public Internet provides global access connectivity via the TCP / IP protocol, without the need to navigate several different security protocols, telephone exchanges, standards • marking or signaling standards, providing this a measure of platform independence for the client. In addition, it would be desirable to provide an intranet / Internet / network-based reporting system that provides a common graphical user interface that enables both the report request, adaptation to the client, programming and display of various types of data from different services of back ends and applications. It would also be very desirable to provide infrastructure of Intranet / Internet / network-based data management systems capable of providing data of telecommunications products and services to customers over the Intranet. Therefore, it is desired to provide connectivity to legacy systems of companies that provide communication network management services over the public Internet, since the Internet provides connectivity with worldwide access via the TCP / IP protocol, without the need to navigate several telephone exchanges, marking standards or signal standards. The present invention is directed to an integrated client interface system, based on a network (web) for administration of telecommunication networks. The client interface system is provided with a graphical user interface to allow a user to interact with one or more telecommunications network management services provided by remote servers located on an intranet, and uses a network paradigm to allow access Easy and convenient for all services from the user's perspective. In the preferred embodiment, the telecommunications products and services provided to a client workstation that has the integrated client interface include: (1) report requestor, report observer, and m report management applications that allow a client requests, specifies, adapts to the client and schedules the supply of the reports related to the detail data of calls "without price" and the data of the detail of calls with price of the client; (2) centralized entry box system to provide online report, presentation and notifications to a workstation of • client from one or more Intranet application services over an Internet / Intranet network; (3) a real-time monitoring system that enables a client to monitor statistics of call details and details of calls related to the use of your special service network, for example, free 800 / 8xx networks, - 4) a free network management system that enables customers to define their own 800 / 8xx toll free routing plans via the Web / Internet, enabling customers to change and modify their 800 / 8xx toll-free routing plans, and, tearily change the traffic allowance for a particular 800 / 8xx toll-free number based on certain criteria; 5) an off-limit network management system that enables clients to manage and trace features and services associated with their virtual networks ("Vnet") including the management of caller number order orders, dial plan orders, call card number management, and the identification code that sets the orders, - 6) an event monitoring system to provide clients with various reports and real-time alarm information related to their switched circuit networks (data and voice) in real time or near real time, including: provision of physical and logical views of the broadband data networks of the clients, physical and logical view of alarms of broadband networks, and physical and logical performance information related to the circuits comprising a broadband data network of the client, for example , frame relay, thus enabling customers to make informed network management decisions to control their business telecommunications networks, - 7) a problem ticket tool that enables a customer to open and monitor tickets problems related to network events in a company network, - 8) a network-based bill reporting system that allows customers access to your invoice and billing reports associated with network services provided to a customer, - 9) a network-based call manager service that enables call center customers to control the supply of free calls from the network of telecommunications company to call centers, including call centers that have multiple automatic call distributors (ACD's); 10) an online "online" order entry and administration service to enable customers to manage their telecommunications accounts; and 11) a system to handle security and authentication requests from both the client and the server side of the applications that implement the set of telecommunications products and services. Integrated into the client interface system is an application backplane unit for controlling and managing the global user interface system to various application services enabled by the network. By invoking the backplane unit a user can receive several different services available from remote servers. Each remote telecommunication service provided includes its own user interface unit, called the client application, implemented independently of the others and the backplane. Although client applications are developed independently as separate modules, the interface of the present invention integrates client applications into a unified system, allowing users to access individual client applications via the backplane unit. In this way, the present invention provides interoperability between each of the client's applications and the backplane, as well as between each of the client's applications. In accordance with the above, the present invention provides an integrated client interface and network-based delivery system to provide customers with various telecommunications products and services available from remote servers, where separate client applications can communicate with each other. and with the backplane unit, Thus, in accordance with the principles of the invention, an integrated system is provided to provide a plurality of services and products of administration of communications networks to a client over the public Internet, services and network management products accessible from a client workstation that employs a client browser associated with the client and capable of receiving network-based communications from a communications services company, the system includes one or more secure network servers to manage one or more sessions of secure clients over e the Internet in response to the client's entry into the system, and supporting each secure network server, secure communications with the client's workstation; a plurality of client applications integrated within a graphical user interface and copied from a secure network server in accordance with the predetermined client rights, each client application to provide an integrated client interface within the graphical user interface and which enables interactive communications with one or more communications network administration resources provided by the communications service company via a secure network server; and, each secure network server supporting communication of request messages entered by the client via the client interface to one or more network administrator resources capable of providing a management function of the network. • desired communication network, wherein one or more remote application resources processes the request messages and provides responses to one or more secure network servers to securely copy to the client browser and display 15 via the integrated client interface, enabling a client to manage their communications network values. Advantageously, the integrated client interface that f implements a paradigm supplied from the Internet for services telecommunications network management solves many of the problems of installation and configuration in the establishment and initial configuration of the workstation of the dial-up client, since the client application that requires connection to the legacy system is can be supplied via the public Internet and run within a standard network browser, reducing compatibility problems of the application to browser compatibility problems. • Other features and advantages of the present invention will become more readily apparent from the consideration of the following detailed description presented with reference to the accompanying drawings, which specify and show the preferred embodiments of the invention, wherein like elements are designated by identical references in all 10 drawings; and in which: Preferred embodiments of the present invention will now be described, by way of examples only, with reference to the accompanying drawings in which like reference numerals indicate identical elements or functionally similar, and in which: Figure 1 illustrates the software architecture component comprising a three-level structure, - Figure 2 is a diagrammatic overview of the • system architecture software architecture networkMCI 20 Interact; Figure 3 is an illustrative example of a schematic backplane architecture, - Figure 4 depicts the greeting process for the nMCI Interact system, - 25 Figures 5 (a) and 5 (b) illustrate an example of home pages of the network of the nMCI Interact system presenting telecommunication network services selectable by the client in which rights are given to the client / interested party; • Figure 6 is a flow chart illustrating the logical process of the backplane when a user selects a service; Figure 7 illustrates an architectural overview of the StarOE order input component of the system of the present invention; Figure 8 is a flow chart of the input process, illustrating inputs to the StarOE command input component of the nMCI Interact system; Figure 9 is a flow chart of the output process illustrating outputs from the 15-order StarOE input component of the nMCI Interact system; Figure 10 is a block diagram representing the physical architecture of the StarWRS component of the report networkMCI Interact system, - • Figures 11 (a) - 11 (c) illustrate flow charts that represent the request / schedule 600 reporting process implemented by the Report Manager StarWRS and the Report Request Applicator tools of the invention; Figures 12 (a) - 12 (h) illustrate several examples of 25 requestor screen dialogs that enable user personalization of report requests. Figure 13 (a) illustrates a central message display dialog based on exemplary browser; Figure 13 (b) illustrates an exemplary report observer dialog box used to request to see available generated reports, - Figure 14 (a) illustrates the primary components implemented in the report component with StarODS 400 prices; 10 Figure 14 (b) generally represents the process • performed by DSS to complete a report request with prices received from StarWRS; Figures 15 (a) - 15 (c) illustrate the end-to-end process 600 for satisfying the request for detailed data reporting of price calls, - Figure 16 illustrates an exemplary screen display when the StarOE application is launched; Figure 17 is a sample StarOE screen 1540 • to add and modify report options that are used by 20 the StarWRS; Figure 18 illustrates the callless price report and the real-time traffic monitoring component 500 for the nMCI Interact system; Figure 19 is a general flow diagram of the process by which the TVS 550 server obtains data.

Figure 20 is a detailed flow chart representing the processes of the internal TVS server to receive client TVS enable data from systems of • entry of orders and CORE; Figure 21 is a high-level diagram representing the flow of TCR data between the processes internal to the TVS server, - Figure 22 is a high-level flow diagram representing the process of generating detailed data reporting of calls without price, - Figures 23 (a) - 23 (b) illustrate flowcharts that describe the process of real-time monitoring of the invention; Figures 23 (c) - 23 (j) illustrate exemplary screen displays illustrating the functionality of the nMCI Interact real-time monitoring system (RTM). Figure 24 illustrates the particular methodology used to periodically update a web page • with updated statistical data; 20 Figure 25 (a) illustrates the high-level design for the 2200 Services Research application architecture; Figures 16 (b) - 16 (c) illustrate the architecture of the Research application server 36 connecting to the Legacy Rear End 40 (a), CSM / SI through objects Requestor and Receiver; Figures 25 (d) - 25 (m) illustrate examples of SI application dialog windows that allow the creation and investigation of the problem ticket user, - Figure 25 (n) illustrates the domain object model (DOM) ) 2600 implemented in the Services Research; Figure 26 is a general block diagram representing the physical architecture of the components of the TFNM system; Figures 27 (a) - 27 (c) illustrate exemplary screens that provide TFNM functionality through the option menus, - Figure 27 (d) illustrates an exemplary deployment when the file menu option is selected / Select Corp ID of Figure 27 (a); Figure 27 (e) illustrates an exemplary screen display representing a hierarchical tree view of an exemplary toll-free routing plan; - Figure 27 (f) illustrates an exemplary IMPL dialog screen that enables the user to generate an TEMP IMPL / IMPL order for a desired Corp Id, - Figure 27 (g) illustrates a QUIK dialog screen that enables the user to generate a TEMP QUIK / QUIK command for a desired Id Id; Figure 27 (h) illustrates an exemplary screen display showing the results of an order investigation, - Figure 27 (i) illustrates an exemplary screen display showing the options for changing the existing network plan routing orders; Figure 28 is a block diagram representing the physical architecture of the ONM system 200 of the invention; Figures 2 (a) - 29 (p) illustrate several examples of screen dialogs on the ONM web page that enable user interaction with the Out-of-Limit Network management system, - Figure 30 is a detailed block diagram which represents the physical architecture of the broadband reporting system component of the present invention, - Figure 31 illustrates the components used for broadband performance reporting, - Figures 32 (a) - 32 (b) illustrate the flow diagrams that represent the report creation process of the broadband system 300; Figure 33 illustrates a process flow diagram representing several broadband reporting data recovery processes, - Figures 34 (a) - 34 (b) illustrate the flow diagrams that represent the process for creating a report broadband system 300; Figure 33 illustrates a process flow diagram representing several data recovery processes • broadband reports, - 5 Figures 34 (a) - 3 (g) represent exemplary graphical reports that relate to a customer's Frame Relay (broadband) network, - Figures 35 (a) - 35 ( b) illustrate two exemplary views presented by the wide band mapper 10, - Figure 36 is a block diagram illustrating a global view of the event monitor component of the nMCI Interact system, - Figure 37 illustrates an example of a back end configuration 15 for the fault management system, - Figure 38 illustrates an architectural view of a central fault management computer, - Figure 39 is a high logical flow diagram • level representing the operation of the 20-event monitor component of the nMCI Interact System; Figure 40 illustrates a high-level global view of a call manager system environment; Figure 41 illustrates the architecture of network station components of call manager of the nMCI Interact system.

Figure 42 illustrates the objects that make up the client interface code, in a modality of the call manager system; Figure 43 illustrates a software architecture embodiment showing communications between the client 20 and the call manager network server 1132 and its components, - Figure 44 illustrates an example of the physical architecture of the network station application of call manager when one or more call manager network servers 1132 bypasses the CMIDS 1140 component; Figure 45 is an example of a conceptual model 1140 that provides details of the CMIDS software components, - Figure 45 is an example of a conceptual model CMIDS 1140 that provides details of the CMIDS software components; Figure 46 illustrates a 1250 application-level process flow for the call manager system component of the present invention, - Figure 48 illustrates an example of a call manager network station application screen including the call center tools and the route writing palette; Figure 49 shows an example of a system status display, - Figure 50 illustrates an example of an ACD collector management function screen displayed to provide the user with the ability to view, create, delete and edit ACD collectors; Figure 51 illustrates an architectural schematic of the online billing system component 1300 of nMCI Interact, - Figure 52 is a flow chart illustrating an online billing process flow, - Figure 53 (a) is a screen of sampling criteria launched from the homepage of nMCI Interact; Figure 53 (b) is a sample screen displaying a list of invoice reports, - Figure 54 is a sample screen displaying an invoice document generated by the component of the billing system online of the invention; Figure 55 is a flow diagram illustrating a process flow of the billing rear end server 1400 during document sorting and storage; Figure 56 is a flow diagram illustrating a process flow of the online back end server when responding to customer requests for document submission; Figure 57 is a schematic illustration of the message format passed from the user's workstation 20 to the secure network server 24 over the Internet • public; Figure 58 is a data flow diagram illustrating the flow of the process of the present invention during salutation, rights request / response, heartbeat transmissions and farewell procedures, - and Figure 59 is a flowchart of data for 10 various transactions reported in the nMCI Interact system. Figure 60 is a diagram representing the physical network architecture of the nMCI Interact system of the present invention; Figure 61 (a) is the schematic illustration that shows the message format passed between the dispatcher server and the specific representative of the application; and Figure 61 (b) is a schematic illustration of the message format passed between the specific representative of • the application and again to the dispatcher server. The present invention is directed to a telecommunication network application delivery system for supplying an integrated set of network management tools to customers of telecommunications service providers using a network finder paradigm.

The integrated set of client network management tools described herein and provided by the assignee of the present invention is collectively referred to as the networkMCI Interact system ("nMCI Interact"). This integrated set of network-based interactive applications provides all the necessary tools to enable clients to manage their telecommunications values, quickly and securely, from anywhere in the world. The architecture of the nMCI Interact system is basically organized as a set of common components comprising the following: 1) a software architecture that details the nMCI Interact client and server-based aspect; 2) a network architecture that defines the physical network necessary to satisfy the security and data volume requirements of the networkMCI Interact system; 3) a data architecture that details the back end or data sources of the networkMCI reporting system; and 4) an infrastructure that covers security, order entry, compliance, billing, self-supervision, measurements and support. Each of these areas of common components will be discussed in more detail in the present. Figure 1 is a diagrammatic illustration of the software architecture component in which the present invention operates. A first level of software services are resident in a client workstation 20 and provides client access to the enterprise system, having one or more copyable application objects 10 addressed to forward end business logic and application services, a layer 12 of backplane services for managing sessions, one or more objects of presentation services for the presentation of telecommunication network administration options and telecommunications network administration data requested by the client in a format recognizable by the search engine and a search engine provided to the client for the presentation of options to the client and data to the client and for internet communications on the public Internet. A second level or medium level 16 is provided, which has secure network servers and back end services to provide applications that establish user sessions, govern user authentication and rights, and communicate with adapter programs to simplify the exchange of information. data through the network. A third level or back end level 18 having applications directed to legacy back end services that includes database storage and recovery systems and one or more database servers to access system resources from one or more more legacy systems. Generally, the client, or client level or workstation 20 includes client software capable of providing a platform-independent, browser-based, consistent user interface that implements scheduled objects to provide a GUI abstraction (graphical user interface). ) common and reusable domain abstractions problem. More specifically, client-level software is created and distributed as a set of Java classes that include applet classes to provide an industrial-strength object-oriented environment over the Internet. Specific classes of applications are designed to support the functionality and interfaces of servers for each application being the functionality provided through the system of two types: (1) cross product, for example, input and reporting box functions, and (2) product specific, for example, Service Research functions, Free Network Administration ("TFNM") or Call Manager ("CM"). The system is able to provide customers with the right functionality to their product mix. Figure 2 is a diagrammatic illustration of the network and platform components of the nMCI Interact system, which includes: the Client workstation 20; Demilitarized Zone 17 (DMZ), - cluster of Network Servers 24; Branch of Servers Dispatcher / Representative of MCI Intranet 30; the enterprise Intranet application servers 40, and the data warehouses, the legacy systems, and so on. The workstation of client 20, is enabled by search engine and includes client applications responsible for presentation services and front end.

Its functions include providing a user interface to several MCI services and supporting communications with the MCI 24 network of Intranet servers. As illustrated in Figure 2, client-level software is responsible for customer presentation services and generally includes a network browser 14 and additional object-oriented programs that reside on the workstation platform of the client 20. The client software is usually organized into a component architecture with each component generally being a specific application, which provides an area of functionality. The applications are generally integrated using a "backplane" service layer 12 that provides a set of services to the objects of the application that front-end business logic provides and handles its launch. As will be described, each of the nMCI set Internet of the network administration applications implements a set of common objects (CO) that minimizes the replication of the code, and provides a frame of reference in which you can manage and create a family of internet applications including: communications, services input / output (1/0) to local resources, user authentication, internationalization, common view and feel, 5 application administration, and a model view controller (MVC) reference frame. The primary common object services for each of the application suite includes; graphical user interface (GUI), - application launch; window navigation between applications, - 10 communications interaplicaciones, - printing, - identification of • user; session management; authentication, and rights; import and export of data, - registration and statistics; error handling, - version management and message services. 15 As shown in Figure 2, the aforementioned objects communicate the data by establishing a secure TCP message session with one of the servers in the network networkMCI Interact of the demilitarized zone network 24 via t a secure Internet communications path 22 established, preferably, with a layer version of safe sockets (SSL) of HTTPS. The network servers networkMCI Interact of demilitarized zone 24 work to decode the message of the client, preferably via the implementation of the SSL, and unwrap the key of the session and verify the session of user. After establishing that the request has arrived from a valid user and mapping the request to its associated session, the servers of the demilitarized zone network 24 re-encode the request using symmetric coding and sending it on a second secure socket connection 23 for the server dispatcher 26 inside the company's Intranet. As will be described hereinafter in more detail, a networkMCI Interact session is designed by means of a greeting, successful authentication, followed by the use of server resources, and farewell. However, the protocol • communications from the global area network www uses HTTP, a stateless protocol, each HTTP request and response is a separate TCP / IP connection, completely independent of all previous or future connections between the same server and client. The present invention is implemented with a secure version of HTTP such as S-HTTP or HTTPS, and preferably uses the HTTPS SSL implementation. The preferred mode uses the SSL that provides a specific message • Separate that provides server authentication during a session. The preferred modality also associates a request for HTTPS given with a logical session which is started and tracked by a "cookie jar" server 32 to generate a "cookie" which is a unique key generated by the server that is sent to the client along with each response to a HTTPS request. The client saves the cookie and returns it to the server as part of each subsequent HTTPS request. As desired, either the servers in the network 24, the cookie jar server 32 or the dispatch server 26, can maintain the "cookie jar" to map these keys to the associated session. A separate cookie jar server 32, as illustrated in FIG. 2, has been found desirable to minimize the load of the dispatcher server 26. A new cookie will be generated when the response to the HTTPS request is sent to the client. This form of session management also functions as an authentication of each HTTPS request, adding an additional level of security to the overall process. As illustrated in Figure 2, after one of the demilitarized zone network servers 24 decodes and verifies the user session, it sends the message through a protection wall 25b over a TCP / IP connection to the dispatcher server 26 on a new TCP base while the original 22 bunker of the search engine is blocking, waiting for an answer. The dispatcher server 26 will unwrap an outer protocol layer of the message from the bunch of servers in demilitarized zone 24, and will recode the message with symmetric encoding and send the message to an appropriate application representative via a third TCP / IP 27 socket.

While waiting for the response of the representative the three bases 22, 23, 27 will block a receipt. Specifically, as soon as the message is decoded, the wrappers are examined to reveal the user and the target mid-level service (Intranet application) for the request. A first level of validation is carried out, making sure that the user has the right to communicate with the desired service. The rights of the user with respect to this are extracted from the memory by the dispatcher server 26 from the StarOE 39 command entry server, at the time of the greeting and stored in the immediate memory. If the requestor is authorized to communicate with the target service, the message is sent to the representative of the desired service. Each application representative is an application-specific "daemon" that resides on a specific Intranet server, shown in Figure 2 as a joint or intermediate-range server 30. Each Intranet application server in set 30 is generally responsible for providing a specific back end service requested by the client, and, additionally, it is capable of requesting services from other Intranet application servers communicating to the specific representative associated with the other application server. In this way, an application server can not only offer its browser to a client for the server interface through the representative, but can also offer all its services from its representative to other application servers. In effect, the application servers that request services are acting as clients for the application servers that provide the services. This mechanism increases the security of the global system as well as reduces the number of interfaces. The network architecture in Figure 2 can also include a variety of application-specific representatives that have associated intranet application servers that include: a StarOE representative for the StarOE application server 39 to handle authentication, order entry / billing, - an input box representative for the input box application server 31, which functions as a container for completed reports, call detail data and marketing news messages; a report manager representative capable of communicating with a system-specific report manager server 32 for generation, administration and scheduling the transmission of custom reports including, for example: call usage analysis information provided from the StarODS server 33; network traffic analysis / monitoring information provided from the Traffic view server 34; virtual status network alarms and performance reports provided by the broadband server 35; problem tickets for switching, transmission and traffic failures provided by the Services Research Server 36; and the free routing information provided by the Free Network Administrator server 37. • As shown partially in Figure 2, it is understood that each Intranet server in set 30 communicates with one or more consolidated network databases which include the information and network management data of each client. In the present invention, the service research server 36 includes communication with the administration legacy platform • MCI 40 (a) customer service. This administration of the network and data of the customer's network is additionally accessible by authorized MCI administration personnel. As shown in Figure 2, other legacy platforms, 40 (b), 40 (c) and 40 (d) can also communicate individually with Intranet servers to attend specific transactions initiated in the client's search engine. The illustrated legacy platforms 40 (a) - (d) are illustrative only and it is understood that other platforms of The legacy can be integrated into the network architecture illustrated in Figure 2 through an intermediate mid-range server 30. Each of the individual representatives can be maintained on the dispatcher server 26, the server related application, or the separate proxy server located between the dispatcher server 26 and the mid-range server 30. The relevant representative waits for the application request from an application client running at the dispatcher station. • work of the client 20 and then attend the request, either by handling them internally or by sending them to the associated Intranet application server 30. The representatives additionally receive adequate responses again from an Intranet 30 application server. Any data returned from the server Intranet 30 applications are translated back to the client format, and returned over the • Internet to the workstation of the client 20 via the dispatcher server 26 and on one of the servers of the network in the cluster of servers of demilitarized zone 24 and the connection of secure sockets. When the resulting response header 15 and the data dragging application is sent back to the client's browser from the representative, the message will cascade all the time back to the real-time search engine 14, limited only by the speed of • the transmission of the network becomes latent. 20 The intermediate-level software includes a communications component that offers three (3) types of data transport mechanisms: (1) Synchronous which is used for situations in which the data will be quickly returned by the application server 30, - (2) Asynchronous which is used for 25 situations in which there may be a long delay in the response of the application server 30; and (3) volume transfer which is used for large data transfers. The demilitarized zone network servers 24 will • are located in an area of the secure special network located on the 5 side of the Intranet to avoid potentially hostile customer access. All demilitarized zone equipment is physically isolated and with protection walls as illustrated in 25 (a), 25 (b) of the Intranet company. Similarly, the demilitarized zone equipment has protective walls and is protected from hostile attacks from the public Internet, except for the access of the network finder limited to the servers of the network that are located in the demilitarized zone. The client's network browser is connected to the network server in the demilitarized zone which at its it is connected to the dispatcher server 26 which acts as a representative to extract selected information from the mid-range servers 30. A user may not connect directly to any company server on the intranet of the • company, thus ensuring the security of the system of the internal company and its integrity. The demilitarized zone also isolates the company's Intranet from the public Internet because the servers of network 24 located in the demilitarized zone never store or calculate actual customer-sensitive data. 25 The network servers only put the data in one place. convenient form for its deployment on the client's network server. Since the servers in the demilitarized zone network 24 do not store customer data, there is a much smaller chance that any customer information will be threatened in the event of a security breach.

Client Finder Application As mentioned, an nMCI Interact system component is the client-level software component that provides the integrated and unified interface to each of the data management services available to a user. As shown in Figure 3, the system of the present invention implements an "application backplane" 12, a single object that keeps track of all client applications, and that has capabilities to initiate, stop and provide references to any of these client applications. The backplane of application 12 is typically implemented as a Java applet and is launched when a page of the network is retrieved via the URL that points to the site of the company network. Client applications typically comprise a graphical user interface program that allows a user to interact with one or more remote services enabled by the network. The backplane 12 and client applications use a browser 14 such as the Microsoft Explorer versions 4.0.1 or greater for an access and distribution mechanism. Although the backplane is started with a finder 14, the client's applications are usually • isolate from the browser because they typically present their user interfaces in a separate frame instead of nesting them inside the network page. The architecture of the backplane is implemented with several main classes. These classes include COBackPlane, COApp, COAppImpl, COPar and COAppFrame. COBackPlane 12 is a backplane of application that launches applications 54a, • 54b, typically implemented as COApp. COBackPlane 12 is usually implemented as a Java applet and is launched by the network browser 14. This backplane applet is responsible for launching and closing the COApps. 15 When the backplane is implemented as an applet, it overlaps the standard applet methods init (), startO, stop () and run (). In the init () method, the backplane applet obtains a user context object COUser (UserCode). The COUser object maintains the information such as the user's profile, the applications and their rights. The user settings and application rights provided in the context of COUser are used to build the application toolbar and the input box applications. When you press on a application toolbar icon, a particular COApp is launched using the launc AppO method. The launched application can then use the backplane for communications between applications, including retrieving data from the input box. The COBackPlane 12 includes methods to provide a reference to a particular COApp, for interoperation. For example, the COBackPlane class provides a getApp () method and returns references to application objects by name. As soon as they are recovered in this way, the public interface of the application object can be used directly. COApp is the basic interface for applications. The applications, for example, problem ticketing 54a or online invoice 54b, generally have their start code and their inteface interleaving in a class implementing COApp. Generally, two classes are available for applications, COAppImpl or COApplet. Alternatively, their own implementation of the interface can be provided. In the preferred embodiment, the applications typically extend to COAppImpl. COAppImpl is an "applet-like" class, but it does not derive from java, applet .Applet or j ava. awc. Panel Without deriving from Applet, applications can be launched at any time without the search engine having to be pointed to a specific page, and it releases the applications of performers within the framework of the search engine. Classes derived from COAppImpl are created, launched, stopped and destroyed by the COBackPlane 12. This provides a close and controlled integration by the system of the present invention. P The COApplet class, on the other hand, extends the class Applet and it is intended to be launched by the search engine from an HTML tag < Applet > . The Applet extension is provided for applications that need more isolation from the present integrated system, or that require a separate browser-based deployment space. The COApplet 10 class implements the majority of the COApp interface by sending it to a content COAppImpl object. The COAppFrame (COAppMarco) 56a, 56b is a computer window created and used by COApp to contain its user interface. The COAppFrame 56a, 56b is a separate window of the network browser 50. Generally, the COAppFrame 56a, 56b has a menu, a toolbar, and a status bar. The attachToviewArea () method of the COAppFrame can be used to paste a COView object (COVista) 60a, 60b, 60c into a COAppFrame 56a, 56b. The COView class is an extension of java.awt. Panel 20 Provide a general purpose display space and container for a visual representation of the application. Application classes typically extend to COView classes to implement their presentation logic. COApp can use none, one, or many COAppFrames 56a, 56b. 25 COParm is a generic data class used to pass parameters between applications. The COApp interface provides a public method for passing COParm message objects, for example, processing public empty message (message • COParm), which can be used to pass messages between 5 applications. The COPparm class contains a set of name-value pairs that are used to present information or requests.

Salutation 10 As illustrated in Figure 4, a process of • Salutation for the integrated client interface of the present invention begins with the search engine launch as indicated in step 60, and the Uniform Resource Locator (URL) entry, such as HTTPS: // www. enterprise com, as indicated in step 62. After a successful connection, an SSL greeting protocol can be initiated at this time as indicated in step 63. As will be explained in more detail herein, when an SSL client and the server for the first time begin to communicate, they agree on the protocol version, select cryptographic algorithms, authenticate the server (or optionally authenticate each other) and use public key coding techniques to generate shared secrets. After a successful SSL greeting in step 63, a The hypertext markup language (HTML) file that invokes and an associated greeting applet are copied with software tools and common objects in steps 64, 66, to present a network page that includes input fields of • name and password for the user to enter. The user is 5 prompted to enter their name and password on the network page. If the nMCI Interact system determines that software files that include classes to start a session have already been copied previously, for example, from a previous session, steps 62, 64, 66 are skipped. 10 The salutation applet verifies the entry of • name / password and instantiate a session object in step 72, communicating the name / password pair. The session object sends a message containing the name / password to a remote server for user validation in step 74. 15 When the user is properly authenticated by the server in step 76, another page of the network is copied which has the object in the back plane in steps 78, 80, 84. This page is called the home page. At the same time, all objects • Application software are copied in step 82. If the system of the present invention determines that the backplane and the application files have already been copied, steps 80, 82, 84 are not performed. backplane is urged in step 86. As will be explained, the backplane communicates with a remote server command entry component ("StarOE") server 39 (Figure 2) to retrieve the rights of the user in step 88. Rights represent specific services in which the user has subscribed and is privileged to have access. It also describes what rights the user may have within a single service. For example, from the COUser context, the backplane can obtain the list of applications that the user has the right to access. In addition, each COApp maintains a set of rights within the application in the COAppEntitlements (COAppRights) object. Using the COUser context information, the backplane knows which COApps to provide, for example, which buttons to install in its toolbar. The backplane stores the user's specific rights in memory for other processes to access. After determining the rights, the backplane starts a new chord and starts an application toolbar in step 90. The application toolbar includes the remote services to which the user has subscribed and can choose to execute. From the application toolbar, a user is able to select a service to execute. After selection of the user, the selection is communicated from the application toolbar to the backplane in steps 92, 94, which then launches the graphical user interface program associated with the selected service. The application toolbar is still in the user's deployment, even after a particular service has been started. This is • useful when a user wants to start another remote service directly from having executed a previous service because the user does not need to recover the home page again. If it is determined that the password entered by the user is not valid in step 70 or step 76, the greeting count attempted in step 96 is incremented. the salutation account that is attempted by the user is • greater than a previously defined allowed number or tests as indicated in step 98, a message is transferred to the user in step 101 and the user must start the search engine. If the salutation account attempted by the user is not greater than the number of previously defined allowed attempts, a "failed entry" message is conveyed to the user in step 102, and the user is prompted to reintroduce the name / password in step 68. If it is determined that the • the user's password has expired, the user is encouraged to change the password in step 104. For example, the user may be required to change the password every 30 days for security reasons. Whenever the user changes the password, the new password is transmitted in real time to a server responsible for updating and maintaining the entry of the password. password for the user. The user then enters the new password in step 104 and continues with the process described above in step 70. As an illustrative example of the network page of • nMCI Interact salutation typically includes a 5 name field and a password field for the user to enter. After the user authenticates properly via the page of salutation, the home page is retrieved. Figures 5 (a) and 5 (b) illustrate examples of pages home of nMCI Interact, that is, a page of the network that has the backplane object 12. The home page 79 (a) is copied after authentication via the page of greeting and provides, for example, a set 95 of network management report applications that include: MCI Traffic Monitor application 85; an alarm monitor application 87; an application of Network Administrator 89 and the Service Research application 91. Access to network functionality is also provided through the • Requester for Reports 83 that provides a variety of detailed reports for the client / interested party and a Message Center 77 to provide improvements and functionality to traditional email communications. An application toolbar 71 is also provided which is different from the icons 95 because the bar tools in the applications is still on screen, even if the homepage 79 (a) is no longer displayed. The home page typically also comprises HTML links to other services 96. These services may be a new information center, benefit offers, or support center for the system of the present invention.

Backplane Logic Figure 6 is a flow chart illustrating a backplane logic process when a user selects a service from a home page or from the application toolbar. The user initially selects an application in step 110. If the selected application is derived from COAppImpl, the object, COBackPlane 12 prompts the desired application object by name. The COBackPlane 12 also creates a COAppStartThread object (COAppStartCord) to handle the start of the COAppImpl in step 116. Each COAppImpl starts on its own string.

COAppStartThread calls the init O method of COAppImpl. Here the COAppImpl typically creates the application-specific classes you need, including the COAppFrame (or a class derived from it) if desired. COAppStartThread calls the startO method of COApp. As soon as the startO method has been completed, the COAppStartThread ends. If the desired application is derived from java. apple .Applet, a new search window is created, and it goes to the HTML page from which the applet will load 338. This will cause the search engine to load the applet, and call its init () and startO method. In this init () method, the applet gets a reference to the backplane by calling the static method of the COBackPlane class getBackPlane () (getPlanePosterior ()). Also in its init () method, the applet notifies the backplane that it has been launched by calling the registerApp () method of the backplane. Alternatively, if the desired application is an application that requires a direct URL launch from the home page, for example RTM, as shown in step 112, the desired application is invoked by retrieving a page from the network having the application URL as shown in step 118. Each application obtains a session identifier in step 120 after its start. If the applications wish to perform another additional authentication, they are free to recover the COUser object and perform any special authentication they need, without bothering the user to re-enter their username and password. During the process of functions specific to each application, the applications are able to communicate with each other as well as with the backplane obtaining a reference to the applications or the backplane and invoking the public interfaces or methods with the reference. After a user has finished interacting with COApp, the user requests the selected COApp to exit via a menu selection, by clicking on a box with a button in a window frame, or with a keyboard command, for example. The COApp then requests to leave the COBackPlane. If the selected application is derived from COAppImpl, the COBackPlane creates a COAppDetainCord to handle the output of the COApp. As with the start, each COApp is stopped on its own string. COAppDetenerCord calls the stopO COApp method. Typically, a COApp will not be mounted on this method. It is called by consistency with the applet interface of the COApp class. A stopO applet method is called by the network browser when the web browser leaves the page from which the applet was loaded, in order to allow the applet, for example, to stop an animation. For consistency with this model, COApp can use this method to stop long-duration strings. The COAppStartThread calls the destroyO method of COApp. Here the COApp typically performs resource cleaning routines, including stopping any chords, and calling the dispose () method for any COAppFrame object. If the selected application is derived from java. applet .Applet, the web browser window contains the page from which the applet was launched closes. This will cause the stop O method of the applet to be called by the network browser. In this stopO method, the applet notifies the backplane that it has been stopped by calling the deregisterApp () method on the backplane.

Then a user typically requests to be dismissed via menu, closing box, and so on. When this request is received by the backplane, it sends transaction Farewell to the network server. The backplane closes the toolbar and directs the network browser to the salutation URL. Then the back plane comes out. As shown further in Figure 6, the home page provides links to other web pages. For example, if the hypertext help is selected in step 122 of the application toolbar, a help URL is launched in a new lookup window in step 124. Similarly, if the customer support hypertext is selected in the Step 126, a customer support URL is launched in a new browser window in step 128. If a user selects a marketing promotion hypertext in step 130, the URL for the new product information will be launched in a new one. search window in step 132 If the hypertext of the general overview of the product is selected in step 134, a URL belonging to the characteristics of the product will be launched in a new search window in step 136. If the user selects home in the step 138, the homepage will be displayed again in step 139.

User The present invention also includes a user unit to represent a user of a current session. The user unit is generally implemented as a COUser class that extends java. lang .Obj ect. The COUser class object maintains information that includes a user profile, applications and their rights. In order to minimize network traffic, the amount of data carried by the COUser is initially minimal, and populated as requests are processed. The requests are usually processed by retrieving information from the Order Entry service. The profile information is stored and populated in the COUser object if this information is required again. A COUser object is created when the user registers, and maintains the user's name and password as an object in the COClientSession objects. The session object is contained within the backplane, which manages the session throughout its lifetime. The code below illustrates how this happens: // in the backplane session COClientSession = new COClientSession O, -intentar. { Session. logon ("username", "password"), -} capture (COClientLogonException e). { ....}. , - // If the user object is required user COUser = session. getUser (); The salutation method of the COClientSession object communicates with the StarOE server (Command Entry) (Figure 2), a back end authentication mechanism, to authenticate the user. The COUser that can be obtained from the COClientSession immediately after the startup process is very scarce. It includes a limited set of information such as user name, a list of applications that the user is entitled to, for example. The details of each rights information are retrieved at the time of actual processing of that information.

StarOE As briefly mentioned, the StarOE 39 server of the nMCI Interact system (Figure 2) is used to order, fulfill, and charge for, as well as administer, the set of network applications, providing a horizontal service for use by all Applications. Applications communicate with StarOE for all authentication, rights and system administration for order entry services. StarOE processes these service requests centrally for individual applications by providing all order and security ticket information for the "networkMCI Interact" suite of applications.

The security information maintained and provided by StarOE describes the identification, authentication and access control used in the set of applications. All access to the "networkMCI Interact" is controlled by 5 user IDs (userIDs) and passwords, as explained in the present. In addition, individual users are specifically granted access only to the necessary system objects, that is, files, programs, menus, reports, and so on. Access to these individual objects is based on the client's privilege models, that is, rights, stored in a StarOE database. Thus, all the information regarding the clients and their levels of access for each product in the set of applications of the network to which the customers have subscribed is stored in a local security profile database to the StarOE application. In accordance with this, the StarOE application provides the ability to prevent unauthorized, non-client access to the data and applications of the "networkMCI Interact"; the ability to allow customers access to multiple companies with a user identification, - the ability to restrict authorized users to specific Intranet applications and databases based on customer-ordered applications, - and the ability of users to restrict and / or update capabilities within from An application or set of data, that is, clients can provide or restrict views of their "company" data to subgroups within their organization. Using the system of the present invention, customers will no longer have to make manual calls to order 5 incoming connections when requesting order transactions. For example, users can add to the system without an intervention from the company's support team. In summary, customers can manage their communications services in a secure environment and also, for example, 10 monitor their network traffic via the Internet, as well as • an ability to add products and services to your account, in an automated way and all in one session without having to log in and out to individual application services separately, and without having to contact a customer support representative 15 . Figure 7 illustrates a general architecture overview of the StarOE application component that includes a StarOE 39 server resident in a mid-range computer, • and an associated client application 154 running on a user platform that has a network browser, hereinafter referred to as a StarOE client application. The StarOE server 39 processes several requests for transactions related to authentication and rights, of other application services, both of the client and of the application server 25 of the network. In addition, the StarOE server 39 receives transaction requests from the StarOE client application. Transactions are typically conducted by message and involve requesting transactions and responding to transactions.

• The StarOE 39 server responds to message requests 5 by formulating transaction responses and transmitting them to the requesting servers and clients.

StarOE client application The StarOE 154 client application is one of the client search applications that run on the • network finder 14 and provides a graphical user interface based on the network implemented according to the standards of the graphical user interface for the integrated set of customer data management and applications of report, as described herein. As described, the StarOE 154 client application is launched at the beginning of the client by the backplane object and generally includes Java applications and applets to provide a • graphical user interface based on network to interact with customers on the front end side. When a client launches the StarOE application from the home page, the main window as illustrated in Figure 16 is presented. From this main window 1500, a client can select to order and fulfill application services, request user identifiers (ids), and create user security profiles for the "nMCI Interact" application suite. The main window 1500 includes a menu bar 1506 with options to perform various StarOE tasks. The main window also includes a 1504 toolbar, common to all data management applications. The 1504 toolbar has buttons that also perform the various StarOE functions. Typically, the user list is presented, ie, it is displayed as a tree 1502, within the main window 1500. The menu options 1506 include: file menu options which includes an option to select company to allow the administration open a user list for a different company, or add a new company to your list of companies, print option, and exit option which closes the StarOE application; option to edit menu in which includes adding new application, modify and delete options, - menu of options that allows a global security establishment for the free administration application, -menu to see that includes options to refresh the screen recovering the last list of users for the company opened from the StarOE server and display the list on the screen, extend all the nodes in the list of users, and collapse all the nodes in the list of users, - and the help menu option that launches the help machine with the StarOE help text. The 1504 toolbar also includes the options to select company, refresh, extend everything, collapse everything, print options and help. A typical process flow logic for a StarOE client application begins with the home page by launching the StarOE client and passing a reference to the common user information object. This object includes the user and company identification by default for that user. The main window 1500 having the menu options 1506 and the toolbar 1504 is then presented. The StarOE client application then sends a "get StarOE security" transaction message that includes the user identification, the company identification, and the StarOE application code in the message. The StarOE 39 server returns the racf id, an access level that represents whether the user is an external admin, a member of an account team, an internal admin, or a customer support admin, for example. If the user who launches the application - StarOE in an external admin, the user list is displayed immediately since external administrators can see only one company. For external administrators, a business name is retrieved from the StarOE server 39 by sending and receiving a request and transaction response "get user company list". If the user is not an external administrator, then a dialog is presented for the user to select which company to see. When the user selects to see a company, a "get user list" transaction message that has the company identification is sent to the StarOE server 39 to retrieve a list of user IDs, a list of applications for each user, a type of access for each application, and types of reports for StarWRS (for example, Toll Free, Vnet, Vision, CVNS). The client application also sends a transaction message "obtain application list" to retrieve a list of application codes, description, and application fix position from StarOE 39 server. The user list is then displayed within the main window as shown at 1502. All user lists have a New User node 1502a as the first node under a 1502b company.

This node can be selected to order a new user.

An existing user node 1502c can be selected to edit and add new applications for that user. When an existing user node 1502c is selected, the options to edit / add new application in menu 1506 are enabled and disabled according to which applications the user already has. An existing user application node I502d can be selected for the edit / modify / delete options within the application. With respect to the selection of the user of the menu option to select company or the button of the toolbar in Figure 16, the search engine displays the page of the network that has a dialogue box that allows a • Administrator work with a different company, as well as 5 add a company to your specific list and additionally includes the ability to establish new users or modify several options available to existing users. During the procedure of adding and modifying described above, you can also initialize • security information regarding client rights for application services. For example, a screen for presenting security information of the Free Network Administrator ("TFNM") may be presented and displayed when the TFNM is ordered or modified. Preferably a security profile of user TFNM includes at least one corporation identification, each corporation identification having an associated racf id. Preferably, a security installation object l handles the process of establishing the security for each application. A constructor for this object initializes the user identification and a modification flag as it passes from the client application StarOE 154. The object retrieves the free hierarchy of the StarOE server 39 using the message "obtain hierarchy". The application of client 154 sends the company identification, and the free network banner in the application, and StarOE server 39 returns the list of identifications of free network corporations for the company. If the flag of • modification, a "get security" message is sent to the server 39 to retrieve the user's TFNM security profile.As a tree structure displayed is loaded with each free network corporation identification, the user enters racf id. submit button is pressed, the establishment security object calls its method of sending security that causes the formatting and sending of • "setTFNM security" message to the StarOE 39 server. When the StarOE 39 server receives the message, it sets the compliance security for the TFNM application. The StarOE administration component is also uses to order, for example, to add or modify, several reporting options used during the generation of network-based reports by the nMCI Interact StarWRS system as will be described. Figure 17 is a StarOE screen of • shows 1540 to add and modify report options that are use by StarWRS. The StarOE deploys the free network hierarchy for the security establishment when the free network report is ordered or modified. The hierarchy includes a list of corporation IDs for a given company, with each 1542 corporation ID having one list of free numbers 1544 under it. The list can be displayed in a tree format. Reporting options at the toll-free level include priceless reports (UR), priceless call detail (UCD), and monitor reports in • real time. 5 Typically, a free network report security profile includes at least one toll-free number with at least one reporting option associated with it. The client application 154 generally invokes an object to handle the report option changes and passes the user identification and a modification flag. This object recovers • then the free network hierarchy of the StarOE server 39 using the "get hierarchy" message. The client application 154 sends the company identification, and the free flag in the application, whereby the server 39 15 returns the list of corporate identifications free to the company. A modification flag is set, a "get free network security" message is sent to the server to retrieve the user's free network security profile. As each corporation identification identification is extended, a "get toll free" message is sent to the server 39 requesting all numbers for the selected corporation identification. As each free number is added, a search on the 25 user profile for that number takes place. If "1 number is found, the report options are added to the number text as shown in 1546. In addition, if the number has been deactivated, a text" <inactive - <", for example, is added to the • screen display as shown in 1548. The inactive numbers 5 are not modifiable. When the priceless call reports or the call detail check boxes without the 1541 price change, the following text to the selected toll-free numbers reflects the status of the check box. The check boxes represent options of reports to which the user has access to • toll-free numbers When more than one toll-free number is selected, the check boxes are checked without checking. When the submit button is clicked, the object calls its method to send security ciase that causes the formatting and sending a message to "fix user's free security" to the StarOE 39 server. It should be understood that in addition to performing various order entry and administrative functions for the TFNM application, other services, including reports for VNET, Vision, Broadband, Call Manager and invoice report can be sorted and the security information relevant to each application can be modified in a similar way. The StarOE 154 client application provides particularly on-screen displays invoking objects of associated classes thrown by the backplane unit as described above. The StarOE 154 client application uses a Java application program and is • implemented by extending the COApp class, one of the common objects 5 provided and used in the present invention. Because the client program 154 is not implemented in an applet, and also because the client program 154 uses the container frame for purposes of windowing the client's display, the client program 154 is executed, a degree, independent of the search engine within which • the backplane is displayed. Referring again to Figure 7, the StarOE client application interacts with the StarOE server to provide various command entry functions for All applications as described above, as described herein with reference to the back end functionality of the nMCI Interact system. Communications between StarOE 154 client and server 39 typically use ^ TCP / IP, running a UNIX process listening on a TCP port known. In the preferred embodiment, as shown in Figure 7, the StarOE server 39 provides a number of processes to perform several specific functions. By. example, a compliance process monitors new customers that are being added to the system and notifies a compliance household 298 in accordance with the above (Figure 9). The compliance household can then send appropriate subscription packages according to the information received • of the process of compliance to the new client. Another process, a reconciliation process, can handle the synchronization of data with a database of the main computer system and also with databases associated with the individual compliance systems. Still another process, a billing process, can handle direct billing information to different collection streams 157 (Figure 7). The StarOE server 39 further maintains a database 160 for storing all users "networkMCI Interact" and its security information such as passwords and application rights and hierarchies describing the privileges of user access to specific application services / subservices that may be requested by other servers and application clients in the network. Generally, hierarchies are defined by the client during the process of • entry of orders, and describe the subdivision of calls in nodes accommodated in a tree of n roads. The back-end servers "networkMCI Interact" apply the hierarchy definitions to their data at the time of the report when they generate reports, typically as queries on a node-by-node basis to the result data set that was extracted using any other criteria supplied. The trees in the hierarchies have essentially arbitrary complexity, that is, the number of nodes is unlimited. Each node is assigned calls according to a template of conditions. The conditions can be defined as a combination of one or more ANIs, corp IDs, ID codes, card numbers, account codes, and place / node identifiers, and so on. These filters can be applied to any node in the tree. Hierarchies can be applied as well as selection criteria (for example, "reporting all calls to these nodes in their descendants", in combination with other criteria) as wrapping objectives (for example, grouping the results in this report at this level in the tree) . These rights and hierarchies can be modified via the client application StarOE 154 executed on the workstation of the client 20. Referring to Figure 7, a process that is executed in the StarOE client application process 154 sends application messages of transactions via the nMCI Interact infrastructure, comprising, for example, the bouquet of network servers 24 and a dispatching server 26 (Figure 2), to the StarOE 39 server. The StarOE 39 server responds to requests by searching for the security profile for the requested information , formulating appropriate transaction response messages and transmitting them back to the application process. As an example, during the task start procedure, the client start process formulates a transaction message that includes a user name / password and a validation request for a given customer. The StarOE server 39 searches for the match of the name / password pair in the security profile for the client, and if the name / password pair is found, the server 39 formulates a valid user message response so that the startup process running on the client platform, including in the message the identification of the company, the zone of time, and user identification information and transmits the response via TCP / IP back to the startup process. When the StarOE server 39 detects that the password has expired, the server 39 notifies the client, via the client request 154 to change the password. The changed password is sent to the StarOE server 39 formatted in a message interface "password change request", for example. The server 39 after receiving the message updates the password for the given user in its user profile stored in the StarOE 160 database, and responds with appropriate return code to the StarOE client 154. The start-up process, after receiving the response can then continue with its normal course of processing. Another example of a service provided by StarOE is to retrieve a list of application rights for a given client. As described briefly above, a right describes a privilege or authorization that a client has. It describes what applications the client can access and also describes what the client can do with that application. It also describes what back end services • can have access in combination that application and client. 5 For example, a customer may have the right to use or have access to many applications and for each application, the client may have a different set of rights. Thus, rights can come in two different sets: a first set that specifies what the client can do with that application, for example, allow the client to have updated access to a particular view and only have read-only access in a different view, - and, a second set that specifies what back end services this particular application can access and customer. As previously described, all the information related to rights for a given client is stored in the database of the client profile 160 located with the StarOE server. When the backplane requests via TCP / IP • the transaction of rights, for example, in a message of In the request "obtain list of applications", the security module retrieves and transmits again via TCP / IP to the backplane the list of authorized applications accessible by a given client in a transaction response. The backplane uses the list to determine which buttons on the homepage "networkMCI Interact" should be activated, controlling access to the products. Similarly, the individual back end application servers 158 can make a request for rights within the ^ application for a given customer. For example, the component of system report "networkMCI Interact", in this so-called "StarWRS" network-based reporting system that provides a client with their data management application reports generates a request for hierarchy data for Vnet, Vision, CVNS and clients Toll-free always that there is a need for reports. In response, the StarOE r retrieves the corresponding hierarchy data and transmits it in real time to the WRS system as described. By providing authentication information, rights, and hierarchy, including those described above, the StarOE server database 160 stores user profiles locally. Additional data required is typically accessed from the corporate computer systems of companies 159. The StarOE 39 server can be deployed as a concurrent server allowing client connections simultaneous multiple. The server 39 listens on a known port, and when a client connects, the server 39 connects a new process to handle the client connection. The server 39 can also implement a chord to handle each client connection. The StarOE server 39 is preferably implemented using object-oriented programming (OOP). As an example, when you start a "get hierarchy list" message in the client application to invoke • retrieval of an identification list of corporations 5 of the server 39, a class of "hierarchy" can be urged, which includes a Get () method to determine which hierarchy product is to be recovered and to return the appropriate information. Another object can be invoked to format the data in a reply message and return the message back to the client.

As another example, when a "get application list" request message is started in the client application, an "application" class can be urged that encapsulates the interface in a database table (not shown) that has application information Particularly, the Get () method in this class access the application table in the database and return the list of application codes and their descriptions. Figure 8 is a flowchart of the process of • high-level entry, which illustrates StarOE server input 39 of the nMCI Interact system. Through the StarOE server, the integrated interface system of the invention handles a wide variety of key functions for the set of network applications. Each application, hereinafter, will also be called a compliance system, which has a compliance client and a compliance server. The system of the present invention handles security and authentication requests from both the client and server side of each compliance system as shown • on 282a-d and 284. These requests are automatically generated 5 whenever the client makes a server request. For example, they are generated when a customer dials the home page icon (Figure 4) for a service such as TFNM. In addition, as mentioned, when a client connects for the first time, the client is presented with a box dialog that prompts the user to provide identification and password. When the client presses a submit button, for example, the backplane (or platform) checks if the client is valid by consulting the StarOE system as shown in 286. The response back is either "invalid user / password" or "valid user". When the client has been authenticated, the client is then presented with a list of authorized applications. This list determines which buttons, for example, that represent each application • are active, controlling in this way, the client's access to products and services. In addition, it is also shown in 286, the client can issue a temporary password with the client's compliance package, which allows a user to register in the system the first time. 25 Information can also be entered and requested by several different sites of a user platform. For example, the command entry "StarOE" connection 288 can enter information directly into the StarOE 160 database to register new clients to the integrated set of network applications. You can also access the data in StarOE directly to modify the information to the client, and to add and remove subscribed services. Other entries to the StarOE server may include rights data of a legacy order entry system called Network Capability System ("NetCap") 290 and a circuit command management system ("COMS") 291.

For example, the main NetCap 290 computer can send the appropriate hierarchy of toll-free numbers for a specific client in response to the registration message by registering the new client to the main computer 290. The hierarchy of toll-free numbers describes the rights of the new customer to the services TFNM. This hierarchy can be used by other services in the integrated set of network applications, for example, the StarWRS report application. Additional authentication data and rights can be transmitted from a corporation order entry system ("CORE") 292 that generates two sets of hierarchy files on a daily basis. One set comprises only delta, the other comprises a complete hierarchy. The StarOE notification is made when they are available. StarOE performs a reconciliation process to update the hierarchy files. Figure 9 is a flow chart of the output process, illustrating outputs and responses from the server StarOE 39 to systems and application processes. An example of an output is a client-side authentication response of the individual applications, for example, the report system 400, etc., as well as the backplane. In addition, a list of accessible applications for a given client is produced from the backplane platform via the platform 24 network servers. The StarOE also produces several updated data to the database systems associated with specific individual applications in the set of data management applications. In addition, individual compliance systems receive messages from StarOE regarding modalities performed by a customer interaction. For example, as part of the reconciliation process, the StarOE can pass a list of toll-free numbers that represent services that will be discontinued and deleted from the Traffic View. After receiving this information, the Traffic View server sends another message to the responsible systems to collect call details information which the system then discontinues the collection of call data on the deleted numbers.

Another exemplary output to the individual compliance system is the hierarchy data to report compliance systems 400, 500 when a client requests reports. The data from • Client hierarchy is sent in real time by the StarOE to update the reporting information.

StarWRS As mentioned here, the data architecture component of the networkMCI Interact system focuses ^ fc 10 on real-time data reporting and reporting of call details (priceless), such as those currently provided by the Server of Traffic View ("TVS"), and data and detail reports of price calls, such as those currently provided by the MCI Operating Data Storage Server. Known as "StarWRS", the WWW / Reporting System Internet 200, as shown in Figure 10, provides ^^ customer components, mid-level services and application reps that allow customers request, specify, adapt to the client, program and receive their data and account information in the form of reports that are generated by several back end application servers. As will now be described in detail, the WRS 200 reporting system comprises the following components and message interface: 1) the components associated with the front application end of the client user graphical interface that includes a client application requesting reports 212, • a client application report viewer 215 and, a entry box client application 210 that implements the logical processes associated with a "Java Client", that is, employs Java applets launched from the backplane (Figure 3) that allow the display and creation of reports and graphs based on the fields of the reports displayed, and, allows the selection of different criteria and reporting options for a given report, - and, 2) the mid-level server components that allow the aforementioned reporting functionality that includes: a server administration of report 250, a server report scheduler 260, and an input box server 270. Supporting the StarWRS reporting functionality as described will be the StarOE client and the corresponding StarOE server applications 39. • The report management server ("RM") 250 is an application responsible for the synchronization of the report inventory with the StarODS 400"compliance" server and the Traffic Vista 500 server; rights recovery, that is, user security profiles, and report list information, that is, data for the options of adaptation of the user report to the client, from the server OE 39; the transmission of replies or messages of reports to the server dispatcher 26; the maintenance of database of reports, - and, the administration of metadata used for • display reports. In the preferred embodiment, the RM 5 250 server employs a Unix daemon that passively listens to connect requests from the client applications of the graphical user interface and other back end servers and deploys the TCP / IP protocol to receive and route requests and your answers Particularly, Unix current sockets using the TCP / IP protocol set are deployed to listen for client connections at a number of well-known ports of the designated central computer machine. The client application processes, for example, requestor of reports 212, wishing to submit 15 requests are connected to RM 250 via dispatcher 26 by providing the port number and the name of the central computer associated with the RM 250 in a request message . The request messages received by the server • RM are translated into "metadata" format and validated by a parser built in a report manager representative 250 that serves requests coming from the front end of the graphical user interface. If errors are found in the metadata entry, the RM 250 will return an error message to the requesting client. If the metadata passes the validation tests, the type of request will be determined and the data will be retrieved in accordance with the metadata request after which a standard response will be sent back to the requesting client. As shown in Figure 10, the interface sockets 252 are shown connecting the dispatcher server 26 and the server RM 250 and, other socket connections 254, 256 are shown connecting to the respective rear end servers 400 and 500. In a modality, a rear end central structure application known as the View System of Traffic receives metadata requests to provide • detail of traffic calls without a wreck and data of reports through the message interface 256 to the Report Manager. Additionally, a mid-range, backward-end application known as the StarODS server receives requests for data reporting details of priced calls through an intelligent game message interface Talarían 350 to the report manager. Additionally, as shown in Figure 10, the data with Q price and without price are directed with the transport protocol file (FTP) directly to the mail box server and a message is sent to the report manager server 250 from the Traffic View 500 server. Although not shown in Figure 10, it should be understood that the RM 250 server can manage report data for the presentation ai client from other back end and legacy servers including, for example, Event Monitor and Service Research servers, etc., in order to present these types of data and report data to a client of administration. 5 The report manager server additionally uses a database 258, such as that provided by Informix, to provide the metadata accounting and the user report inventory. Preferably, an SQL interface is used to access processing stored used to process requests and track • customer reports. A variety of C ++ tools and other tools such as Rogue Wave 's tools.h ++ are additionally implemented to perform syntactic analysis validation of metadata messages and translation functions. The report manager server 250 additionally includes programming information data, however, and a reporting program server component passes the report request to the back end f-fulfillment servers 400, 500 at the scheduled times. As shown in Figure 10, the Reporting Server ("RS") server component 260 connects directly to the report manager server 250 to coordinate the scheduling and processing of report requests. It should be understood that the respective functions of administration and programming of reports could be done on a single server. Particularly, the RS 260 is a Unix program that deploys Unix current sockets that use the TCP / IP protocol to send requests to the back end compliance servers such as the Star ODS 400 server, the TVS 500 server, at previously specified times. , and receive your answers. As shown in Figure 10, the RS 264, 266 interface socket connections are shown connecting to the respective rear end servers 400 and 500. In the case of charge data with Star ODS 400 price, the report requests are published by the RS 260 server to a previously defined subject on the Talarian server. When handling other input messages published by back end servers that use Smart Talarían 4.0, another daemon process using Talarian C ++ objects is needed to connect its message queue and extract all messages for a given subject to store in the table of the database contained in the database 263. Each message includes the tracking number of the report that was requested from the compliance server. From the requesting report interface, the user can specify the type of report, including an indication of the schedule for the report, for example, by hour, daily, weekly, or monthly. For data in real time, or without price, the user has the option of hourly, daily, weekly or monthly. The report programming interface additionally allows a user to specify a caller or email account so that a message can be sent by email or caller to indicate when a requested report is on the input box server 270. The component Input Box Server 270 serves as a repository when the completed report data and event notification data are stored, they are maintained, and eventually they are erased and it is the data source that is copied to the client's user via the dispatcher (Figure 2) on a secure 2 ^ 2 connection. It is also a Unix program that is designed to handle and process user requests presented in metadata format using the Informix database. While the report results are received from the data servers 400, 500 and any other back end compliance server (not shown), the report manager server 250 communicates the corresponding report metadata to the input box server 270 on the connection of the 274 sockets as shown in Figure 10. The metadata will be stored in the database of the input box server 273 together with the results of the reports. In this way, if the metadata is required to be changed, it will not interfere with the information necessary to display the reports contained in the input box. Additionally, as shown in Figure 10, the input box server connects with the report scheduler to coordinate the execution and presentation of reports. As described above, the StarOE server 39 and the database 160 is the deposit of the user choice lists and the user report rights. Particularly, it is shown to be connected to the input box server 270 and to the report scheduler servers 260. The report manager server includes information that will tell the requestor client application of reports that needs to be obtained (for example, lists of reports). Choice) of the StarOE server 39. With respect to the front end client user interface components, the aforementioned entry box client application 210 functions as an interface between the client software and the cashier server. entry 270 to present to the client the different types of reports and messages received in the entry box that include all completed reports, call details, and news. Preferably, the message for the user in the entry box is classified by type (report, data detail, alarms) and then by type of report, report name, date, and time. In particular, the application of the input box client uses the services of the backplane (Figure 3) to launch other applications as necessary to process report messages. The input box will also use the services of the data export objects to • provide a save / upload feature for the 5 mailbox messages, and is used to provide a user interface for software enhancement / copying control. The messages of the input box are generated by the services of formation of versions of the posterior plane, - the real copies will be made by an application through of the entry box. In the preferred embodiment, the input box client can receive information on multiple strings to allow a high priority message to arrive even if a large copy is being carried out. Typically, the search engine is configured to allow more than one network connection simultaneously, that is, the scrutiny string in the client uses a separate connection to check for new messages, and starts a new string in a new connection • when a new message is detected. In this way, you can copy multiple messages simultaneously. The application of the report requestor 212 is a client application that allows user interaction to manage reports and particularly includes processes that support: the creation, deletion, and editing of reports of the user, - the recovery and display of reports based on selected criteria, - the display of data of selected options, - and the determination of rights which is the logical process that defines what functionality a user can perform within the StarWRS application. In the preferred embodiment, a report request can be executed immediately, periodically, or as a "shot" to be performed at a later time. As described herein, the report scheduler service maintains a list of the reports requested for a given user, and sends the actual report requests to the appropriate middle level servers at the appropriate time. Additional functionality is provided to allow customers to manage their inventory, for example, reprogram, change, or cancel (delete) requests for reports. The report visualization application 215 is a graphical user interface Applet that allows a user to analyze and visualize the data and reports supplied from the compliance servers such as ODS 400, View of Traffic View (TVS) 500, and other systems, such as broadband and free network administrator. Particularly, all reports are provided through the client's application 215 report viewer that supports visual text displays, a worksheet, a variety of chart types and diagrams, or worksheets / diagrams simultaneously, and, launches from the input box client 210 when a report is selected. The report manager 250 includes and provides access to the metadata that is used to tell the requestor of reports how a standard report and the "election list" options that the user has in order to adapt the standard report to the client should be viewed . It is used to tell the client the report viewer how to display the report, what calculations or translations need to be done at the time of the exhibition, and what other options the customer has to adapt to the client while reporting. Additionally, it includes a common report view executing an applet user graphical interface that is used for the display and graph of report data and, in particular, it is provided with worksheet management functionality that defines what operations can be performed on the data sheet. work including the movement of columns, the deletion of columns, single or multiple selection of columns and rows, import and export of data from the worksheet, printing of the worksheet, and so on. A report data management functionality is also provided defining what operations can be performed on the data displayed in the worksheet including dynamic operations such as report data classification, subtotalization of report data, and so on. In addition, the report viewer 215 is provided with functionality that allows the interpretation of metadata; and, functionality that allows communication with the backplane (Figure 3). The report viewer application 215 will also be able to accept messages that tell you how to display an image or text that can go through one of the applications instead of the report data (for example, invoices, broadband report, etc.) . By associating each data set of reports that are copied via the input box server 270 with a metadata report description object, the reports can be presented without a specific reporting code. At one level, these metadata descriptions work like the catalog in a relationship database, describing each row of a result set returned from the middle level as an ordered collection of columns. Each column has a data type, a name, and a desired display format, and so on. The descriptive information of the column will be stored in an object, and the whole result set will be described by a list of these objects, one for each column, to allow a standard viewer to present the result set, with labeled columns. Nesting these descriptions one inside another allows cuts and subtotals in an arbitrary number of levels. The same metadata descriptions can be used to provide common report export and report printing services. When it is extended to describe levels of aggregation of data within the dimensions of the report, it can be used for worksheets • generic to slide up and down the contents of a screen (rollup / drilldown) with "just in time" data access. The type of metadata data may include geographic or telecommunications specific information, for example, states or NPAs. The report viewer can detect these types of data and provide a geographical view as one of the types of graph / map. An overview of the application / scheduling process of reports 600 implemented by the StarWRS report manager and the report visitor tools 15 will now be described. After the preliminary salutation, authentication and verification of the StarWRS network based on reporting rights, as described above with respect to Figures 4-6, • the user can select the 20b solicitor icon 95b from the on-screen display of the home page 79 (a) of Figure 5 (a), which initiates the deployment of a page of the StarWRS report requester network. Figure 12 (a) illustrates an exemplary dialog box 1550 provided on the network page of the requester of reports that are presented to the user after the process of greeting and authentication. In this dialog, the user is enabled to edit an existing report maintained in the inventory of the report manager, selecting the "edit" button 1551, generating a new report by selecting the "new" button 1553, copying an existing report by selecting the button 1554 , or delete an existing report by selecting the 1555 button. When creating a new report or editing an existing report, the user can enter the desired report options that include: 1) the report product, as indicated in menu 1558, and includes free options, vision, and Vnet; 2) the category of report, as indicated by the menu 1559, and which includes options for: analyzing traffic, call center, detail of calls, checking frequencies of calls, financial use, marketing, supervision, and categories of telecommunications; 3) the type of report, as indicates menu 1560, and which includes details of call details with price or traffic data options, - and 4) a reporting address, as indicated by selection areas 1563, and which includes within the limit , outside the limit, or both directions. Making reference to the flow diagram of the Figure 11 (a) which represents the StarWRS report options, the user selection of the report product, the report category, and the type of report, is indicated in step 320. Additionally, in step 325, the user can select the report format associated with a report category. For example, in the on-screen display of Figure 12 (a), associated with the category of analyzing traffic report, the ^ > Report format options indicated in the field of 5 selection 1565 include the following: area code summary, country code summary, status summary, frequent numbers, phone payment report, and call review options. For the financial reporting category, the report formats include: longer calls, calls most expensive, telephone payment report, and code summary • area, - for the marketing report category, the report formats include: summary of country code, summary of status, frequent numbers, summary of frequent area code, frequent status and frequent cities. For the category of telecommunications report, the report formats include: summary of call duration; For the category of call center reports, the report formats include: most active toll-free numbers, state summary, and country code summary. For the category of monitor usage report, the report formats include: more delayed calls, more expensive calls, more active calling card and more active free numbers. For the reporting category of verification call frequencies, the report formats include: frequent numbers, codes of frequent areas, frequent status, and frequent cities.

It should be understood that the enabling of any of these reporting options is based on predefined user rights. This is, as described above, a "Get User Security" message with a report application set 5, and a "Get User Report Security" message is sent to the StarOE server 39 via the Dispatcher server 26 to retrieve the detailed security profile (Rights) for a user that has the option of applying reports. These rights include a list of all report products, that is, Vnet, Vision, Toll free, types of reports (with price or without price) and the categories of reports that are available for that user. According to the selections of the user report, if a report has already been created and maintained in the database of the report manager data will be displayed in the field of the report inventory 1568 of Figure 12 (a). Referring again to Figure 11 (a), in step 326, a determination is made as to whether an existing report of an inventory is selected. If a report is not selected then the user is prompted to generate a new report in accordance with the client's adaptation options that the user is entitled to for the product, category, type, etc. of the selected report, as indicated in step 330. If a user is selected existing report in step 326 based on the product, category, type, etc. of report, then the user is prompted in step 328 to select among the following options: a report editing option, as shown in step 335; an option to delete report, in which case the selected report will be deleted in steps 338 and 339; and, a copy-of-report option, in which case an existing report will be copied, for example, for subsequent editing, as shown in steps 340 and 341. Whether a new report is created or an existing report is edited , the user is enabled to select customer adaptation options as indicated in step 330, Figure ll (a). Figure 12 (b) illustrates the 1596 dialog screen presented to the user that shows all categories of report personalization to build a new report and edit an existing report. From this screen and from the dialogue boxes of construction of related reports, all the initial values to recover the metadata, the options of adaptation to the client and the options of the graphical user interface builder of the report management server 250 necessary to build ( edit) a report are provided in accordance with the user's rights. Thus, in view of the exemplary network page shown in Figure 12 (b), a user can provide the following report builder and customization options as indicated in field 1570: general customization options, by selecting the field 1571; design customization options, selecting field 1573; access customization options, selecting field 1575; hierarchy customization options, selecting f field 1577; geographic customization options, 5 by selecting field 1578; and options for personalizing notifications, selecting field 1579. For the following description with respect to Figure 12 (b) it is assumed that the area code summary format has been selected, however, it should be understood that the same principles are apply to any selected format. P Regarding personalization options "general", the user is enabled to specify or change the report title, selecting the field 1571a, the description of the report, selecting the field 1571b, and the report program, selecting field 1571c. For the sample selection of the report title customization shown in Figure 12 (b), the field on the right 1580 will present the user with a field 1581 to enter the title of the report. If an inventory report has been selected existing, then field 1580 will display the existing title. Generally, for each of the customization screens displayed for existing reports, the Report Manager will autopopulate the field on the right side 1580 with the existing report values. 25 When the 1571c report program is selected, the user is presented with a 1597 screen, as shown in Figure 12 (c). The options for selection in the field on the right side 1580 include: time zone selection through menu choice 1582; selection of report program radio buttons 1583 to specify the report as a recurring entry field, daily, weekly, monthly, or hourly nature of the screen; a time range for the report as specified by the 1584 entry fields; and, a date range for the report as specified by the 1585 entry fields. The user can also specify the report as "one shot" by selecting the 1586 radio button. Referring again to the exemplary screen shown in the Figure 12 (b), with respect to the customization design options, enables the user to specify or change the number of report rows, selecting the 1573a field, and specifying or changing the report columns, selecting the 1573b field. For example, the selection of the personalization of the report columns will present the user with a column customization screen such as the 1598 screen display presented as shown in Figure 12 (d). In Figure 12 (d), the field on the right side 1580 indicates a column label 1587, and a classification label 1588. The column label enables the user to specify add or remove columns, with the selection of column names provided in field 1589. An example description of the column headings for • an example selection of the column is shown in field 5 1590. Referring again to Figure 12 (d), the selection of the classification personalization label of report 1588 will present the user with a classification personalization screen such as the deployment in exemplary screen 1599 presented as shown in figure 12 (e). The classification label enables the user to specify the columns to be classified in a 1591 available classification selection field, if the totals are going to be made, if the data in the column is going to be provide in ascending or descending order, for example, as provided by the selection of buttons 1592, shown in Figure 12 (e). In the preferred mode, the Report Manager provides the client with the capacity • to specify selected columns as a classification primary and secondary. The user can specify additional secondary classifications in addition to default classification. For example, the user can provide the following classifications: for a Longer Call Report, a primary classification is the Number of Minutes in descending order. For a More Faces Call Report, the primary classification is dollars in descending order. Referring again to the exemplary screen shown in Figure 12 (b), with respect to access customization options, the user is enabled to 5 specify or change an "IDACC" code or supplementary code, selecting the field 1575a, and specify or change the type of access within limit, by selecting field 1575b. For example, the selection of access customization within the limit presents the user a network page that has a screen of • access customization within limit such as the 1601 exemplary screen display presented as shown in Figure 12 (f). In Figure 12 (f), depending on the selected report format, the input field on the side Right 1604 presents the user with the following selectable access types: Dial 1, Card, Dedicated, Remote Access 800, Direct Dial Fax, Store / Send Fax, Business Line 800 (highlighted in Figure 12 (f)), Service • 800 wide area telecommunications, dedicated 800, Redirecta Network call, local, cellular. Referring again to the exemplary screen shown in Figure 12 (b), with respect to the hierarchy customization options, the user is enabled to specify or change the collection location by selecting the field 1577a. After the selection of the personalization option of the collection site, the user is presented with a network page that has a personalization screen such as the screen display 1603 presented as shown in the • Figure 12 (g). In Figure 12 (g), depending on the selected report format, the right-side screen presents the user with three tabs: a corporate tab 1607, a search tab, 1608, and, a selected elements tab 1609. When is selected, the 1607 corporate label enables the user to add or remove a corporation identification to / from a place hierarchy • charging in the entry field 1610. A search of the corporation identifications can be done by selecting the search tag 1608, and the items that have been selected can be displayed in a field (not shown) presented by the selection of the selected elements label. Likewise, referring again to the exemplary network page screen shown in Figure 12 (b) with respect to geographic personalization options, the user is enabled to specify or change the place of charge by selecting field 1577a. After the selection of the collection site personalization option, the user is presented with a network page having a personalization screen such as the exemplary display 1611 display presented as shown in Figure 12 (h). 25 In Figure 12 (h), depending on the selected report format, the right-side screen presents the user with three labels: a 1612 country label, a search label, 1613, and a selected element label 1614. When is selected, the 5 countries 1612 label enables the user to select, add or remove a country that can be a subject for reporting as provided in the 1620 entry field. A country search can be carried out by selecting the label search 1613, and the elements that have been selected are can exhibit in a field (not shown) presented by the • selection of the selected elements label 1614. Referring again to the exemplary screen shown in Figure 12 (b), with respect to the notification customization options, the user is enabled to specify reporting of reports by paging, selecting field 1579a, and report notification by email, selecting field 1579b. After the selection of the paging notification option, at • user is presented with a network page that has a screen of customization (not shown) that presents the user selecting or entering the user's page number, personal identification number and description of paging message. After selecting the email notification option, the user is presented a page of the network that has a personalization screen (not shown) that presents the user to select or enter the user's email address.

As mentioned above with respect to Figure 10, the Client Request Requester 212 application obtains access to the metadata stored in the report management server 250 through messages. Particularly, as described hereinafter, a message generated by the solicitor of reports of agreement with the user's request is first received by the • representative manager of reports 250 '. In the preferred embodiment, the report manager representative comprises a set of tools in the form of reusable objects, preferably written in C ++ code, or the like. By For example, a syntax parsing object tool is used to decompose the metadata messages sent by the report requestor 212 to validate the message. If errors are found in the metadata entry, the RM • return an error message to the requesting client. If the metadata pass the validation tests, the type of request will be determined and the appropriate service will be invoked after which it is sent back to a standard response to the requesting client. The report manager 250 implements stored procedures to translate the message, make the request, and send the information back to the report requestor 212 which uses the metadata to determine how a standard report should look, the adaptation options • the client that the user has, and the types of screens that should be used for the different options (ie, single selection, multiple selections, etc.). It is understood that the selection of standard template reports available are based on the user's rights. 10 The following types of metadata requests and responses that can be generated by the report requester components StarWRS 212 and report manager 250 include: 1) obtain / send report template list (GRTL / SRTL) - whose request allows the recovery of list of all standard report templates for all products and is used only to obtain general report information, for example, title, description, etc. of the report; 2) obtain / send report template detail (GRTD / SRTD) - whose request retrieves the details of a specific standard reports template; 3) obtain / send user report list (GURL / SURL) - whose request retrieves the list of all user reports for the selected report format from a user report table and is used only as a request for information general report, for example, report title, status, etc. of the report, - 4) obtain / send details of user report (GURD / SURD) - whose request retrieves the details of a specific user report, - 5) add • report definition / recognition that requests the addition of a 5 report created by the user for a report table. If the report is a scheduled report, this request is also communicated to the compliance server at the time the report expires, - 6) delete definition / report recognition (DRD / DRDA) - whose request erases a report created by user from the user table; 7) copy • report definition / recognition (CRD / CRDA) - which requests to create a duplication of the report the user is editing (other than the report title) and creates a new report identification for him; 8) update program / report recognition (URD / URDA) - whose request updates the scheduled information on a report without having to send a request to delete and add, - and, 9) obtain a selection / recognition list (GPL) - whose request allows • that the 212 requestor obtain a list of choice provided by the StarOE server. The aforementioned appendices A-H provide a series of tables comprising the content of each metadata message request that may be sent by the requestor 212 for each of the requests lists of the user, in addition to the format of the corresponding metadata message responses by the RM 250 server. Having described the functionality of selecting and / or generating a report and adapting it to the client, it is now done • reference to Figure 11 (b) where the next step 350 is described to present the user with options to execute and save the report. Particularly, in the preferred embodiment, (as shown in each of the personalization screens (Figures 12 (b) - 12 (h)), the user can select a save and exit option, represented in the Figure 12 (b) as button 1562 or an option to save and • run, represented in Figure 12 (b) as button 1563. In any scenario, the WRSEdit object allows a WRSScnMgr object to save the report to the RM server. The WRSScnMgr object launches each method of saving screens which communicates with the data manager object to place the screen data in its corresponding WRSNode. As soon as all WRSSNode objects have been updated, the WRSScnMgr object calls the object report saving method • data manager to build a noise table, to contain all the data of the reports. The communications manager uses the RptManagerMsg object to create the ARD metadata message from the noise table, the WRSCommWrapper for direct communication with the back end, and the WRSReportManagerUtilParser to handle the errors sent by the server. The report manager creates the dispatcher object, and uses the services of the class RMParser and validation objects. After determining that the client has sent a valid message, the appropriate member function is invoked to handle the request. The answer is builds inside the esql wrapper function after obtaining the necessary information through the stored procedure from the RM database. The report manager creates the RMServerSocket object and sends the ARDA message back to the client. When a report presents the type of report selected and the reporting criteria are sent to the • report manager. As illustrated in Figure 11 (b), in step 355, in reference to the user's selection of a save and run report option, the report is marked as proclaimed 15 and stored in the report scheduler server 260 via the report administrator. Subsequently, as indicated in step 360, the report server 260 sends the ARD message to the compliance server that queues the report and executes the report in the specified time, as indicated in step 365. Generally, if the report is going to be executed for immediate ad hoc reporting, or, if scheduled for a normal scheduled report, the following sequence of operations is performed, as indicated in steps 370-395, Figures 11 (b) - 11 (c): first, in response to receiving the ARD message, for example, submit to the compliance server by the report scheduler, the compliance server completes the report and compresses the report / data, as indicated • in step 370. Then, the report / data is "pushed", 5 implementing the file transport protocol, to the compliance server directory on the input box server 270, as indicated in step 373. Each application server, for example, the TVS 550 server (Figure 10), is responsible for generating unique file names within your directory on the input box server 270. By • example, the following naming and directory conventions used for reports generated by the Traffic View server are labeled inbox \ files \ TVs with the text files suffixed *. txt or * .txt_zip (compressed). The server of compliance then verifies that the file transport protocol process was successful, as indicated in step 376, and, in step 379, a notification is sent by the compliance server to the report manager for • notify the report manager server 250 the scheduled reporting location. This is done using the metadata message "NRL". In the preferred embodiment, the NRL message received by the RM 250 server includes parameters that verify whether the process of the file transport protocol was or not successful. If successful, then the compliance server notifies the entry box that the file was successfully transmitted by transmitting the name of the report (file name) and its location. When the compliance server encounters a problem executing a report, a notification is sent to the report manager. In particular, an error flag is placed in the status field of the user_report by the report manager when the user is displayed during the report request. The description of the error message will be placed in a text file and use the file transport protocol for the reporting location of the compliance server on the input box server (for example, \ inbox \ files \ TVs) by the compliance server. Referring to Figure 11 (b), step 379, as soon as the RM 250 server has received the NRL message from the compliance server, it verifies the presence of the file, as indicated in step 382. The RM 250 server then constructs a metadata file, for example, by compressing the appropriate metadata (to display the report) into a .MTD file, as indicated in step 385. This .MTD file is used by the report viewer to know how to display the report. The report manager server creates a file that includes metadata that uses the same file name as the report / data file, but has the following suffix: * .mtd or * .mtd_zip that indicates a compressed metadata or metadata file , respectively. As soon as the metadata file corresponding to the requested report is built by the report manager, the RM ftp's of the .MTD file to the input box server, as indicated in step 388, Figure 11 (c). The RM server additionally updates the status field of the user table with a status "C" indicating termination, as indicated in step 391. As soon as the report administrator has updated the status field, the RM 250 server adds then the report to the input box server, as indicated in step 393. In particular, the RM server supplies a metadata message "A" to the input box indicating the location of the file transport protocol file. Via the report viewer, the report is now available for viewing, copying, saving, or printing by the user. Particularly, as shown in the exemplary nMCI homepage in Figure 5 (a), the "Message Center" icon 81 can be selected which will cause the display of a network page that includes the central dialog box of the message 1510 as shown in Figure 13 (a). From dialog box 1510, a user may select from three labels, a news label 1512, a report label 1513 and a data label 1514. The selection of the report label 1513 allows the retrieval of both a file of data as from a metadata file from the input box server • corresponding to the reports that have been executed and are available for viewing by the client. The information provided for visualization by the visual display of the message center 1510 is provided by the user_table which keeps track of the status of all the reports for a particular user. Particularly, by pressing twice on a chosen report, a viewer application for • report is enabled to display the chosen report on a web page. Figure 13 (b) illustrates an exemplary network page displaying a text observer screen 1515 enabled by selecting the highlighted report 1514 in the Figure 13 (a). Referring again to Figure 10, the report viewer 215 connects to the user input box 210 to present the client with various types of reports received in the input box. Preferably, all the applications of report requestor and report viewer communicate with the RM 250 server through the use of common object communication classes. It should be understood that compliance servers such as Broadband, and Free Network Administrator 500, StarODS 400, Report Scheduler server, and any other back end or compliance server (not shown), send report results and event notifications to the incoming mail server 270. The servers of • compliance, and the report manager server can 5 communicate with the entry box server 270 by making requests to the representative of the entry box 270 '. The representative usually waits for a request for an application and then hears the request. The main responsibility of the representative of input box is to process requests either by handling them • internally within the representative of the input box 270 'or by sending them to the input box server 270, and then responding back to the client (that is, the compliance servers in this case). In order to maintain secure connectivity throughout the system, the representative of the 270 'input box uses the interfaces of application programs (APIs), provided by the "networkMCI Interact" that support different types of data transport mechanisms: synchronous transaction; transaction asynchronous; and, synchronous volume transfer. The transport mechanisms are implemented as a message protocol of the basketball, and the representative handles their conversation processing in a single string or process per conversation basis to attend multiple simultaneous clients. As an alternative to the previous transports, the file transport protocol (FTP) "put" for very large transfers is offered in the input box server 270 in order to alleviate some of the loads of the • network server. 400, 500 5 compliance servers with large data transfers typically use a common ZIP file sharing compression format also supports PKZIP. Alternatively, the compliance servers 400, 500 distribute information via the input box can "put" the data in the input box and 10 postpone the compaction after the input box receives the data. As described, the compliance servers, when they place the data in the input box, notify the Reporting Manager server 250 that they are adding new data in the entry box. The report administrator 250 then retrieves and the file transport protocol transports the appropriate metadata associated with new data in the input box, notifying the input box of new additions to the input box, ie the new data and the associated metadata. The metadata is then stored in the server database of the input box 273 together with the results of the report. In this way, if the metadata is required to change, this does not interfere with the information necessary to deploy the reports included in the entry box.

Particularly, as shown in Figure 16, the interface of the input box server 270 with the input box client 210 supports the message that allows the user • Remove an item from the entry box, for example, delete 5 a report, or, delete all the items in the entry box, for example, for a particular company and user identification as well as other associated reports. Particularly, the "L" list message is a synchronous request for a list of all items in the box entry for a specific user. The function of extracting • the "F" memory of the input box is a volume transfer request that allows the volume transfer of the required file to the input box client. Referring again to Figure 12 (b), After editing or modifying an existing report, the user can simply select to save the report and exit. In this case, the ARD message is sent from the requesting report client to the RM server and stored in the RM inventory database for subsequent execution. In consecuense, the report is marked as incomplete in the User_table table and can not be executed until an execution option for that report is chosen. Otherwise, the report can be programmed immediately if the user selects the save and execute button. 25 As described, metadata messaging is used in all the different components of the StarWRS 200 system. The format of an interface message that is sent to the reporting server is identical to the format as in the format • interface messaging returned by the RS 260 server. 5 Thus, in the case of reports that recur automatically, a variation of the process projected in Figure 11 (b) is presented in step 360, whereby the ARD request is sends alternatively from the report scheduler to the compliance server at the scheduled frequency. Particularly, when a report is required to be executed, the server • report scheduler 260 (Figure 10) sends an ARD request to the compliance server in a metadata message format that has parameters as included in the add report definition table provided in appendix D previously mentioned. After processing the metadata message, the compliance server will respond to the report scheduler with an acknowledgment of the command, and the process projected in Figures 11 (b) and 11 (c) is executed.

• The report scheduler server 260 additionally is able to update the user-status-report table and, preferably, is provided with a tracking mechanism to track the programming of the user's reports. If the report is an adequate report, it is marked as inactive in the user report table as soon as the status is complete.

StarODS As mentioned above, the StarODS data management tool of the integrated suite of telecommunications network applications comprises a back end architecture that provides customers with report data with prices related to the use of their telecommunications networks. Figure 14 (a) shows the high-level logical approach of the StarODS 400 data management system integrated with the StarWRS 200 component of the nMCI Interact architecture. Generally, the data management system 400 of the invention, referred to herein as "StarODS", provides customers with price report data related to telecommunications services. Although the description herein is related to collection data with price, it should be understood that the principles described herein could apply to any type of reporting data. Through a StarWRS network-based report, the StarODS system provides report data and implements a DataMart approach to maintaining the data used for reporting to clients. StarODS increasingly stores and processes customer data, and uploads this processed data into data stores. From these data trades the customer's reporting data can be provided to the customer daily via the StarWRS reporting system.

For data of reports with price, categories of • reports from which a variety of reports can be generated 5 include: a) financial category - to provide price data reports related to longer calls, more expensive calls, out-of-peak calls, telephone payment report , summary of use, summary of calling card, and summary of area code for customers Free network, Vnet, Vision and CVNS; b) marketing category - to provide price data reports related to the country code summary, state summary, frequent numbers, frequent area code summary, frequent status, and frequent cities, - c) telecommunications category to provide price data reports related to call duration summary, IDACC / Supp Code Summary and Call Access Summary for Free network clients, VNET, Vision, CVNS; d) Call Center report category - to provide price data reports related to the most active toll-free numbers, - Hourly distribution, Day of the week distributions, state summary, and country code summary for your Free network clients, VNET, Vision, CVNS; e) Use of Monitor - to provide price data reports related to longer calls, more expensive calls, more active calling card and more active free numbers for your clients Free network, VNET, Vision, CVNS; f) Analyze Traffic - summary of area code, summary of country code, summary of status, summary of rank, summary of city, frequent numbers, report of telephone payment, summary of use, summary of calling card, summary of IDACC / Supp Code, Distributions by Day of the Week, Hourly Distribution, Call Access Summary and call review; and g) Category of Checking Call Frequencies - to report frequent numbers, frequent area code, frequent country codes, frequent status and frequent cities. Figure 14 (a) illustrates the primary components implemented in the data management component of reports with StarODS prices. As shown in Figure 14 (a), a first data feed 405 provides detailed records of 'raw calls from external network switches, translates and classifies the data into collectible records to be input into two systems: a server process of central computer ("NCBS") of the commercial billing system 410 to price the registers at subscription rates of customers to, for example, VNET telecommunications products and MCI Vision; and, a free network charging server process 420 to price the registries at a rate for customers subscribed to free network telecommunications products. A common data gate component 430 that includes a 435 central computer extraction process and a meeting process • 440 data receives these entries daily and monthly 5 for processing. Particularly, the 435 central computer extraction process creates a selection table that includes all subscription clients, compresses files for transmission and extracts report records from execution streams. The meeting process 440 is responsible for performing validations, data filtering, data translations, data grouping, data routing, and data logging functions. According to a table of dimensions based on data with within selected BDRs, the meeting process applies business rules to the data, clean the data, transform the data, create load files for DataMarts and compress files for storage in the DataMarts. The 440 meeting component can additionally perform an aggregation function to support long-term storage and fast data access for client reporting, and performs trigger actions / events based on predefined criteria. Additionally, as shown in Figure 14 (a), other external systems and applications can be connected to the common data gate component 430 including: Cyclone 422a billing and Virtual Concert 422b services that provide additional billing detail records; and, an area database 425 that provides geographic reference information, i.e., identifies • city, state and country information. 5 After the data has been processed in the 440 meeting component, it is entered into an operational data storage component ("StarODS") 450 that stores the billing detail records and the dimension tables as a data model. . This StarODS 450 10 layer is composed of all the collected data of all the • applications in the data gathering layer 430, and feeds DataMarts of 470 report support in the way that it supports access to data adapted to the client. DataMarts can be technically designed to pre-process data, create 15 aggregates, and otherwise perform transformations on data before loading DataMart 465 in order to implement a defined data model, - for example, keyframe structures star, table of facts and dimensions • represented as block 460. In the preferred embodiment, 20 as shown in Figure 14 (a), the operational data store 450 includes multiple DataMarts 470 each for storing and retrieving data daily and monthly periodically. Mainly responsible for hosting very common data, for example, when less than 72 hours old. 25 According to the customer's reporting needs, the DataMarts 470 are divided according to division schemes that, in the invention, can be based on customer identification. In particular, each DataMart is technically designed to serve specific customers or specific product groups, as well as technically designed for specific customer / product requirements such as high insertion activity, heavy reporting requirements, and so on. As the data is volatile and changing and can not produce consistent results for the same query released at different times, ODS is technically designed for high performance through appropriate storage technologies and parallel processing. Although not shown, a common data store is provided in this ODS layer that is responsible for storage, retrieval and data archiving, typically of relaxed relevance (eg, more than 24 hours) and is aimed at analysis and detection of data. trends. In a preferred embodiment, DataMarts use an Informix® database in a star topology. As described herein, from the data included in these DataMarts one-time reports or recurring price data are available for reporting through the nMCI Interact StarWRS 200 reporting system. Additionally, the ODS component 450 includes a decision support server ("DSS") reporting the 475 machine component that performs the following functions: (1) receives requests for data access from multiple users in the form of requests for reports from a component • request for reports of graphical user interface of StarWRS and consequently generates database queries; (2) Route the query to the appropriate DataMarts 470, the data store or the operational data store, - and, 3) respond to the requestor with the result set. The DSS 475 server can also perform cost estimation, programming of agents, workflow transmission interface, and • transaction registration functions. In the preferred mode, the DSS 475 is a bunch of Unix 8400 servers from DEC (Digital Equipment Corp) running information with the Advantage® software that accesses an Informix® database, by example the Informix Dynamic Server database product V.7.3, distributed through multiple DataMarts. According to the invention, the primary function of the DSS 475 is to generate billing report data according to the customer request which is received from the StarWRS report component as a metadata message. To accomplish this, the DSS connects to two StarWRS systems: the administrator / report scheduler 250, and the input box 270, as shown in Figure 14 (a). The administrator / programmer of reports formats the request of the client according to a defined set of rules and sends the metadata request message to the DSS. DSS 475 reads client requests that are metadata descriptions of the type of data reports requested by a client, • translates metadata to database queries, and implements immediate commercial tools ("COTS") such as Decision Suite® of Information Advangtage, to generate SQL queries, and execute queries against data in DataMarts. After this, the results of the queries are formatted by a formatting process in a readable form for the StarWRS report display components, and • the completed reports are transmitted to the directory of the customer's entry box. In the preferred embodiment, a publish and subscribe communication tool 350 such as software adapted to the SmartSockets® message client is used.

They would log to coordinate requests for reports transmitted from the StarWRS report manager to the DSS, and the DSS report termination notification to the StarWRS report manager. The report administrator formats the • customer's request according to a defined set of rules and send the requests to the DSS as a message Talarían with the report manager 250 maintaining the sending program of Talarían and the decision support server 475 that maintains the receiving program Talarían. Messages are sent with guaranteed message delivery ("GMD"), ensuring so all the request data sent by RM are received by the DSS. As is known, the software adapted to the Talarian message client defines a message as types of subjects. A message type is a structure that defines the format of the message. Message subjects are subsets of message types and describe messages by which Talarian recipients can subscribe. Conversely, message subjects describe messages by which Talarian senders publish. In the "API" application programming interface, the RM 250 server publishes the message to the decision support server in response to its receipt of a report request. Similarly, a DSS / Inbox application programming interface is provided to handle FTP transmission of completed client report files that include: error handling, retry logic, and the ability to maintain the name and location of the file from which it is stored. they store the report files. In particular, the application programmer interface sends the report file to the input box (Figure 14 (a)). In the preferred mode, the DSS architecture is transparent to the report manager that posts messages Talarían to which the DSS will subscribe. More particularly, an RTServer process located in the report manager is provided to maintain connections, implement a queue of 490 report requests to ensure guaranteed message delivery, and track the success of all message operations. In addition to message • request for string of characters in symbols that specify 5 the type of report, filters, and any specific information of the request, the report manager server provides additional fields as part of the request message Talarían that include: a Corp_ID, priority, and RequestID. Corp_ID allows the DSS to route the request to appropriate data store without invoking the parser.

• The data is divided into Corp_ID in the ODS database store. Request_id is used to send again an ARDA fault message, in the case of an invalid message. The priority field allows the DSS to collect the next registration request queue priority of unprocessed requests, without invoking the syntax parser. Figure 14 (b) illustrates the implementation of an Information Advantage® Interface ("IAIO") object 472, the • what is a process that runs on the DSS 475 to perform the following functions: 1) publish and subscribe messages Talarían to the Report Scheduler; 2) parsing the ARD request metadata messages (Add Report Definition) received from the Report Scheduler (RS) 260; 3) publishes an ARDA (Add Recognition of Definition of Report); 4) populate a request table 493 with information of the total, subtotal and classification according to the received report request, -L 5) transforms the ARD symbols of the metadata request into a superimposed file 492 which is • a text file that is submitted to the Decision Suite® 5 Information Advantage process to generate the corresponding SQLs; 6) update a 4941 Application Status table with appropriate status, for example, complete process, failed, in progress, etcetera; and, 7) if a failure occurs, update an error log (not shown). 10 More particularly, in view of Figure 14 (b), the • ARD metadata request messages are received in the ODS system via arbitration processes that are responsible for routing the request message to the appropriate ODS database according to a Corp / ODS mapping table (not shown). 15 In Figure 14 (b), a Talarian receiver, referred to in the present Talarian Interface Object ("UNCLE") 350, is a process that receives the Talarían message, handles the GMD functionality, and updates the request table. 493 and the table of status of requests 494. The contents of the table of ODS requests 493 is the table maintained for the purpose of maintaining report request information specific to the ARD message received, and, a Request Status table 494, to track the status of the DSS processes for the current request. As shown further in Figure 14 (b), the Receiver 350 inserts the received message from an arbitrator in the table of requests 493 and the table of status of requests 494 together with the fields of priority, stamp of time and status. The table of status of requests resides in the base of • ODS data and messages are stored in the queue to 5 provide queue training, logging and fault tolerance. To determine the pending messages to be processed, flags of a status field and historical statistics (history_stat) are used. As shown further in Figure 14 (b), in operation, the Information Advantage® Interface Object • ("IAIO" 482 reads status table 494 to determine new entries.) When a new entry is placed, it invokes a parsing process 495, to analyze the message ARD of request of received report, and generates a file of superimposed text 492 comprising symbols corresponding to descriptions of data and format of the requested report. An SQD machine generator, for example Decision Suite®, receives the superimposed file 492 and performs the following functions: 1) generates SQL; 2) submit the SQL to the appropriate datamart (base ODS data); 3) generates a Report file with an extension *. txt; 4) Update the Application Status table 494 with adequate status; and, 5) if a failure occurs, update the error log. After the generation of the * .txt file, a classification process is invoked to perform the following functions: 1) read the table of Requests 390 to see which column is to classify the Report; 2) read the file * .txt; 3) Classify the file *. txt and generates two files: i. a file with a * .hdr extension whose file contains the header information, which consists only of column IDs only, and ii. a file with a * .data extension whose file contains classified data provided in the file *. txt and is the body of the report, - 4) also updates the status table of requests with a code of 'success' or 'failure', - and, 5) if shows a failure, updates the error log. • The end-to-end process 600 of a data reporting request to report the delivery is shown in Figures 15 (a) - 15 (c). Assuming a user authentication and greeting successfully, as described herein, the first step 602 of Figure 15 (a), indicates that a user has opened the report requester dialog box of the home page (Figure 5 (a)) by selecting the requesting icon of • report 83. 20 Using metadata messaging, the StarWRS report requestor retrieves an available report list (including user defined list) from the StarWRS report manager, as indicated in step 605. This process involves invoking an administrator object of communications to communicate with the RM server in order to obtain a SURL metadata message, as described. Then, as indicated in step 610, the inventory of reports for the specific user is loaded and • display for the user on the display screen of 5 user report request, allowing the user to select a report, as indicated in step 612. Then, in step 615, the selected report is retrieved from the report manager StarWRS and it unfolds in the manner described. 10 Then, as indicated in steps 618 and 620, the • user selects a product, including telephone numbers and geographic locations, etc. and introduces criteria, that is, reports intervals and frequencies, if a new report is desired. Specifically, when the user selects a report of the inventory list or a new report, a StarWRSEdit screen is launched to provide the editing capabilities that are available for the report format, as described. As soon as a report is created, the user can save the report request, for example, by pressing a "save and exit" button, or by submitting the request, as indicated in step 625, for example, by pressing a "save and execute" button. When a report is submitted to the selected report type and reporting criteria are sent to the administrator of report. As indicated in step 628, the RM creates the request for metadata for which the DSS has a predefined interface. The metadata request is submitted by the StarWRS report requestor to the COTS software module, for example, such as the one provided by Information Advantage® whose module is used for generating and executing SQL queries and retrieving and formatting the results. In particular, the metadata requests are transmitted via an interface with the Talarian SmartSockets product and a header is built for each report request that includes the CorpID and the company information used by the IAIO to select the appropriate DataMart as the target. for the consultation. At this time, the requestor of reports additionally creates an entry in the RM table to track the progress of the request. RM communicates with the StarODS using Talarían's SmartSockets® that creates a header that comprises the product and other information, and controls the delivery of the report requests. The guaranteed messaging feature SmartSockets automatically routes the call and repeatedly tries until delivery is successful. Next, as indicated in steps 630 and 632, the DSS receives the request and acknowledges receipt. Specifically, when the application is received it is first validated with StarOE to ensure that the user is entitled to receive information about the product corporation and number or numbers. As soon as the request passes the validation, the DSIO IAIO reads the header to determine which DataMart will finally be consulted. It then parses the metadata in a format in which the COTS software can • easily convert into a SQL statement, as indicated in 5 in step 635, Figure 15 (b), and add the report to the DSS report queue based on the type (daily, weekly, monthly, adhoc) and the associated DataMart as indicated in step 638. It should be understood that at this point, the request has been marked as filed in the RM database, as indicates in step 633. • From that point on, the DSS activity is controlled by a process of control and progress or the errors are recorded internally in the DSS system. This control process includes logic that enables the priority of the report requests and the application of rules that define the order in which they should be executed. In this way, at the appropriate time, depending on the type of report, the reporting period and other parameters, the query machine • Information Advantage® selects the report of the queue, how is indicated in step 640, whose action is recorded in the report status table (Appendix I) as indicated in step 642. The SQL statement is then constructed by Decision Suite® and routed to the appropriate datamart for its execution in the manner described herein, as indicated in step 643.

The query machine generates the SQL statement from the metadata and executes the report whose action is recorded in the report status table as indicated in step 645. Then, as indicated in step 648, the results of the • query are returned, and, a 5 post-SQL formatting process is invoked. More particularly, the suite of decision results of the Decision Suite® is introduced in a Formatter module that performs different transformations of report results that include: 1) Converting column headings generated by Information Advantage® in suitable column identifiers that are recognizable for the StarWRS client observer functionality (as indicated in step 650), - 2) Provide subtotalization for specific columns requesting "subtotal by" in the required format by StarWRS client interface (as indicated in step 653) and provides totals based on reports as requested by the client; 3) convert the binary stream data file to ASCII text file (as indicated in step 655), - 4) implement the Replacement logic, for example, replacement of delimiters " " with appropriate "Coma" field delimiters (as indicated in step 657); 5) implement the logic of Repeat / Fill, that is, identify columns / compressed values and decompress (or repeat) the values that were compressed; 6) provide alphanumeric translations of any coded data element returned in the result set data file (as indicated in step 659); and, 7) add new calculated / derived columns, for example, by hundreds, averages of column data values, etc., as required by clients on specific reports. After formatting the report, as indicated in step 660, a message is sent to the control process to update the status table of requests 494 (Figure 14 (b)). It should be understood that, if a failure occurs during formatting, the error file is updated and a status message is sent to the status table of requests 494, as well. Then, as indicated in step 665 (Figure 15 (c)), the formatter creates a * .csv file (As Separated Value) or * .txt, gives the file a unique name and saves the file. Preferably, a * .csv is the generated file if the report is generated successfully, as indicated in step 668, the report / data file * .csv is "pushed" then, implementing FTP, to the StarODS server directory in the input box server 270. Finally, as indicated in step 670, as soon as the file has been successfully transferred to the data reporting directory with Price on the input box server, an NRL message is sent to the server Reporting Manager 250 notifying the name of the report file, its location in the Entry Box, the information of the requestor and whether the transfer was successful. This is done using an NRLA metadata message sent back to the DSS. The report manager is subsequently notified of the successful completion of the report and the report request is marked as completed in the report manager database. If the report is a recurring report, it is not marked as complete. After the control process updates the report status table, the StarWRS report manager is notified that the report is complete and the inbox server notifies the user that the report is ready. A user can subsequently retrieve the report by pressing the center message icon 81 from the household page of Figure 5 (a) which will present the client with a list of all available reports. To view a report, the user selects the report and the report metadata and the appropriate viewer are copied to the user's workstation (client).

TVS As mentioned, the traffic view system ("TVS") 500 of the present invention comprises a Server of Traffic View 550 which is responsible for storing the records of the detail of calls in the network (CDR's) and statistics, generating and providing reports and / or detail of calls to the client through the StarWRS Reporting System of the network and providing access online detail of customer calls and statistics per hour that help the customer in the administration of the network, in the administration of the call center and in the analysis of the customer's call pattern. For real-time data (without price), the statistics are generated for the following totals: minutes, attempts, complete, incomplete, others, overflow of direct termination (dto), short calls, did not wait, did not answer, tec and failures of the equipment. The process by which the TVS 550 server obtains information is now explained in more detail with reference to Figures 18 and 19. As shown, the call records are created by a switch of the 501 network. A switch is placed with each switch attached processor (AP) or an item verification and storage platform ("SAVE") 502 that receives all call records from the switch as soon as possible after the call is disconnected. The AP / SAVE sends all call records to a Network Information Concentrator (NIC) 503 where the records are grouped and numbered to achieve more efficient network utilization. If the NIC determines that a space is missing in the numbers, it will require the AP / SAVE to forward that group of data to ensure there is no loss of information. If the NIC is not available to receive data, the AP / SAVE queues the data for later delivery. The NIC 503 receives all calls from all switches as soon as possible after a call has been disconnected (hangs) and distributes the 5 registers to clients that meet certain criteria. A component of the generalized statistical machine (GSE) 504 receives all records that are considered free calls (800 / 8xx, etc) from the NIC and also uses the same sequence of record groups to ensure that 10 information is not lost. If the GSE is not available, the NIC will queue the data for later delivery. The GSE 504 component then filters the free calls to process only those calls that match a list of subscribers which is maintained by an OE process of entry order in the GSE (not shown) that accepts, adds and deletes requests from the TVS by a message interface 507 as shown in Figure 18. The GSE component then gives shape to the CDRs, that is, it improves the call records of the form originally 0 provided in the switch, in a standardized way to achieve a common record form regardless of the type of switch that created the record, or the exact type of call record. For example, different switches in the network generate different call detail records, that is, call detail record, improved call detail records, etc., which denotes differences in the services and features of free calls. This type of call detail record generated by the GSE component • refers here to a translated call record (TCR). 5 The TCR groups are sent from the GSE to the TVS via TCP / IP. When the TVS has safely stored that record, it sends an acknowledgment to the GSE 504 so that the GSE can discard the group. If the TVS is not available to receive data, the GSE queues g ^ 10 the data to be sent later. As shown in Figure 18, in the preferred embodiment, the provisioning of the initial client occurs either in the entry order system of the corporation 292 (CORE) or in the component 39 of the StarOE server of the MCI interaction. As shown in Figure 19, CORE 292 transmits daily to the TVS 550 server through the network data mover (NDM) files that include information about new reports for TVS to create them, and where to send them • these reports, that is, Fax, email or US mail. In the NMCI interactive traffic view server 550, a CORE FEED 523 process provides report orders and profiles in a reference database 551 and establishes a schedule of reports for working in the next neighborhood, that is, each hour, daily reports at midnight of the 25th following full day, weekly reports at the end of the following week, monthly reports at the end of the month, etc. If this report requires call detail records, unlike the aggregated data, a CDR database is selected based on the weights of the values for the existing database. If a request contains a free call number that has not been provided with the GSE, a 524 GSE_OE process is invoked to track the order, that is, the free call number of the reference database to a queue of DEC messages (DMQ) 526a. A process 527 GSE_OE_SEND is invoked to keep a TCP / IP plug open to the GSE process in such a way that the pending command can be directed to the GSE 504 via a TCP / IP interface. Once the order has been provided in GSE, the GSE can initiate the collection of CDRs based on the required toll-free number. In response, the GSE will invoke the 527 GSE_OE_SEND process to send a response order to DMQ 526b, where it will be accessed by the 524 GSE_OE process. The GSE_OE process 524, in turn, will confirm that the number has been provided within the TVS server and update the reference database accordingly by removing the order from a list of pending orders. The invocation of the GSE_0E and GSE_OE_SEND processes allows the tracking of new client orders, that is, new numbers of free calls in the network for which CDR data should be collected.

As shown below in Figures 18 and 20, in the preferred embodiment, requests to enable traffic view clients are received in real time from StarOE 39 through TCP / IP. Generally, the StarOE specifies that general categories of reports may be required for a given nMCI interactive subscriber. These categories include: (1) reports that only require aggregation of data, - (2) reports that require the collection of call detail records, - and (3) real-time screen reports (RTM). This is provided in the reference database 551 for future verification of requests from the nMCI interactive platform. If a request contains a toll-free number that has not been provided with the GSE, a subscription request is sent to the GSE 504 to initiate the collection of traffic view data pertinent to the toll-free number. This request is sent by placing a request in the DMQ queue 553 and the process 554 GSE_SEND_OE then directs this request to the GSE 504 through a TCP / IP interface. In the preferred mode of an "order entry" message generated by the TVS server for the priceless traffic data request from the GSE, it selects all the TCRs for the TVS enabled clients and places them in a storage queue. SAVE, that is, Versant or Talarían, for a subsequent distribution of the TVS server.

As shown later in Figure 18, an input feed of component 508 of the calling area database ("CADB") provides the TVS 550 server with reference data that includes information on the state and country to map to. NPA / NXX (Number plan area / Number exchange) the name of the city and the state code, and, to map country codes to country names. The data is transported from the CADB 518 database to the TVS server through the network data mover ("NDM") or the FTP via a 519 interface. A subsequent input power of the global information repository component (" GIR ") 511 provides the TVS server with free international call number terminations on a periodic basis. From the component of the command circuit management system ("COMS"), TVS receives three NDM feeds: 1) a master-type trunk feed 516 used in a priceless report to map EVS / DAL information (enhanced voice service / line dedicated access) to specific service locations; 2) an automatic number identification ("ANI") 517 feed also used in the priceless reports to map EVS / DAL information to specific service locations; and 3) a switch mapping power 518 for mapping the switch identifier (per network control system) to the billing representations of the same switch. As shown later in Figure 18, the priceless data collection process begins with the • placement of an order for priceless reports with the customer account team 5. Specifically, the account team places the order in real time using a component of the order system. In a periodic process, the information of this order is transmitted to the OEHubs 224, that is, by e-mail which later places the necessary service and 10 the report flags in the StarOE 285 component, through • of the message interface 226. The OEHubs 224 subsequently adds new customers to the system component ("CORE") of the entry order of the corporation 292, which provides the customer with a hierarchical billing information 15 used by the StarWRS system. The new client hierarchy information is extracted by the CORE system 292, and is available for use by the StarOE server 39 through the message interface 227. The StarOE server 39 then sends a message to the traffic view server. 550 in real time through TCP / IP in the sense that the number has been added for a priceless report. The TVS additionally sends a message to the GSE 505 component in real time to immediately start collecting details of the call for this number, as will be described in greater detail here. Due to the inherent latency in process compliance, customers can select and receive daily reports after the CDR collection begins. • According to the invention, they are available a wide variety of reports and report frequencies. In the preferred modality, there are reports in frequencies by hours, by days, by week and by month. The types of TVS reports that are available to clients include: Standard reports, - summary reports, - 10 completion reports; exception reports, - and, detail of • free calls. For example, the standard reports that can be generated from the hourly statistics of the free calls stored include, but are not limited to-. Summary by free call number and time that is find available in the following frequencies (Adhoc "A", "Daily", "D", Weekly, "W" and Monthly "M"; summary by free call number and date (A, D, W, M); Summary by free call number and day of the week ("DOW" (A, W, M); Summary by free call number and week (A, M), - Summary by number of free call and NPA (A, D, W, M); Summary by free call number, service location and date (A, D, W, M); Summary by free call number, Service location and DOW (A, W, M); Summary by free call number, service location and week (A, M); Summary by service location and time (A, D, W, M); Summary by service location and date (A, D, W, M); Summary by service location and DOW (A, W, M); Summary by service location and week (A, M); Summary by service location, free call number and time (A, D, W, M); Summary by service location, free call number and date (A, D, W, M); Summary by service location, Free call number and DOW (A, W, M), Summary by service location, free call number and week (A, M). Free call summary reports generally cover three sections: Summary, Incomplete call analysis, and client analysis blocked on the network (another category stop). Termination summaries include three types of termination reports: Free call by location, that is, show completion summary and incomplete call analysis by service location for a specific free call number, - By location, that is, by service location through all the toll-free numbers that end in the same service location; and, free call location, that is, for a specific service location, shows each free call number ending in this location. The code summary reports that originate in NPA / Country provide information by NPA and Country for each toll-free number attached to this report. Additionally, what is called the Call Detail Exception Reports / Images that provide reporting information pertaining to the following are found: Completion and retry rate (A, D, W, M); Completion rate and retry with queue abandonment (A, D, W, M); Missed caller and retry (A, D, M); Lost caller and retry with queue abandonment (A, D, M); Most frequent call numbers (A, D, W, M); Most frequent NPA / NXX calls (A, D, W, M); Most frequent call country (A, D, W, M). The nMCI interaction exception reports (images) include: Completion and retry rate (A, D, W, M); Completion rate and retry with queue abandonment (A, D, W, M); Missed call and retry (A, D, M); Missed call and retry with queue abandonment (A, D, M); Most frequent call numbers (A, D, W, M); Most frequent NPA / NXX calls (A, D, W, M); and, Most frequent call countries (A, DW, M). The nMCI interaction (data) exception reports include: ANI call detail by origin (A, D, W, M), - Call detail by ID code (A, D, W, M); Call detail by NCR indicator (A, D, W, M); Detail of call by origin state (A, D, W, M); Detail of call by arrangement (A, D, W, M); Detail of call by service location (A, D, W, M); Telephone payment summary (A, M), - The nMCI downloadable interactive call detail reports include detail of traffic view calls (available as adhoc and diary) and call detail details of out-of-limit traffic view ( available as adhoc, daily and weekly) As mentioned, through TCP / IP messaging, the TVS 550 system receives a real-time request from the interactive StarOE nMCI component to initiate the collection of call detail records for the reports TVS / without price of a particular customer, whose number has been previously assigned during the order entry process. When a customer discontinues the reports without price for a number, this information is entered in the StarOE tables where it is stored for a determined period subsequent to the termination of this number. After the predetermined period of time, for example, seven days, the numbers programmed for the elimination of the service are passed to the TVS through real-time TCP / IP connectivity. After receiving this information, TVS instructs the GSE (504 to stop in real time the collection of the CDRs for these numbers.) Figure 21 illustrates a generalized block diagram that details the internal data acquisition process of TVS. in figure "1, a TVS server process" GSE_TCR_RCVR "564 receives a group of TCR records from the GSE 504. The GSE_TCR_RCVR 564 process inserts that group into a DMQ queue (DecMessageQueue) 553a which provides a guaranteed delivery of the message. If a record is successfully stored in queue DMQ 553a, the process GSE_TCR_RCVR 564 sends an acknowledgment to the GSE 504 component in the sense that it can delete that group If the TVS fails to recognize this group after a predetermined time frame , the GSE continues to send this group until an acknowledgment is received.

• TCR_DISTRIB 566 reads record groups and distributes a 5 record based on the toll-free number associated with that record as follows: First, as the reference database 551 contains information about what toll-free number it belongs to which CDR database associated with the server TVS, the registers are grouped for each CDR 561a database, • 561b, ..., 561n, to which they belong. The reference database 551 additionally marks which numbers are going to be collected statistics. Thus, an additional group of records is created and can be routed to a DMQ 553b queue which captures these records in a "stats" 570 statistics counter process for statistical processing as will be described in more detail here. When all the records in the group have been read, each group is written to its DMQ queue • 554a, 554b, .., 554n associated with its destination database CDR 561a, 561b, .., 561n. For example, through a TCR cartel process 555a, the records destined for the CDR 561a database are taken from the DMQ 554a queue. Particularly, each poster process CDR 555a, 555b, .., 555n reads data from its corresponding DMQ queue and shapes it and stores these records in its base. data.

Further considering the stats counter 570 shown in Figure 21, the TCRs are taken to the statistical records. Specifically, the stats 570 counter keeps • accounts of the following: summary information on each 5 free call number for one hour, - summary information on each free call number and one hour termination, - and, summary information on each number of free call and origin NPA for an hour. These statistics are kept in memory for a predetermined amount of time, for example 10 hours, one hour. As matching records appear, they are updated statistically. At the end of the time period, these records are written to the statistical database 571 particularly by high-speed electronic devices. The statistics that are collected for each subscriber's free call number in the TVS system of the invention include: Total terminations, total call duration, total attempts, total call control of the switch, network control systems blocked totals 20 (NCS), total NCS's rejected, total network locks (all routes occupied), total supp code blocked, and out of blocked bands. Additionally, the statistics gathered for the processing of NP tables include: NPA of origin, total of attempts for NPA, total calls completed (Tec) by NPA, total calls not delivered (blocked) by NPA, total attempts by international origin, tcc's by international origin ("10"), total of calls not delivered (blocked ) by 10. 5 Additionally, end-of-call statistics include: Type of termination, address of termination, total terminations, total duration of the call, and call provisions indicating the cause of an incomplete call, which includes: total short calls, 10 total unwritten, and total unanswered. With respect particularly to the design of the statistical data base and, in the subsequent view of Figure 21, the stats 570 counter contains processes that read TCR's from the queue DMQ, and create statistical records to fill the tables_c in the statistical database 571. The algorithms implemented in the stats counter process of the TVS 570 are to generate tables of statistical data in such a way that the TCR records can be batch processed by flP. The processes include: a process of summary table whose process generates statistics for call summary data, - an NPA table process; processes of tables by country and processes of termination tables. The stats 570 counter allows you to run multiple processes at the same time on the same machine. To allow a number In the arbitrary counter-stats process, the statistical database is organized as a series of configurable tables, for example, the "C_tables" 572, which are temporary tables in which the statistical counters first insert records. These tables are identical to the normal statistical tables, with the exception that they include a field for the date. According to the provision of the tables_C, a table of pending statistics list and a table of use list of statistical table is used to keep track of what information is in tables_C and to handle the movement of data from tables_C to more permanent tables in the database 574. Particularly, when the counter stats 570 process begins, it performs a verification of the set of C_tables by inserting its process name in the field ("used_by_process") of the usage table table of the statistics table. If the stats counter process dies unexpectedly, it reclaims the previously used tables by looking in the list of utilization of statistical tables for the tables marked with their process name. The stats counter process adds an entry in the list of pending statistics each time you create a statistic for a new day. The usage flag is initially in "1" within the table. At the end of the hour, for example, the stats counter process marks all the usage flags in "2", and modifies the value of the field ("used_by_process") in the utilization list of the statistics table by leaving the content of "MOVE". The process of • stats counter then looks in the list of use of tables 5 statistics another set of tables to use for the count of the following hours. If the stats counter process can not find a set of tables, it aborts. To avoid this, there is an extra set of C_tables configured with entries in the list of utilization of statistical tables. 10 In a list table of pending statistics which includes a directory in which the stats counter is working, or with which it has ended, each record represents a name of a table_c containing statistics and dates that are contained in said table_c. The 15 generation report process, an online access, uses this table to determine if there is any information in tables_C that is of interest, and what is the name of the table. The stats counter process inserts records in this table and the data_mover 573 processes shown in Figure 21, delete 20 entries from this table. An example of the list table of utilization of statistical tables includes a list of all the C_tables that are configured and used by the stats counter processes and by the data_mover processes to assign tables between them. The number of records in this table remains static. The stats 570 counter processes update the field ("used_by_process") with its process name when they are under the control of that table. At the end of the hour, you can modify the field ("used_by_process") 5 to "MOVE", and try to find another table that is unassigned. Movers change the name of the field ("used_by_jprocess") to "NONE" when they finish moving the data from that_C_table. In the preferred embodiment, there are four types of movers that are configured concurrently • to run: NPA, Summary, country and termination. Each type of mover searches the list of pending statistics for the name of the table__C of the same type with a use flag in "2", for example, and the smaller date. The mover later transfers the data from this date from table_c to the appropriate permanent table. At the end of the data transfer, the matching record is deleted from the list of pending statistics. If there were no more entries for this table_C • in the list of pending statistics, the mover process carries out the precautionary step of looking in table_c for additional data that were not recorded in the list of pending statistics. Then entries are added to the list of pending statistics for any data found in table_C. If no additional data is found, the field ("used_by_process") of the statistical table usage list is modified from "MOVE" to "NONE" for this C_table. The interaction between the reporting system based on the StarWRS network and the TVS 550 system will be explained in greater • Detail with respect to Figure 22. In the modality preferred, the reports can be triggered by two possible sources: a definition of itinerary report by means of a CORE order; and, through real-time reporting requests followed by the report request / report management server 250. The report generation process here onwards will be described with respect to reports in time • Real StarWRS system. As mentioned, the requests are received in real time from the report management server 250 which passes the reports as required by the end user, or report that it has a report with internal itinerary through the server of itinerary of reports 260. In the server TVS 550, a proprietary process of administration of reports 250 '' gathers information on the reports that are going to be generated from the reference database 551 determining whether the request for the report can be carried out through statistical processing, or through the CDR's. If the CDRs are required, a determination is made of which database contains the necessary information. Additionally it is determined if the CDR information necessary to fulfill the request covers a long period of time, for example, several days. Once these determinations have been made, the requests are sent from the proprietary process of the report manager 250 '' to the appropriate DMQ queue 554a, 55b, .., 554n, or 553b where they queue for report generation. For the scenario where it is required to generate data reports of call details, that is, those that require records of call details, the destination of the report, for example, the server box of entry StarWRS 270, fax, US mail, etc, is determined from the reference database 551. Then, the required information is gathered based on the metadata request, analyzed and accommodated by several processes corresponding to the report generator in detail, indicated in Figure 11 as 559a processes , 559n. Although they do not appear in Figure 11, it should be clear that reference data originating from CADB and COMS may be necessary to complete these reports. In addition, although it does not appear, the TVS server is provided with an additional set of queues and reporting processes for each CDR processed to allow long reports to not interfere with short reports. In the reporting processes in detail, the information is placed in a comma-separated value (CSV) format and taken to a database of finished report files 582, where a server interface process input box 583 FTPs the report to the nMCI 270 interaction input server server. The input box interface will in particular take the completed report to the pre-defined directory in the input box database. In particular, the input box is notified via TCP / IP that the report is complete as far as the input box interface process is concerned and that the appropriate meta information is available for the presentation of the report by the reviewer of reports. If the required report has its destination through the delivery by mail MCI (Fax, Mail, US Mail): then the information is accommodated with headers, page breaks, line numbers in a report that is saved to a file. The report is then sent to an internet gateway 279, for example, the MCI Internet gateway directly from the report generators in detail 559a, .., 559n to be delivered via MCI mail. Once the file has been sent successfully, it will be erased, allowing the generation of reports to continue when the MCI Internet mail gate is not available. For those requests for customer reports that require adding data, an identical process is applied, that is, statistical. However, the data that is collected and analyzed is obtained from a summary report generation process 581 which obtains the data from the required report from the statistical database 571 under a report request receipt from the DMQ 553b. As described here, when the user requires detail of calls for a particular period of time, this request is processed through the StarWRS component to a metadata file which is sent to the TVS in the manner described here. Users schedule the execution of the reports using the report scheduler in StarWRS in the manner described here. When the user has finished the selection, the modifications and the scheduling of the reports, the component of the report scheduler of the StarWRS 260 creates a metadata message that covers this information, and whose file is passed to TVS in real time. The TVS then uses this file to formulate a queue and executes the report for the programmed time period. After TVS executes the report, it sends the report to the server component input box 270 of the StarWRS immediately after they are finished.

RTM As shown later in Figure 18, the infrastructure of the mid-level and front-end TVS system based on the nMCI Interact 500 network implements processes that allow customers to monitor in real time their traffic detail statistics in the network, through TCP / IP connections 293 and 294. As shown, the client requests are captured by the client 100 via a RTM user graphical interface and preferably communicated by a secure TCP / IP connection socket for the entry on a protection wall 25 to at least one secure server, for example a DMZ RTM network server 52 (Figure 2) that provides session management, validation and authentication in the manner described herein. In particular, the user first establishes communication with the RTM network server 52 (Figure 2), Dispatcher and StarOE systems to allow the greeting, authentication and verification of traffic monitor rights in real time, as described above with respect to Figures 4-6. If the customer subscribes to the real-time monitor, a traffic monitor icon 85 (Figure 5 (a)) will automatically be enabled when the main page appears. The flow of process 700 to implement real-time monitoring of a customer's network traffic is shown in Figures 23 (a) - 23 (b). Preferably, as shown in Figure 23 (a), in response to selecting the RTM function in step 721, an instantaneous link connection is made to the TVS CGI / HTML implementation of the RTM to initiate a security / authentication process for RTM data products without price for which the customer is provisioned. With more particularity, the user • connects to the RTM URL and confirms that the RTM network server is 5 implementing a post HTTP method. In response, the RTM network server generates a cookie and implements the common gateway interface protocol of the RTM network server ("CGI") to send a validation request to the TVS via TCP / IP with the cookie. The TVS 550 server validates the request for salutation by referencing the service level tables (not shown) provided in the traffic view server confirming that the client is enabled in RTM, as indicated in step 729. The TVS server stores the user information with the cookie and returns the validation information to the network server. Then, through CGI, an HTML page is sent to the user as indicated in step 731 presenting the user with the RTM screen and the menu options, as indicated in step 735, thus allowing the client to access all the RTM functionality to which the user has the right As we will explain, this functionality includes interaction with the RTM application to formulate and transmit requests and receive the results. For example, the user can select the toll-free numbers that will be controlled, capture a scrutiny period and define the desired statistics in the detail of the call.

Particularly, the selection of the traffic monitor icon allows displaying the page of the profile list of the traffic monitor 760, shown in Figure 23 (c), the • which presents a list of the profiles defined by the user 762 for which 763 real-time monitoring functions can be invoked. Particularly, from the 760 network page, a user can activate a real-time monitoring function by selecting and activating the button 766, or delete an existing RTM profile by selecting the button 768. Additionally, a user can create a new profile • RTM for a new toll-free number, by selecting a 769 profile addition button. By selecting the 769 profile addition button, a new 770 dialog window is presented, such as the window example shown in Figure 23 (d), which may allow the customer to capture desired RTM profile parameters for a selected free call number (within limit) 775b including: a profile name 772, a time zone 774, and, a counting interval 776, which specifies the interval of time in which the statistical data are to be collected by the GSE and which, in the preferred embodiment, can be brought to an interval of one (1) minute. In particular, a client can be presented with a list of available numbers 775a from which a number can be selected for the generation of the profile.

It should be clear that a profile selected from the profile list page 760 (Figure 23 (c)) can be edited under the selection of a 766 profile edit button. • client will be presented with a profile edit page 5 which is similar to the profile addition page 770 (Figure 23 (d)). Thus, from the dialog shown in Figure 23 (d), the profile parameters of an existing RTM profile can be modified for a particular number. Referring again to Figure 23 (c), in the 764 activation button selection for a profile • selected, a 780 active profile network page will appear or will be displayed, such. like the one shown in Figure 23 (e), which presents the summarized information in real time for the selected free call number / profile. How I know shows in Figure 23 (e), the active profile network page 780 is divided into three sections: a first section 782 that shows summary data of the profile for the selected free call number, including call attempts, complete calls, incomplete calls, blocked, NCR, duration average and total duration; a second section 784 showing a split summary of the incomplete calls for the selected profile, including the busy ATBs (all busy trunks), short calls, calls that did not wait, calls that did not answer; and, a third section 786 where it shows other summary data not presented in the first two selections such as network congestion, identification codes, blocked pay phones, etc. It is in this window where the client can see information in real time pertinent to the use of the network of the free calls, and make informed business decisions regarding the plans of the call routing. As shown later in Figure 23 (e), the customer can select a start time button 785 allowing the selection of a specific time for which traffic statistics will be collected in real time for presentation to the customer. Thus, with the selection of start time button 785, a start time definition network page 790 will appear, such as the one shown in Figure 23 (f), which allows the specification of a start date to from a vertical menu 792, and the specification of a start time from a vertical menu 794. Also, as shown later in Figure 23 (e), the customer can select a counting interval by specifying the interval of time in which the summary data displayed on the active profile's network page can be updated. Thus, with the selection of the start time button 787, a scrolling definition interval page 795 will appear, such as the one shown in Figure 23 (g), allowing the selection of a scrutiny interval, example, in minutes, from the vertical menu 796, in which the information of the statistical traffic on the network in real time of the active profile page 780 will be displayed in a refreshed form (Figure 23 (e)). Furthermore, as shown in the display of the active profile page of Figure 23 (e), the client can select a query button 789 allowing the appearance of RTM call layout parameters selected for the currently selected RTM profile. Thus, with the selection of the query button 789, a query request page 797 will appear, such as the one shown in Figure 23 (h), allowing the subsequent selection of query / and / or modification of the RTM parameters for the profile Selected 762 including: the telephone number within limits, the start date, the end date, the limit of the report size, the time zone, the start time and the end time. Additionally, you can ask for the subsequent call layout parameters 778 to appear on the active profile page of Figure 23 (e) including: answered calls, blocked supp code, blocked switch control, number dialed failure, unanswered ringing, blocked out of band, blocked network, range privilege failure, unexpected call, (network control system) NCS rejected, busy, blocked pay phone, unanswered, NCS blocked, and all trunks busy .

Particularly, with the selection of the displayed button 777 of display 797, a page of query results 798 will appear, such as the one shown in Figure 23 (i), which shows the basic statistical information of the detail of the call in real time in a 799 display line format for the selected RTM profile. As shown later in Figure 23 (i), the customer can select a CDR 791 detail link to invoke a display showing details of the detail record of a specific call, such as the example shown 793 in Figure 23 ( j). In addition, the customer can select detail links for enhanced voice services (EVS) 795 to invoke a display displaying the selected EVS details (not shown). Thus, referring again to Figure 23 (b), the customer can select or modify his predefined RTM usage profile, as indicated in step 740 of Figure 23 (a).

Specifically, the customer can create or edit their user profile, for example, capturing selection criteria such as: 800 / 8xx or Vnet number to report, a scrutiny interval, and time zones. The user can also delete a user profile. The selection criteria captured can be recorded by the subscriber as a new user profile for storage in the TVS server usage level tables, as indicated in steps 744 and 745, or presented directly to the TVS server, as indicated by the steps 749 and 750. It should be clear that all TVS RTM functionality may be available to the customer. If in step 740, the subscriber has selected a previously defined usage profile, as indicated in step 747, the subscriber can modify the profile, that is, 800 / 8xx or VNET number to report, scrutiny interval, and define statistics , as indicated in step 748, and present it directly to the TVS server, as indicated by steps 749 and 750 of Figure 23 (b). At this point, the user can interact with the RTM application to formulate a request, transmit it and receive the results according to the free call numbers selected by the user to be considered, the scrutiny period and the desired defined statistics. Briefly, after receiving the request, in step 752 of Figure 23 (b), the TVS formulates a query and presents the query to the detail database of the call, which is the repository of all the records of the call. call detail for the selected number in particular. The TVS server selects the detail data of the call according to the user profile or the selection of step 754, and passes the data to the RTM network server which accommodates the data in an HTML table, as indicated in step 756. This HTML table is sent to the user's pagmator in step 758 and the process continues in step 759 for each successive counting interval until the user completes the request. As mentioned, the interactive real-time traffic monitor of the MCI network provides the customer with a real-time summary display of the calls made to their toll-free numbers. This information is displayed on the active profile page 780 as shown in Figure 23 (e), which can be automatically refreshed at a specified scrutiny interval of, for example 1 to 30 10 minutes. This value is selectable by the user with the ^ r creation of the profile. The information on the active profile page is refreshed at this interval by the user's pager (a 'client_pull' operation). This happens automatically because the active profile page contains an HTML meta refresh tag that tells the user's paging software to revisualize the current page after the indicated number of seconds has passed. Figure 24 is an illustration showing the RTM counting process of nMCI interaction. As shown in Figure 24, the RTM system supports an HTML form "Post" or automatic refreshing, to an active server page script. Thus, a network page that provides call detail data with no price in time has an out time interval, such as one minute or more, at which point the network pager 20 will reassign a request for data ( HTTP post). The Post request is received by an internet information server ("IIS") process 590 on the RTM server 52 executing an active script of a • server page (".asp"). This script asp calls a routine of scrutiny of DLL 593 through a communication interface (COM). This scrutiny routine DLL is a Visual C ++ application that runs on the RTM network server 52. Upon receiving the request for time out, the DLL calls the TVS 550 server to obtain details of the real-time call through TCP / IP messaging.

In particular, the request for detail of the call is received through an RTM data recovery process 595 running on the TVS 550 server. Then, the real-time data for each telephone number (eg 800 / 8xx) or VNET) are obtained from the detail database of the call 598, which is the repository of the detail data of the call in real time. The real-time data obtained is returned to the scrutiny process DLL 539 and the w? RTM current output is accommodated by the scrutiny DLL and it is prints to the HTML page. The HTML page with the included hyphenated HTML is again returned to the network pager 20 through an IIS 590 process. In the preferred mode, the RTM 52 server application dynamically adjusts the number of seconds that appear on the meta tag 25 of the summary view page, a feature that allows the user's visualization to be in sync with their selected screening interval regardless of how long the counting operation lasted for the last scrutiny. When the user's pager requires an update, the data recovery software of the RTM network server 52 starts a timer. When the data recovery software has obtained the necessary data to display the next active profile page, it stops the timer. The page is then displayed with the Refresh meta tag that contains a value of the scrutiny interval less than the amount of time, for example, seconds, that the data recovery process took. Finally, the page is sent back to the user's pager. For example, if the current profile has a minute of scrutiny interval and the data recovery process takes 3 seconds, then the next update will start at 1 minute minus 3 seconds, or 57 seconds. During the next update, the data recovery process can take 5 seconds, in which case the next update would start in 55 seconds. Without the dynamic update functionality, if the update rate were to the left in the entire scrutiny interval each time, scrutiny would be traveled forward in time. In sum, a subscriber through a client workstation that runs a network pager can monitor in real time, or in addition, using the RTM system, has the ability to monitor in real time, the operation of the network as soon as to its relation to calls directed to that subscriber's special service call numbers. For example, the subscriber can see in real time how many calls are being attempted minute by minute, how many calls are being allowed through the network, how many calls are incomplete, how many calls are blocked, etc. This ability to monitor the operation of the network provides the subscriber with the ability to decide in real time the specific actions that need to be carried out. For example, if there is an abnormal number of incomplete calls for a given period, the subscriber can see the specific call records that make up those incomplete calls. In the manner described here, the subscriber can then require the network administrator to restructure it in such a way that it modifies the route of subscriber arrival calls to different locations where they can be handled in a better way.

Service Research Another application of all the applications of the telecommunications network is the Service Research application networkMCI Interact ("SI"), which consists of a network-based management product that allows customers to manage, that is, create, rank and display service requests ("tickets problems"), to an MCI service provider. Particularly, through a client application of the graphical user interface, customers have the ability to create and consult problem tickets ("tickets"). Figure 2 illustrates the service research application server "SI" 36 that is connected to the back end host computer system ("CSM") 40 (a). The service investigation application server component 36 includes processes for handling all requests made for service research by the client (as relieved via dispatcher 26). Specifically, the requests are sent to the back end processes of service research and the responses are received from the back end processes investigation of services to be routed again through the dispatcher to the network browser of the workstation of the client 20. Like any of the previously described set of communications network applications, the service research application uses the common object application framework (COF) to interoperate with the backplane of the MCI Interact network and integrate with the others elements of the networkMCI Interact architecture. The common objects framework is used to build up existing infrastructure services such as the • Salutation and authentication, administration of 5 transactions, and security. In particular, the service research application extends the COAppImpl class in order to interoperate with the backplane and other networkMCI Interact applications (as required), and, includes one or more screens derived from the COAppFrame class.

Most of the high-level classes that manage the • Initiation of transactions are used by the service investigation. The COClientSession class is available for the service research application after successful initiation to the networkMCI Interact system and is used to session management (for example, connect, disconnect, and exit). The COTransaction family of classes is used to send and receive messages to the back end service research service. These classes include CONoblockTransaction, COSyncTransaction, and COAsyncTransaction and, a COBulkTransaction can also be used if necessary. Additionally, service research uses all classes of COCommunications with the exception of COBulkTransaction. However, as the development and testing continues, the class can be used COBulkTransaction.

Figure 25 (a) illustrates the high-level design of the 2200 service research application including the 2250 client application and 2300 server application components.

• As shown, service research requires integration with several external systems and uses the structure of common objects for interaplications communications. Connecting to the service research application server 36 via the structure of common objects is the StarOE server, for example, for information of user profile, as well as other specific data of • service research, and, the CSM legacy central computer that provides the ability to query, rank, and take action in service queries. Communication between the service research application server 36 and CSM 40 (a) is via software adapted to the client Registry. Figure 3 shows the COF-based interaplications communication between service research and StarOE. It should be understood that if an external system does not use the COF, the investigation of services may use that set API system and communication mechanism for communication interaplicaciones. The aforementioned Registry system has several options of communication interaplications, including the Java and CORBA interfaces. The application server packages and service research communications provide the framework for transporting messages from clients to the middle-level application server for invocation of domain objects. The domain objects encapsulate the logic to translate the actual client messages and supply the request to the back end services. The response of the back end service is received by the application server and returned to the originating client. The framework is designed to allow the user to develop business logic independent of the transport layer underlying and denies the need to modify the transport flp layer whenever a new domain model is introduced into the framework. The separation of the framework of the domain is carried out through the use of reflection by dynamically loading and executing the business logic in the server of applications as soon as the client's request specification is received. As described herein, the service research application server 2300 is connected to £ the back end of legacy 40 (a), CSM through the object Requester 2310 and Receiver 2350 object as shown in Figure 15 (b). In particular, the SvcInqCSMRequester 2310 object is the class representing the requestor that takes the request data that comes from the front end / client application through the transaction manager 2320, build the CSM request transactions by interacting with the 2380 translator classes and send the requests to CSM. The requested data coming from front end / client is an array of strings that are required from the ^ client for the request that is going to be made. Minimal pass client information to reduce the communication load of the client to the server of service research applications. All other information is packed into the solicitor. In particular, requestor object 2310 uses the classes SvcInqRegistryHeader and SvcInqSIHeader in the 2380 translator to build the "registration header" and the ßm "Registry header" and "service research header" strings that are required for CSM request transactions. He also speaks to the classes SvcInqActivity or the SvcInqRemarks to build the portion of data of the CSM application. Regarding the transaction chain CSM is formatted, the actual request to CSM is made. When sending the transaction to the standard CSM interface (SI) via the classes Registry does this. The receiving object is an instance of class 20 SIRegistryHandler whose responsibility is to obtain the CSM responses, analyze the response syntactically, unstick the headers and construct objects from the response data, interacting with the 2380 translator classes. Particularly, it uses the SycInqRemark class, 25 SycInqActivity, SycInqTroubleTicket or SycInqRegistryEntry in the translator to build the observation, activity, detail or list of ticket objects from the response string that is received from CSM. The constructed object is sent again to the 2380 transaction manager that • 5 passes back to the front end / client. Figure 25 (b) illustrates a flow diagram representing the execution of a transaction by the service investigation application server 36 each bubble representing a separate string. First, in step 2501, the Service Investigation Application Server 36 urges and initiates Transaction Manager 2500 on a string • separated in step 2502. The Services Research Application server 36 urges and starts the Registration Server on a separate string in step 1503. 15 More particularly, as shown in the Figure 7 (a), the Transaction Server receives a client transaction request, as shown in step 1504. The connection is accepted and the Handler's cord is removed.

Transactions of the deposit of ropes for execution, as is indicated at 2505. The Transaction Manager unpacks the transaction request in step 1506 and places the request message in the RequestQ of the Transaction Manager. The Transaction Manager 2600 removes the message from its RequestQ in step 1507 and generates an Executor string of Transactions to execute the transaction. Then, in step 2508, the Transaction Executor translates the message and executes the transaction by loading the domain class and invoking the specified method which sends the request to the back end services. As indicated in step 2509, the back end service responds by sending the result of the transaction to the Registry Server which accepts the connection. In step 1510, a Record Manager is removed from the string repository for execution to perform the translation of the received message and place the result in the ResponseQ of the Transaction Manager, as indicated in step 2511. The Transaction Manager recovers the result of the transaction of the ResponseQ in step 2512 and the transaction response is supplied to the client in step 2513. The back end of the main computer legacy 40 (a) "Registry" is the cross-platform communication mechanism that it is used for research of services to send messages and to receive messages from the central CSM computer. Protects applications from network protocols. CSM is provided with a main computer database (not shown) that provides a set of transactions to request CSM information through its standard interface (SI) which uses Registry as the messaging system. The service research application server 2300 is configured to communicate asynchronously with CSM using Registry RQS as the interprocess communication mechanism (IPC). Since CSM only supports I- messaging in one direction, communication between the service research and CSM is asynchronous. When CSM 40 (a) receives a request from the solicitor, it does not send any acknowledgment back to the solicitor. The requester only receives a confirmation from the Registry that the request was sent successfully. When CSM ends process the request, send the response to the receiver. The Registry configuration consists of configuring the Registry client that sends request messages to the CSM from the service research requester and the Registry server that receives responses from the CSM and passes them to the service research recipient. As shown in Figure 25 (b) the Registry queuing system, RQS is an asynchronous mode of interprocess communication where there is a queue on the client and one on the server and there is only one TCP / IP connection always open between the client and the server. • 20 The client places its request in its own local queue 2322 and is sent to the queue on the server. The server takes the request from the queue, processes the request and the response messages are put in the queue of the client 2325. Since there is only one TCP / IP connection at any given moment between the client and the server this mode is very efficient in terms of both the network and system resources. As in the other data management suite application, the service research client application is written as a Java application to be executed by the client's network browser running, for example, Microsoft Internet Explorer 4.0. The service research client can start from the homepage after the selection of the service research icon 91 shown on the home page 70 (a) of Figure 5 (a). 10 Figure 25 (c) illustrates an example of the screen • 2400 service research main submitted after entry into the service research system selection. As shown in Figure 25 (c), the 2400 service research deployment features a bar title, a menu bar, a toolbar, work area, and message window to provide the user with alternative ways of handling different components of the service research product. It should be understood that • any action available from the toolbar will also be available within the menu bar. Preferably, there are two levels of permission that the user can have: 1) a Vista permission that allows a user to see the desktop of the service research application (default query), define service research queries, see details, observations and activities, print, and report; and, 2) a permission to edit that allows a user to create tickets problems, refer tickets problems, close tickets problems, ? add observations to tickets problems, and update tickets problems More specifically, the 2410 menu bar includes the following elements that correspond to the associated functionality: a 2410a file option that includes selections to create a new ticket or a new query, open a existing query, save a query that is being edited, -fl print and exit service research service, - an edit option 2410b that includes selections to consult a specific ticket number, close a currently selected ticket, or reference back to a currently selected ticket; an option to view 2410c that includes selections to show details of a currently selected ticket, and refresh current query results; a 2410d tool option that includes selections to classify tickets in the active window, - and, an option to help. The 2450 toolbar provides a create button 2451 to create a new ticket, a 2452 query button to generate a new query, and, a 2453 find ticket that allows queries on a specific ticket number. The query component of the service research application allows service research users to query problem ticket information within the system, ie the list or display of tickets based on, for example, different selection criteria. This component also allows users to have the ability to add observations to the tickets. A default query functionality is provided that allows users to maintain a dedicated query available at all times. This query allows users to monitor the subset of tickets that are most interesting to them. A refresh mechanism is additionally provided so that the user can maintain as current a status of these tickets as necessary. The default query can be executed and deployed immediately at the beginning of the service research application and is available throughout the service research session. Preferably, the service research application includes a set of predefined queries, one of which is previously set as the default query and which can be redefined at any time. The user can set his query by default of a saved query. To create a new query, for example, after the selection of the "query" button 2452 of the 2450 toolbar, a "criteria" window is displayed as in the display of the exemplary window 2460 shown in Figure 25 ( d) which allows the client to select among the following criteria that will be used in the query: priority, status, identifier, open date, and ticket number. As the criterion is selected from the "CRITERIA" label 2462, new labels (not shown) appear that are associated with the selected criteria. It is from these labels that the actual parameters against which the query is executed are specified. As the query is constructed, the parameters that are selected will populate table 2464 to the right of the labeled panel. At any point in this selection process, the user can do the following: move back and forth to any criterion label by selecting the "back" and "next" buttons 2461a, 2461b respectively, or directly select the desired label, - add or remove criteria labels by selecting or deselecting the associated check box of the "CRITERIA" label 2462; execute the query by selecting the "execute" button 2461c, • save the query by selecting the "save as" button 2461d; remove parameters highlighted in the table by selecting the "remove" button 2461e, - or remove all the parameters in the table by selecting the "remove all" button 246lf. As an example, a "list by status request" transaction will provide all tickets with a given organization code (ORG) with the status requested and created after a specific date. The ORG code that will be passed in this transaction is one of the selection criteria that represent the originating organization or organization where the ticket was created. The customer can choose from an ORG list that the client has authority over and a primary ORG is obtained from every client and stored locally in the user profile. The information resulting from all tickets will be stored in immediate memory for future processing. Generally, only one type of status can be specified in a single request: status open, closed, referred or canceled. If a client has authority over more than one organization that the client is able to see tickets of any organization has authority. If a client has access to a primary organization, then it has involved access to all subordinate organizations which means that the request will also apply to subordinate organizations. In addition this transaction can only display some of the details / fields of the tickets which means that the data stored in the immediate memory of this request can only be used to process queries about the tickets. They can not be used to see all the details of the tickets for which other CSM transactions will have to be made as will be described later in this. As soon as the query is specified and executed, the "query results" window as provided ^ P in the example window 2470 of Figure 16 (e) is displayed to present the results of the query in table 2472. Preferably, these results can be classified by column either by clicking on the column in the table to classify it or by selecting "tools / classification" from the 2410 menu bar. "tools / "classification of the menu bar will start the display of p a" classification "window such as the exemplary deployment 2475 shown in Figure 25 (f) that is capable of a classification of three levels per column in the table. The columns in the table can also be reordered by dragging them and lowering them to their desired places. The details of a particular ticket can also be seen. The ability to save and retrieve queries allows a user to persist in queries not only for the ^ current session but for future sessions too. This gives the user the ability to define a query once, then save it so that there will be no need to define it again, that is, all the user needs to do is recover and execute it. To save a query, the user must first create the query and select the "save" button as "allowing the display of a" save as "window such as the example window 2480 shown in Figure 25 (g) This window allows the user to select from the list of existing saved queries or enter a new name in the entry field 2480. If an existing saved query is selected this query will be copied over and its name will refer to the new query A check box 2482 is available to designate this new query as the default query. saved query, for example, after selecting the "file / open / query" menu bar 2410, a window "open query" as the example window 2485 shown in Figure 25 (h) is displayed that provides A list of all the saved queries As soon as the desired query is selected, the user can do the following: execute the query, that is, execute the query and display the results in the window of "query results" or the "default query" window if the user selects it as the default query, - or, edit the query by placing the "criteria" window 2460 (Figure 25 (d)) with the appropriate parameters already in the table. The client can then see the results of a query, that is, the details, observations and activities of a ticket selected from the ticket list. To see the details of a ticket, the user can either select it from the results of the query and select "view / detail" from the menu bar or double-click on the ticket in the query results. In particular, a "display ticket transaction" (transaction CSM / SI) can be used to obtain the details, activities and observations of a ticket. This transaction allows several requests to be deployed, for example, by setting the corresponding flags in "Yes". Whenever the client wants to see details, observations or activities of a particular ticket, this request will be made with the three fixed flags and the ticket number placed in the service research heading which will generate three or more answers. The "display detailed response transaction" is a response that returns all data elements corresponding to a given ticket in a "detail" window such as the exemplary window 2490 shown in Figure 25 (i). This 2490 window provides information about the selected ticket that includes: ticket number, ticket priority, ticket status, ticket identifier, ticket product, ticket service, date presented, problem description, and organization (ORG). It should be understood that the number of data elements may be different for different types of tickets. Alternatively, to find a ticket, for example, after selecting the "find" button 2453 from the 2450 toolbar, the transaction CSM / SI, "display ticket request transaction" is invoked, where the number of ticket in the application to handle it as described above. It should be understood that, in the preferred modality, a "change in ticket application transaction "allowing the customer to change some of the fields of the ticket he has already created." This restriction is reinforced by the graphical user interface since this CSM / SI transaction does not impose any of these conditions on the field that is is modifying 10 Observations and comments added to a flp ticket for historical purposes and can help in the resolution of the problem A client of the details of a particular ticket that include the desired observations The "display the observations response transaction" is an answer that shows all the comments added to the ticket either by the client or by the company The CSM legacy system supports "public" and "private" observation types, thus starting from the "detail" window "2490 shown in Figure 25 (i), the user can press the button • 20"observations" 2491 that will carry the "observations" window such as the example window 2495 shown in Figure 25 (j). From the observations window, the observations of that ticket are displayed. It should be understood that the observations will be added to the ticket for historical purposes, for example, to help in the resolution of the problem.

From the window of "observations" the client can click on the button "add observations" 2496 that allows the display of the "add observations" window (not shown) B that allows the client to add observations to that ticket. 5 In this way, by implementing "a request transaction add observations", the customer can add observations on a ticket that is in an open status at any time. This can be used as a final step, just after creating a ticket, for example, to allow the client to describe the problem in their own words or add any • commentary. This transaction returns a success or failure response. The activities are events that are presented in a ticket throughout its life cycle. These events include change status, change priority, and reassignment of the person who works the ticket. The customer can see the details of the particular ticket that contains the desired activities. The "activity display response transaction" is a response that provides all activities, that is, actions that have been taken on the ticket. Specifically, from the "details" window 2490 (Figure 25 (i)), the client can press the "activities" button 2492 which brings the "activities" window 2498 as shown in the exemplary screen display of Figure 25 (k). Starting of the activities window, the ticket activities are displayed .. This is a useful transaction to verify the status of the ticket, and helps to track a ticket that shows in which organization the ticket currently is. The create component of the service research application provides customers with service research the ability to create a ticket within the system. The first step in creating a problem ticket is to identify the type of problem that is basically the way in which the CSM handles different types of problems and is required for most CSM / SI transactions. To do this the front end of the client asks the customer the type of problem / identifier and then narrows the problem by having the customer choose from a list of product types, types of services and problem descriptions as described herein with respect to to Figure 25 (1). Based on these selections the system maps to the correct type to which the mapping is done using the database tables stored locally in the client. As soon as the type is determined, the data ranges corresponding to that type are obtained from the database tables. The information required for all these fields is gathered from the client by presenting appropriate questions. As soon as all the required information is available, the system performs an "open ticket request transaction" and passes all data fields. The CSM legacy system then attempts to open a problem ticket based on past data, and performs a "ticket opening response transaction" to indicate whether the ticket was successfully created along with the ticket number. Based on this response, a confirmation message is displayed along with the 5 customer ticket number. As an example, create an auxiliary job service request, the customer can select, for example, the "create" button 2451 from the 2450 toolbar in Figure 25 (c). This will start the display of a window "create" such as the example window 2500 shown in the ^ Figure 25 (1). From this window, the client provides answers to the questions on each 2510 label shown as questions 2512, and presses the "next" button 2514 when it is ready to go to the next set of questions. When the following label appears, the responses of the previous label populate table 2515. The user can navigate via the "back" and "next" buttons or using the labels. In the preferred modality, the questions are dynamic depending É- ^ of previous answers. Thus, if the user returns and changes the answer to a question that depends on subsequent questions, then those questions will be overwritten by the new set of questions. The user is warned that this will happen. As soon as a ticket is opened, reference must be made to "organization facing the client" to initiate the problem resolution process. To do this, the CSM system refers the ticket out to an organization obtained from the user's front and stored in the profile of • user. This is done using a "5 activity input transaction" that allows the customer to enter different activities such as "refer out", "close", "refer in" and "open" on a ticket by passing the appropriate activity code . Finally, the research application of services allows the customer to close the ticket using a • "transaction request to introduce activity" described with respect to the creation of the ticket. When a client wants to close a ticket, the system will make this transaction on behalf of the client by passing the activity code by "close". Yet The client is allowed to close a ticket only if it was created by the organization and the ticket is currently in that organization, that is, it has been referred outside of that organization. Since only the organization that opened the ticket has the authority to close it, as soon as the ticket has been resolved the ticket is referenced out to the customer's organization. If the client is not satisfied with the resolution of the problem, that client can refer the ticket back to the company (MCI). This is also done using the request transaction to enter activity. Again, the system makes this transaction and passes the activity code by "refer back". The creation of problem tickets through service research will now be described in more detail • in view of Figure 25 (). In the preferred embodiment, the service research application implements a domain object model (DOM) 2600 that allows the collection of information regarding a problem with a product offered by a company. The issues that need to be answered to open a ticket vary by product and by type of problem.

In addition to specifying a problem with a particular product, service research provides the user with the functionality to inquire about problem tickets and to view the details of the problem tickets. DOM responsibility is the creation and consultation of tickets problem and carries out its tasks via interaction with the client's presentation layer and interaction with the back end systems. The information that is gathered via the presentation layer is used to construct transactions of ^ W 'back end. The information returned from these back end transactions are formatted in DOM classes, which are sent to the presentation layer. As shown in Figure 25 (m), problem ticket 2610 is the root of the service investigation DOM. The ticket ticket instances contain information from identification that is used by the presentation layer to classify and filter a collection of problem tickets. The problem ticket class is responsible for accepting requests from the presentation layer, send the requests to the back end and scramble results to the presentation layer. In addition to maintaining identification information, a problem ticket also contains references to 2620 question tree and a 2650 record. Specifically, a 2600 question tree is composed of three domain classes: question tree 2620, questions 2630, and record entry 2640 Question trees 2620 are essentially a set of questions for a particular product and type of problem. The question tree is responsible for grouping the questions and navigation between the groups. In addition, a question tree knows and has been completely specified, that is, all of its required questions have been answered. Within a question tree, the group or category is designated by a unique name string. Preferably, the questions are stored in a noise table (not shown). A group name is the key and a question vector is the value for each entry in the noise table. The order of the groups is significant and since the noise tables do not maintain a name, a vector of group names is required. This vector of names is used for some of the navigation behaviors of a question tree.

The 2650 registry is responsible for maintaining collections of objects that represent information retrieved from the CSM via the client interface. The collections of objects represent observations, details and activities in the 5 CSM. Observations and details are also represented by instance vectors of a class of an "Entry Record". The activities are represented by an instance vector of activity class 2660 that is an information keeper that has variable instances that contain information that corresponds to fields in the record • of CSM / SI activity. The Entry Registration class is a class in the Server DOM that includes instances 2640a that are used by query instances 2630 and instances 2640b, c used per registration instances 2650. When used for a question, the EntryAddress 2640 instances represent the possible choices for the answers to the question. As soon as a user selects a "choice" Registration Entry, (This EntryInstance instance becomes the response to the question. When used by a record, the EntryInstance instances 2640b, c represent observations or detailed information respectively, which is retrieved from the CSM / SI. Specifically, EntryIndex 2640a, b, c comprises the following instance variables: 1) a variable of instance of text that is an optional variable used to specify text that will be presented to the user as a choice for a response to a question if the value is different from that specified by the registry value, - 2) variable variable registry key that maps to a key in the CSM; 3) a variable variable register instance which maps to the value in the CSM specified by the key in the key record; 4) a following instance variable GroupID which is an optional field used by the question to help the TreeQuestion in some navigation task, - and 5) a question instance variable is a reference to the question instance to which the question belongs. Registration Entry. An Entry Record is included by this question, - this instance variable is a later marker. Registration classes, that is, classes that represent CSM / SI records, have two additional responsibilities that are variations of a single behavior. The registration classes (EntryRegistration and Activity) are used for communication between service research and the CSM / SI. The CSM / SI requires information of observations, detail and activity in fixed length field record format, - the service investigation requires observation information, detail and activity in Java object format (entry or activity registration instances). To provide these two formats, the record classes include behavior to convert the fixed-length field record format into instances to be instantiated to the fixed-length field record format. Questions are the main component in a field ^ m questions. A question has a vector of identifiers of groups that indicate the groups to which they belong. A question has a vector of EntryInstance 2640a instances called options. When the user "answers" the question, the answer is established in the selected option; that is, the selected Entrance Register. The short answer or text responses to the questions are a specialization of this behavior. Within each group of questions, there is a question that is designated as the decision point that is used to determine the next set of questions that need to be presented to the user. As an entry record can contain a followingGrupoID, the followingGrupoID of the selected InputRegion instance as a response to the question of the decision point is used to derive the following group of questions. Occasionally, the only difference between two groups of questions is the inclusion or exclusion of a • 20 particular question. One solution is to create two identical groups, one with the optional question and the other without it and survey the mechanism of the decision point. In the preferred mode, an optional parent-child relationship between questions is created. The inclusion / exclusion of a question (child) in a The group is based on the answer to a previous question (father).

A child question maintains a reference to one of the possible choices (EntryRequest) of the parent question. If the answer of the parent question is the same as the parent answer of the child question, the child question is included in the group, - otherwise, it is excluded from the group.

TFNM As mentioned above, another application of the set of management applications of a telecommunications network is the free call network administration tool (800 shown in Figure 26. Referred here as "TFNM", the administration tool for 200 free calling network provides the client with a GUI and middle level service that allows the customer to require, specify, receive and view information pertinent to their free call network management assets, for example, free call number routing plans , and generate orders to modify aspects of the routing plans through a global network interface, In particular, client directives are captured by user 100 through a graphical user interface TFNM.These directives will preferably be communicated as Java applets. on a secure TCP / IP connection for entry into the 25th protection wall to at least one server secure network 24, for example a DMZ network server that provides authentication, validation and session management in the manner described herein. As seen in Figure 26, as will be described, the TFNM 800 tool implements a TFNM 840 domain server which is a component part of the back end MCI infrastructure which comprises: The MCI 240 NetCap system, an administrator service control 290a ("SCM"), and data access points 290b ("DAP"). Particularly, the NetCap 290 order entry system processes (ie, edits, validates, registers) orders 10 with call routing characteristics for the client's ^ 800 / 8xx traffic and submits orders to the service control manager (" SCM ") which then shapes and distributes orders to each of the three redundant data access points (" DAPS "), which implements the orders of the 15 plan in the network switches. Once the order is implemented in the DAPS, calls to the customer's 800 / 8xx number are processed with the characteristics specified in the order. The TFNM 840 server makes an E? interface with the "NetCap" 290 main system, which provides the user interface with the network control system, that is, DAP switches 290b. The TFNM 840 domain server includes object classes in Java whose methods are invoked by Java applets that run in the client's pager. The Java applets of pager 25 specifically execute the client directives by invoking certain methods on the TFNM 840 domain server. These Java objects additionally provide the interface functions with the NetCap 240. The preferred mode, the • Java objects on the TFNM domain server work as a representative 5, and are invoked remotely by implementing a remote Java method invocation "RMI" - like the methodology. Particularly, as described herein with respect to Figure 3, with the interactive MCI network framework for producing Java applications on the Internet, there are common objects and an infrastructure that allows secure communications between a client (residing in a pager) and a server (which resides securely in the MCI protection walls). As mentioned briefly, security strategies include: encrypted communication in cryptic language 15 from the client to the network server via SSL (HTTPS) and implementation of HTTPS as the preferred method to allow communication to the network server from the Internet; providing an additional protection wall between • the network server and the dispatcher to allow only specific traffic from the network server to the dispatcher to occur; - encrypted language traffic between the network server and the dispatcher through encryption in DSA cryptic language; and allow the dispatcher to validate all packets destined to the internal MCI servers to ensure that these are from an authenticated client and that a particular client has permission to communicate with a specific end-back server. To do this more seamlessly for the client, the aforementioned set of • Common objects carry out this messaging. In the modality Preferred, the invention implements a modified RMI which is referred to as "CORMI" (RMI Common Objects) which provides an RMI-like interface between the client and the server using the interaction protocol of the MCI network. The implemented CORMI procedures have additional controls included to provide the necessary session security • and the maintenance of communication on the protection walls. More specifically, CORMI is the nMCI interaction protocol to provide security, communication client to server with Java semantics similar to RMI and comprises a library of Java classes used by both the client applet and the server application. In the Figure 26, you can see how is the communication path of the • client and server: 20 The TFNM 840 server application registers the remote objects with the CORMIoteSessionServer of the CORMI (analogous to the RMI registration service in Java) and then the blocks that are waiting for connection. The TFNM client applet initiates the communication by performing a greeting through an object COClientSession. The COClientSession creates a COSynchTransaction (an atomic unit of work based on the HTTPS pool) which connects to the dispatcher server of the MCI 835 interaction system (which is located behind the outer protection wall 25 (b)) and which communicates by means of an interface with the StarOE server 39. The dispatcher server 26 validates the client's authorization to achieve the greeting (a process that involves contacting the StarOE service and generating a key session with a cookie jar process). After validating the client, the dispatcher uses a request protocol to select a TFNM server and then opens an HTTPS connection to an instance of the TFNM server application. On this server, the CORemoteSessionServer creates a new session for this client and records the key session. A replication of a greeting is sent back through the dispatcher server 235 to the client 20. The client can then perform a search that results in a serial remote interface of the remote object previously registered and being sent back to the client. The client can then use this remote interface as it would with the RMI Java remote method invocations. Remote method invocations are handled by CORMI with COSynchTransactions through the dispatcher to the same instance of the TFNM server where the salutation and interface search took place.

It should be clear that there is no permanent connection between the TFNM client and the server, - CORMI, through a COSynchTransaction, creates a new HTTPS connection to the dispatcher (and the dispatcher creates a connection to the TFNM server) for each communication unit. After the greeting described above, and the authentication and rights processes, the user is presented with an initial nMCI interaction page (Figure 5 (a)) in which the user can select the network administrator icon 89 to enter to the TFNM system. With the selection of the network administrator icon, a TFNM client application is loaded to the client presented with the display of the TFNM 1640 network page, such as that shown in Figures 27 (a) - 27 (c). As shown, this display of the TFNM network page presents a variety of TFNM file menu options that include: 1) a 1645 option that allows the user to select a corporation identifier, that is, a corporation, set, number and plan to establish a work environment, - 2) an option 1646 that allows the user to cut through a main NetCap 3270 application; 3) an option 1647 that allows the user to implement a plan, that is, put a plan in use creating an IMPL order; and 4) an option 1648 that allows the user to modify the termination information on a plan by creating a QUIK order. As shown later in Figure 27 (b), the open menu includes a Plan 1642 option that allows the user to select from a list of plans in the current work environment and allows the opening of a plan in graphic mode in a VORT ("View-only routing tree"), as • 5 will be explained; and a Tree View 1643 option that shows the last plan accessed on the VORT screen. As shown later in Figure 27 (c), the report menu includes an option 1644 that allows the user to define and execute an order filter query that results in the display of a list of orders, as will be described hereafter in &m more detail. Thus, the client is allowed to select a view of their routing plans according to user privileges. To determine privileges, it is required TFNM user security profile information from StarOE, which comprises a list of corporation identifiers and access identifier combinations, referred to herein as "RACF ID" combinations to which the ^ Client has access within TFNM. In particular, the elements of the user's security profile obtained from the StarOE include: Corp Id, that is, the identifier of the corporation to which the client user has access within StarOE; Defaultlnd, this is., A default indicator that has for example 'Y' or 'N' values. Once the client has entered the TFNM and has received the StarOE security message, a communication is made from the TFNM 840 server to the NetCap 290 requiring a user security profile. In particular, the message system implemented for all communications between the TFNM server and the NetCap will be called here as "Registration". The security of NetCap is through Racf Id and Corp Id. For each Corp Id, to which a user has access, that user must have a Racf Id, If the user has security at company level, then the list of corporations lowers those companies within of NetCap have the same security as the company. Particularly, in response to a user greeting, in the preferred embodiment, an application of the TFNM server is executed. From this application, the TFNM server instantiates a Java profile management object, which is registered with CORMI and is called to invoke subsequent objects related to the following: user profile, for example, preferences, user security profiles, this is to keep track of client rights / privileges that include rights to create or modify specific TFNM routing plans or to generate QUIK or IMPL commands; and, session management, that is, objects that encapsulate the state and behavior associated with a specific user's greeting, for example, the elapsed time of connection. In the preferred mode, once the profile administrator is instantiated, the TFNM server additionally instantiates related objects to view screens and options according to the rights / privileges of the user.

• Specifically, an administrator object is invoked corporation ("CorpMngr") to allow the user to select the corporation that has the desired routing plan on which it will be searched. Then, the following objects are invoked sequentially: An administrator definition object for the selected corporation; an object number manager who knows the TFNM numbers (for example, l-800 / 8xx) that belong to the set and / or corporation; and, a plan administrator object, which knows the routing plans that belong to the selected corporation, set and / or number selected by the user up to that point. It should be clear that the TFNM server is enabled to communicate with the NetCap server to obtain this information if it is not provided by the TFNM database, or, if the information in TFNM is not up to date.

• For example, for some messages, it can always be invoked a data synchronizer. Thus, the TFNM can contact the NetCap and pass the date and time indicating the last update for that record. If NetCap determines that they have previous versions of data, it will pass the updated version, otherwise it will send an empty message of return to the TFNM. Alternatively, an internal table 845 can be accessed, as shown in Figure 26, indicating the intervals for updating the data records, which will indicate the last time a data synchronization was performed for a registration in particular. By checking this table, a determination can be made as to whether NetCap should be contacted to perform a data update. In the preferred embodiment, as shown in Figure 26, the TFNM server 840 communicates a plan / data synchronization message 843 via a registration message to the NetCap. The call of the registration message "NPSNC" is the request to synchronize a plan and it is transmitted from the TFNM server to NetCap. There are a variety of registration response messages for this request. As shown in Figure 27 (d), the menu option File / Select Corp ID, causes a 1650 screen to appear on the network page which allows the user to select items (Corporation identifiers, set identifiers, routing numbers) that invoke objects to establish a work environment, or, select a plan for viewing. The data items displayed on this screen differ according to the type of plan selected. In the preferred mode, the TFNM 800 network management component allows the client to create or modify orders for four types of TFNM routing plans: A number level plan ("NLP"), Super routing plans ("SRP") , enhanced voice service routing plans ("EVS") and universal routing plans ("URP"). As shown in Figure 27 (d), the radio fll buttons number level, EVS, or super routing plan 5 1655 can be selected to access the corresponding visible screen elements. For example, when selecting an NLP plan, the following elements will appear: a 1656 corporation identification element, which is a simple selection list box that is filled with the identifications of corporations available to the user of tPP according to the rights of said user, - a set identifier element 1657 which is a simple selection list box containing the set identifiers to which the user has security access for the selected corporation identifiers; a box item of list of numbers 1658 which is a simple selection list box containing information of numbers for the corporation / set indicated, - and, a list box of plans l ^ 1659 which is a list box of simple selection that contains plan information such as: a description of the plan, the plan in use, or when the plan was last modified, for the selected number. It should be clear that the security of the corporation is obtained from the NetCap when a new corporate identifier is selected, in the manner described.

In the preferred embodiment, using the additional buttons 1652, 1653 and 1654 of the screen shown in Figure 27 (d), the user may, respectively, open or close flb the "plan" portion of the screen, - record the identifier of the screen. corporation / set / number / plan selected as the user's current work environment, - and / or display a tree view of the highlighted plan. When the user selects to see a selected routing plan, and after verifying security with both 10 StarOE and NetCap, the TFNM server can execute the synchronization process with NetCap 290 as described below. During this process, TFNM updates any record in the TFNM server copy of the routing plan selected by the client with modifications that were made in NetCap 15 since the user last accessed the system. The TFNM server database is updated with the latest routing plan information for that client, and the updated routing plan information is sent to the user, as indicated in step 333. The customer is now presented • 20 the view of the routing plan required through the TFNM client application. A user can see a routing plan in various formats, for example a hierarchical tree graphic or a spreadsheet. In the preferred mode, as shown in the example screen display 1660 of Figure 27 (e), the routing plan appears as a tree structure comprising a series of node types linked in a specific hierarchy. As shown in Figure 27 (e), the • screen is divided into two main sections: a first section 1662 comprising the graphical representation of the routing tree having nodes and tree branches that can be expanded and collapsed, - and, a second section 1663 to show the detail of the node of the tree currently highlighted. The node types that are available include: a) a node plan 1666a which is highlighted in Figure 27 (e) and • details the characteristics for the plan; 2) a source node ("ORIG") 1666b that details the geographical elements used in determining where to route the call. There may be multiple source nodes under a plan node, - 3) a node of day of the week ("DOW") 1666c which details how to route calls based on the day of the week. There may be multiple nodes of the day of the week under one origin and all seven days of the week must be counted for each origin, - 4) • a node of time of day ("TOD") 1666d which details the specific hour ranges to route calls. There may be multiple nodes of time of day under a day of the week and all 24 hours a day shall be counted under each day of the week, - and, 5) a percentage logical termination node ("% LTERM") 1666e which details where the calls end and at what percentage of the time.

As shown in Figure 27 (e), multiple% LTERM nodes can exist under one hour of the day. The percentages in sibling nodes should add up to 100 percent. The user ^ \ can select details of any node by dialing and traveling. The trigger points (not shown) can also be displayed as children of the node on which they are mounted. For example, a trigger point that is mounted on a source node will be displayed under the origin at the same level as the day of the week node. In each node, they are executed decisions related to the routing of the call. As shown later in Figure 27 (e), for a plan node, the corresponding plan detail screen 1663 will be filled with the description of the existing plan; the originator of the origin by default of the plan, - and the characteristics of the origin that have derived values based on the characteristics of use in the plan. Likewise, for a source node 1666b, the detail screen of the corresponding plan shows: the identifier of the source node highlighted and the corresponding description including cancellation • 20 lists that show the geographical elements (countries, states, area codes and exchanges) associated with the highlighted source node. For the DOW 1666c node, the detail screen of the highlighted source shows the day ID of the NOW node and the list of days associated with the DOW node. For the TOD node 1666d, the screen, the detail screen of the corresponding plan shows the list of time ranges associated with the TOD nodes. For termination node 1666e, the detail screen of the corresponding plan shows: the termination identifier associated with the highlighted node, - • a description of the termination associated with the highlighted node; an indication of whether a corporation cross-period is associated with the highlighted node, and, if the corporation cross-period indicator is "Yes", a field that shows the cross-company identifier associated with the termination in the identification field; and an indication -4p of the percentage of calls hosted to this termination node. Later details may appear that include a detail tag (not shown) to show: the customer service identifier associated with the termination; the date of activation of the termination; The received activation date associated with the termination; the service status associated with the termination, - the identifier of the switch trunk associated with the ^^ termination; and, an indication of whether the termination is EVS; yes the termination has an ANI delivery in real time and, the activation date for the ANI in real time. Additionally, an ANI tag (not shown) may appear to show the user whether the termination has an automatic number identifier ("ANI"), the country code associated with the termination and termination ANI. An "overflow" tag of the termination details screen displays for the user: a network call redirection indicator indicating whether the termination has an NCR; a • direct termination overflow indicator that indicates whether the termination has a DTO. Also, a "DNIS" tag (not shown) may appear to present the user with information on whether the enhanced DNIS / DNIS is active in the termination, - the date on which DNIS was activated; an indication of whether the digit digit button (DDO) is active at the termination, - the prefix digits used for DNIS, and the number of digits • that they will be used for DNIS. Finally, an out-of-limit international tag (not shown) may appear to present the user with information on whether the termination is active outside the international limit; the country code associated with the termination if the out of international limit was active; the carrier code associated with the termination if the out of international limit was active; and the free phone number associated with the termination if the out of limit was active international. Using the TFNM client application, the user can now invoke the TFNM functions as the "IMPLs" shown in Figure 26 as the IMPL 822 request that allows the user to quickly modify the routing plan number to which it is routed a job number or a set of job numbers; or the "QUIK" shown in Figure 26 as the QUIK 824 request that allows the user to quickly add, modify and / or delete one or more termination locations, and / or modify ^ the percentage assignment of two or more of these locations , for a routing plan currently implemented. In accordance with the present invention, additional directives may include: a temporary IMPL ("TEMP") directive that is created in conjunction with an Impl by capturing a recovery date such that the routing plan is reverted to 10 its status of previous use before the creation of the Impl; and a ^ P TEMP QUIK directive that allows to make a recovery of the modifications made by a QUIK order to what they were before the QUIK. For the case when a user wishes to implement the IMPL IMPL / TEMP plan, or the QUIK QUIK / TEMP, the user selects the IMPL definition of the TFNM screen. Specifically, the TFNM client application causes a copy of the instance of an "order management" object which invokes methods capable of accessing all information pertinent to commands • 20 for a given corporation identifier, set, TFNM telephone number and plan. An order comprises two components: a) an order management record that includes data such as: status of the order, effective time of data and order number, etc .; and, 2) administration detail record on which includes the detailed information pertinent to that order, such as, for example, modifications to the percentage allocation or effective dates / times, etc. for a plan, etc. The order management object includes an ImplOrder subclass that knows fl about the IMPL commands, for example, the IMPL functionality, and 5 invokes objects to obtain order records pertinent to the plans. As mentioned, an IMPL command allows the user to modify which routing plan they want to be "in use" for a specific number or set of numbers. Figure 27 (f) illustrates the IMPL dialog screen 1670 that allows the user to generate an IMPL / IMPL TEMP command • for the desired corporation identifier. Particularly, as shown in Figure 27 (f), a dialogue box for selection of number / set 1671 appears that has radio buttons that allow the selection of the desired 800 / 8xx number, a set of numbers, a reserved number, - or, an EVS number to implement an EVS plan. The selection of one of these will invoke a "data controller" object to retrieve information from the TFNM database, causing a dialog to appear É?) Corresponding that allows the user to look for the number 800 / 8xx desired, set, reserved number or EVS number for the desired corporation identifier. After selecting the desired number or set, the user is required to select from a 1672 dialog box the specific type of plan that will be the subject of the IMPL for the number or set.

As shown, the dialogue box 1672 comprises radio buttons that allow the user to select the identifiers of the desired plan, which includes, but is not limited to, the number level plan ("NLP") implemented for a ^ P number 800 / 8xx, or a set of numbers, a super plan of 5 routing (SRP) implemented for an 800 / 8xx number, a set of numbers, or a reserved number; and, an EVS plan implemented for an EVS number. It should be understood that if the user has privileges for only one corporation identifier, the system will select only the plans associated with the corporation identifier for the user. If the user • has privileges for more than one corporation identifier, the user is presented with a list of all corporation identifiers from which he will select one. Any subsequent action that the user performs within of the application will be applicable to that selected corporation. After selecting the corporation, set, routing plan number or routing plan identifier, the user can define or modify the routing plan. In the preferred mode, the user can define the plan of routing according to any of the options described above: Origin, Country, State, NPA, NXX, Day of the Week, Time of Day, and termination. These options can be defined for each corporation, set or number identifier. In the preferred mode, the user is enabled to implement NLPs, SRPs and EVSs and URPs for a selected free call number, or implement NLPs and SRPs for a set of numbers that are desired to be routed differently. Using the IMPL request messaging, the user selects • the desired routing plan for the number / set and the desired date and 5 hours when you want to start routing the number to the selected plan and direct the request to the TFNM server through HTTPS messaging. As shown in Figure 26, the IMPL send request from client 822 is communicated over the connection HTTPS as a request to invoke methods in the order manager class / subclasses through CORMI. Once the plan has been presented to the TFNM server through the IMPL 822 send message, the TFNM server receives the new routing plan and verifies the user's security with NetCap. Once the user's security has been verified, the TFNM server presents the IMPL request to the NetCap 290 through the registration messaging. Particularly, the order manager classes / subclasses ^ p executes methods to translate the IMPL command in a way suitable for submission to NetCap. Included in the log message calls that are transmitted from the TFNM server to the NetCap for the IMPL / TEMP IMPL command and the corresponding NetCap responses, is the message to submit an IMPL command (NIMPL) to NetCap.

It should be understood that, in the case of a user implementing a TEMP IMPL request, the user follows the same procedure as for the IMPL command, for example, selecting the desired routing plan for the number / set 5 and the corporation identifier. However, as shown in Figure 27 (f), the user is presented with a 1673 dialog to submit the desired date and time when the user wishes to begin routing the number to the selected plan, and a 1674 dialogue to submit the Date and Time recovery when you want the previous routing plan to be • cash again. Thus, a couple of messages are sent both IMPL and TEMP IMPL to the TFNM server to be processed as explained here. After the request TEMP IMPL and / or IMPL has been transmitted to NetCap 290, it is recorded for future implementation. By looking at Figure 26, NetCap sends an acknowledgment via the registration messaging back to the TFNM server. • Included in the registration message calls that are transmitted to the TFNM server from the NetCap in response to the IMPL command submitted is the message indicating the successful processing of the IMPL request (NSUCS) and the message indicating the order completion in NetCap (UCOMP). The TFNM server passes this information to the user through the CORMI messaging over the HTTPS connection. If the user is still active, this acknowledgment appears as a sudden message on his screen, as indicated by line 826 of Figure 26. If the user is not active, the TFNM retains the • recognition that the IMPL has been received and saved for 5 the next user's greeting. Likewise, when an IMPL has been transmitted to NetCap and has been implemented or terminated, NetCap sends a log message back to the TFNM server which, in turn, passes this information back to the user via HTTPS connectivity. 10 The user of the TFNM system can, in turn, wish • Execute the QUIK feature that allows customers to quickly add, modify and / or delete one or more termination locations (nodes), and / or modify the percentage assignment of two or more of these locations, for the 15 routing plan Currently implemented, Figure 27 (g) illustrates a screen of the example 1680 network page instantiated by the TFNM client application for the QUIK / TEMP QUIK order process which is presented to the user. As shown in the • Figure 27 (g), a number of radio buttons is provided which the user can select: 1) a number 800 / 8xx 1682 button which causes a dialog to appear that allows the user to capture or select an 800 number / 8xxx from a list of 800 / 8xx numbers (not shown) that have an associated "usage plan". Once the 800 / 8xx number has been captured, 25 the system returns the corresponding plan in use SRP or NLP; 2) a SRP 1684 button that causes a dialog to appear that allows the user to capture or select an SRP identifier from a list (not shown). Once the number is captured, the system returns the SRP Routing Plan for the SRP identifier; 3) an EVS 1686 button which causes a dialog to appear that will allow the user to capture or select an EVS number. Once captured, the system returns a Plan In Use EVS if available. In each dialogue, a corresponding "data controller" object is invoked to obtain information from a TFNM database, which causes a corresponding dialog to appear, allowing the selection of the user. After selecting the desired plan, the user is required to type or select each of the following buttons: Source identifier / Description 1687, Identifier of Day of the week / Desc. 1688, and a Time Start / Desc. 1689. The selection of the Source Identifier / Description button 1687 causes a list of source identifiers and corresponding descriptions to appear. In this way a user can go through the list and identify the branch that includes the endings that are going to be modified. Also, the selection of the button ID of the day of the week / Desc. 1688 causes a list of day of the week node identifiers / descriptions to appear for the selected source identification node and through which the user can browse and select what is necessary to make modifications. Similarly, selecting the Time start button 1689 causes a list of node identifiers of Time of day / descriptions to appear for the * DOW (Day of the Week) selected and through which the user can select what is necessary to make modifications. By using the class / subclass order handler, the system automatically loads the source, the DOW, the TOW and once loaded, the system displays the "Lterms" for the TOD node in the 1692 display field. which includes the assignments of terminations and percentage.

^ In the preferred mode, the user can modify the percentage assignments by overwriting the quantity or by using the up / down arrow box 1690 (with 1 percent increments). The user can additionally modify the percentages for the remaining termination (s) as long as the sum of the percentages for all terminations attached to the selected time slot node equals 100 percent. The action keys 1695a - 1695d can additionally be enabled for the user selection according to the business rules of the company and / or user safety. Specifically, the key 1695a allows the presentation of the QUIK / TEMP QUIK order for NetCap to approve it (send key). The 1695b key allows the user to add a termination to the TOD node (including terms between corporations with which the client has agreements), or modify the identifier of the termination, the description, or the percentage assigned to the termination for this plan. Preferably, selecting the key 1695b allows the display of a page of the network that has a termination screen that allows these selections to be made. The 1695c key allows the user to select the termination that the user wants to replace and presents the termination screen to select the change period (change period key). The 1695d key allows the user to select the time period to be deleted in the selected routing branch. In the preferred mode, the system defaults to the effective date / time on the current date / time, however, the user can select a future recovery date / time of up to 1 year in the 1695a date and time entry fields , b. of Figure 27 (g).

If the user captures a recovery date / time in the date fields, the system generates a QUIK TEMP command that sets the Routing Plan back to its state before the QUIK command. Preferably, the recovery date / time may not be more than 1 year in the future. Thus, from dialog box 1680 (Figure 27 (g)), the user will be able to carry out the following: 1) Modify one or more terminations for NLP or SRP: 2) replace one or more terminations in an EVS Routing Plan; 3) modify the percentage allocation of the NLP, EVS or SRP Plan currently implemented; 4) add one or more terminations to the NLP or SRP plan currently implemented; 5) add one or more terminations to an EVS Routing Plan; and 6) delete one or more terminations of • currently implemented plan of an NLP, EVS or SRP plan. 5 It should be clear that, in the case of a user who implements a TEMP QUIK request, the user selects the desired routing plan for the number / set, the desired date and time when he wishes to add, modify and / or delete one or more termination locations and / or percentage allocation of these locations for a routing plan currently implemented, and, optionally, the date and time of recovery when the changes have to be reverted to their original definitions. Thus, a pair of QUIK and TEMP QUIK messages are sent to the TFNM server to be processed as described here. Referring again to Figure 26, the QUIK sending request of the client 824 is communicated by the TFNM client applet through a communication between the dispatcher server 235 and the objects of the TFNM server using fl CORMI. The administrator / subclass object executes methods for translate the QUIK / TEMP QUIK order into a form suitable for submission to NetCap. Included in the log message calls that are transmitted from the TFNM server to NetCap for the QUIK / TEMP QUIK command and the corresponding NetCap responses, finds the message to present a QUI (NQUIK) command to NetCap. Once the plan has been submitted to the TFNM server through the QUIK sending message, the TFNM server receives the • new routing plan and verify the security of the user with 5 NetCap. Once the user's security has been verified, the TFNM server submits the QUIK request to the NetCap 290 via registration messaging. After a TEMP QUIK and / or QUIK request has been transmitted to NetCap, it is stored for a future implementation. In the view of Figure 26, NetCap • sends a registration message to the TFNM server recognizing that the request has been recorded. Included in the log message calls that are transmitted to the TFNM server from NetCap in response to the Once the QUIK order has been submitted, the message indicating the successful processing of the QUIK request (NSUCS) and the message indicating the completion of the order in NetCap (UCOMP) is found. The TFNM server then passes this information to the user through A of the CORMI messaging over the HTTPS connection. If the user is still connected, this acknowledgment appears as a sudden on-screen message, as indicated by line 826 of Figure 26. If the user is already disconnected, the TFNM retains recognition that the QUIK command has been received and recorded for the next user's greeting.

Also, when a QUIK has been transmitted to NetCap and is implemented or terminated, NetCap sends a registration message back to the TFNM server which, in turn, passes this information back to the user through the ^ HTTPS connectivity. 5 As described, a modification to the routing plan is recorded locally before being submitted to NetCap. Submission occurs when modifications to the plan become an approved order that has an approved order management record and with the condition that 10 NetCap has no orders preceding it queuing against the 4 ^ plan The submission process is carried out in two stages: first, the order management record is sent immediately to NetCap, and second, when there are no pending orders from the plan, the detail record of the order management. The delay results because NetCap does not queue more than one order for one plan at a time. The tTFNM server is configured to hide this limitation by stacking the commands - a process of accepting multiple submissions that are internally queued for their subsequent transmission to NetCap. The order management record is sent immediately. The order management detail record is subsequently sent as soon as possible. Other functionality provided by the TFNM server is the ability to open plans, that is, to display a list of routing plans under the current work environment for viewing as VORT (Figure 27 (e)), or as a view of orders and order filters. In particular, the TFNM client will instantiate the order manager object and other objects to obtain administrative records that comprise the details for a particular order in the TFNM database. For example, selecting the command-list menu option shown in Figure 27 (c) will cause an order filter screen to be displayed that allows the user to capture items that he or she would like to use to query orders and submit order queries . The results of an order inquiry appear in a 1698 order selection list like the one shown in Figure 27 (h). From this list, a user can obtain pertinent details to an order, or, modify the status of an order or update the comments. In particular, of a 1699 administration button, the user works with a dialogue 1700 as shown in Figure 27 (i), for example, 'allowing the user to update the order status and effective date / time. It is from these dialogs that the user can select a 1703 button to disapprove an order (if the selected order has been approved by NetCap) and, a button 1704 to delete an existing order. Log message calls are also transmitted from the TFNM server to NetCap for the disapproval of an order (NOUAP), its removal (NOZAP) and the pending order data request (NPIUO). It should be clear that, according to the principles described herein, the TFNM administration tool of the invention is capable of supporting "characteristic" commands, that is, the functionality allows the client to add a new TFN routing plan, for example, NLP, SRP, URP, or EVS, or modify the attributes or structures of an existing plan, for example, modify the attributes of a routing plan directly from VORT (Figure 24 (b)). The TFNM tool can additionally provide the "drag and drop" feature allowing users to configure routing elements between plans. Although the TFNM network / internet management tool has been described here with respect to a customer's toll-free number, for example, l-800 / 8xx networks, the principles can easily be applied to other types of telecommunication network numbers .

ONM Another application of the set of telecommunication network applications is the NetworkMCI 2700 interactive non-limit network administrator. Referred here as "ONM", the network management tool outside of limit 2700 provides the GUI and mid-level service that allows customers to handle and keep track of call-start number orders, calling card orders, dial plan orders, and key identifier definition commands relating to their private networks such as Vnet networks and View. As shown in Figure 28, the ONM tool 2700 of the invention implements an ONM 2750 domain server integrated with a back end MCI intranet and a legal infrastructure system comprising the MCI NetCap order entry systems described above 290, a service control manager 290a ("SCM") and data access points 290b ("DAP"). The ONM 2750 server allows customers to modify their Vnet / Vision network management plans, both on a real-time and scheduled basis, through a mid-level and front-end infrastructure based on the interactive nMCI network. In particular, the client order directives are captured by the client 20 through a ONM graphical user interface. These directives are preferably communicated as Java applets over secure HTTPS connections 2722, 2724 to be carried from the protection wall 25 (a) to at least one secure server, such as a DMZ network server 24 that provides session management, validation and authentication in the manner described here. After validation and authentication, the DMZ network server 24, in turn, recodes the messages with cryptic language and dispatches them to the dispatcher server 26 over a TCP / IP 2734 connection. The dispatcher server can implement an ONM representative 2735 on the which properly receives the ONM command messages from the • network server, and translates them into an appropriate format for transmission over another TCP / IP 2736 connection to the ONM 2750 domain server. As will be described, the ONM 2750 domain server interfaces with the "NetCap" host system 290 which provides a user interface to the network control system, that is, the DAP switches 290b (Figure 6). The ONM 2750 domain server can • include Java class objects whose methods are invoked by Java applets that run over the client's pager. Java pager applets specifically execute client directives by invoking certain server methods ONM domain 2750. These Java objects additionally provide the interface functions to the NetCap 290. In the preferred embodiment, the Java objects on the ONM domain server function as the ONM representative, and are invoked remotely by implementing an invocation of remote method Java "RMI" - similar to the methodology. Particularly, as described there with respect to Figure 2, within the framework of networkMCI interaction to produce Java applications over the Internet, there are common objects and an infrastructure that allows communications secure between a client (residing in the pager) and a server (which resides safely within the MCI protection walls). As described, the security strategy includes: cryptic language encryption of communication from the client to the network server via SSL (HTTPS) and the implementation of HTTPS as the preferred method to allow communication to the network server from Internet; Provide an additional protection wall between the network server and the dispatcher to allow only specific traffic to occur from the network server to the dispatcher, - Encryption with cryptic traffic language between the network server and the dispatcher through encryption with cryptic DSA; enabling the dispatcher to validate all packages destined for internal MCI servers to ensure that they are from an authenticated client, and that a particular client has permission to communicate with a specific back end server. To make this transparent to the user, the set of common objects carries out this messaging. In the preferred embodiment, a "CORMI" (Common RMI Objects) is implemented which provides an interface similar to RMI between the client and the server using the networkMCI interaction protocol. The implemented CORMI procedures have additional interconstructed controls to provide the necessary session security and maintain communication over the protection walls.

After the client connects, a networkMCI interaction applet consisting of authentication and determination of rights to the clients' network pager is downloaded by establishing TCP / IP connections, and the pager presents the client with an initial page of the networkMCi interaction system that includes a network administration icon 89 (Figure 5 (a)). The selection of this icon allows an ONM application of the client to be downloaded to the client that is currently present on the ONM screen, as indicated in step 318. In Figure 29 (a), an example page display is shown. ONM 2764 network which presents a variety of ONM menu options that include: 1) A menu option File 2702 that provides a 2704 selection to create a new order, a 2706 selection to open an existing order, a 2708 selection to display events , and a 2710 selection to allow 3270 cutting through the Vnet / Vision configuration management system, - 2) an Edit 2715 menu that provides options for deleting an ONM order or, enables a search for specific components, for example, within of a detail of order and inventory windows belonging to a call start number ("CPN"), Calling Card, Dialing Plan, and Key / Set Identifier, such as described, - 3) a control menu 2720 that provides a refresh option that allows the user to obtain a list of all updated lists that have been altered in the host system, including: Network identifiers, range privileges, joint key identifiers, billing location identifiers, customer service identifiers, location / access types and provisioning bearer; and 4) a report menu 2723 that provides options that allow the client to consult about the inventory of CPNs, calling cards, dial plans and Joint Key identifiers. With respect more particularly to the File menu option 2702, when a user selects the new order menu option 2704, a vertical menu (not shown) is presented which presents a section of the order types that can be created by its pager network, for example, CPN, calling cards, Dial Plans and Joint Key identifiers. When the user selects the open order selection 2706 from the vertical menu of Figure 29 (a), the user is presented with a network page 2725 that displays a request request window in which the user can enter search criteria to from which the user can select orders, or choose all orders. As shown in Figure 29 (b), the user can enter the following search criteria: an exact order number or partial order number in the "matching order" field 2730; a type of order, for example, call card, CPN, dial plan, joint key identifier, or all, from a vertical list presented by the vertical menu "order type" 2732; an initial date or a current default date in the "start date" field 2737; a current user identifier or identifier of the "user identifier" field 2739, and a set of order status check boxes 2740 that allow the user to choose an order status, for example, unapproved, approved, complete and error / rejected. When multiple orders are obtained as a result of a search criteria, a network page 2744 will appear that presents a "orders" window as shown in Figure 29 (c). From the order detail window, an order can be selected, for example, by double-clicking a summary line of order 2743. The field descriptions for an order displayed in the order window include: An order number 2745 on the which is a unique number assigned to the order for identification, - a user ID currently connected 2746; the status of the current order 2747, the order type 2748, for example, key identifier, as shown in Figure 29 (c), - the date the order was prepared 2751, and the effective date / time 2752 when the order will be implemented on the network by the host. The details of an order can be obtained by highlighting the summary line of order 2743 and pressing the details button 275453, or by double clicking on the summary line of order 2743. It should be clear that the user can, when obtaining existing orders , obtain a network page having an order window either by selecting a new order from Figure 29 (a) or by selecting the open order window. The selection of a new or an existing CPN order option through the nMCI interaction ONM system allows the client to "link" or attach network features to any call start number (CPN) that exists in the client's inventory, that is, CPNs that are active in that client's database. Preferably, the following characteristics can be defined / linked to the CPNs: 1) Multiple networks; 2) supplement keys including key identifiers and accounting keys; 3) range privileges including universal and customized; 4) data specifications against voice; and extended company type location / Access). Figure 29 (d) illustrates a network page 2755 comprising a CPN order window encompassing the following sections: An order management section 2760 for handling the administrative aspects of the CPN order; a CPN 2770 inventory section used to obtain CPNs from the inventory that are not included in another order. This is carried out by selecting the obtain button 2775 and enables the display of among others, the associated CPNs and PINs, a description assigned to the CPN, and a component counter; an update section of CPNs 480 which fills the CPN order window by moving the selected call cards from the cards of the inventory section or by adding new call cards to the current order; and, an attribute section 2790 to fill an area of the display screen of the 2755 network page with a list of attributes or characteristics, for a selected CPN in the inventory or in the updates section. More particularly, the order management section CPN 2760 of the display of the network page 2755 comprises the following field descriptions: 1) a field 2762 that allows the customer to define the date / time when the order is to be implemented by the host. For example, a default time is the current date and time of the computer, shown in the format of MM / DD / YYYY HH: MM (24-hour clock), -2) a field 2764 that allows the establishment of a priority (depending on security access privileges); 3) A field 2766 to describe the current status of the order. For example, new CPN orders may have by default the status of "not approved"; 4) A comment text field 2767 optionally used to describe the contents of the CPN order; and 5) An approval field 2768 such that when it is confirmed, it indicates that the order is approved and will be transmitted to the host. After the transmission, the name of the field changes to Approved and the status field of the order shows Approved. It should be clear that, if authorized, a client can disapprove an approved order that has not been completed by reselecting the approved verification box. A sudden appearance message (not shown) on the network screen will tell the client to confirm the action. More particularly, the CPN 2770 inventory section used to obtain CPNs from the CPN order inventory comprises the following descriptions of field / command buttons: A CTRY 2772 field that includes a three-digit country code for the CPN; a CPN start field 2774 comprising the remaining digits of the CPN or the initial number within a range; - A description field 2776 comprising an alphanumeric description assigned to the CPN, for example, the CPN location or company name; a component counter field 2778 that indicates how many CPNs are in the CPNs in the inventory section; a obtain button 2775 in such a way that, when selected, it obtains a list of the CPNs available from the customer in inventory that are not included in other orders. The selection of this option will allow a visualization of the network page of the CPNs obtained from the inventory window 2812 as shown in Figure 29 (f), - and, a command button in the form of a right arrow "> "2779 that allows a customer to move single or multiple (selected) CPNs from the CPNs in the inventory section to the CPN updates to include them in the current order. More particularly, the CPN update section 2780 comprises the following field / command button descriptions: a status key indication field 2781 shown next to the CPN, with the following designations; an indication (blank) means that there is no status, - an "A" indication indicates that a new CPN is to be added, for example, Stentor clients, - a "C" shown next to the CPNs means that they have been modified; and a "D" indicates that a CPN has been marked to be deleted; a CTRY field 2782; a CPN start field 2783; a description field 2784; and, a component counter field 2787 as described above, a left arrow command button "<2788" which allows the client to delete a CPN of the current command, and restore its attributes back to those that were last transmitted. the host, that is, moving one or more CPNs highlighted to the CPNs in the inventory section; a "add" command button 2785, for example, displayed by Stentor clients, which presents a network page that has a New Add CPN window such as that shown in Figure 29 (c); and, a button "Delete" command 2786, for example, shown for the Stentor clients which marks the highlighted CPNs shown in the CPN update section to be deleted. More particularly, the CPN attribute section 2790 comprises the following field / command button descriptions: an "element" field 2792 comprising those characteristic Vnet / Vision elements that are listed in this column once linked to the CPN (s), for example, rank privileges, set key identifiers, etc .; a "Value" field 2793 that comprises the defined value of the characteristics of the network (for example, U 001) linked to the CPNs (s), - a field "CPN Nbr" 2794 which designates the information shown in the section of attributes and that is for the selected CPNs, which can be in the inventory CPNs as well as in the CPN updates sections; a "Variable" field 2795 which changes according to the element selected in the attributes section and allows clients to add / modify information for the selected element, except when any pre-loaded information gradually decreases, - A button < Define omission > 2796 that allows a client to define the default values of the computer for the CPN attributes. Once defined, the default values of the computer can be applied to other CPNs by selecting the < Use omission > 2797 whose command provides the option to apply both the default values of the host and the default attributes of the computer defined by the user for the selected CPN. For example, if the current CPN lease type is "C", the default attributes that would change this to "A" or "B" can not be applied. On the other hand, if a location type "C" was defined as the default value with the <buttonDefine omission > , a pop-up message will appear that will prompt the user to confirm using it as an omission when < Use omission >; a button < Undo > 2798 to eliminate any changes made to the selected CPN, and restore its attributes back to those that were last transmitted to the host, a button < Expand > 2799 which allows the display of the attributes window of the call party number, as shown in Figure 2 (g); and a button < Close > 2791 to close the CPN order window. The CPN Add New 2800 window like the one shown in Figure 29 (e) allows a client, if authorized, to add a new CPN to their inventory and assign their attributes. In the example of displaying the network page shown in Figure 29 (e), the Add New CPN functionality includes: assigning a provisioning bearer in the entry field 2802; add a CPN number in the entry field 2804; add a CPN number in the entry field 2806; and, adding a CPN description in the entry field 2808. Preferably, the CPNs (s) are displayed in the update section CPN 2780 with the indication "A" 2781 as shown in Figure 29 (d). It should be clear that the CPN commands can be deleted by selecting the delete button 2786 of Figure 29 (d). As mentioned above, the selection of the obtain button CPN 2775 allows the visualization of a page of the network of CPNs obtained from the inventory window 2812 as shown in the example of displaying the page of the network of Figure 29 (f) From this window, the client can specify a search criteria or obtain a predetermined amount of CPNs that have a default criterion. Particularly, the CPNs obtained from the inventory window 2812 come the following field / command button descriptions to obtain CPNs from the customer's inventory: a 2814 country field for the country key from a vertical list by selecting an arrow "down" 2815 when a CPN is specified in the CPN field; a field of CPN 2816 that allows the client to capture a partial or complete CPN, for example of 3-25 numeric characters. The nMCI interaction ONM system matches the partial NPC and obtains the first 10 available exchanges in inventory; a Quantity field 2817 that allows the client to enter a value of l to 200 per CPN group, specifying the number of CPNs to be included in the procurement; a network identifier field 2818 that allows the client to select a specific network identifier from the vertical list by selecting the down arrow, - a range ilege field 2819 that allows the user to select a specific range ilege from the vertical list by selecting the Arrow down; a set key identification field 2820 that allows the user to select a specific set key identification number from a vertical list by selecting the down arrow. It should be clear that the joint key identifiers should be defined before creating the CPN command, as will be described here; a description field 2821 that allows the user to write a full or partial CPN description as a procurement criterion, - a button < Add > 2823 to update the list box with the group information of the Country edition boxes, the CPN, Quantity, Network identifier, rank ilege, joint code identifier and description; a button < delete > 2825 which allows the user to delete a highlighted display element in such a way that it is not included in the obtaining request, - a button < Ok > 2826 to accept all entries in the obtaining CPNs of the inventory window, and perform the messaging to the host. If the nMCI Interactive ONM finds one or more CPNs that match the specified search criteria, it will close the obtaining CPNs from the inventory window. If the obtaining CPNs of the inventory window are accessed from the CPN order window, the results will be displayed in the CPNs in the inventory section and IP will replace any CPNs that have been in this section 5 r to the obtaining, - and, a button <; Cancel > 2827 to close the CPNs to obtain the inventory window without accepting any modification. As mentioned above, the selection of the CPN attribute button < Expand > of the CPN (2799 Figure 29 (d)) allows a display of the attribute window party number Calling 2830, as shown in the display example of the network page of Figure 29 (g). From this window, a client can "see only" CPN attributes or characteristics, if the selected CPN is located at the CPNs of the inventory section of the order window CPN, or view or modify attributes if the selected CPN is in the CPN updates section. As shown in the example display of the network page of Figure 29 (g), a first section referred to as the information section CPN 2840 comprises view-only fields presenting information such as: a country key field of three digits 2841 that identifies the country of origin for this CPN; a "From" field 542 that indicates the initial number of a possible range of CPNs affected by this CPN order; an "A" field 2843 indicating the last number of a range of numbers affected by this CPN order; a customer account field 2844; a division identifier field 2845; a description field 2846 describing the CPN (s), - and, a yes or no cell field 2847 indicating whether this CPN originates from a cellular phone. Additionally, a second section referred to as the feature information section of the CPN 2850 comprising the following field / command buttons: a network identifier field 552 obtained from the vertical list by selecting the down arrow, - a field of privileges of rank 2853 to select the privileges of rank (personalities or universals) that are going to be linked to this calling card from the vertical list by selecting by means of the down arrow, - a field of identifier of key set 2854 to select a set key identifier that will be associated with this CPN from the vertical list by selecting the down arrow. When selecting a set key identifier, the nMCI interactive ONM automatically populates the key length identifier; a launder 2855 supplication field that allows the selection of a vertical list to indicate when a key and / or account identifier will be collected for this CPN. A tone will instruct callers to digitize the code (s) after the dialed number. Selections include: 0 - No additional keys are collected; 1 - Get supplementary keys for all the numbers; 2- Replenish additional keys in all calls except private numbers over the 7-digit network; 3 - Replenish additional codes only for international numbers outside the network; 4 - Get supplementary codes for all the numbers outside the network; a data indicator field 2856 that allows the user to denote data against voice traffic by selecting a vertical list; a provisioning carrier 2857 indicating the provisioning carrier (MCI or 'Stentor') associated with the CPN, in the form of a country code, filled in with three digits with leading zeros and the 4-digit carrier key, - a field of type of location 2858 which can be selected by marking on the down arrow to activate the vertical list; a key length identifier field 2859 that is automatically populated only with two-digit numbers according to the selected set key identifier, - an account key length field 2860; and, option buttons < Define omission > , < Use omission > , < 0k > and < Cancel > , as described here. When opening an existing call card order, the nMCI interactive ONM system call card order option allows the customer to "bind" or append network features to calling cards that exist in the customer's inventory, ie , calling cards that are active in that customer's database, or linking network features to a new calling card. The following features can be defined / linked to calling cards: 1) Multiple networks; 2) Privileges of rank including universal or customized; range restrictions including corporate and personal; and extended company (type of location / access). Figure 29 (h) illustrates an example network page 2870 comprising a call card order window encompassing the following sections: 1) an order management section 2880 to provide administrative aspects of the calling card order such as: allow the capture of a date / time in which the order is to be implemented by the host; select a priority based on user access and security privileges; -establish an order status, for example, approved or unapproved for new orders in accordance with user authorization; 2) a section of 2890 inventory cards used to obtain inventory calling cards that are not included in another order. This is carried out by selecting the acquisition button 2895 and allows the display of, among others, the numbers of calling cards and associated PINs, a description assigned to the calling card, and a component counter; 3) a 2900 card update section which fills the calling card order window by moving the selected calling cards from the inventory section cards or by adding new calling cards to the current order; and, 4) an attribute section 2910 to fill a 2912 area of the screen with a list of attributes or characteristics for calling cards selected in the inventory or update section. More particularly, the call card order management section 2880 of the display of the network page 2870 comprises the same field descriptions mentioned here with respect to the management of CPN orders, which includes: 1) a definition field of date / time 2882 for when the calling card order is to be implemented by the host, - 2) a priority field 2884 for establishing the priority of the calling card order (dependent on access and security privileges) , -3) a current order status field 2886; 4) a commentary text field 2889 optionally used to describe the contents of the calling card order, - and, 5) a 2888 approval field such that when marked, it indicates that the order is approved and has been transmitted to the host. The calling card inventory section 2890 used to obtain call card inventory card (s) comprises the following field / command button descriptions: an NBR-PIN 2892 card field showing the calling card number and its associated PIN if the user has security access to view the PINS; a description field 2894 comprising a description assigned to the calling card, for example, the name of the employee or the company; a component counter field 2896 that indicates how many calling cards are in the inventory section of calling cards; a button to obtain 2895 so that when you select it, you get a list of the customer's available calling cards in inventory that are not included in other orders. The selection of this option allows a display of the network page of the calling cards obtained from the inventory window 2920 such as that shown in Figure 29 (i); and, a right arrow command button ">" 2898 that allows the customer to move calling cards in a single or multiple way (selected) from the calling cards in the inventory section towards calling card updates to include them in the current order. The calling card updates section 2900 comprises the same field / command button descriptions mentioned herein with respect to the CPN order management, which includes: a status code indication 2901 shown immediately following a calling card having the same designations, that is, without status, "A", "C", and "D"; an NBR-PIN card field 2902, a description field 2903 and, a component counter field 2904 as described above, a left arrow command button "<2905" which allows a customer to delete a calling card from the current order, and restore its attributes back to those that were last transmitted to the host, that is, move one or more call cards highlighted to the calling cards in the inventory section, - a "Add" command button, for example, only show the 'Stentor' clients; and, a "Delete" command button. The call card attributes section 2910 comprises the same field / command button descriptions that are mentioned here with respect to the administration of the CPN command and that include: a table 2912 that includes an element field 2911 comprising those characteristic elements Vnet / Vision that are listed in this column once the calling cards have been linked, for example, privilege of ranges, type of location, etc .; a "Value" field 2913; a "Nbr Card" field 2914 which designates that the information displayed in the attributes section is for the selected calling card, which can be in either the calling cards in Inventory or in the calling card updates sections, - a button < Define omission > 2915 which allows the client to define the default values of the computer for the attributes of the calling card. Once defined, the default values of the computer can be applied to other calling cards by selecting the < Use Omission > 2916 whose command provides the option to apply both the default value of the host and the user-defined default attributes of the computer for the selected calling card; a button < Undo > 2917; a button < Expand > 2918 that allows the display of the attributes window of the calling card, which is shown in Figure 29 (j); and a button of < Close > 2919 to close the calling card order window. As mentioned above, the selection of the "obtain" button 2895 of the calling card of Figure 29 (h) allows a display of a network page of the calling cards obtained from the inventory window 2920 as shown in the example of the network page of Figure 29 (i). From this network page, a customer can specify a search criteria or obtain a predetermined amount of calling cards that have a default criterion. Particularly, the calling cards of obtaining the inventory window 2920 comprises the following field / command button descriptions to obtain calling cards from the customer's inventory: a Nbr 2921 card field that allows the entry of a calling card number. partial or integer of 10 digits, - a PIN field 2922 that allows the entry of an optional 4-digit personal identification number that is associated with the calling card number and can only be used in combination with the Nbr card; a quantity field 2923 that allows the client to capture • a value, from 1 to 200 per calling card group, 5 specifying the number of calling cards that must be included in the procurement; a network identifier field 2924, - a network privilege field 2925 that allows the client to select a specific range privilege from a vertical list by selecting the down arrow, - a field description 2926 that allows the client to write a • full or partial description of the calling card as a procurement criterion; a button < Add > 2927 to update the list box with the group information of the Nbr card, PIN, Network identifier quantity, range privilege, and description edit boxes, - one button of < Remove > 2928 that allows the client to eliminate a highlighted display element in such a way that it is not included in the obtaining request, - a button < OK > 2929 to accept all the entries in the call cards getting the inventory window, and send the messages to the host; and, a button of < Cancel > 2930 to close the call cards to obtain the inventory window without accepting any modification. As mentioned above, the selection of the button < Expansion > 2918 of the calling card of Figure 29 (h) of the attributes section of the calling card allows the display of a network page of an attribute window 2940, as shown in Figure 29 (j). From this window, a customer can "only see" attributes or characteristics of the calling card, if the selected calling card is located on the cards in the inventory section of the calling card order window, or view or modify attributes if the selected calling card is found in the card updates section. As shown in the network page of Figure 29 (j), a first section referred to as the calling card information section 2935 comprises view-only fields that present information such as: the calling card number 2936 and the Associated PIN 2937; the customer account number 2938; and the description of the calling card 2939 which will be accessible and defined by the user. Additionally, a second section referred to as feature information section 2941 comprising the following field / command buttons including: a network identification field 2942 obtained from a vertical list and selecting with the down arrow; a privilege field of rank 2943 for the selection of the rank privilege (personalized or universal) that will be linked to the calling card from the vertical list and selecting with the down arrow; a range restriction field 2944 to select a corporation or customer rank restrictions that will be linked to these calling cards from the vertical list and which will be selected by the down arrow, - a provisioning carrier field 2946 indicating the provisioning carrier (MCI or 'Stentor1) associated with the calling card, in the country key format, filled with three digits with leading zeros, and the 4-digit carrier key; a field of location type 2948 for example, the default host, which, once selected, can not be modified until the calling card is deactivated and reinstated, - a button of < Define omission >; a button of < Use omission >; a command button < 0K > to return to the calling card order window, - and a button of < Cancel > to exit the calling card attributes window without making changes to the characteristic information. In a similar way as described above with respect to the page display of the CPN Add New network (Figure 29 (e)), a 'Stentor' client, if authorized, can add a new calling card to its inventory and assign attributes. The new functionality to add to the calling card includes: assigning a card number and an associated personal identification number (PIN), add a provisioning carrier in the country key format and, add a calling card description. It should be clear that the calling card orders can be deleted by selecting the delete button. By opening an existing dial plan order or creating a new one, the nMCI Interaction ONM system dial plan order option allows a company to define its call routing dial plans to meet their business needs and manage your network costs. Thus, the NM dial plan order outside the nMCI Interact limit allows customers the following: 1) create 7-digit private numbers that are translated into public numbers and use them for convenience in the call and its location association is easy; 2) force the public numbers in the network in such a way that they are no longer routed according to the rules of the public network, but rather by the customer's dial plan, - 3) exclude a specific number, or range of public numbers, control the abuse of the network; assign specific numbers to end in personal message announcements to provide user-defined lines of information, - and, establish snapshots to improve customer service by providing convenience to the caller and local presence. Within a dial plan order, a user can specify the origin, or the range of dialed digits (the dialed number), and the termination data (where and how the call is answered, for example, ending in lines of Dedicated access (DALs) Figure 29 (k) illustrates an example of network page comprising a 2950 dial plan order window that ^ P encompasses the following sections: 1) a 5 order management section 2960 to provide administrative aspects of the dial plan order such as: allowing the capture of a date / time when the order is to be implemented by the host; select a priority based on the user's security access privilege, - set 10 an order status, for example, approved or not approved for • new orders in accordance with the authorization of users, - 2) a section of 2970 inventory marking plans used to obtain inventory marking plans that are not included in another order. This is carried out by selecting the procurement button 2975 and allows the display of the country keys associated with the marking plan; display of the number or initial number of the dial plan within a range, - a type of termination for the dial plan; and, a component counter indicating the number 20 of dial plans that are in the inventory section; 3) an update section of the 2980 dial plan to fill the dial plan order window by moving the selected dial plans from the inventory section of the dial plan or by adding new dial plans to the current order; and, 4) an attribute section 2990 to carry an area of the 2950 screen with a list of attributes or characteristics for a selected marking plan in the inventory or in the updates section. More particularly, the display plan order management section 2960 of display example of the network page comprises the same field descriptions mentioned here with respect to the management of CPN orders which include: 1) a field to define date / time 2961 for when the dial plan order is to be implemented by the host, - 2) a priority field 2962 for prioritizing the order of the dial plan (dependent on security access privileges); 3) a status field of the current order 2963; 4) a text field for comments 2964 optionally used to describe the contents of the dial plan order, - and, 5) an approval field 2965 such that when it is confirmed, it indicates that the order is approved and will be transmitted to the host . The 2970 inventory marking plan section used to obtain markings from the marking plan inventory comprises the following field / command button descriptions: a country field 2971 that shows the country code of the dial plan, - a dial plan start field 2972 indicating the remaining digits of the dial plan number of the initial number within a range; a field type 2973 that indicates the type of termination for a dial plan, - a component counter field 2974 that indicates how many dial plans are in the call card inventory section, - a 2975 procurement button which, When selected, it obtains a list of the available dial plans of the customer in inventory and that are not included in other orders. The selection of this option will allow a network page visualization to have an inventory retrieval marking plan window 3000 such as that shown in Figure 29 (1); and a right arrow command button ">" 676 that allows the customer to move single or multiple (selected) dial plans from the inventory dial plan section to dial plan updates to include them in the current order . The dial plan update section 2980 comprises the same field / command button descriptions as those mentioned herein with respect to the CPN update section including: a status key indication 2981 shown immediately following a dialog plan having the same designations, that is, without status, "A" (added), "C" (Modified), and "D" (deleted); a country field 2982, a marking plan start field 2983, a "type" ending field 2984, and a component counter field 2985 as described above, - a left arrow command button "<" which allows the customer to delete a dialog plan from the current order, and to restore its attributes back to those that were last transmitted to the host, that is, move one or more of the dial plans highlighted to the inventory marking plan section, - a "Add" command button that allows entry of new dial plan records, - and, a "Delete" command button to remove records from the dial plan. The attributes section of the 2990 dial plan comprises the same field / command button descriptions mentioned herein with respect to the CPN attributes section including: an "element" field 2992, eg, a network identifier; a field "Value" 2994; a field "Mark Nbr" 2996 which designates that the information shown in the attribute section is for the selected marking plan, which can be in the inventory marking plans as well as in the updates sections of the marking plan; a button < Undo > 2997; a button < Expand > 2998 that allows the display of the attributes window of the • 20 dial plan, as shown in Figure 29 (m), - and a button of < Close > 2999 to close the dial plan order window. As mentioned above, selecting the "Get" button from the 2975 dial plan in Figure 29 (k) allows a display of the network page of the procurement marking plans from the inventory window 3000 as shown in the example of the network page of Figure 29 (1). From this display, a customer can specify search criteria or obtain a predetermined number of dial plans that have default criteria. Particularly, the acquisition marking plans of the inventory window 3000 comprise the following field / command button descriptions to obtain plans for marking the customer's inventory: a radio button 3001 of international digits with direct dialing "IDDD" that allows the entry of digits marked as public numbers in a field of digits marked 3003. When IDDD is selected, the user requires to designate a country code in a country field 3002; a private radio button 3005 that allows the entry of a private number in the field of dialed digits when it is selected. The country field is protected when this type of dialed digits is selected, - a country field 3002 that must be selected from a vertical list when IDDD is selected as the type of digits dialed, - a field of digits marked 3003 that allows the entry of a partial or whole number (dialed digits that do not include the country code); a quantity field 3004 that allows a customer to enter a value, from 1 to 100, specifying the number of dial plans to include in the procurement, - a network identifier field 3006; a termination / location identification field 3008 indicating the location identifier of a DAL which can be selected from the vertical list (if available within the customer's network), - a button < Add > to update the list box in the selected dialing plans section with the group information of the IDDD, Private, Country edit boxes (only when IDDD is selected), Marked Digits, Quantity, network identifier and terminator identifier / location, when applicable; a button < Remove > which allows the customer to remove a highlighted item from such rule that is not included in the procurement request, - a button < OK > to accept all entries in the inventory retrieval marking plan window, and to perform the messaging to the host; and, a button of < Cancel > to close the procurement marking plans of the inventory window without accepting any modification. As mentioned above, the selection of the < Expand > 2998 of the dial plan from the attributes section of the dial plan allows the display of a network page of the attributes window of the dial plan 3020, as shown by the example of the network page shown in Figure 29 (m). From this visualization, the customer can see the attributes or characteristics of the dial plan if the selected dial plan is located in the dial plans of the inventory section of the dial plan order window, or view or modify attributes if the card selected call is in the updates section of the dial plan. As shown in the display of the network page of Figure 29 (m) the first section refers to the range section of digits marked 3022 and that includes buttons fields / commands that allow the client to define the source data ( marked number) for a dial plan. The field / command buttons include: radio "type" buttons 3025 that allow the selection of the original number as a public or private number (IDDD), - a country field 3026 to allow the entry of a country code from a vertical list when selected IDDD as the type of digit dialed, - a network identification field 3027 that allows the entry of a network in which a new dialing plan is defined, - a "From" field 3028 that allows the entry of an initial number of a number range, -an "A" field 3029 that allows entry of the last number in a range of numbers, - a carrier identification field 3023 which is an optional entry for numbers defined in the dial plan order that it will only be terminated by the DAP if it was originated by the specified carrier key within the country of origin, and that it was only captured when a country and carrier code was specified. As shown in the example of the display of the network page of Figure 29 (m), a second section refers to the termination section 3030 which comprises buttons fields / commands that allow the client to define the termination data for a marking plan. The field / command buttons include: location name field 3031 which is an alphanumeric field that allows the entry of a description of the termination, for example, name of the company or location, - a type field 3032 that allows the selection of a vertical list of the following types of termination to which the private or public number sends the call: a DAL - used for dedicated access lines, an IDDD - used for all public numbers, a CMA - used for custom message announcements, and, an EXCL - used to exclude a number or range of numbers, - a location identification field 3033 from a dedicated access line (DAL) which can be captured (for example, shared DALs) or selected from the vertical list. If the type of termination is "DAL", a section / entry is required, - a country field 3034 for the selection of a country code (where the call will end) of the values in the vertical list and where it is required an entry when the type of termination is "IDDD"; a field of prefix digits 3035 to capture the numbers at the beginning of the termination number (not including the country code) that are the same for all numbers in the range, or the complete completion number when capturing individual numbers; a field of reuse digit length 3036 that allows entry of the number or digits of the dialed digits • that will be reused in the terminal number when 5 are used in a range with prefix digits. This field shows the default values, for example "00" and is protected when the termination numbers are captured individually or when the type of termination is CMA or EXCL. When a value is required, it can be typed or selected from a list vertical; a field nature of the subsequent address 3037 ^ allows the entry of pulseless digits delivered to a customer's equipment (CPE). When the type of termination is a DAL, the default value is changed from "None" to any of the other selections. However, "Subscriber" is what is typically selected, as well as "National" and "International" would only be used by a private network owner; A routing indicator source point check box 3038 to indicate the originating point of routing P which allows the client to designate an alternate DAL, which replace the DAL specified in that customer's dial plan, based on the source switch. This helps to handle load balancing for DALS, for example, for Vnet; and, a button < 0K > and one < Cancel > to close the attributes window of the dial plan without making changes to the characteristic information.

When you open a key / set order identifier or create a new one, the key order / set of the interactive ONM system identifier nMCI allows the customer to define a unique number of the 11 digits as a key identifier and assign that number to an individual number .

The key identifiers preferably have a privilege of rank assigned to them, therefore, a client can custom create call privileges and assign them to individuals by means of their identification key. Once an identification key system has been established, the key is captured after the number dialed on each call made. It should be noted that the DAP switches in the network (Figure 28) verify the identification keys. Thus, a correct identification key must be captured or the MCI switch will not complete the call. In the preferred embodiment, there are two types of identification key definition commands in the NM outside the nMCI Interact limit: 1) Add / modify the identification key identification order; and 2) delete the identification order of the identification key. In the preferred mode, the Add / modify identification order of the identification key allows the client to carry out the following functions to implement identification keys within the Vnet / Vision network of this client: 1) Define the length of the identification key (1 to 11 digits); 2) Assign rank privileges for identification keys; 3) define local sets, - 4) Generate identification keys sequentially or • random to any set of identification keys, - 5) 5 Individual entry of identification keys, - and 6) modify / delete identification keys in a set. Figure 29 (n) illustrates an example of network page 3050 comprising a window to add / modify the identification order of the identification key and which in turn comprises the following sections: 1) an order management section 3051 to provide administrative aspects of the order such as: allowing entry of a date / time when the order is to be implemented by the host; the selection of a priority based on the user security access privileges; establish an order status, for example, approved or not approved for new orders according to the authorization of the users, - 2) a section of identification key sets in • 3060 inventory used to obtain key sets of inventory identification and that are not included in another order. This is carried out by selecting the procurement button 3065 and allows the visualization of the details of the set of identification keys that includes: identification key, set identifier, types of set, length of identification key defined; a description of the set of identification keys, for example, by location; and, a component counter indicating the number of sets of identification keys in the inventory section of the key identifiers / sets, - 3) a section of updates of key identifiers / sets 3070 to fill the order window of key / set identifiers by moving the key identifiers / sets selected from the inventory section of key / set identifiers or by adding new key / set identifiers to the current order; and, 4) an attribute section 3080 to fill an area of the screen with a list of attributes or characteristics for key identifiers / sets selected in the inventory or in the updates section. More particularly, the key / set identifier order management section 3051 of the display of the network page 3050 comprises the same field descriptions mentioned herein with respect to the order management of the dial plan which includes: 1) a date / time definition field 3052 for when the key / set identifier order is to be implemented by the host, - 2) a priority field 3053 for establishing a dial plan order priority (dependent on access privileges) of security); 3) a current order status field 3054; 4) a comment text field 3055 optionally used to describe the contents of the key / set identifier orders, -and, 5) an approval field 3056 in such a way that when selected, it indicates that the order is approved and will be transmitted to the host. The inventory key / inventory identifier section 3060 used to obtain key identifiers / set (s) from the inventory of key / set identifiers comprises the following descriptions of field / command buttons: a definition field 3061 indicating the identifier of key / set; a "type" field 762 that has an indication of a local ("L") or global definition ("G"), - a length field 3063 indicating the defined length of the identification key, - a description field 3064 indicating the description of the key identifier / set, for example, location; a component counter field 3066 that indicates how many key identifiers / sets are found in the key identifiers / sets of the inventory section; a procurement button that, when selected, obtains a list of key identifiers / sets available for the customer in inventory and that are not found in other orders. The selection of this option will allow the visualization of the network page that has a key identifier / sets obtained from the 3090 inventory window as shown in Figure 29 (o), - and, an arrow command button 3067 right ">" that allows the client to move the key identifiers / sets of key / set identifiers in the inventory section to key / set identifiers updates in a single or multiple manner (selected) be included in the current order. The key identifier / set 3070 update section comprises the set fields, "types", lengths, descriptions and component counter described above, and a left arrow command button "<3086" that allows a client to move one or more key identifiers / sets highlighted to the key / set identifiers in the inventory section; a button "Delete" command; and, a button "Add" command 3069 that allows the addition of new key identifiers / sets to the order including functionality that allows the creation of a key identifier / set that can be added to an order and which must contain at least an identification code prior to the approval of the order. Adding a new set to the order entails specification of key identifiers / local or global sets. The attribute section of key identifiers / sets 3080 comprises the same field / command button descriptions mentioned herein with respect to the marking plan attributes section, which includes: an "Element" field 3082, for example, including key identifier information / set and key identifier, - a "value" field 3083; a "Set" field 3084 which designates that the information shown in the attributes section is for the selected key / set identifiers, which can be found in both the key identifiers / sets in inventory and in the update sections of key / set identifiers, - a button < Undo > 3085; a button < Delete key > 3086 to delete a selected key identifier; a button < Add key > 3087 that allows displaying a subsequent network page that includes a window of adding key identifiers to set, such as the one shown in Figure 29 (p), - and a button of < Close > 3088 to close the order window of Add / Modify key / set identifiers. As mentioned above, the selection of the "get" button of the key identifiers / sets 3065 of Fig. 29 (n) allows a network page to display the key obtaining identifiers / sets of the inventory window 3090 such as the one shown in the example display of the network page of Figure 29 (o). From this window, a customer can specify search criteria or obtain a predetermined number of key / set identifiers with a default criterion. Particularly, the key obtaining identifiers / sets of the inventory window 3090 comprise the following fields to obtain key identifiers / sets from the customer's inventory: a set field 3091 that allows the entry of a set number, -a field Description 3092 that allows entry of a complete or partial description of the key / set identifier, for example, an alphanumeric description, - a key identifier field 3093 that allows the entry of a specific key identifier; a quantity field 3094 that allows a customer to capture a value by specifying the number of key identifiers / sets to be included in the procurement; a button of < Add > 3095 to update the list box in the section marked dial plans with the group information of the text boxes of the set, description, key identifier and quantity; a button of < Remove > 3096 that allows a customer to delete a highlighted visualized element in such a way that it is not included in the obtaining request, - a button < 0k > 3097 to accept all the entries in the identifiers of obtaining keys / sets from the inventory window and for sending the messaging to the host, - and, a button < Cancel > 3098 to close the identifiers of obtaining keys / sets of the inventory window without accepting any modification. As mentioned above, the selection of the button to add key 3087 of Figure 29 (n), allows the visualization of the window of adding identifiers of keys to set as the one shown in the example of the page of the network of adding identifiers of key to set 3100 of Figure 29 (p). As shown in Figure 29 (p), the Add key identifiers to set 3100 window allows the client to delete key identifiers from a set, - add a key identifier at a time, for example, a simple generation, - Generate key identifiers to the set sequentially and randomly identify key identifiers to the set. For example, the client can capture the set information in the following fields: The joint field 3102 for which the key identifier modifications will take effect, - a length field 104 that defines the length of the key identifiers contained in the set, - a description field that allows the entry of text that describes the set, - and a type field that indicates that the set is local or global. With respect to options for generating key identifiers, a simple generation option 3110 allows the user to add key identifiers one at a time to a set, for example, by capturing the number in the key identifier field 3112; a sequential generation option 3114 that allows the user to specify an initial key identification number and an amount in the input fields (not shown). The "nMCI Interact ONM" will automatically generate, sequentially, key identifiers according to the amount specified by selecting the Add button 3118 which updates the list box 3125 with information of the generated key identifiers; and, a random generation option 3120 that allows the user to specify an initial key identifier number, and a final key identifier number, and, an amount in the input fields (not shown). The "nMCI Interact ONM" will randomly generate the specified number of key identifiers within the start and end range by selecting the Add button 3118 to update the list box 3125. The selection of the < Ok > 3126 will allow the acceptance of all newly generated key identifier entries, by messaging the host on the new keys and returning the control to the order page of Add / Modify key / set identifiers. (Figure 29 (n)). As mentioned above with respect to Figure 29 (a) showing the display of the "nMCI Interact ONM" 2764 network page, the control menu option 2720 provides a refresh option that allows an update of all internal lists that have been altered in the NetCap host system. Specifically, the "nMCI Interact ONM" 2700 system updates the following lists: The network identifier, the privilege of ranges, the key / set identifiers, the invoice location identifiers, the customer service identifiers, the types of location / access, and the carrier of ^? provisioning. It should be understood that the option of refreshed will not modify the values of an open window that includes the data of one of the lists. In addition, with respect to the option of the report menu 2742 provided in the display of the main page of the network of Figure 29 (a), users will be able to ask 10 for their respective inventories, the CPNs, the cards (f called , the marking plans and the key identifiers / sets The ONM system will show a respective "Obtaining" element of the inventory, for example, the selection of the report option for the CPNs allows the updating of the CPNs obtained from the screen of the inventory as shown in Figure 29 (f), particularly in the ONM 2700 system, there are four inventory reports available to the client, - CPNs, calling cards, dial plans and key / set identifiers. may be required from the display screen of Figure 29 (a), however, they will be delivered to the message center of the nMCI 270 interaction system for the client to see and obtain nga in the way described here. 25 EVENT MONITOR As mentioned above, another application of the set of network administration applications • telecommunications is the event monitor and the 850 broadband network performance reporting system. As shown in the high-level process flow diagram of Figure 30, customers are allowed to request, specify , schedule and receive reports of information related to bandwidth, for example, switched packets, networks of data. • As shown in Figure 30, the broadband reporting system ("BB") includes a broadband view client comprising the client workstation 20 employing a network pager running, for example, he Internet Explorer 4.0 or higher, to allow the generation of requests and reception of responses of broadband system processes over the network / Internet through a secure connection socket. As described here, the f StarWRS 200 component of the nMCI interaction system can to be implemented to support broadband reporting requirements, obtaining reports and alarm monitoring functions. All interactions with the broadband reports and the characteristics of the system's network management platform ("SNMP") occur between the applet of the broadband client 852 and broadband server 860.

Particularly, the Java classes of the broadband application invoke a "message class" that has the common object code as an interface definition. Integrated with the broadband report system architecture 850 of Figure 30 is the nMCI 24 interaction network server and the dispatcher components 26 that provide transport between the BB client pager and a band representative interface. wide that includes all authentication and encryption with cryptic language. Thus, in this way, secure communication is enabled from the client's pager to the server of the DMZ network over a first TCP / IP secure connection socket, such as SSL, and, the DMZ network server communication will be enabled. a corporate protection wall to the dispatcher server over a second TCP / IP connection socket, such as DES. These secure paths allow the client to have requests and responses from the server communicated between the client's pager and the broadband server 860. Specifically, the dispatcher server 26 includes a broadband representative application integrated with subsequent user requests and responses. to / from the 860 broadband server processes to enable broadband functionality. As described herein, this rendering capability includes a multi-string machine that allows multiple and simultaneous execution of sessions that support an anticipated user load. The interface between the dispatcher server and the broadband representation processes are also message-based and employ, for example, transport by TCP / IP socket, and, as will be described, a message protocol is defined comprising a generic message header followed by representative-specific data. For sending messages to the broadband server, the generic message header is first followed by the specific data of the representative. In the other direction, the same process is used, that is, the broadband representative sends the generic header followed by the representative's specific response back to the dispatcher server for communication on the protection wall and again to the network server . In the embodiment shown in Figure 30, all responses of the bandwidth including the CSV data files pass through the dispatcher server 26 and the DMZ network server 24 intervenes with the server of the broadband message entry box for the subsequent access and the eventual visualization in the client. In the preferred embodiment, the broadband server ("BB") 860 performs the various database queries and function calls in response to the requests received from the client by the broadband representative 854. That is, the The BB client submits all requests and queries to the BBB 860 server using a generic representative framework called BBProxyServer 854. These communications include requests for reporting, obtaining and viewing, requests for circuit information using obtaining commands (Get) SNMP, allocation of mnemonics for circuit names using definition commands (Set) SNMP; and, establish a session for alarm monitoring activities in circuits. Particularly, the broadband server 860 is responsible for all tasks that lead to an inclusion of the generation of the performance report and SNMP information, including information collection, calculation, storage and generation of reports. As shown in Figure 30, the components that feed information to broadband server 860 include: 1) A performance report system ("PRS") server 880 to send statistical and performance information to the broadband server , - and 2) the SNMP 870 platform which is a tool that feeds SNMP network and alarm events in real time or almost real time to the broadband network server 860 through a representative interface 871. One of these SNMP tools implemented by the assignment of the present invention is entitled "NetExpert". The broadband server 860 additionally supports SNMP "get / define" functionality which is a menu driven installation that allows the user to query the SNMP database to obtain the value of a variable in the management information base ("MIB"). ") 887, or, define the value of certain variables in the MIB, as will be described in more detail here. The broadband server 860 additionally supports communication with the StarOE 39 component which provides command entry functions including the functionality needed to manage (create, update, delete) broadband users and, allow the feeding of the appropriate information to the server of broadband in order to associate the appropriate reports and broadband functionality to the correct client once the broadband service has been accepted. As described, the StarOE command entry process essentially provides the means to authenticate users, and initiate report generation. A messaging interface is provided between the StarOE to the broadband network server 860 that functions as a client to receive authentication information and the billing identifier and service level information which is supplied in response to the launch of the applet broadband To establish a basic level reports, the broadband server 860 transmits information of new clients to the PRS1 880 component when it is received. The customer billing identifier and the circuit information are captured in the PRS1 tables by a message interface 884. Any addition to or update of the user name, user identifier, billing identifiers are periodically passed from the broadband server 860 to the PRS1 880 through an FTP message inferred 883 in response to the period, for example, every night update the broadband server from the StarOE. Particularly, broadband server 860 receives from the StarOE server 39 a file containing all current BB clients with the following information: a date / time stamp, - a user name, - a user identifier, - an indicator of service level; and, the number of billing identifiers and billing identifiers. For the service level indicator, broadband offers the following options: 1) basic, 2) standard, 3) improved SNMP; 4) Premium; 5) Improved Ad Hoc reports, - 6) Improved SNMP plus Ad Hoc reports; and 7) Dedicated SNMP. Specifically, of the information downloaded from the StarOE, reports with separate values with comma (CSV) are automatically created on a daily basis from the beginning of the PRS1 service until the service is discontinued. As an example, for the basic level of service, the broadband server delivers three (3) CSV files to the StarWRS 270 input box: configuration report, circuit usage, and PVC utilization. Referring to Figure 31, the PRS 880 device performs the following: 1) queries to the MIB 887 in each switch through the interphase 886 to obtain information about that circuit, - 2) collects the data; 3) assembles that data into the appropriate tables for storage in the broadband server database 885. A nighttime process between the RMS 872 and the PRS 280 database synchronizes the PRS service level information with the RMS 270 to determine what level of reports is assigned to each circuit / PVC and execute the appropriate reports. Of these components, the following functions, reports and capabilities are available for users of the nMCI interaction; a) performance statistics in almost real time; b) customer performance reports that include, - 1) frame relay graphs that include: Network health (daily or monthly), - network performance (daily, weekly, monthly); Circuit trend in hours of occupation (daily, weekly, monthly), - Delivery of customer frames (daily, weekly, monthly); use of PVC through access to the circuit of hours of occupation (daily, weekly, monthly), - and port access quality per hour (daily), - 2) Frame relay text reports that include: network performance (daily, weekly, monthly); Trend of the circuit in hours of occupation (daily, weekly monthly), - Delivery of the frame to the client (daily, weekly, monthly); use of PVC by the access circuit in hours of occupation (daily, weekly, monthly), - quality of the access port per hour (daily); and, client configuration (daily); 3) Frame relay downloads including: use of the circuit (daily) and use of PVC (daily), - and 4) SMDS graphs that include circuit statistics (daily, weekly, monthly) and circuit trends in hours of occupation (daily, weekly, monthly). Additional capabilities include providing near real-time alarms and configuration reports (framework and SMDS) relative to a virtual transport network of the MCI client. Thus, the broadband system 200 of the invention provides a set of tools by which a customer can understand the performance of their virtual data network. It provides the client the ability to statistically analyze the performance trends of the network over time, and then determine if the network should be modified to ensure that it is operating at its highest performance levels (that is, it meets the needs of the business). The broadband reporting system allows customers to review the performance data of the network over a period of time, for example up to 45 days, creating and recording reports on their workstations, on a network server or in a network server. diskette Analyzes and trends of alarms can also be carried out, correlating the occurrences of the alarm with the availability of the network, network performance and resolution of • problems . 5 In a view of Figures 30, 31, 32 (a) and 32 (b) a detailed flow diagram is shown that shows the process of creating reports in CSV. As shown in Figure 32 (a), steps 902-906 show the addition of the user's billing identifier to the PRS1, the addition of the client's service level information to the StarOe, and the addition of any information from the customer. deletion of the report to the RMS. As described, the service level information will be available in the StarOE system. The StarOE service level information is of a 'courser' 15 granularity and is used to allow access to the appropriate broadband capabilities, based on the order entry process. A user can suppress the transmission of a report or set of reports using the BB application, but this does not stop the collection of performance statistics, only the generation of reports. The next few steps 908-914 are related to the data collection process. Specifically, data on the performance of all circuits associated with a particular billing identifier are collected from all the switches in the ATM or frame relay network through a periodic scrutiny process, for example, by hours. The addition of a new billing identifier to the PRSl tables (step 902) is used by the scrutiny process which processes circuit and PVC adds to your scrutiny requirements based on the association with the new billing identifier, as Then, as indicated in step 910, the teller consults the MIB 887 on each switch in the network to obtain statistics on the selected circuits and the PVC on a cyclic basis, for example, every 15 minutes. As shown in Figure 31, the PRS 896 scrutiny function scrutinizes the MIB 887 in each switch 888 in the network, for example the frame relay or the ATM network in sequence. The scrutineer sends a UDP packet to the MIB on each switch in sequence to obtain statistics on all circuits / PVCs enabled for the broadband service. In response to the UDP request, in step 912, the MIB returns all current statistics on circuit / PVC data of the switch. In the event that a switch is not within reach, the counting process records an error in the PRS1 error log indicating that the specific switch was not within reach. Next, as indicated in step 914, the PRS1 writes the data to a text file and a volume loading process Sybase adds the information to a data table without preparation. Particularly, as shown in Figure 31, a PRS 897 assembly process distributes the statistics to the appropriate tables in the active database PRS1 880. The assembly process compares the data from the previous hour with the data from the table without preparation, compare the values and write the deltas in the tables of each hour, which are then copied to the reporter. Then, in Figure 32 (a) in step 916, an automated process executes the selected reports on statistics available in the PRS database tables. In the preferred mode, as shown in Figure 31, this 298 reporting process occurs at night, however, it can be executed on any periodic basis. The specific reports that are run are determined by the level of service to which the billing identifier is entitled, which is recorded in the StarOE tables. Referring to Figure 32 (b), as indicated in step 922, for each billing identifier, the reporter determines which reports will occur, generates queries against the appropriate tables, executes the queries at the appropriate time and delivers the reports to the input box BB of the users 270. The creation of reports is carried out in sequence: all the newspapers, then all the weekly ones (if applicable) then all the monthly ones (if applicable). Particularly, as indicated in steps 925 to 927, a control process "s_RunAHReports" is invoked to load all the client lists, and in step 925 it is called "s_GenReport" which collects the information about service levels for all customers As indicated in step 928, the RMS process returns the service level information indicating any deletion of the report, and in steps 929, the "s_GenReport" creates and executes queries against the data collected in the PRS1 database. In step 930, the resulting sets are written to a temporary report directory and then compressed in step 933 and added to the PRS database which can store the report for a predetermined amount of time, for example, a week. Next, as indicated in step 935, the reports are copied using immediate components, for example, the sybase RepServer, and recorded in a broadband server reporting (RLD) database 885 which it can be remotely mounted by broadband server 860. Particularly the PRS 298 reporter shares a unit in which these reports are located with the broadband server through a remote file mount. The database of the broadband server retains the data and reports for a predetermined period of time, for example, 45 days, prior to the current date. Finally, as indicated by step 938, broadband server 860 determines which reports have been produced and sends them directly to the broadband input box component associated with the billing identifier. The broadband server creates a unique file name for each CSV report and places each report in the broadband entry box 270 (Figure 30 = so the client can obtain it, as indicated in step 940). steps 922-938 appear in a condensed physical architecture diagram in the broadband system shown in Figure 31. As shown in Figure 32 (b) in steps 925-927, 933-935, a determination of whether the processing carried out in each step was successful, if the processing carried out in each step was unsuccessful, or an error occurred, then the error can be recorded in a 939 record file on the broadband server and in the input box for later review, when necessary. The details of the 950 broadband reporting process are described in a view of Figure 33. It is assumed that StarOE has already validated the identifier and the ^ fc password of the user, and that the user has the rights to to receive broadband services. Thus, by selecting the broadband services icon 93 from the initial page of the "nMCI Interact" (Figure r (b)), the user can enter the broadband service system and particularly access the front end of the service. client of broadband. A client's broadband applet is then downloaded to the client that appears on the main broadband display screen, as indicated in step 952. Figure 34 (a) shows an example of the client's screen.

• BB main display of broadband network page 5 1720 which presents a variety of broadband options selectable by the user, which include: a 1722 input box option that allows the user to obtain their broadband reports, - 2) an option 1724 that allows the user to see the SNMP alarms; 3) an option 1726 that allows the user to specify the reports that are going to be deleted; • 4) an option 1728 that allows the user to obtain broadband reports that have been archived; 5) an option 1730 that allows the user to receive information regarding the locations of their circuits, - 6) an option 1732 that allows the "obtain / define" functionality to provide significant labels to the circuit locations to improve the readability of the reports, - and 7) an option 1734 that allows obtaining a map view application for ia • generation of maps showing the virtual networks of the client. In the preferred embodiment, a main bandwidth display applet is provided as a launch pad to access all of the broadband services mentioned above. The display applet The principal will preferably be a Java applet running within the user's network pager 20) and that will use classes that extend the basic functionality of the Java applet in areas such as application management, user session administration, interface with the user, inter-applet communications, and client / server communications. Particularly, access of the broadband main display applet provides communication between broadband applications using the common COApplet object, the COAPP, and the COBackPlane services, which are objects operating in the manner described here. As shown in Figure 3, the main display applet BBMainDisplay inherits from the COAppIMPL the class with a COApplet interface which is launched from the nMCI Interact COBackPlane using the COApplet interface. When a user clicks on the toolbar button of the broadband service or on a menu item, BBMainDisplay creates an instance of a COApp (let) to handle the corresponding application. When the user exits the broadband services, the COBackPlane is used to destroy the application and its windows. The main broadband visualization applet provides a menu bar, a toolbar and a status bar to access broadband services according to the customer's subscribed service option, which includes: Basic, - standard , - Improved SNMP; premium; improved reports Ad hoc; SNMP improved more reports Ad hoc; and dedicated SNMP. As determined by the user's greeting session with the StarOE 260 server), if the user has no right or does not have authorization for a particular service, the icon of the corresponding toolbar or menu item will be disabled (inhibited) and will be supplied insensitive to the user's input according to the customer's service option. When launching BBMainDisplay, the primary display first determines the user's broadband service level option, for example, basic, standard, improved SNMP, etc. The user selects the broadband service, for example, custom reports, file reports, or SNMP features such as get / define and the alarm panel by clicking on the icon of the corresponding toolbar or on the menu item in the applet of the main display (Figure 34 (a)). For the case of custom data reports (Ad hoc), for example, of the MIB frame relay, a customized report applet interface is provided. From this network interface, a client can select from the available data variables (that is, physical or logical circuit, data point value, time frame for reports, etc.). The specific responsibilities of the custom report applet include: 1) allow customers to define a custom report query using a simple performance statistics category, a range of statistics, and a date / time range, - 2) allow customers select reports that present statistics relative to their access circuits to the current network or to the PVCs of the network. This includes allowing the customer to select both an access circuit and a PVC report category type, in which case a vertical list shows the current performance statistics for the selected category. The client then selects a category of simple performance statistics from a vertical list; 3) allow the client to specify a range on statistical values using relational operators and numerical values, for example value > = 80%; 4) allow the client to specify a date / time range coverage, for example, the previous 45 days of service. A client can select at any time start and end dates / times within a range, - 5) allow the client to record the customized queries defined by the option "Record Query"; and 6) provide an "Auto-execution" function that allows custom reports to run automatically and be available when default reports occur through the broadband input box. Once the user submits the customized report request, this is directed to the input box of the bandwidth for its subsequent view.

When providing the basic service option, the main broadband view applet has the responsibility to: 1) require the type of service (rights) of both the StarOe authentication server and the BackPlane data (Figure 3); 2) require reports that are no longer in the server box of entry to be obtained from a report data file if a predetermined period of time has elapsed, for example, 45 days, and provide these reports to the client through the broadband entry box, - 3) define how client reports should be required, for example, report identifier, date, etc .; 4) provide context sensitive online help for all aspects of the broadband WEB application, - 5) provide access to the broadband user guide, -6) provide the ability to produce separate dialog windows, for example , explain the progress of the reporting activity; 7) provide a "send mail" function to provide the client with a method to create a mail memo for distribution at a helpdesk, - and, depending on the client's service option, 8) provide access to the custom report capability (Ad hoc reports) using the toolbar and the menu; and 9) provide access to the SNMP features (get / define and alarm) using the toolbar and menu.

Referring again to Figure 33, the user can select the BB entry box characteristic as indicated by steps 954a-954c by clicking on the BB entry box icon. By clicking on the BB checkbox icon starts a download of the broadband entry box applet, as indicated in step 956. Using this applet, the broadband view entry box client requires all the data (headers) of available report from the database of the location of the report as indicated in step 958. 10 Then, in step 960, the RLD returns information of the (B header such as the name of the report, identifier, location, date / time required, date / time produced for the client, and use the information to auto populate the entries in the broadband input box of step 962. The report availability then appears on the (customer) screen in the BB entry box in step 964. It should be understood that for when the user has received the welcome packets of the "nMCI Interact", the data collection of the back end and the activities of • 20 generation of the report at the appropriate service level. As a result, full reports will be available at the first salutation. Figure 34 (b) shows an example of screen display input box for broadband view 1740 that has a 1745 screen area to display the reports currently available. Referring again to Figure 33, a user can obtain any report by double clicking on the desired report, whose action causes a request P for the report and sending the appropriate reviewer to the broadband server 5, as indicated in step 968. The broadband server responds by locating the file (using the RLD) and transferring the file to the user and the appropriate reviewer to the client. In the preferred modality, the user will be able to show text and comma separated values ("CSV"), as indicated in step 971; multigraphic health reports of • the network, as indicated in step 972; and map reports, as indicated in step 973. Thus, in the preferred modality, the broadband reporting review component includes revision classes with applets in Java that allow the download and display of performance reports generated by broadband server 860. In the preferred modality, there are at least two types of review classes that provide the following reports: 1) monthly health reports of the network that are reports static standards and multigraphic reports that have three areas of information: i) domestic latency, that is, delays in the network; ii) delivery, this is network performance; and iii) peak utilization, for example based on the information rates committed; and, 2) daily health reports of the network that are standard static reports and multigraphic reports that have views of domestic latency, delivery, and peak utilization reports, as well as a fourth view of report exceptions. In addition to having the ability to select reports on a daily or monthly basis, a custom Java applet for reports is also provided which allows customers to select "ad hoc" broadband reports (one at a time) for any interval previously defined. For example, a customer can have a standard "Daily Performance Performance" report delivered every day. 10 However, for a particular day, the same customer can select P to present an ad hoc report "performance performance" for a previous time interval, for example, the previous week, or the previous month. In the preferred embodiment, the broadband network server adds complete report data 15 in the CSV to the broadband input box server 270 whose components allow the client to report display processes 215 to display reports. In particular, the BB client application loads the report's reviewer, which loads the required report and shows it to the user. For CSV reports / spreadsheet the user has the option to manipulate the data in the reviewer. When multigraphic reports such as the network health report are viewed, the reviewer provides in-depth capabilities: by double-clicking on a section of a graph, the 25 supporting data will appear.

The broadband report reviewer component additionally includes Java applet classes that allow the display of client configuration maps that are two-dimensional maps that have certain highlighted locations, for example, customer gates, in addition to lines that connect two or more locations representing dedicated data transport paths of the client, for example, permanent virtual connections ("PVC"), as will be described here in more detail. In addition to having the ability to generate reports of network performance and configuration maps, the report review component of the broadband reporting tool includes Java applet classes that allow the presentation of real-time or almost real-time alarms. network event data obtained from the network management platform "NetExpert" 870 as shown in Figure 31. Through a "representative application 871, notifications of events and alarms are sent to the BB 860 server which processes the alarms for communication through the applications of the dispatcher / BBProxyServer directly to the client BB 852, by means of a secure TCP / IP server messaging, as will be described in great detail at once. Referring again to Figure 34 (a), selecting the deletion option of report 1726 will allow the presentation of a BB 1750 report view deletion screen, an example screen of what is shown in Figure 34 (c) . From this screen, the user will be enabled to suppress or enable the name, type and programming of the selected report in particular, by selecting it in menu 1755. In addition, as shown in Figure 34 (a), the selection of the option file 1728 will allow the display of the report view of file BB 1760, an example screen of what is shown in Figure 34 (d). From the screen of Figure 34 (d), the user will be able to select the archived report that will be displayed in the BB entry box by name, type, programming period and reporting time period in 1769 entry fields. As shown subsequently in Figure 34 (a), the selection of circuit location option 1730 will allow the presentation of a BB 1762 view circuit location screen, of which an example screen is shown in Figure 34 (e). From the screen of Figure 34 (e), the user will be able to obtain configuration information of the network pertinent to the client's network by clicking on the appropriate circuit identifier and the location field of a list 1763. By clicking on this field, a textual report containing circuit configuration information can be displayed. The preferred method of reporting to a client the current configuration of its virtual data network provided by MCI is by means of a network based geographic image map. The broadband mapping report and the customer configuration map report are available to customers at all service levels through the broadband reporting system. Preferably, all broadband clients receive a basic set of reports that includes information on the use, performance and processing of data transmitted over their virtual data networks as part of the set of default reports for the selected service option. Each service, for example, SMDS and the frame relay option, is to provide specific reports to the performance indicators of that service (for example, use, performance and processing of data transmitted over the virtual data network). The actual reports and the interval of reports can be unique, based on the type of report even if the default reports are available. A client configuration text report is included within a set of default reports. The mapping report is preferably updated on a daily basis based on modifications that have occurred within the customer's network in the previous 24-hour period. Since the update is dependent on the successful completion of the record, the update latency may be greater than 24 hours from the actual event that caused the change.

The data source for the customer configuration map and customer configuration text reports include: a customer name, - billing identifier, - contact (representative customer name and telephone number) for this account); mail address of the customer, - and the company providing the FR service, for example, MCI; a field of location that includes the mnemonic identification of the MCI point of presence (POP), that is, the city and state where the circuit is located; a name of circuit assigned in the circuit command management system for the FR access of the client, - a gate field containing a mnemonic identification of the gate that provides service to that circuit, - a field of identification of the administration of the network that identify the address of "NetExpert" system (Figure 30) by gate, slot, port and channel on the router card for this circuit, - a field of bandwidth that indicates the speed of the circuit, - a PVC number field that indicates the number of PVCs associated with - ± this circuit (name of the circuit), - a field of CIR total which indicates the sum of the CIRs for all the PVCs in this circuit; and an OVB SUB field (%) that indicates the total CIR (top) divided by the bandwidth by 100; a PVC field indicating a PVC number; a gate field comprising a mnemonic identification of the gate that serves the circuit on the A side of the PVC; a circuit field indicating the name of the circuit assigned to the A side of the PVC; a DLCI field indicating the DLCI assigned to the A side of the PVC; a CIR field indicating the CIR for the A side of the PVC; a gateway field comprising a mnemonic identification of the gate that serves the circuit on the B side of the PVC; a circuit field that indicates the name of the circuit assigned to side B of the PVC; a DLCI field indicating the DLCI assigned to the B side of the PVC; and, a CIR field that indicates the CIR for the B side of the PVC. 10 As mentioned above, the BB report review component includes the ability to display maps. The map reviewer shows all available circuits (enabled in BB) provisioned for the user. By clicking on the circuit, a sample of the latest 15 statistics is enabled for this circuit. All visualization functions, including classification, disc engraving and report printing, are executed locally by the reviewer. In the preferred embodiment, there are two graphical views of the configuration report to support the 20 standard and improved service level options: Figure 35 (a) illustrates the first map view 1770 which presents a two-dimensional map of the States Joined with all the endpoints of the client's virtual data network represented with the 1775 indicator, for example, a star, - 25 Each star represents a terminal point location of the client circuit within the MCI data network, but can also indicate a non-domestic frame relay, or LEC or SMDS access terminal points. As shown in Figure 35 (a), the selection of the button "View of all PVCs" 1778, allows the presentation of all circuits supported in the network. A second view of the map 1776 can also be displayed as shown in Figure 35 (b). From this view, the client can 'drill down' at a selected terminal point by clicking on an identified location 1777 and receiving a modified view (text box) that includes a description 1779 of the physical circuits supported by the terminal point of that network . Thus, clicking on any identified point provides more detail regarding the circuits supported from this terminal point, which includes: location of the circuit; number of the circuit, -nemonic of the gate, - identifier of the administration of the network; Bandwidth, - Number of PVCs, - and Total of CIR. As shown in Figure 35 (b), the lines that connect to the PVC end points are also extracted by a mouse click on an identified terminal point. In the preferred embodiment, the map views of Figures 35 (a) and 35 (b) are supported by the invocation of Java applets which have the advantage that an image map implemented as a Java applet provides instant feedback to the users. When a user clicks on a map displayed by a Java applet, the applet calculates a response locally and instructs the pager to load a new page. Referring again to the flow of the process of obtaining report 400 illustrated in Figure 33 in step 964, the client can delete a report by selecting the option to delete report. To delete a report, the user highlights the report in the entry box listing (Figure 34 (b)) and selects a delete function, as indicated in step 966. In response, in step 970, the customer submits an application deletion to the BB input box server which locates the report, registers the request, deletes the file and returns an acknowledgment to the client, as indicated in step 974. Upon receipt of the acknowledgment, the client of the input box refreshes the screen to reflect the deletion. The errors in the deletion activity result in an error message which is registered in the server and is returned to the client of the input box. In response, the client can notify the user of the erasure failure by using a dialog box on the screen. In the case of accessing the SNMP capabilities, an SNMP application is launched from the SNMP broadband main display application if the client has the dedicated SNMP or the PRS enhanced service option. The specific responsibilities of the SNMP application include: 1) providing SNMP obtain / define operations that include: obtaining selected variables from the company's MIB upon initialization; 2) communicate with the BBProxyServer and the database of the broadband server, - 3) invoke the operations obtain / define on MIB and return the results and visualizations; 4) provides an alarm panel to display alarms and event reports, - 5) handle the client near the real time in terms of notifications of updates for those alarms if the client's network pager is pointing to the page of the broadband network, - and 6) provide the client with the ability to obtain the SNMP for the smallest data interval, for example, from 15 minutes to 1 hour. Thus, as shown later in Figure 34 (b), the selection of the SNMP alarm option 1724 allows the presentation of a BB 1765 alarm panel screen of which an example is presented in Figure 34 (f). From the screen of Figure 34 (f), the user will be enabled to obtain and see the alarm conditions of his virtual network including the following indications: a type of alarm, - circuit identifier; alias, - severity level of the alarm, - alarm trap level, - alarm description; and, date of the alarm. In one modality, as shown in Figure 34 (f), the alarm data is handled by listing all the PVCs and also the associated access circuits. For each PVC and access circuit, all relevant events and alarms will be displayed. Preferably, color codes are used to indicate the severity of the alarm in accordance with OSI standards, for example, orange for the main ones, red for the critics. In the preferred mode, broadband alarms can be grouped into two categories: alarms detected by the network and alarms defined by the user. The alarms detected by the network include: "Define alarms" that are generated when there is a condition that indicates a degradation or failure in the service, and "Clear alarms" that are generated when a previously defined alarm condition no longer exists. Particularly, in order for the alarm data to be updated, the process of the alarm collection server invokes two methods on BBProxyServer: 1) a "recordAlarm" method which registers an alarm and writes the alarm data to the base of the alarm. data, - and 2) a "clearAlarm" method which cleans an alarm and removes it from the database. It should be clear that all alarms detected by the network are based on events and are discovered by the SNMP network management tool. The alarms defined by the user include alarms of "ad hoc thresholds" which are generated in instances when a value defined by the client in a customized report is exceeded. Alarms are generated while the reports are updated, based on the scrutiny frequency, and only when the threshold defined by the client is exceeded. The alarms defined by the user additionally include SNMP alarms which are generated when there is an alarm condition defined by the client based on the SNMP service. Assuming that the order of entry for the user has been completed and the user is provisioned with a service level which includes SNMP functionality, the user has additional access to the SNMP functions of Get and Define. The Get and Define represents a paired functionality which is accessed when the user selects the Get / Define SNMP 1732 option from the main view of the broadband view of the Figure 34 (a). The selection of the option Get / Define the SNMP 1732 allows the presentation of a Get / Define SNMP BB 1731 screen, of which an example is shown in Figure 34 (g). From the screen of Figure 34 (g), the user is allowed to: Obtain the SNMP statistics and Define the SNMP name. In particular, the process flow to provide SNMP Get / Define capabilities starts with the invocation of an SNMP applet which is sent to the client workstation through the BB server application. Selecting the Get / Define button of SNMP 1732 (Figure 34 (a)) of the main display causes the creation of an SNMPGetSetAPP (COApp) object to handle the session and create a series of objects, SNMPGetSetFrame, SNMPGetSetVIew, SNMPGETSetModel and SNMPGetSetController to handle the presentation / interaction with the user. This also results in the presentation of a get / set display window (Figure 34 (g)) that has a dialog box 1731) that presents the user with the client, PVC or circuit that will be consulted. In particular, the SNMP client substitute invokes the following BBProxyServer methods to populate the dialog box with the PVC and circuit information: 1) a getSnmpCategories () method that communicates the request to obtain SNMP variables from the MIB; 2) a "getPVCList ()" method to return a list of PVC's clients, - and, 3) a "getCircuitList ()" method to return a list of client access circuits, that is, circuit identifiers. Preferably, the appropriate service is invoked with BBProxyServer, the broadband database is consulted and the results are returned to the client's pager for viewing. The user selects the desired SNMP category 1733), for example, client, PVC or access circuit to be consulted. For example, as shown in Figure 34 (g), the selection of the PVC statistics category 1733 will allow the list box of variables 1735 to be updated with a list of only those variables of the selected category. When a GET operation is desired for an SNMP variable, the user selects the particular SNMP variable, then the user invokes the select operation, marking the GET button 1738 of the Get / Define screen of Figure 34 (g). Selecting the GET button causes the SNMP client 5 substitute to invoke the BBProxyServer method on the "getAtribute" side, which returns the <String> object (string), this string being an SNMP attribute name to the client's pager. "getAttribute", the request is submitted to the server BB and communicated to the MIB to obtain the SNMP attributes, for example, circuit and PVC statistics The MIB obtains the latest SNMP data, transfers the data to the server BB and returns the control to the client BB which handles the visualization of the data to the client (Figure 34 (g).) Particularly, the server BB in turn issues a 5 GetService request to the MIB over the appropriate switch (s). MIB locates the latest status information scrutinized and returns the data to the server, which passes the data back to the client with a GetService response message. With the reception of the data, the client closes the string and updates the display. Finally, the user can submit the requests for the SNMP variables of other circuits, or he can end the session. Also, when the user wants to define the name of a circuit, it first selects the particular SNMP 5 variable and then captures the value of the variable "alias" ^ for the selected SNMP circuit. This variable value "alias" is captured in the input field "value" (1773 as shown in Figure 34 (g).) Then, the user invokes the define operation by selecting the SET button 1739 of the Get / Define display. Figure 34 (g) The selection of the SET button causes the SNMP client substitute to invoke the BBProxyServer method on the "setAttribute" side, which updates the selected SNMP variable in the broadband database sets. setAttribute ", the request is sent to the server BB which issues a setServiceO request to the MIB about the appropriate switch (s). The MIB modifies the (user-defined) alias assigned to the circuit and returns an acknowledgment to the server, which passes it to the client with a setService response message. With the reception of the data, the client closes the rope and updates the update, recognizing that the name of the circuit has been modified. Finally, the user can submit new requests to define SNMP variables from other circuits, or he can end the session. The nMCI Interact suite of network management applications includes an event monitoring tool 1000 to enable clients to monitor, over the Internet or an intranet company, their dedicated voice and data circuits. A user-friendly and network-based interface presents network alarms on degraded or broken circuits and provides alarm information and network performance, effectively increasing efficiency in troubleshooting and allowing customers to take network administration decisions being 5 informed. It should be clear that the event monitoring tool can be integrated with the broadband network reporting service to provide a comprehensive alarm monitoring system and voice and data network performance reports. 10 More specifically, the monitoring tool for - > Events 1000 of the nMCI interaction system gives customers the ability to: exercise alarm management from a single workstation, this administration includes triggering alarms and clearing events, - recognizing new alarm conditions when these occur, receive notification of fiber losses that impact their data circuits, - define or display custom error correction procedures for specific circuits or alarms; To access a comprehensive database of their circuits dedicated data and voice, - display or print lists of active alarms; define or display custom alarm filters to specify which alarms will appear in the alarm presentation; and generate reports on the performance of the network. A general diagram of 25 blocks illustrating the architecture of the event monitoring system 1000 is shown in Figure 36. Generally, as shown in Figure 46, the event monitoring system 1000 is integrated into the nMCI interaction system comprising : the user's network pager 14 that employs a GUI 1030 event monitor that allows the generation of requests and responses receptions from different server processes of 1050 event monitoring systems over the network / internet through a secure connection socket the presentation of reports and alarms of the monitor of events, - a reviewer of reports 215 and processes of request 212 (Figure 10) of the tool StarWRS 200 which provides the support for the generation and presentation of reports related to the conditions of the network of voice and customer data as described here; a lateral reporting component of the corresponding server that has the input box described above, report scheduler and report management components, as well as report and alarm reviewers and application components that implement Java applets that have reviewer classes that allow Downloading and viewing performance reports generated from 1050 event monitor server processes. In the preferred mode, the reviewer classes provide the following types of network alarms on dedicated circuits that carry the following types of service: services within limits, for example 900 numbers and free calls, - outbound services, for example Vnet / Vision and PRISM; and data services TDS 1.5. The types of circuits for which the present invention presents network alarms include: dedicated access lines such as DALs; TDS 1.5 circuits; ISDN DALs; and DALs SW 56. In addition, the report characteristics of the event monitor allows customers to review alarm data over a period of time by creating and recording reports. The reports that can be generated include the alarm summary, alarm detail, alarm duration, data circuit performance and DAL performance. The performance and alarm reporting scheme effectively allows customers to carry out alarm analysis and trends, and correlate the occurrence of alarms to the availability of the network, solve network performance problems. Fault reports may be required through the requisite report component of the StarWRS, and obtained from the StarWRS input box. Recurring reports can be requested on a temporary basis, for example, every hour, every day, every week and every month. Moreover, through the reqisitor of reports, the user can specify if the user should send a page or email when a report is in the entry box. Also, shown as part of the architecture of the event monitoring system 1000 of Figure 36, is the server / dispatcher component of the 1035 network which provides transport between the network pager and an interface representative of the event monitoring that includes all authentication and encryption with cryptic language. A) Yes, in this way a secure communication is enabled from the client's pager to the DMZ network server over a first TCP / IP connection socket, such as SSL, and the communication of the DMZ network server over a company protection wall towards the dispatcher server is enabled by a second TCP / IP connection socket. These secure paths allow client requests and server responses to be communicated from the client's pager to the 1050 event monitor server. Specifically, the dispatcher sends user requests to the 1050 event monitor server process that employs an application integrated representative 1040 to receive and interpret user messages and enable event monitor functionality. This representation capability includes a multi-arm machinery that allows the simultaneous and multiple execution of sessions that support an anticipated user load. The interface between the dispatcher server 1035 and the representative process of the event monitor 1040 is also based on messages, for example, using a TCP / IP transport by satellite, and, as will be described, a defined message protocol which includes a header of generic message followed by specific representation data. In the other direction, the same process is used, that is, the event monitor representative 1040 sends the generic header followed by the response of the specific representative back to the dispatcher server 1035 for communication with the protection wall (not shown) and again back to the user's page 20. In the mode shown in Figure 36, the required CSV data files and the metadata files of the report definition can be downloaded to 1 message server from the StarWRS input box. 270 for its eventual presentation to the lateral pagers components of StarWRS 212, 215 for subsequent access. However, it should be clear that all the responses of the event monitor including the CSV data files and the metadata files of the report definition are sent through the dispatcher and the DMZ network servers that intervene for their eventual visualization. the client. Additionally, the event monitor can return a variable length report object which includes the report data that will be displayed at the client's workstation. In a preferred embodiment, the event monitor server 1050 performs the various database queries and function calls in response to the requests received from the client by the representative of the event monitor 1040. Particularly, the monitor server 1050 events is responsible for all the work that leads to and includes the management of performance and alarm reports, as well as data collection, 5 calculation, storage and report generation. In operation, the 1050 event monitor server supports communication with the StarOE server component 39 which provides command entry functions that include the functionality required to manage (create, update, delete) the event monitor users, and allows feeding the appropriate input information of commands to the event monitor server in order to properly associate the appropriate functionality of the event and data monitor to the client correct one time provided admission to the event monitor service. Thus, an inferióase of messages enters the StarOE 39 to the 1050 event monitor server operating as a client to receive the authentication information including the user's greeting identifiers which are supplied in response to the launch of the GUI applet of event monitor 1030. Billing identifiers and service levels, including specific rights information are provided by StarOE 39 to the 1050 event monitor server using flat files that can be be generated daily.

From the host of the back end legacy the 1050 event monitor server receives statistics of voice services (DAL) and data (TDS 1.5) to provide its functionality to the users of the event monitor. The DALs are groups of dedicated 64K circuits that transmit the voice traffic to and from the customer's terminal equipment, that is, PBX, to a switch of the telecommunications service provider. A TDS 1.5 data circuit is a dedicated point-to-point circuit that spans from one client location directly to another. The data circuit includes at least two monitoring units, called Supermarco Extended Monitoring Units (ESFMUs or ESF cards), which generate alarms and collect statistics on circuit performance. The alarms are presented almost in real time and indicate that there is a fault associated with the data circuit. Performance statistics are compiled in 15-minute intervals and are used to derive performance alarms that provide users with an indication that the performance of their network has degraded before the problem impacts the service. The performance statistics are compared against predefined performance parameters and deviations from these parameters are recorded. When a given threshold is exceeded, the alarms are generated and the notification is sent to the clients in such a way that they can then see the alarms and carry out the necessary steps to correct the problem. The performance parameters and thresholds can be modified by the GUI applet of the 1030 event monitor for those clients that have adequate access levels and rights as verified by StarOE 39. Each of the components shown in Figure 36 and their respective processes will be described in more detail here.

Client application GUI event monitor All alarms and reports for the event monitor are accessible via the alarm and report structure "networkMCI Interact" established within the home page of 5 nMCI Interact 79. The event monitor alarms are via an alarm monitoring system in which both broadband and event monitor alarms can appear. The event monitor GUI client application is launched via the event monitor icon 87 on the home page (Figure 5 (a)).

Reports for lack of report can be requested through A- of the StarWRS report requesting component, and the input box server. In the preferred mode, the 1030 event monitor GUI client application is launched by selecting the icon of event monitor 87 from the homepage "networkMCI Interact" (Figure 5 (a)). The event monitor GUI client application provides a menu bar, a toolbar, and a status bar to access event monitor services depending on customer service subscriptions. The availability of monitor service is determined by the user greeting session with the StarOE 1060 server. If the user does not have rights or does not have authorization for a particular service, the corresponding toolbar icon or menu item is disabled. In this way, according to the customer service option, the corresponding service icon and / or menu item is not activated and will not respond to a user input. To provide its basic services, the event monitor deployment applet may be responsible for: 1) requesting reports that are no longer in the input box server to be retrieved from the report data file if a predetermined time period, for example, 45 days, and provide these reports to the customer via the input box; 2) define alarm thresholds and parameters and problem detection procedures; 3) define how the customer reports should be requested, for example, identification of reports, date, etc., - 4) provide context-sensitive help online for all aspects of the network-based application of the event monitor; 5) provide the ability to produce windows of separate dialogues, for example, to explain the activity of reports in progress, -and 6) provide access to the client's reporting capability via the toolbar and menu. In the preferred embodiment, the GUI application of the event monitor is implemented in Java to ensure platform independence and is particularly developed using many of the common objects of networkMCI Interact as described herein. In particular, the GUI event monitor application, via the COApp object, can create its own deployment space and present its user interface in a separate frame having the space in one or more advantages of COAppFrame. The COAppFrame class and its COStdAppFrame subclass are wrappers for the Java structure class that provide COApps with standard elements to see and feel and implement some standard behavior, such as participating in the window management functions of the COBackPlane. The COAppFrame is a desktop computer window, separate from the search engine. It presents the user with the default project of a menu, toolbar, status bar, company logo, an application icon, etc., and a main display area. Since a separate structure does not need to be located within a network page, concurrent access (side by side) to more than one networkMCI Interact application service is possible. In another mode, the start code of the event monitor GUI application can be implemented using the COApplet class. To determine the user's event monitor service options, the GUI client application requests and retrieves user profiles including user rights from an event monitor client database populated by a periodic feed (for example, daily ) from StarOE 39 (Figure 36). From the event monitor GUI client application, an alarm management object is also launched after the initialization of the GUI client application. The alarm management object essentially creates a blank user interface and initiates a chord to handle communications with the event monitor server for events or alarms. The alarm chord is created to run periodically, for example, every two minutes. Specifically, the alarm chord invokes COAsynchronousTransaction with the network server to poll current event monitor alarms. When the alarm chord receives the data again from the network server it creates a command to update the deployment and executes the command. Event monitor alarms are generally grouped into two categories: voice alarms and data circuit alarms, including broadband and SNMP alarms. The voice alarms are further divided into two types: service exit alarm that are generated when a percentage of circuit in the trunk group are not available for complete calls, - and traffic alarms that are generated when a percentage of DALs reach a predefined blocking percentage, terminating the failure rates and originating speeds of height. Traffic alarms are based on accumulated data for 5 or 30 minute intervals. Data alarms are divided into two types: alarms that affect the service that are generated in instances where the service can not be used because there is a signal loss, frameless signal or equipment failure, - and alarms that affect performance that are generated when high error rates are received for ten seconds or more, there are out of frame conditions or frame slips exist but the service is still available. A view that runs down representing each alarm to the individual circuit is available via the GUI as will be described later.

Reporting functionality As described above, existing and new event monitor reports can be requested via the report requestor, a component of StarWRS. The reports are announced in the entry box. Customers see the reports by launching the report observer applet, another component of StarWRS. As soon as the report is made available, in the preference and selection of the client based on priorities and serenity, the clients can receive notification through one or any combination of pages, email, or fax in addition to the deployment option of the notification of the customer's entry box. For example, a customer can choose to receive notification on page and in email on all severity alarms 1 and only display notifications in the entry box for level 2 severity alarms, and so on. Recurring reports can also be created by the user to run on a per-time basis, for example, per hour, daily, per week, and monthly, as well as ad hoc reports (at one time). For example, a client may have a standard DAL performance report provided daily, and on a particular day, the same client may choose to submit an ad hoc DAL performance report for some given interval, ie, previous time, several hours before or days. In addition, the event monitor can provide the ability to scroll down within the equipment of the client's facilities to see an interruption of the client equipment and monitor performance capability and reporting alarms on individual channels within each circuit. Giving clients the ability to create and save a variety of reports and graphical views allows them to perform custom trends and analyzes to maintain better control and problem-solving schemes during their network management process. Furthermore, the event monitor presents via the report observer applet, the map of the Continental United States (the world for client / global services) for purposes of displaying the configuration of a customer network. The client can see their sites, the different connections between any two or more of these sites, and information about each specific site and circuit. Topographic mapping allows customers to see a logical representation of their network. The ability to navigate individual sites, nodes and circuits is also available via the observer applet. For example, if a client has a circuit between New York and Los Angeles, the highest level of the map shown can be the two places at either end as well as the circuit between them. If a customer oppresses on the same circuit, raw data related to the current production of that circuit or any alarm condition that exists in the circuit can be displayed. Additionally, if the customer oppresses either of the two locations, another logical design project presentation of the customer's facilities equipment, such as a DSU or CSU, can be enabled. In addition, if the alarms are present for that particular site, the downward view can represent each alarm to the individual circuit in a T-l of 24 channels. Another type of reporting service provided by the event monitor is called a busy interval rebound report of integrated management services. This report provides an image of a DAL group during the busiest hour of the day reporting statistics for the current or the 7 days prior to the busiest interval. The busiest interval is defined as 30 minutes or 60 minutes in which total usage was at the highest point. Other reports that can be obtained through the event monitor include: monitoring and reporting the performance of individual DS3 and OC3 circuits, IDNS channels, private point-to-point lines of voice or international data, El line, and trunk utilization reports.

Alarm functionality The event monitor presents all the alarms detected to the client automatically, without the intervention of the client. The alarms detected within the event monitor are sent to the customer's entry box for deployment on the online review worksheet. All current alarms are retrieved by the client's network browser GUI applet using counting techniques at the beginning of the session. Clients can define a period of time during which their alarms remain at their current status, allowing non-current alarms to be cleared. In addition to providing alarm notifications to clients, the event monitor can also provide a scheme in which a predefined problem detection procedure, which can be modified by a client, is automatically launched when an alarm is detected. For example, if an alarm is generated related to a fiber output that impacts the customer's free call circuit, an option allows the user to go directly from the alarm message in the appropriate alternate routing plan entry box. In order to integrate two services, that is, the event monitor with the free network administrator (TFNM), the key data of the event and alarm monitor are communicated to allow the free network administrator to find the appropriate routing plan associated with the interruption of the service. Key data may include: toll-free number, service identification, circuit identification, and type of service, for example, free or broadband. The free network administration application is typically launched directly from an alarm viewer with the above parameters to find the associated routing plan. The user profile information is needed by the free network administrator for authentication and rights verification before actually proceeding with the alternative routing plan, they are also passed as parameters to the free network administration application at the same time.

Performance metrics The event monitor follows and confirms the general "networkMCI Interact" reporting standards in order to provide a consistent and common interface with customers. Weekly reports do not have to be a calendar week and can cover any group of 7 consecutive days. The monthly reports are, unlike the weekly reports, based on the calendar and are defined covering the entire month. Ad hoc reports are reports outside the structure of pre-selected reports and are available to clients within two minutes from the point of request by clients. In a preferred embodiment, the event monitor alarms are distinguished into two types: event-based alarms, and statistical alarms. Event-based alarms are alarms generated in the physical connection between the CSU / DSU client circuits and the telecommunications service provider's switches, for example, alarms that occur due to a loss or loss of a circuit. In addition, the customer can specify this notification to be sent as a page, fax, or email. In these cases, the notification is sent within the 30-second window required from the moment the alarm is detected by the event monitor. The statistical alarms are alarms generated due to the percentage of lost time or other statistical nature. The statistical alarms depend on the frequency at which the client's web browser is scrutinized, for example, intervals of 2-4 minutes. As soon as the count is established and an alarm is detected, the alarm delivery time notification is similar to event-based alarms, that is, within 30 seconds.

The back end configuration of the event monitor Figure 37 illustrates an example of a back end configuration 1002 for the fault management system for reporting telecommunication service conditions. The back end configuration includes a network management system 1004 that collects network events, including alarms and traffic densities from a common carrier network 1006. All events collected by the network management system 1004 are reported to a central monitor computer of event 1008.

The common carrier tracks the performance and failures of the network for the network 1006 through a myriad of network management systems 1004 and routes the information in real time to the central computer of the event monitor 1008. With the In order to provide information regarding rented services from a particular client, the events collected by the central computer of the event monitor 1008 are copied to the event monitor server 1050. The event monitor server 1050 accumulates in near real time a database of events related to each customer's rented service. The accumulated data are observable via the client search application GUI and also via the StarWRS reporting system as described above. Because individual clients can subscribe to different services that may experience different events, the 1050 event monitor server must not only collect different sets of data in real time, but also the client search application GUI and the reporting system as well. must present the data in a format relevant to the particular services to which the client subscribes. This data can be organized for deployment to the user in an event queue. In the preferred embodiment of the present invention, the event monitor 1008 central computer is a centralized integrated network management system (INMS) central computer implemented as an IBM S / 370 main computer and the 1050 event monitor server is implemented such as DEC Alpha and Sun Solaris; the architecture of this embodiment is depicted in Figure 38. The present invention can be implemented in other ways, as would be apparent to those skilled in the related art. Referring to Figure 38, the INMS 1008 central computer operates in an ibm client information control system (CICS) environment with a transport protocol / Internet protocol (TCP / IP) in connection with the server of event monitor DEC Alpha 1050, which operates under the DEC UNIX operation system. The server 1050 comprises two servers: a structure query language (SQL) 1016 and an open server 1018. The open server 1018 receives events from the central computer of the INMS 1008 and stores them in a database 1010 stored in the database. server 1050. The SQL server 1016 is a database machine that provides access to and manages the database 1010. In the preferred embodiment, the database 410 is a database Sybase® and the SQL 406 server is a SQL Sybase® server. The 1010 database compiles information that is sent regularly by the central computer of INMS 1008.

The data stored in the SQL server can be consulted as desired by a user via the client search application for analysis. The database 1010 is a relationship database that uses the SQL server 1016 as the database management system (DBMS). In the preferred embodiment, the database 1010 comprises a database having four partitions. Database 1010 includes several data tables that are accessed through the client browser application GUI to event displays, including alarm deployments, alarm report, facility cross-references and event log displays. In addition to the verification of authentication and StarOE rights, the user's access to the database 1010 is monitored by the SQL server 1016; security levels can be provided to allow stages of access to different levels of information within the database 1010, as would be apparent to one skilled in the related art. The data within the 1010 database is organized into views. For example, an alarm view provides an alarm description, an alarm severity that represents the degree of consequence for the alarm, and selected conditions associated with the alarm. The interface between the INMS 1008 central computer and the 1050 server is two-way. In this scenario, the INMS 1008 central computer is a client, which issues calls for stored procedures on the SQL Server 1016 via TCP / IP when there is an event to report. When a new client is provided, the event monitor server 1050 makes a client call to the session of the central computer INMS and updates the user profile table in the central computer INMS. Figure 39 is a high-level logic flow diagram representing the operation of the preferred embodiment of the present invention. Typically, a customer subscribes to several private rented services. In order to limit the collection of data to the data related to those particular services, the user must specify the data that will be collected. The user does this by defining an event view of data to be collected, as shown in step 1020. The event view specifies, for example, which services will be monitored and which data will be collected and reported for those services. For example, the event view can include the following points: severity: critical, major, minor, information, without alert, - server types (MCI): 800, 900, TDS 1.5, TDS 45, VNET, Prism®, Vision®, ISDN, SW56, and DDS / DDO; corporation identifiers: a list of corporation identifiers related to the client's company and for which the user has authorized access; installations: all the elements of a physical telephone plant required to provide a service and to which the user has authorized access (for example, trunk groups and circuits); data elements: the user can configure a customized event view by selecting the data fields to be displayed; date and time elements: the user can configure a customized event view by selecting the date and time period for the client event view; sorting order: the user can configure a customized event view by selecting, for example, the data fields in which the data to be displayed is classified. As soon as the event view has been defined, the client browser application transmits a transaction request to the server 1050 and to the network server / dispatcher. A predefined stored procedure, which takes as input a "where" clause and a "requested by" clause, is used to create the event view from the data stored in the database 1010. In the preferred embodiment, the SQL statement is constructed so that each element / field is joined by a "Y" and values within each element / field are joined by an "O". In this way, a partial SQL statement could be similar to: severity = critical OR severity = greater AND service type = VNET AND CORPID = 123434 OR CORPID = 32432423 And ... etc. The SQL statement created in step 1023 is sent B to the SQL server 1016. The SQL statement identifies the SQL Server 1016 the particular stored procedure that is to be stored to obtain the event view specified by the SQL statement. The SQL server 1016 then executes the stored procedure and constructs a report of event data specified by the view of event, as shown in step 1028. As soon as the event report is built, it is sent to the client browser via the network servers / dispatcher. Events are typically loaded into an event queue, which is an existing pass-through mechanism between the INMS host computer and the Sybase database. The events in the event queue are classified by classification criteria entered by the user when defining the event view, as shown in step 1032. In a preferred embodiment, the criterion of P main classification is severity. The events classifieds are displayed to the user in a client search application GUI in a step 1034. Each displayed event is accompanied by a recognition field for the user to indicate his recognition of the event, - for example, the user can recognize an event , nap authorized by entering an asterisk in the associated recognition field. When the user recognizes an event, as indicated by the "Y" branch of step 1036, the client browser application reports the acknowledgment to server 1050, as shown in step 1038. When the user has acknowledged the last event in the event queue, as indicated by the "Y" branch of step 1040, the event processing ends. At this point, the user can retain the session or close it. If the session remains open, the server 1050 will report new events defined by the event view as they are received by the server 1050. When the server 1050 receives a new event, as indicated by the "Y" branch of the step 1042, the processing is resumed in step 1028, as shown in Figure 39. In this way, according to the event view defined by the user and communicated to the event monitor server 1050, reports of events identified in the event view, based on a configurable interval by the client, to a client browser application, and made available in an event queue for deployment to the user in order to severity of the event.

Event monitor representative In the event monitor representative process for validation, translation, and communication of client requests to the successful back end system, the validation includes incoming parsing requests, analyzing them, and confirming that they include messages formatted validly for the service with acceptable parameters. If necessary, the message is translated into an underlying network protocol message. If no errors are found in the message, the representative manages the communication with the mid-level server to actually obtain the requested service. The application supports specific translation of the application and communication with the back end application server for both network server messages (originating java applet) and application server messages. The representative functions and services provided include enabling multi-cord representative functionality so that representatives can serve multiple clients simultaneously. In general, the servers of the event monitor representative (Figure 36 in 1040) 1) invoke received methods when their corresponding client side substitute method is invoked by the search engine 1030 and, - 2) return responses for the side substitute method of the requesting client, if required.

In particular, the 1040 event monitor server representative is a process with multiple interfaces to the event monitor network server database and GUI 1030, each interface provides method tunings for a series of discrete services via specific Java methods. These interface combinations (method includes: 1) HSAlarmServerlnterface that provides SNMP alarm functionality via (the) getAlarmList method, - (lb) recordAlarm method, -y (lc) clearAlarm method. 2) HSMapServerlnterface that provides graphical configuration mapping functionality via (2a) getSwitchLocations method, - (2b) getAccessCircuits method, -y (2c) getPVCList method; 3) HSReportServerlnterface that provides representative management and supply functionality via (3a) getReport method; (3b) getReportList method, - (3c) getlnboxReports method, - and (3d) method setReportGeneration, - 4) HSServerlnterface that provides access functionality to the broadband network server via (4a) logon method; 5) HSSnmpServerlnterface that provides SNMP functionality get / set via (5a) getSnmpCategories method, - (5b) getPVCList method; (5c) method getCircuitList, - (5d) method setAttribute; and (5e) getAttribute method, - 6) HSUtilityServerlnterface that provides the interface for all other search engine functionalities (6a) method getLevelOfService; (6b) getHelpDeskNumber method; (6c) getCircuitLocation method; (6d) method setCircuitLocation; (6e) getServiceType method; and (6f) getMessageCenterText method; 7) HSEMReportServerlnterface that provides an interface to the features available in the event monitor database via (7a) method changeReportName, - (7b) method createReport, - (7c) method deleteReport; (7d) getAlarms method, - (7e) getAlarmTypes method; (7f) method getCorpIDList, - (7g) method getDALGroups, - (7h) method getDataCircuits; (7i) getFacilities method, - (7j) getReport method; (7k) method getReportCategories, - (71) method getReportList, - (7m) method getServiceTypes, - (7n) method getVoiceCircuits; and (7th) updateReport method. Each side server method 1) performs a specific back end function. You can also, 2) return an object, or basic type (int, float, etc.) to the lateral substitute client invoker. Most methods generally perform back end database updates, encoded by values as will be documented later. Object return methods return either 1) a single object made of chain values as documented below or 2) vector objects, including lists. Vector objects are variable byte streams and essentially are objects that are containers of a group of related objects. All side server methods have the ability to throw error exceptions, instead of generated return codes.

CALL MANAGER Another application of the telecommunications network management application suite is the call management system ("CM") that provides sophisticated mechanisms, for example, intelligent call routing, for call center customers to control call supply. free calls from the company network of telecommunications to call centers, including ^ P call centers that have multiple automatic call distributors (ACD). Particularly, using a call manager system the client has the ability to define routing rules which, on a call basis call, determines the best place to route the incoming free calls. A high-level overview of the 1100 call manager system environment is illustrated in Figure 40. The 1100 k \ call manager system generally includes a service control point (SCP) 1110 to provide call management routing features, known as "call-by-call" routing (CXC), - an intelligent routing client (ICE) element (not shown); a central intelligent routing computer (IR host computer) 1112; and client work stations, is say, the call management network station of the 1130 client, and / or the workstation of the Nexus 1126 client. The SCP 1110 is a routing machine that essentially maintains the call routing rules and uses those rules to determine where to route the calls. A typical call processing flow for a call received from a caller 1122 includes routing requests and responses from the switches of company 1124 through the aforementioned data access points (DAPs) 616 and remote data ports (RDGs) 1118 in and out of SCP 1110. DAP 16 executes a routing plan by translating a toll-free number passed through switch 1124 to a network number, and maps it to an address. The RDG 1118 provides a standard gate that allows communications between the SCP 1110 central computer and the company's central structure network. The translated network number is then communicated to the central computer SCP 1110 via RDG 1118. Data collection and storage of ACD-based statistics from the customer call centers and network statistics are supported by statistics Traffic DAP (DTS) 1114, IR 1112 central computer and ICE components. The DTS collects network routing statistics from DAP 2906 and passes them to the central computer IR 1112. The IR 1112 central computer stores the routing statistics from DTS 1114 and ACD 1120. ACD data statistics 1120 are collected by the ICE for each ACD 1120, normalized by the IR 1112 central computer and provided to SCP 1110. When the SCP 1110 receives a routing request, the SCP 1110 typically determines the best place to route a call by modeling each call center using data from the automatic call distributor (ACD) to keep the model in line with the ones that are currently taking place in each place. After completing the call processing according to the client routing plan, the DAP 2906 passes routing instructions to the switch 1124 to establish the call to a client ACD 1120. The ACD 1120 balances the call load based on defined rules by the customer such as the "occupation" of a call center. Calls can be distributed evenly using a "request" technique, or direct which calls are routed based on a percentage assigned to each destination identifier. The voice communications are carried out from the switch 1124 to the ACD 1120 terminating the call in the appropriate trunk of the destination identifier. The routing capabilities supported by SCP 1110 include a termination selection based on one or more of the following: initial list of eligible destinations, destinations removed from considerations based on proven conditions, artificially biased pricing criteria, percentage allocation, and manipulation of counter variables predefined by user. SCP 1110 also supports the routing and blocking of incoming calls using event-level ^ m data, based on one or more of the following characteristics: the week, day of the year, choice of destinations, time of day, membership of the automatic number identification (ANI) or digits entered by the caller (CED) in a defined list of values, load balance and / or availability in specific destinations, quota schemes 10 defined by user, key counters defined by user, preference of destination choices, and artificial bias of load balancing algorithms. The call manager integrated data server (s) (CMIDS) 1140 is included for provide front end functionality to the SCP 1110 central computer and download several processing-related workstations from the routing machine. In addition, CMIDS 1140 can access p directly to data stored in the IR host or on other data servers. Other details about the CMIDS 1140 will be described with reference to Figures 41 and 45. As shown in Figure 2, the call manager system of the nMCI interaction system further includes one or more 1132 network servers for provide searcher-based client connections from the World Wide Web (WWW or Web). The network server manager 1132 passes the client connections through the central computer SCP 1110 via the CMIDS 1140, and thus supplies the call manager functionality to the network station of the 1030 call manager client via a search engine of standard network and the Internet. The network server 24 is addressed by the clients using the public Internet by directing a network browser 20 running on a call manager network station to the point of a uniform call manager (URL) resource locator. The call manager workstation 1130 can be any hardware / software platform connected to the public Internet and running a supported network browser. The network station call manager 1120 typically belongs to and is maintained by the customer. The call manager network station 1130 includes a network-based graphical user interface (GUI) application that enables clients to define their call terminations, and the provision of routing rules and associated tabular data to control routing through central computer SCP 1110. The GUI application also presents alarms and almost real-time graphical displays of key accounts and statistics based on ACD. The application also provides reports and extracts of historical data, including call detail records (CDR), ACD-based statistics, and key accounts. In addition, user identification management functions that include business hierarchy structures and role profiles can be carried out via the network-based GUI application of the call manager's network stations. In addition, the workstation of the Nexus 1126 client is included as an alternative client for the central computer SCP 1110. The presence of the call manager network station 1130 does not prevent the use of the Nexus 1126 client workstations. Nexus 1126 client workstation typically runs a graphical user interface application to enable the client to define their call terminations, routing rules and to display the ACD and routing information either in tabular or graphical form. The client workstation Nexus 1126 connects directly to the central SCP computer 1110 typically via circuits dedicated to customer premises or through the company's central structure networks for company locations.

Call manager network station architecture Figure 41 illustrates the call manager network station component architecture that shows interconnections between the components. In a preferred embodiment, the call station network station system includes three components of the call manager platform: client desktop computer systems, or a workstation, hereinafter also referred to as the 1130 client network stations for provide call management functions through a standard network browser, - a 1132 network server to support secure access for the Internet or Extranet / Intranet-based clients to the back end of the call manager and thus to the SCP host computers; and integrated call manager to the data server (CMIDS) 1140, which forms an integral part of the back end call manager application and which supports access to the SCP central computer systems. As shown in Figure 41, 1130 client desktop computer systems with Internet connectivity have standard browsers running Java applets, ie, a client GUI application, copied from this the 1132 call manager network server. The network server 1132 that is located in the demilitarized zone described above (DMZ) 17 of the MCI Interact network system includes Java class files, but not client data storage to ensure data security. The DMZ is generally bounded by two protection walls: an Internet protection wall 25 (a) and an Intranet protection wall 25 (b). The integrated call manager data server (CMIDS) generally manages the 5 businesses and the data logic associated with call manager functionality. Each of the above components will now be described in detail with reference to additional figures. As described above, the network station of the 1130 client provides a graphical user interface ^ Network-based P (GUI) that offers data management and data presentation features for the call manager system. The front-end, network-based GUI is typically written using the programming language Java to ensure platform independence. The client network station 1130 typically includes a network browser with Java applets for the interface to provide access to the network station application.

(B from a standard network browser, for example, Internet Explorer V4.01. In addition, common networkMCI Interact objects are used to implement many functions needed by the client / server communication protocols. Java applets generally reside on network servers 1132 and are dynamically copied to search engines (network stations) client) 1130 when the Uniform Resource Locator (URL) for the call manager's network station client GUI application is addressed. The call manager network station client GUI application of the system of the present invention is typically invoked by pressing a "call manager" icon 97 from the home page of networkMCI Interact 79b (Figure 5 (b)). The client is presented with a toolbar to launch each of the call manager's network station application features as shown in Figure 49 at 11880. Furthermore, online help is provided via documents in markup language Hypertext (HTML) residing on network servers 1132. Each call station network station application feature can be addressed through an icon button on a 11880 toolbar as shown in Figure 49. More Still, each feature is brought to a separate window frame, giving a consistent view and feel throughout the network environment. As shown in the exemplary deployment of Figure 49, the main features offered include: user installation and administration, that is, 11882 security functions, business hierarchy installation, call-by-call application for written rules and provisioning in 11874, 1884, - display of graphic data in 1878; alarm administrator in 1872; and report and data excerpts in 1876. A detailed description of each feature will be provided with reference to Figure 48 below. To provide the above features, the client browser includes class objects forming the client interface code, in a first embodiment shown in Figure 42. Specifically, user interface classes 1134 represent the main GUI objects for performing a functionality specific call manager. Each of the classes, that is, installation of user and business hierarchy, call-by-call application, graphical data display, alarm manager, report extracts, and authentication / rights, performs the corresponding functionality on the associated client side with the features of the call manager provided. The classes of the network server 638 provide the communication step through the back end server. The class of communications (not shown) are used between the client finder 1130 and the network server 1132 to request transactions and / or data sets from the network server 1132. In the first mode, the communications from the client 20 and the rear end CMIDS 1140 (Figure 41) via the network server 1132 are carried out using the common gate interface (CGI). Customer requests are typically directed to a CGI program first, which then places the request in the appropriate representative process. The results are returned from the back end processes to the requesting client in the same way. Each transaction or data request can be executed as a separate process, to allow processing to continue from other applications within the call manager's network station system. In a preferred embodiment, a Netscape server application program interface module (NSAPI) can be used as an alternative to the CGI layer, the NSAPI module replaces the CGI protocol communication layer between the client 20 and the server network 1132. The network server 1132 can be configured to pick up the NSAPI module and load it into installation. The Java client code 1134 (Figure 42) can be configured to refer to the NSAPI module. For example, the Java client can invoke a method to communicate directly with the NSAPI module that performs the same function as the CGI program. Using the NSAPI module increases performance and message production. When the server 1132 recognizes requests from the NSAPI module, it invokes a particular function in the module that performs essentially the same function as the CGI program. For example, a mid-level transaction handler, typically a message handler (msgmgr) and resident with the 1132 network servers, can be modified to use the NSAPI instead of the HTTP CGI.The advantage of the NSAPI over the CGI is that it is not necessary to create a new process whenever a request comes from the network client 20. In general, and as described above, the network server 1132 provides a step through communication between the 1130 network client GUI application and the data server integrated with the back end call manager (CMIDS) 1140 which can communicate with the central computer SCP Figure 43 illustrates a software architecture mode showing communications between the client 20 and the server network 1132 and its components Network server 1132 provides network-based call manager applications to network clients that have a network browser at their work stations or client 20. The network server 1132 includes an HTTP service manager 1152 and a message manager 1156. The HTTP service manager 1152 generally handles multiple client requests 1130 to copy network pages and Java applets for deployment within of a search engine. Network pages include hypertext markup language (HTML) files and Java 654 applets that are copied to clients 20 and run inside a browser by Java applets. The HTTP Service Manager 1152 also handles the message transaction via the POST method defined by the Hypertext Transfer Protocol (HTTP). The HTTP service manager can be the standard World Wide Web server software for immediate tension, for example, Netscape Enterprise Server. The message manager 1156 is typically a CGI program that runs in a process produced within the HTTP Service Manager 1152 when a message transaction is received from the client via the POST method sent to the HTTPS (443) 1150 port. HTTP Service Manager 1152 produces a process to return a instance of message manager 1156 each time ^ P receives a message transaction from the client. Alternatively, message manager 1156 can be implemented as a function in the NSAPI module as described above. The HTTP service administrator 1152 then invokes the message function in the NSAPI module. Both the input and output streams are created by the message manager 1156 to receive message data from the client 20 and to return them back to the client p 20. The message manager 1156 is generally responsible for the following: 1) accept the introduction of a new user by assigning a new session key for a newly created session, - 2) join a dispatcher and a representative header to the client's network message and send the message to the representative server 1170; and receive a SCP host computer response message from the proxy server 1170 and resend this message with the dispatcher and the representative header and send this formatted message to the network client 20. The message transactions are sent to the proxy server 1170 on a new connection by opening a new TCP socket to the proxy server 1170 while the original search engine socket is blocking, waiting for a response from the network server 1132. Typically, communications to and from the client 20 are carried out on the data transfer protocol. secure hypertext, which uses a hypertext transfer protocol (HTTP) over a secure (SSL) channel layer encoded in cryptic language. Applications can include network pages in the form of hypertext markup language (HTML) such as Java 654 files and applets that are stored on network server 1132. HTTP Service Manager 1152 copies HTML files and Java 654 applets to the client 1130 upon request via the HTTPS port 1150, typically configured with port number 443. Each transaction from a client 20 is sent to the network server 1132 in the form of a logical message that has been encoded in cryptic language. The network server 1132 decodes the message and wraps the message with the user information, including environment variables in a session identifier generated by the server (id). The message is encoded in cryptic language and sent to CMID 1140, or alternatively, as will be described later, to the server component representative of CMID 1140. Message transactions created by client 20 can be transmitted over HTTPS using the method POST defined within the HTTP protocol. Using the POST method, a specific CGI program and more specifically, an invoked message manager runs as a chord in the HTTP service manager 1152. The message data is passed to the message manager 1156 by opening an input stream and a current of exit inside the rope. As described above, the HTTP service manager 1152 produces a message manager process 1156 for each message transaction sent to the network server 1132. Each message transaction is a single request from the client 20 that is completed by a single replica of the message. network server 1132. Network server 1132 also includes a session manager 1158 and a session table 25 (a) to provide session manager functions that include the authentication of multiple network requests. A session is defined as the amount of time between which a client 20 registers on the network server 1132 and when the client is dismissed. During a session, a client 20 may present several message transactions to the network server 1132. The status data of each session is stored in the session table 25 (a). The session entries are deleted from the session table 25 (a) when a user says goodbye or • when the session ages. Each message transaction 5 received by the network server 1132 is associated with an active session. If a session for a particular transaction no longer exists, the message transaction returns to client 20 as rejected. The application prompts the user to register again. 10 In general, session table 1160 is a table ^ which has status information of all current client sessions that are active on the network server 1132. When a client registers on the 1132 network server and is authenticated, the client is provided with an "identification of sessions "which is a unique key generated by the server, which is maintained by the client and returned to the server as part of subsequent message transactions. 1160 maintains a "session key table" that maps these keys to the associated session. The session table also includes a time stamp for each client session. A client session time stamp is updated each time a message transaction comprises the session identification for each session it receives. A session gets old if you do not see any message transaction that belongs to the session after a given amount of time. If so, the session, with its entry deleted from session table 1160, says goodbye to the central computer SCP 1110. Session manager 1158 is generally responsible for monitoring all current client sessions. The 1158 session manager typically monitors the sessions by accessing the 1160 session table and verifying the current times stamp values for each current session. If the time stamp value shows that a session has aged, the session entry for the aging session is deleted from session table 1160. Deleting the entry from the session forces any other message transaction associated with the session. session identifier is rejected, requiring the user to restart the session. For communications to and from the network client and the back end, the mid-level network server 1132 supports three types of transport mechanisms that are provided by the networkMCI Interact platform: synchronous, asynchronous, and volume transfer, as described herein. In particular, the synchronous transaction type has a single TCP connection that remains open until a full message replica has been retrieved. The asynchronous transaction type is typically used to handle message transactions that require a long delay in the back end server response. A server process that handles the message transaction responds again to the network client 20 immediately with a unique transaction identifier and then closes the connection. The network client 20 can then poll the network server 1132 using the transaction identifier to determine when the original message transaction has been completed. The volume transfer type of the transport mechanism is typically used for transferring large data that can be virtually unlimited in size. In the embodiment shown in Figure 43, the network server 1132 includes ability to communicate directly with the central SCP computer, bypassing the CMIDS 1140, making the proxy server reside physically on the network server. Figure 44 illustrates an example of a physical architecture of call manager network station application where one or more call manager network servers 1132 deviate from the CMIDS component of the present invention. As shown, the servers of the call manager network 1132 directly communicate the MML messages, ie translated client request, to the Nexus 1110 SCP host computer. In addition, in this mode, it is the central computer SCP 1110 that receives ACD statistics, alarms and other information from the central computer IR 1112, and communicates the information to the network servers 1132. The central computer SCP 1110 serves as the routing machine through from which the client provision routing rules and associated tables or lists, view alarms, key account routing, and so on. It hosts the applications used by the client to manipulate the characteristics of their automatic call distributor (ACD). Figure 44 also shows the network administrator call manager 20 being authenticated via the networkMCI Interact platform and the StarOE authentication and rights system 29 as described herein, ie the networkMCI Interact platform validates the password and authenticates with the StarOE 631 system, verifying that the customer profile allows access to the network station application and call manager. After valid authentication, the call manager network station application session may start with the customer's network station communicating with the call manager network servers 1132 to provide the various functionalities. In another embodiment, the data processing components for business and data logic, i.e., the proxy server and the database, reside with the CMIDS 1140, thereby reducing the functions of the 1132 network server to an application server. It mainly provides state administration and sessions. Carrying the representative server 1170 over the CMIDS 1140 can be done easily. The middle-level transaction manager, that is, message manager 1156 still passes messages between client 20 and CMIDS 1140. The only change needed is for the transaction handler to connect to the representative residing in CMIDS 1140 , as opposed to the representative 1170 on the network server 1132. The representative server 1170 generally processes message transactions from the client 20 and is connected with multi-rings to simultaneously handle multiple message transactions. The representative server 1170 is designed to process a type of message transaction or a set of message transactions. In this mode, the routing of messages to and from the representative is handled by the message manager 1156. The representative server 1170 also interacts with a database 1172, for example, Informix, to pass back information that is to be displayed by the client 20. The representative server opens a connection to the central computer SCP 1110 to retrieve information about routing plans or report statistics by sending SCP protocol commands "man-machine language" (MML). After recovery, the proxy server 1170 formats a reply message that is sent back to the network station of the client 1130 so that it is displayed on the current network page. As the reply of the message is sent back to the client 20, each chunk created by the representative server 1170 is completed. It should be noted that the proxy server 1170 does not need to reside on the network servers 1132. Instead, as will be described with reference to Figure 45, the proxy server 1170 may reside in the CMIDS 1140, the back end server component. . The database 1172 generally maintains information necessary to translate the messages to and from the central computer SCP 1110. A message translation program is written in 4GL accesses the database 1172 when a message transaction is received. The program translates the message and sends the message to the central computer SCP 1110 for processing. After the message has been processed, the program translates the response and sends it back to the message manager 1156. The proxy server 1170 typically invokes an instance of the translation program for each message transaction it receives and processes. As noted above with reference to the representative server, database 1172 can alternatively reside in the CMIDS with the representative server. In the first mode, a data server, that is, the CMIDS, is included. In this mode, many of the functions of the representative server are performed within the data server. More specifically, the representative server 1170 and the database 1172 can be carried over the CMIDS 1140. The network server 1172 communicates with the representative in the CMIDS 1140 which then communicates with the central computer SCP. The integrated call manager data server (CMIDS) 1140 generally handles network requests for the network station application and serves as the front end of the SCP 1110 central computer. Referring again to Figure 41, the CMIDS 1140, furthermore, provides data storage and administration for resident data in the central computer SCP 1110, the central computer IR 1112, and / or other servers. The CMIDS 1140 also provides pass-through connectivity for written rules and other provisions from the 1130 client network station to the SCP 1110 host computer. The CMIDS includes 1142a-c database and provides an 1162 interface to the central computer Call administrator SCP 1110 for administration of written rules and lists. The CMIDS database ll42a-c is extracted or replicated from the central computer SCP 1110 and / or the central computer IR 1112. The services of the central computer SCP 1110 are typically requested and satisfied through a protocol known as commands of "machine man language" (MML). The CMIDS 1140 uses human machine language as well as other interface mechanisms supported by the central computer SCP 1110. The integrated call manager data server (CMIDS) 1140 physically resides in hardware located behind the Intranet protection wall 25 (b) As shown, The representative server 1170 and the database 1172 which is described with reference to network server 1132, may reside in CMIDS 1140. In addition, CMIDS 140 may also include a session manager and associated session table to administer sessions of the central computer. As described above, the representative server 1170 usually handles customer requests from the station I re < 20 passes from the network servers 1132 accepting message transactions from the client of the network station 20 via the network servers 1132, maintains record information, sends the requests to a session manager, and receives data from the back end and sends it to the servers of the network 1132. In addition, the representative server 1170 can accept messages originating from the workstations of the Nexus client (1126 in Figure 40), and perform validation of salutations. user for the station work of the Nexus 1126 client. Nexus client transactions, with the exception of user salutations, pass directly to the central computer SCP 1110 for processing via a Nexus port manager (not shown). The session manager 1158, resident in CMIDS 1140, receives data from the proxy server 1170. The session manager 1158 updates the session table 1160, validates what the user is privileged to perform the task and determines whether the transaction originating from the network station 1130 or a Nexus client 1126. The user validation function can be performed from the customer's network station 20 as well, in addition to a validation carried out by the authentication system and rights of the networkMCI Interact StarOE during the session salutation. The CMIDS1 1440 can also include a Nexus host computer formatter, a CMIDS transaction manager, and a Nexus port manager. The session manager 658 typically passes a transaction request received from the network server 1132 either to the Nexus host computer formatter, or to the CMID transaction manager. The Nexus mainframe formatter modulates transaction services that require SCP core computer services to fulfill the request. If the transaction originated from the workstation of the Nexus client 1126, the command message in man-machine language is adjusted to use a generic identification selected to access the central computer SCP 1110. If the transaction originated from the network station of the client 20, the request is translated into the correct machine man language format. When the message is prepared, it is then sent to the central computer port manager component. The CMIDS transaction manager module handles transactions that do not require the SCP 1110 core computer, that is, the types of client requests that can be addressed directly in the CMIDS, including: obtaining NEMS alarm information, obtaining GDD information, and processing security of user. When the local processing is complete, the results are sent back to the representative server component 1170. The Nexus port manager component of the CMIDS handles session scrutinies with one or more SCP 1110 core computers. The Nexus port manager records each session in a deposit using a "generic" user identifier. Using a "generic" user identifier allows each section to be addressed with data from an individual user without having to register each user in the central computer SCP 1110. MML commands for a particular user are sent to a central SCP computer using a session available in the "generic" session repository. After a command is sent in machine language and a response is received, the session is returned to the session repository and freed for use by successive transactions. A session repository is defined as a set of sessions connected to a particular SCP central computer 1110. Therefore,, the Nexus port manager component of the CMIDS 1140 supports multiple session repositories to communicate with multiple SCP 1110 core computers. The Nexus port manager also maintains the status of each session on each deposit. The Nexus port manager generates a message to stay alive whenever a session rests to maintain the connection of the SCP 1110 central computer without being disconnected. If a session in a repository has failed, the Nexus port administrator will try to reset the session and add it back to the repository when the establishment is complete. The Nexus port manager determines the communication channel to be used to access the central computer SCP 1110 and maintains several open connections to the central computer 1110. Each message is sent to the central computer SCP 1110 and the channel is blocked until it is receive an answer Figure 45 is an example of a CMIDS 1140 conceptual model that provides details of the CMIDS software components. The components perform specific functions of the back end which will also be described with reference to Figure 46. The software architecture CMIDS includes the representative 1148, representative, systems administration, and input box components applicable to the application of the station. Call manager network (CMWS). The CMWS 1148 representative is generally a logical internal software entity that verifies application access and connects to central computer applications. Depending on the application access chosen by a client, either the networkMCI Interact dispatcher or the CMWS 1132 network server communicates the client's transactions to the CMWS representative 1148. The networkMCI Interact, as described herein, typically accepts the request from client encoded in cryptic language from the NetworkMCI Interact network server network bouquet and connects it with the CMWS representative. The user interface interface software component 1143 generally maintains sessions with the central SCP computer and provides the Nexus port manager functions described above. The report management process generally maintains the 1142a-c databases and provides reporting facilities. The CMIDS 1191 back end interface supports various interface mechanisms including human machine language and command line access to the Nexus SCP host computer, common alarm and logging services, and data recovery from the IR host. The back end of the call manager's network station As was generally described above, the back end is responsible for transmitting network client requests to the central computer SCP and supplying the central computer answering information back to the network clients. network. To support request / reply transmissions, the back end system of the present invention generally includes three logical components: front end interface (BFI), translation / data manager (TDM), and back end to Nexus, i.e. SCP central computer interface (BNI). It should be noted that the SCP core computer functionality is currently implemented in the Nexus, hence the acronym, BNI. However, other central computer systems that are capable of supporting the SCP host functionality for the purposes of the call manager's network station system of the present invention are not impeded. Figure 46 illustrates a rear end process flow 1200 for the system of the present invention. A customer 1122 typically dials a toll-free number. As an illustrative example, this toll-free number can be provided by a company that has operators that take orders over the phone. further, the company provides three front lines or destination identifiers that go to their ACD. The company serves a sales application based on a half-centered, no-call, for example, a home shopping network through its ACD that includes a toll-free number for customers to call. To handle calls to the home shopping network customer, the company sets an ACD path group called "HSN". This ACD path group includes the three trunk lines as member destinations and agents of call reports and statistics from the total number of agents that serve the home shopping network, independently of the particular trunked lines. In accordance with the above, as shown in step 1241, when the customer 1122 dials the toll-free number, the call goes to the network through the switch. In step 1242, the call passes from the switch to the DAP for translation. The DAP translates the toll-free number to a network number and maps it to an address readable by the RDG. NetCap 290 generally hosts routing plans, destination tags, toll-free numbers, logical terminations, DAP-based details, and triggers the plans required for the network station's call manager system. Most of this data can be provided in NetCap 290 via the free network administrator application service (TFNM), as described herein. Upon viewing the trigger point and other DAP-based data provided by NetCap 290, the DAP passes the call to the RDG in step 1243. In step 1244, the call statistics are stored in the DAP traffic statistics (DTS) for its use in case of the end of time or other failures. They are also stored inside the IR central computer. In step 1245, the RDG, which with its ability to communicate with the central computer SCP, passes the network number and address associated with the call-by-call (CxC) routing application of the central computer SCP. Based on instructions in the set of rules defined by the customer of the call manager's network station system, the call-by-call application selects the HSN ACD path group in step 1246. Step 1247, the call-by-call application. The call then selects the individual destination identifier within the ACD path based on the specific distribution method which can be either pair / "request" or directed distribution / percentage. In step 1248, the call is routed again through the RDG to the DAP. Then in step 1249, the DAP routes the call to the ACD via the specific destination and trunk. Specifically, making reference again to the example illustrated above, calls received on Thursdays between 5:00 and 7:00 GMT can be fixed routed in Orlando, and according to the destination identification is the Orlando headquarters. The call-by-call routing application returns the identification of the "Orlando Central" destination to the network, which routes the call to the ADC via the Orlando trunk or destination trunk.

Implementation of the call manager client GUI application As in other client applications of (B Internet network administrator nMCI, the client application 5 call manager (CMApp) is preferably derived from the COApp class (common object) and is can be thrown by the backplane object that is typically derived from the COBackPlane class, including the backplane of the Interact network (Figure 3) .In an embodiment of the present invention, the ^ client application call manager is launched in a separate browser window from within the backplane of network Interact is running. For example, after validating that a customer profile allows access 15 to a call manager application, and after a customer clicks the call manager icon 97 on the home page of networkMCI Interact (Figure 5 (b )), the backplane network Interact creates a separate tfp browser window and populates the administrator network station URL calls. The network server of the call manager's network station then copies the call manager client application for execution within the new browser window. The call manager client application copied from the server includes a CMBackPlane class that is a derived applet and inherits from the COBackPlane class. The COBackPlane is launched with the network page of the call manager's network station and provides backplane functionalities within the context of the call manager's network station application. The call manager client application also includes an aFeature class from which the CMFeature is derived. The CMFeature is typically invoked by the CMApp and provides application-specific functionality within the call manager application such as report, alarm manager (NEM), graphical data display (GDD), and call-by-call application (CxC) ). After the launch and initialization of the call manager application, the main toolbar sets its icon. For example, the search engine starts the backplane applet which launches the CMApp by calling its init method. The CMApp calls the setlcon method to set an icon for the main toolbar. The toolbar can be implemented using a view of a model in an MVC paradigm described above. When a user presses a button on the main toolbar to launch a feature, for example, NEMS, rules, provisioning, and so on, the CMAppView derived from the theMainToolbar class creates / activates the selected feature and initializes it. When the selected CMFeature is instantiated or started, it invokes a setIcon method to create a framework, which the CMFeatureFrame in which to execute the selected feature.

Characteristics and application of call manager network station client As explained above, call manager network station applications allow authorized clients to manage their ACD data networks via a network-based interface. Specifically, customers are allowed to provide hierarchies for their businesses; control all the routines of your free traffic; create, modify or delete agent deposits; manipulate capacity tables; and define quota schemes, lists of values and program tables. In the manner as described herein, a client in a client network station 20 having Internet connectivity and a network browser, and after the greeting, is presented with a homepage of networkMCI Interact [Figure 5 ( b)] copied from the network server. With the copy and presentation of the home page, the network browser in station 20, displays a backplane applet via which the call manager GUI client application is invoked. The backplane requests a list of authorized applications from the StarOE authentication and rights system for the neworkMCI Interact platform and an application selection list that can include the call manager's network station application, it is enabled in the home page according to the specific rights of the client. The call management network station application is addressed from the homepage [Figure 5 (b)]. The customer can be presented with a call manager network station application greeting dialog box, in which the customer enters the name and password of the call manager's network station. In addition, the customer can be presented with a password change dialog. This dialog implements a password expiration design feature, which due to security reasons, the client must change after a predetermined period of time. In addition, multiple central computers can be managed through the front end of the network client and the process translation at the back end. The back end client application sends the command "get Nexus host computer" to retrieve a list of names of SCP host computers. The central computer information is stored at the back end with the Informix database and, typically, a SQL routine retrieves the available SCP Nexus host computers. The representative residing at the back end returns a list of the SCP Nexus host computers available to the front-end network GUI client application. The representative usually maintains a list of "central computers" that have names of SCP host computers and their Internet protocol addresses. Maintaining the list of names of central computers in the representative allows the easy modification of the names of the central computers and the Internet protocol addresses without impacting the client code. When the front-end network GUI client application receives the list, a list of central computer names can be displayed in a drop-down list for the client to select, or the client can be prompted to choose the computer machine SCP Nexus central desired. The name of the selected central computer is sent along with the registration transaction that has the user's name / password to the back end, where the client presses a "record" button for the initiation dialogue. The "set session" command sends to the back end where the representative can open a connection to that central computer. The representative maps the name of the SCP host computer to the appropriate Internet protocol address and sends the user initialization request to the central computer. The identification of the SCP host computer selected in the initialization is populated in the toolbar (Figure 48 in 1880) in the client's network station. A process flow of application level 1250 for the CMWS system is now presented in view in Figure 47. After a registration name entered by the StarOE is validated and the user's rights are checked, the applet of the monitoring station is checked. The call manager's network is copied to the network station of the client 1130, and as indicated in step 1254, the client is presented with the screen 1870 shown in Figure 48 through which the client can perform the characteristics of call manager of the present invention provided. Those features include: manipulating the user and business hierarchy by query, creating, or avoiding user identification records as shown in steps 1256 and 1258; manage routing schemes via the call-by-call application as shown in steps 1260 and 1262a-k; invoke the alarm manager in step 1264 and 1266 to see the problems that occur through the call manager components, such as loss of connectivity, failure in ACD data collection, system failures, and application abnormalities; status of reports and data in steps 1268, 1270 to print, display and manage ACD statistics, alarm history, database usage, key counter, and system performance, and display of graphical data in steps 1272, 1274 to view histograms and diagrams of ACD statistics and pin counts. More specifically, by selecting the option in step 1256, to manage a business and user hierarchy, via, for example, the security button 1882 (Figure 48) from the 1880 toolbar (Figure 48), a client You can search for a user ID and, with the appropriate privileges, create or edit a user ID for a business level below yours. Through this option, the client can also access report visibility to all data points belonging to the client and at any level of business below their own. In addition, the client can assign read, read / write, or non-access privileges to each function in the user identification profile. Moreover, customers can manage and modify limits on several entities that a business unit can have in the provisioning database. Selecting the call-by-call application in step 1260, for example, by pressing an icon labeled "provisioning" (Figure 48 in 1874) in the toolbar of the call manager's network station displayed on the 1870 screen in the Figure 48, the client can perform business hierarchy provisioning as shown in step 1262a. The customer can select the option in step 1262b and perform load balancing by determining the degree of "occupancy" by tracking the average call handling time, the number of agents, and the number of calls routed to each destination. In steps 1262c and 1262e, the client is enabled for the provision of capacity tables to provide a default personnel allocation for use by the load balancing algorithm. With the call-by-call option as shown in step 1262d, the client can also provision for identifications of basic destinations representing a single call termination in the network which can be a single telephone instrument or a line termination in a PBX. Identifications of destinations with ACD feeds, which can represent a single call termination in an ACD, can also be provisioned. The provisioning of ACD path groups is represented in a set of destination identifications that end in the same physical ACD and share the same statistical data are also enabled. The provisioning of destination groups representing a set of identifications of logically related destinations and / or groups of ACD paths is possible via the call-by-call option. Target groups are a convenience mechanism for writing rules that relate to multiple destinations without having to list each destination separately. In addition, the client can provision distribution methods, for example, uniform, when it is a contest selection of destination or targeted identifications, in which calls are routed to destination identifications based on the percentage assigned to each identification of destination. In step 1262f, customers quotas to specify and maintain call routing quotas for destinations. In step 1262g, the client is enabled to provision called numbers. For example, the client creates a set of rules associated with the called number. The rule set typically determines the place of the caller and selects the appropriate destination number for the nearest store. In step 1262h, the client can be provisioned with lists of values that are sets of related numerical values. Typically they are used in rule sets to test the attributes of an incoming call to determine a characteristic of the call or caller. An attribute of the call (such as the ANI) is tested against a list of values. If the value of the call attribute matches an entry in the list of values, then the other rules are executed based on this logical condition. This feature is very useful for callers who do not speak English. In step 1262i, the client can provide the translation tables. Translation tables include a very flexible mechanism to perform a table query and return a value that corresponds to the argument sought. In steps 1262j and 1262k, clients can maintain user variables such as installation names for key counters and rule variables and routing instructions. Selecting the alarm manager option in step 1264, for example, by pressing an icon labeled "NEMS" (Figure 48 in 1872) in the call manager network station toolbar displayed on screen 1870 in Figure 48 , the client can deploy several alarms for problems that arise through the components of call manager. These components were described above. Typically, the alarm is performed through the BMC patrol software agents with monitoring provided by the operating system support organization (SOS), which monitors other components of the call manager platform. The "logwatch.cinfing" of the patrol allows you to install a file name and a selection string. Patrol agents typically monitor the file and pass alarms that match the selection chain to network clients. To register alarms at the application level, the UNIX installation syslog is used. A set of "send alarm functions" connected between application processes and the syslog daemon is added to a common utility library. Through the function of sending alarm the call manager application processes and sends the alarm messages to the same log file with different levels of severity. Alarms with a high level of severity are generally monitored by the operating system support organization (SOS) through the BMC patrol software. Each alarm message typically includes a process name, an alarm number, and a severity level. A typical alarm message looks like this: "Apr 8 17:23:31 cmjwstest Process Ñame [Process PID]: [LOG: Alert Number] can not establish a connection with Nexus XXX on line 65 representative file". The alert number can be used to determine possible solutions. Referring again to Figure 47, when selecting the option of reporting and extracting data in step 1268, for example, by clicking on an icon labeled "report" (Figure 48 in 1876) in the toolbar of the network station Call manager displayed on screen 1870 in Figure 48, enables the client to obtain ACD statistics report, alarm history, database usage, CDR extracts, key counters, and system performance. Each of these reports can be generated online or through a print function within the application. The ACD statistics are monitored live, almost in real time by the application of the SCP central computer. A load balancing algorithm uses ACD statistics to determine the "occupation" of a destination. When an ACD path group is selected as the least occupied place by the load balancing algorithm, one of the individual destination identifications 5 within the ACD path group is chosen to carry the call. The alarm history reports allow the client to see the status of alarms and events in the different central computers. An alarm or event can be an information message sent autonomously to from a central computer. The reports of use of • databases generally provide information about users, typically by user identification, having access to a workstation, SCP host computer, or call-by-call application. The CDR extracts generally provide a database record of call detail record information about a call number translation query and its output in the routing translation process. The key counters fl usually represent a series of accumulators that are available to the user to count actions or situations found in a set of rules. System performance reports allow the client at the workstation (network station) to monitor the capacity of the central computer and the application components for predict and prevent potential problems.

When selecting the graphical data display option in step 1272, for example, by pressing an icon labeled "GDD" (Figure 48 in 1878) in the fl tools bar of the call manager network station displayed on the 1870 screen, the client is enabled to obtain and view histograms, diagram displays, and graphical line of ACD-based statistics and routing key accounts, which can be refreshed as frequently as once per minute. 10 • Characteristics of rules writing, testing, debugging The rules feature (Figure 48 in 1884) allows users to write rules for routing or calls free. Rules can balance the load based on call center capacity and routing based on automatic number identification (ANI), caller input digits (CED), or quotas. Via this feature, the user can also try, install, uninstall, and change rules as shown in Figure 48. Half of the screen button 1870 in Figure 48 displays a typical template for writing / editing rules. Users can build rules about the rule construction area 1882 including the selected statements from the list box of constructions and from the list of declaration lists 1884.

Users can also select various 1886 options available for the construction or statement selected to build the rule. To enable a rule writer to test a rule set, the rules feature provides a debugger / tester functionality that runs a set of rules against a set of test data, for example, call context, simulation call scenarios in which test the logic of a set of rules. This optional installation allows the rule desktops to verify whether their rule set exhibits the desired behavior, for example, before installing the rule set on the network. Moreover, because this test feature is purely optional, a rule writer does not need to run the rules test functionality before the rule is installed. When a client, for example, a rule writer, selects the debugger / tester feature option, a rules test dialog appears. Via that dialog, a user can define call context parameters, to assimilate call scenarios in which to test the logic of a set of rules. The basic call context includes, called number, ANI, CED, bearer, date and time of the call. Optionally, the user can also modify the different parameters of destinations and quotas that can affect the load balance. In addition, an option is also provided to allow the database to be updated during the simulation. During the testing process, the client can go through the simulation one line at a time or choose a "run" command to execute through all the calls at once. further, during the simulation, the client can select several view tags for network, including, a record view, a destination status view, a destination details view, a CDR view and a user variable view. To run the test process, the debugger / tester uses the human machine language interface for Nexus, that is, the debugger / tester formulates user actions for one or more man machine language commands and sends the translated command to the computer central SCP. The SCP host typically stores the test status (including the different views in the registry) and handles the test run.

System status display Typically, a system status display 1850 shown in Figure 49, opens by selecting "system status display" from the security button on the main toolbar (Figure 48 in 1882). The dialogue is non-modal with a higher half having a dialogue 1852 that includes general information about the system, and a lower half that includes a combination of boxes 1854 that allows the user to select from the 5 different options described above, that is, status of application, ACD gate status, status of associated links, status of signaling network links, and status of network station session links. When selecting an option, a list is displayed that includes information relevant to that option. As shown in 1854, the selection of application status P displays information including application names 1856, instance numbers 1858, desired states 970, current states 1862, release numbers 1864 and TPS 1866. Similarly, when selecting the option of 15 door status ACD displays information including gate names, gate states, gate link states, collector link states, and dates / times of the last change. By selecting the partner link status option, host names, states, link states 20, synchronization status information are displayed. Likewise, the status option of signaling network links displays information that includes names of link sets, link names, states, dates / times of the last change, and codes of adjacent points. When selecting the session link status option, network station displays information such as workstation instance numbers, places, states, user IDs, and dates / times of the last change. When a message announcing that the user is ready is received by the central computer, the central computer sends status messages to the system at a regular interval. The length of the interval can vary from every second to every minute. System status display messages are automatically sent from the central SCP computer, as soon as the messages are turned on. The back end typically stores this type of messages received from the central SCP computer until the client wants to consult them. A single data set is stored for each user who currently performs a system status deployment. Subsequent message received from the central computer SCP is typically overwritten on the above data.

Central computer administration functions A user can select to perform central computer administrations by selecting the appropriate icon from the main toolbar (Figure 48). In response, a menu that runs down from the beginning is presented with options that include: backup option to back up the server database to a user-selectable backup media; for example, tape or a disc; an ACD gate management option to provide users with the ability to view, create, erase ^ and avoid ACD gates; and an ACD collector 5 management option to provide the user the ability to view, create, delete and avoid ACD collectors; an FMS gate management option to provide the ability to view, create, delete and avoid FMS gates; and administration of FMS collector to provide the ability to see, create, delete and avoid FMS collectors. ^ When the ACD collector management option is collected, a dialog 1870 shown in Figure 50 opens with a list of retrieved door types. Typically the client GUI application sends two messages to retrieve the information needed to populate the dialogue box 1870. An "rtrv-acd-type" is used to fill the combo-type door box 1872. An "rtrv-acd-status" is sent to retrieve information 1874 on the selected door type . Pressing a row in list 1874 enables the delete button. The characters of writing in the name of the site collector 1878 enables the add button 1879. The FMS administration dialogs share the same dialogue box with the ACD port described above and the collector administration functionalities. The same messages, that is, the "rtrv-acd-type", and the "rtrv-acd-status", are sent back to the back end but with different types of parameters, for example, "FMS" or "ACD".

Company Brand The CMWS component of the nMCI Interact system supports brand functionality that allows users to open the application of the call manager's network station in a specific company context.

Language support The CMWS component of the nMCI Interact system additionally provides an internationalization feature that supports local languages for text deployments. This optional feature allows the user to open the application in the call manager in a language set by the user. Subsequent texts and phrases are converted to the chosen language. Typically, the call station network application of the call manager is opened with a default language set by the operating system. The user is also given an option to select a language other than the default language. A call manager applet typically determines a local set for the operating system and launches the appropriate language version including the local as a parameter. For example, the parameter with a "local" name can have one of the following values: "en_US" for English of the United States, "en_CA" for English of Canada, and "fr_CA" for French of Canada. The applet uses this value to set the locale for the system string and phrase resources. A CMResource class handles the general resources of numeric formatting and formatting of data encoding.

Online billing Another application of the telecommunications network management application suite is the online billing system, hereinafter referred to as "ClientView", which provides customers with the ability to view invoices and reports online, and offers a facility to print and fax documents. The online billing system takes information available from different billing systems and incorporates that information into the database for the retrieval and subsequent submission to a user according to a request specified for the user. A general block diagram illustrating the architecture system of the online billing system 1300, integrated with the networkMCI Interact platform, is shown in Figure 51. Generally, as shown in Figure 51, the VistaCliente 1300 system is integrated within the networkMCI Interact system comprising: the user's network browser 1320 that employs a user interface of VistaCliente 1130 to provide an interface to which the client can request and view various billing invoices associated with the application services subscribed by the client and provided by the networkMCI Interact system via a secure connection to the presentation of billing reports. For example, by using the client application of the graphical user interface 20, clients can scroll down their applicable invoices, typically by accessing them via the identifiers of given clients such as corporation identification, billing payer, or payment numbers. mega accounts. Invoice reports are also available for various application services including free network, Frame Relay, and ATM; the StarWRS reports and requestor processes on the side of the StarWRS 200 client that provide the support to generate and present reports related to the conditions of dedicated voice and data networks of the client as described herein; a corresponding server side reporting component that has the input box described above, the report scheduler and the report manager components, plus an alarm and report viewer and solicitor components that implement applets Java that have viewer classes that allow the copying and deployment of reports generated from the Vista 1350 server processes.

As shown as part of the billing display system architecture on line 1300 of Figure 51 is the server / network dispatcher component 1335 which provides transport between the network browser and an online billing representative interface 1340 which includes all communications and secure encryption. In this way, customer requests and server responses can be communicated from the user browser 1320 to the online billing server 1350 in a secure manner. Specifically, the dispatcher 1335 sends user requests, such as the "get index" message to retrieve a list of documents available for client viewing, to the online billing server 1350 process which employs an integrated representative application 1340 to receive interpret user messages and perform billing functionality online. This representative capacity includes a multi-string machine that allows simultaneous execution of multiple sessions that support early user load. The interface between the dispatcher server 1335 and the online billing server 1350 is also message-based, employing, for example, TCP / IP transport of basketball, and, as will be described, a message protocol that is defined and which includes a generic message header followed by specific data from the representative. The same message schema process is used in the other direction. That is, the online billing representative 1340 sends the generic header, followed by the representative's specific response back to the dispatcher server 1335 for the communications on the protection wall and back to the user's browser 20. The billing representative in line 1340 uses a "template representative" as an implementation of the listener / slave portion of the representative. The 1340 representative passively listens on a previously defined port number and forks a process on an interrupted basis, after which the parent representative continues to listen to another request. The bifurcated process is usually dedicated to handling the detected requests. The bifurcated process detects a type of transaction from the proxy protocol header. The types of transactions generally include synchronous transfers,. asynchronous, and bulk transfers, as described above. The representative 1340 then calls a "back end" function whose function depends on the type of transaction detected. The back end functions typically provide individual services for which the application is responsible. For example, if the transaction type of a detected request is of the "synch" type, the bifurcated process executes the back end synch function and passes the request as an argument. The back end synchronization function generally passes the request to a CICS task on the online billing server and waits for a response. More specifically, the synchronization function (synch) first establishes a CICS task via a direct TCP / IP connection to the TCP / IP interface service of the CICS. The synchronization function waits for the response indicating whether a connection was successful or if an error occurred. If an error occurred, an error response from the CICS task is returned to the synchronization function, which then terminates appropriately. If a connection to the CICS task is successfully established, the request is sent to the task and the synchronization function waits for a response. The response is usually preceded by a preamble block, which indicates the request status and the number of bytes to be followed. The preamble block can include an error code, which indicates the error conditions that may have occurred during the processing of the CICS task. Certain error indications may prompt the synchronization function to terminate the connection of the CICS task, and also exit the synchronization function. If the preamble block indicates that the request was processed successfully, the preamble block is returned, and the specific byte count in the preamble block is removed from the CICS task, to the request process, and typically all the way to return to the graphic user interface application of the client. After completing the data return, the synchronization function disconnects the CICS task and exits. The bifurcated process that called the synchronization function also ends up coming out. In the preferred embodiment, online billing server 1350 stores documents from various billing systems and performs the various database queries and function calls in response to requests received from the customer via online billing representative 1340. Particularly, The online billing server 1350 is responsible for tasks that include data collection, calculation, storage, and report generation. A more detailed description of the server 1350 is provided with reference to Figures 55 and 56. During its operation, the online billing server 1350 supports communications with the StarOE server 39 which provides user authentication, providing rights information, and enabling the entry of orders for the different order entry functions of the billing invoice viewing services online including the functionality needed to manage (create, update, delete) online billing users, and feed the billing information appropriate orders to the online billing server 1350 in order to properly associate the appropriate online billing functionality and the data for the correct customer as soon as the online billing invoice viewing service is given admission. As previously described, the order entry for the networkMCI Interact search engine and all the applications in the networkMCI can be done through the StarOE command entry system. The online billing application service can be ordered for all customers in business markets. For example, a user may choose to have an online invoice billing for a given company, corp, account payer, and / or mega-account number. These include all NCBS, Free network, PLBS, and Mega bills. In addition, selections may include images for MCI CVNS-ROW, MCI CVNS-Mexico, MCI CVNS-Canada as well as images of Stentor Advantage Vnet / CVNS invoices. In the preferred embodiment, a message interface is used between the StarOE 39 and the online billing server 1350 for communications medium. The online billing server 1350 typically operates as a client and receives authentication information, billing identifiers, and level of service information, which may also be provided in response to the launch of the customer's graphical user interface application. online billing 1330. For example, when the online billing customer application 1330 is launched from the home page (Figure 5 (b)), a customer identifier such as the userid and the applicable corporate account numbers can be Recover by the order entry system administration server, StarOE 39, and move to the online billing server. The online billing server then makes the necessary association for the individual account payers that the user is authorized to see. The invoice display can include a particular portion of the invoice as well as the entire invoice. Online billing server 1350 can also interact with the input system server component of the reporting system, StarWRS 270, storing new information regarding online billing services, in addition to event notifications, and reporting data from networkMCI Interact application services. In addition, the invoice files stored in the entry box can be retrieved and viewed using the report requestor 212 and the report viewer components 215 of the StarWRS 200 (Figure 10) resident in the user search engine 20. Via the requestor reports, the client can request made-to-measure reports regarding the invoice files and view or print the made-to-measure invoice reports displayed by the report viewer as described herein. A process flow at application level 1360 for the VistaClient system is now presented in view of Figure 52. After a successful salutation and determination of rights (by the StarOE server), and after the selection of the invoice application in line (CustomerView) from the homepage networkMCI Interact copied to the user (Figure 5 (b)), a CustomerView applet is invoked in step 1362 to display an online invoice screen on the client workstation. As indicated in step 1364, the user then enters the customer identifiers in the online invoice screen which are checked against the available list of customer identifiers in the online invoice server database in step 1368 If the customer identifier does not exist or is not a valid type in step 1370, the user is prompted to reintroduce the identifier in step 1365. When the customer identifier is properly validated, the user is presented with billing products in line associated with the customer identifier in step 1372. The user can then select products by their data ranges in step 1374 to display them. In step 1376, a server module retrieves a list of documents based on the selected product and the range of dates from the online billing database, and in step 1378, the list is presented to the user, starting with the which user can select to view a document, in step 1380. After user selection, the server modules retrieve the document from the database in step 1382. In step 1384, the invoice documents and / or report are presented to the user at the user's workstation. In step 1836, the user may scan, or print the presented data, or the user may, in step 1388, select to view another document in step 1378. The information stored in the 1355 database generally originates from different systems billing. When data is available from these billing systems, the online billing server typically performs a conversion process and stores the converted data on tape until an external monitoring approval. When the converted data is externally monitored and approved, the data that the billing documents have are stored in the database 1355. After the data has been stored in the database for a predetermined period, it can be moved to a direct access storage device (DASD) and store in optical plates. These plates can be left in an optical box for another previously determined period and then migrated to an optical shelf where the data may be available for a certain period. Having generally described a global vision of the online billing application service and its integration with the networkMCI interaction network and the data infrastructure, the specific functionalities of the online billing application, namely the graphical user interface application billing on the client's side of the platform and the online billing server on the company's Intranet, will be described in detail right away.

Online billing GUI application As with other nMCI Interact network management client applications, the online billing client application is implemented in Java to ensure platform independence and is particularly developed according to many of the common objects, as described herein, to achieve interoperability with the backplane of the application. The customer component of online billing includes a customer interface for the user to select the data to retrieve. Data is retrieved through various procedures and applications, and a list of invoices and reports is provided for the user to choose from an online visualization. When the customer clicks an "online billing" icon 99 on the homepage (Figure 5 (b)), after proper authentication via a greeting, the customer is presented with a 1900 criteria screen as shown in the Figure 53 (a) from which the customer can specify various types of, date ranges for, the desired invoices. The criteria screen 1900 is divided into a customer identifier section 1902, product section 1910, and dates section 1912. The customer identifier type includes 1906 corporation identification, account identification, account payer identification, and so on. . Each online billing user is given at least one type of identifier 1906 and a customer identifier number 1908 associated with the type at the time of order entry via the StarOE. The StarOE maintains this customer information and communicates the information to the graphical user interface application of online billing, when the application is invoked by the backplane applet. In accordance with the foregoing, at the same time that the application of the graphical user interface of online billing exhibits the criteria screen 1900, it also fills the type of identifier 1906 and the customer identifier fields 1908 automatically as it receives them from the system User authentication and StarOE user rights. The user can then select a desired type of identifier from the list of identifier types shown in 1906. The application of the online billing user graph interface automatically fills the customer identifier field 1908 associated with the type 5 selected identifier. In addition, if the last customer selection was made within a certain type, for example, corporation identification, the next time the customer sees the 1900 criteria screen, the type of corporation identification can be selected 10 automatically. After selecting a desired identifier w, the user can typically execute the search for available invoices for that identifier by pressing the recovery button 1904, pressing a return key, or using a combination of hot keys such as Alt + S. 15 The products and selections dated 1910, 1912 are used to display the service products for which the invoice view is available for a given customer identifier type and a range of dates for the available invoices. When the user executes the search, 20 the 1910 product field is filled with the 1912 data ranges, indicating invoice reports available for various ranges of periods. To retrieve invoice documents, the user can select date ranges including multiple ranges of dates as shown, and then press return button 1904, press return, use the Alt + R key combination, or press any area within from the date range list box 1912. After executing the recovery user command, the online billing user interface application displays screen 1915 shown in Figure 53 (b) listing report documents. For each document, the date, the invoice number, the identification of the billing payer, and the number of pages is displayed as shown in the 1915 screen display. The 1917 status bar at the bottom of the screen can display several loaded indexes (document lists). The number of indexes that can be loaded each time can be configurable by a client via the application of the graphical user interface of online billing. A listed invoice report can then be selected and retrieved by pressing the recall button 1904, by pressing a return key or by double clicking on a highlighted item 1918, or by using a combination of fast keys such as alt + R. When a selection is entered, a 1920 range selection box appears. The 1920 selection box allows customers to enter the desired range of pages to display. The 1922 mail / payment option to retrieve only the sender pages without having to retrieve additional billing pages is available on this screen.

Figure 54 illustrates an invoice document sample 1925 retrieved from when an invoice item is selected from a screen 1915 shown in Figure 53 (b). Using the 1927 menu bar or a 1928 toolbar, a client can access the following functions: open a saved document, - save the current document; print the current document; send the current document by facsimile; batch print a document; look up words in a document; display the first page copied; display the previous page, - display the next page; display the last copied page, - go to a specific page; increase the font size of the document displayed; reset the font size of the displayed document to the default size, - decrease the font size of the document displayed, - and, return to the screen that invoked the document. More specifically, the option of batch printing can allow customers to send a print job in volume that is done on the company's intranet for customers, for example, via Federal Express, to a place specified by the customer. Another feature provided by the VistaCliente 1300 system includes an accumulator function that allows customers to add numerical figures, such as minutes and charges, by highlighting the numbers directly on the screen. The current document option sent by facsimile mentioned above offered by the online billing application includes an ability to send by fax to the customer, to a place specified by the customer, a current page, a specific range of pages, or the entire document making an appropriate selection in the facsimile dialog box.

Online billing server As described above, online billing provides online visibility to several documents. By submitting several online documents to a customer, the client application of the graphical user interface communicates with an online billing server via the representative to retrieve updated information maintained by the server. These documents are classified and stored in the online billing database 1355 (Figure 52). The online billing server includes several processes for document classification and storage. Figure 55 illustrates a process flow 1400 of the online billing server 1350. The server can receive data from various data centers 1432. Figure 56 shows three places of data centers: the "A" place 1432a, the place " B "1432b, and the" C "site 1432c, as illustrative examples. In each site, invoice data associated with different products are available from various charging systems associated with the products as shown in 1434. Products may include Vnet, Free network, Cross Border, • Mega, etcetera. In a preferred embodiment, an online billing conversion process 1436 is used to convert documents in each of the data centers. The conversion process generally defines the key information needed to recover the document and compresses the document for its storage. Each conversion process 1436 generally • performs the same tasks. More specifically, these tasks include creating a formatted compressed data set (FCDS) file and a conversion statistics report for each conversion run. The FCDS file is the document that can eventually be incorporated into the online billing database. In step 1438, the online billing conversion process reads a PARM file and an invoice file. The PARM file includes information from • document such as logical record length. The file of Invoice is read one line at a time and in step 1440, key information including page numbers and document dates are placed in a header record that is kept in memory until the FCDS file is created. In step 1446, the conversion process creates compressed pages of the document. Compressed pages follow the header record in the FCDS file. As soon as the FCDS file is created in step 1448, the file is stored on a tape in step 1450, and places B and C NDM the tape to A in step f 1452. In step 1452, the report of 5 conversion statistics are also created which includes page information and conversion information associated with each execution - conversion. The last line of the report has the conversion statistics record, which includes the number of pages converted and the number of headings created. This 10 NDM report then up to A by B 1432b and C 1432c and maintains ^ P in DASD for future revisions and external verification. The FCDS file is usually placed on hold, as indicated in step 1454, until external monitoring approval is received typically via the 15 MCImail email, which is sent by several groups responsible for externally monitoring and approving the document files sent to online billing. As soon as the external supervision approval email is received, an online billing production manually enters the 20 product / division date and the invoice account in the external monitoring statistics database 1459, in step 1456. The store task is manually released in step 1458 by the online billing production control after the external supervision approval is received.

Online billing includes a DB2 database subsystem that resides on a central computer N0R4. The subsystem also includes a database of objects and an index database. A store process online billing 1460 loads the compressed document to a database object online billing and charging process index online billing 1480 stores bookmarks indexes each document in the database index . An external monitoring check is executed to ensure that the correct document number is added to the online billing database during object load and index load processes. More particularly, the storage process loads the conversion statistics record in the external monitoring statistics database in step 1462.

In step 1464, the conversion records are selected by comparison against manually entered external supervision statistics records. The warehouse process 1460 also includes loading the FCDS file from which an index is constructed for each object and an index file, which includes the bookmarks of the document, as shown in step 1466. The warehouse process 1460, the loads of compressed documents in the online billing objects database 1467, as indicated in step 1468. In step 1470, the warehouse process 1460 then creates a warehouse status report and loads the report into the base of external monitoring statistics data 1459. In step 1472, an external monitoring verification point verifies that the stored numbers match the converted numbers. If there are errors with the numbers in the external monitoring statistics database at any point in this process, the job automatically stops the warehouse process 1460 until the power / problem is corrected. As soon as these numbers are verified, the index process 1480 can begin. The index process 1480 in step 1482, that is, EDINDEXX as shown in Figure 55 as an example, generally loads the index pointer of each document, which is typically created by the warehouse process 1460. In step 1484, the 1480 process also updates the account product table with new customer identifiers such as corporation IDs or bill payers. In step 1486, the index process 1480 creates an index status report. In step 1488, another external monitoring verification point verifies that the index numbers are selected by comparison with the stored numbers. The stored and indexed data is maintained in DASD 1491 for a predetermined number of days, for example, 45 days as shown in step 1492. After the predetermined number of days, the object access method (OAM) copies the files from DASD 1491 to an optical disk via the 1493 optical drive. After another previously determined period, the O.AM migrates the objects from the optical disk to the optical rack as shown in step 1494, where they remain available during another period of time previously determined. As soon as the indexes are loaded into the database, the documents are available for viewing. The following database tables are included in the online billing database: a product cross-reference table that assigns the online billing product code to the product name, - a CDSPARM table that maintains the statistics of execution of the warehouse process to allow a reset when necessary and which includes an entry for each product code and execution stream; an EDBAAPPL table that assigns a product code to a warehouse group, - an external statistics monitoring table that maintains external monitoring statistics for each product / execution stream recorded by the warehouse process; and a conversion program parameter file that defines when a conversion can find key document information. The information in the documents for image formation and storage are typically received from various applications services of networkMCI Interact. The online billing server application is typically written in COBOL II using CICS / DB2 and OAM. Those skilled in the art will appreciate that the server application can also be implemented with any other compiler language or software tools. The server application includes a start transaction (EDUP), and a multi-purpose transaction, EDS2. The EDUP-transaction passes several DB2 tables such as a function table, a version control table, and a batch print request table. The EDUP transaction also calls O.AM to verify that OAM is active and to take the tab for future calls to OAM. A cluster table is constructed for system information and temporary storage records are constructed for control, versions and pricing of batch printing. The EDUP generally runs at CICS startup time. EDS2 is a multi-purpose transaction that starts when a request is received from an application of the graphical user interface of the client. Its functions may include listing products and dates, retrieving indexes as shown in 1915 Figure 53 (b), and batch printed request storage. The transaction uses the common top-level function (EDOCS000) and is linked to a lower-level function designed to perform a specific task, based on a specific function. The results of the lower level function are passed back to the higher level function that checks the return codes to determine possible error. The result of the data then passes to the application of the graphical user interface of the client via the representative and the network / dispatcher 1335 (Figure 51), and the statistics are written to a VSAM file. EDS2 also runs for document retrieval to retrieve documents from invoices shown in 1925 Figure 54. Uses a common top-level function and links with lower-level functions to perform recovery processing. Figure 56 is a flowchart of the 2000 VistaCustomer server process that illustrates the server processes to respond to client requests. After a 2002 user suitably registers in the networkMCI Interact system and invokes the online billing application in step 2004, by selecting an appropriate icon in the home page networkMCI Interact, the application of the graphical user interface of billing client online, in step 2006, it generally requests communications with a listening process that runs on the server. Generally, communications from the online billing server to the client workstation are made through a set of calls to the TCP / IP address space. As an example, a listening process, EZACIC02 is activated at the CICS startup, and constantly "listens" for activities. When a request is received from the client, the listener, for example, EZACIC02, invokes transaction EDS2, in step 2008. In step 2010, CICS invokes the first program, that is, EDOCS000 in the example shown, in transaction EDS2 via the CICS transaction control table. Then, in step 2012, EDOCS000 loads system tables into memory. In addition, EDOCS000 also makes calls to TCP / IP to communicate with the client's graphical user interface application. EDOCS000 is also responsible for registering both successful and unsuccessful requests, as well as routing the request to one of many eubprogramae, downloading in function code and in object name. The subprogrammes include EDOCS030, EDOCS001, EDOCS020 / EDOCS040, and EDOCS220 / EDOCS440, each of which will be described in detail below. When the listening process has to pass a data to EDOCS000, EDOCS000 invokes a RECOVERY command to obtain the data. EDOCS000 then performs a sóquet take and responds to the client through a written sóquet. The client typically responds to the server with a function code and additional data such as a customer identifier, data, and so on. EDOCS000 performs data validation such as function code, checks to see if the system is working, supplies pricing information for batch printing, links to low-level functions, verifies results of low level results, produces error input when It is necessary, it writes statistics, and it passes all the recovered data (or an error) back to the application of the graphical user interface of the client. After each call to a subroutine, EDOCS000 checks a return code. EDOCS000 also checks the return code of TCP / IP calls and sends an error message when the TCP / IP return code is a non-zero value, indicating an error. The errors are usually recorded in the TCP data file and can be reviewed as necessary. When all the processing necessary to respond to the client is complete and the response data is successfully sent to the client, the application of the graphical user interface of the client sends an acknowledgment of the receipt of the data, back to the server. The pool then closes, releasing it for another application that will be communicated. Referring again to Figure 56 in step 2014, EDOCS030 is executed when a request is made to retrieve all products and dates associated with a customer identifier. This process obtains all entries from the cross-referenced account / product table for the client identifier received from the customer's graphical user interface application. For each entry in the cross-reference account / product found table, the process consults the product in the product cross-reference table. If the group is different than any group already processed, then the process adds an additional entry at the group level, obtains the product cross-referencing of the product, and obtains dietintae date for addition to the table. When the entry in the table has been exhausted, the process certifies the product as, for example, in alphabetical order or by product description followed by date and sorting in descending order, for proper deployment at the customer's workstation. In step 2016, the classified dates are returned to the customer graphical user interface application to be seen by the user. EDOCS000 links to EDOCS001 and executes it when an application of the graphical client user interface requests index retrieval for specific dates within specific products. EDOCS000 passes the customer identifier, the product and a list of dates received from the application of the graphical user interface as they enter the criteria screen 1900 in Figure 53 (a). In step 2018, EDOCS0001 reads the index table and extracts all matching entries from the online billing database and sorts them in order of dates and invoice numbers. Different sort order can be used for different products. The entries that satisfy the product / date criteria are sent back to the client user graphical interface application for presentation to a client in step 2020. The matching input message, which is sent to the application of the The client's graphical user interface includes a subset of the input records found. EDOCS000 links to EDOCS020 / EDOCS040 and executes either any of the doe when an application of the graphical user interface client requests document retrieval such as invoice document 1925 shown in Figure 54. EDOCS020 and EDOCS040 are generally used for document recovery and are clones with each other. The difference between the two is that EDOCS020 was written for new style objects and EDOCS040 was written to handle old style objects. In your operation, EDOCS020 and EDOCS040 generally allocate storage for the document and retrieve the document by overriding the range of pages required in the assigned warehouse as shown in step 2022. The recovered document is sent back to the client's graphical user interface application for the presentation to the client. In step 2024, EDOCS220 and EDOCS440 are used for object searches in the requested document. These processes perform similar functions as the EDOCS020 and EDOCS040 processes. Typically they obtain the name of collection and object, and cycle through the index portion of the object to find pages in the range requested for the requested document. In step 2026, the retrieved document is sent back to the customer's graphical client interface application and displayed on the user's workstation. To handle batch printing requests, EDOCS000 can be linked to EDOCS050 and executed. A next available application number is determined by obtaining the EDBPREQ record in the database and adding one to the last request number. The EDBPREQ record is then updated. Information passed to EDOCS050 is mapped in the EDBPRINT table project, and a new row is inserted into DB2. The erroree of EDOCS050 is sent to EDOCS000, which reports it to the application of the graphical user interface of the client.

Security of communications The security of communications, which is related to the authenticity of the network servers of the company 24 (Figure 2) and the security of the transmitted data will be described with respect to an implementation in the preferred embodiment of the HTTPS Secure Sockets Layer (SSL) version. In order for a communication to be accurate, you must know that the message comes from the correct source, arrives at the correct destination, has not been modified, and has not been intercepted and understood by a third party. The normal encoding protects against understanding the message even if it is intercepted, and certain types of encrypted encoding provide the ability to determine that the message has attempted to be violated and in some cases reconnect the message if it is intercepted and intentionally modified. The disadvantage of the normal coding is the difficulty associated with the secure distribution and updates of the keys used for coding and decoding. Public key coding solves the problem of distribution and updating, but not, for the public Internet, it ensures the identity of the part with which one is communicating. A scoffer who appropriates the DNS address of a company for a leg of the Internet can substitute the public key of the pirate with the public key of the company with which the user is trying to communicate, thereby tricking the user into revealing the name of the user and the password used in the company's system. To avoid this problem, digital signatures (tuning) have been developed to ensure the identity of the sender. Also, simultaneously, the sender is made to commit to the message, avoiding ebullient repudiation. The communication link between the company and the user can be secured with S-HTTP, HTTPS, or proprietary coding methodologies, such as VNP or PPTP tunnel training, but in the preferred modality ee uses the secure e-tickets layer protocol (SSL) developed by Netscape Communications. It is noted that these solutions are intended for use with IPv4, and that Ipv6, currently under comment by the Internet Engineering Steering Group, may be able to ensure transmission between client and server without relying on proprietary protocols. The remaining security protocols of the present invention can be used with IPv6 when it becomes an available standard for secure IP communications. The SSL component of HTTPS also includes non-repudiation techniques to ensure that a message originating from a source is the actual identified sender. A technique used to combat repudiation includes the use of an external monitoring protocol with message digestions of a direction with electronic dynamism that they include with each tranex. Eeta technique employs SSL public key cryptography with one-way key calculation functions. Another communication problem involving the secure communication link is the business associated with allowing a copy of the common Java objects used in the present invention, as discussed above with respect to the search engine, since the Java objects used require that the user authorizes access in dieco and input / output by the Java object. Digital certificates, such as those developed by Verisign, Inc. with Verisign Digital ID® rights, provide a means to simultaneously verify the server to the server, and verify the source of the Java object that it will copy as a reliable source as from here hereafter will be described in more detail. The aforementioned authentication and coding procedures are carried out in the health protocol, which can be summarized as follows: the client sends a greeting message to the client client to which the server will respond with a server greeting message, or otherwise a fatal error will be presented and the connection will fail. The client greeting and the server greeting are used to establish security enhancement capabilities between the client and the server. The greeting of the client and the greeting of the server establish the following attributes: protocol version, session identification, encryption set, and compression method. Additionally, two random values are generated and exchanged: clientehola. Random and server hello. random. After the greeting messages, the server will send your digital certificate. Alternatively, you can send a server key exchange message, if required (for example if your server does not have a certificate, or if your certificate is only for tuning). Once the server is authenticated, you can optionally request a client certificate, if it is appropriate for the selected number set. The server will then send the given server greeting message, indicating that the greeting message phase of the greeting is complete. The server will wait for the response of the client. If the server has sent a certificate request message, the client must send either the certified message or an uncertified alert. The client key exchange message is now sent and the content of that message will depend on the public key algorithm selected between the hello of the client and the hello of the server. If the client has sent a certificate with tuning capability, a digitally tuned certificate verification message is sent to explicitly verify the certificate. At this point, a changed cipher spec message is sent by the client, and the client copies the spec cipher into the current cipher spec. Then the client immediately sends the finished message under the new algorithms, keys, and secrets. In response, the server will send its own spec message change, transfer the pending spec to the current digit, and send its finished message under the new spec cipher. At this point, the greeting is complete and the client and the server can begin to exchange user layer data.

Client Server ClientHello > ServerHello Certificate * ServerClaveChange * ServerHelloCheck Certificate CertificateChangeChange CertificateVerify * [ChangeCifraSpec] Terminated [ChangeCifraSpec] Done Register Data > Register HTML * Indicates optional messages or dependent situation that is not always sent. Figure 57 is an illustration of a logical message format sent from the client browser to the desired middle-tier server for a particular application. As mentioned herein, messages created by client applications (Java software) are transmitted to secure network servers 24 over HTTPS. For incoming communications (client to server), secure network servers 24 decode a request, authenticate and verify session information. The logical message format of the client to the network server is shown as follows: | | TCP / IP | | coding | | http | | network header | | dispatcher header | | specific datarepresentative | | TCP / IP Coding ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡! where "¡¡" separates a protocol level and the protocols are nested from left to right. Figure 57 illustrates a specific message ^ fc 10 sent from the client browser to the server of the desired middle level for the particular application as shown in Figure 57, the client message 170 includes an SSL 171 encoding header and an HTTP header / Network level protocol POST 172 that is decoded by the or servers of the secure network 24 to access the underlying message; a demilitarized zone network header 174 that is used to generate a cookie 181 and a type identifier 186 to handle the client / server session, - a dispatcher header 175 that includes the identifier objective representative 180 associated with the particular type of transaction requested; specific data of representative 185 that includes the specific metadata of the application used by the target representative to form the particular messages of the server of the particular middle level providing a service, - and, the HTTP / POST dragnet at network level 186 and the encryption hacker 188 that are also decoded by the secure demilitarized zone network server 24. • Referring again to Figure 2, deepuée 5 to establish that the request has arrived from a valid user and map the application to the associated session, the request is sent through the protection wall 25b over a connection 23 to one or more decoding servers / dispatchers 26 located within a ^ 10 Intranet of the corporation 30. The message sent to the server 26 will include the identifier of the user and the session information, the identifier of the target representative, and specific data of the representative. The decoder / deeparator server 26 then authenticates the exceedance of the user to the desired middle level service from data stored in immediate memory previously received in the StarOE server as will be described later in this In more detail with the user identification and authentication 20 As shown in Figure 2, a secure network server 24 sends the proxy header and representative-specific data to the dispatcher server 26"enriched" with the user's identity (any other information related to the session) provided by the data mapping / session cookie, the object representative identifier and the specific data of the representative. The dispatcher server 26 receives the requests sent by the secure network server (s) 24 and sends it to the appropriate application server or its representative. The envelopes of the message are examined, revealing the user and the middle-level service object for the request. A first level of validation is carried out, making sure that the user has the right to communicate with the desired service. The user's rights with respect to this are extracted from the memory by a dispatcher server from the StarOE server 39 at the time of greeting and stored in immediate memory. Assuming that the solicitor is authorized to communicate with the target service, the message is sent to the representative of the desired service. Each of the representative processes also performs: a validation process to examine input eolicitudee and confirm that they include meneajee formatted validly for the service with acceptable parameters; a translation process to translate message into an underlying message or network protocol; and, a management process to manage the communication of requests from specific clients with the medium-level server to actually obtain the requested service. Data returned from the mid-level server is translated back into the client's format, if necessary, returned to the dispatcher server as a response to the request.It should be understood that the representatives of application servers can either receive or dispatch the server itself, or, preferably, they can be referenced in the middle level application server, i.e., the front end code of the dispatcher can locate resident representatives. on other servers.

Security Session As described above, the SSL protocol includes a security level of security, and can negotiate and change a code between numbers. Additionally, the present invention uses the set of "cookie" features of the contemporary searchers to maintain the security of the session, and to prevent hacking or the use of a name and password obtained through sniffing, simulation or EMR monitoring. Figure 58 is a data flow diagram illustrating the flow of data between the processing modules of the "networkMCI Interact" system during salutation, rights request / response, heartbeat transmissions, and farewell procedures. As shown in Figure 58, the client platform includes the user 20 representing a client, a page of the greeting network having a greeting object for the greeting processing 220, a page orad having the object in plan later. The network server 24, the dispatcher 26, the cookie jar server 28, and the StarOE server 39 typically located on the company site. As described above, after the SSL greeting, certain cab files, class files, and replenishment requests are copied to the page of the salutation network as shown at 221. On the salutation network page, client 20 enters then a user identifier (user id) and password for user authentication as illustrated in 221. The client also enters replenishment recognition 221 on the page of salutation 220. If the user ID entered and the password is not valid or if there are too many transactions of unsuccessful greeting, the greeting object 220 communicates the appropriate message to the client 20 as shown at 221. A greeting object 220, typically an applet launched on the page of the greeting network, connects to the network server 24 , to communicate a salutation request to the seventh as shown at 222. The salutation data, which have a coded user ID and password, are sent to the dispatcher 26 when they are established in connection as shown at 224. Dispatcher 26 decodes then the data of salutation and sends the data to StarOE 39 after establishing a connection as shown in 26. The server OE 39 vali gives the user identification and password and sends the results back to the dispatcher 26 as illustrated at 226 along with the user's application rights. The dispatcher 26 passes the results of the data obtained from the StarOE 39 to the network server 24 as shown at 224, which passes the data back to the greeting object 220 as shown at 222. The client 20 is then notified of the salutation results as shown at 221. When client 20 is properly validated, the client is presented with another web page known as homepage 79, from which the backplane is typically launched. After user validation, the backplane generally manages the entire user domain until the user says goodbye to the seventh "networkMCI Interact". As it is shown in 228, the following plane starts a heartbeat that is used to detect and maintain the live communications between the client's platform and the intranet site of the company. The backplane also prompts a COUser object to clean up all client information as it is received from StarOE 39. For example, to determine which applications a current client is entitled to access and activate only the application options on the page home to enable the client to select, the backplane sends a "get applications list" message via the network server 24 and the dispatcher 26 for the StarOE 39 as shown in 228, 224, and 226. The list of client rights is sent from the StarOE 39 back to the dispatcher 26, to the network server 24 and to the backplane to the home page 79 via the path shown at 226, 224, and 228. The rights and applications for the client are kept in the COUser object for the proper use by the backplane and for subsequent recovery by the client's applications. The rights information for the COUser is stored in a cookie jar 28, held in the cookie jar server 28 (illustrated in Figures 2 and 58). When the network server receives the rights request from the previous plane on the home page 79 or any other application of the client, the network server 24 makes a connection to the cookie jar 28 and verifies whether the information requested is included in the cookie jar 28 as shown at 230. Cookie jar 28 is a deposit of variae eesiones of the client and the details of each eeion are included in a cookie that includes server rights information OE 39. During the process of greeting described above, the OE server 39 can include in its response, the rights for the validated client. The dispatcher 26 transfers the rights data to the network server 24, which translates them into binary format. The network server 24 then transfers the binary rights data to the cookie jar 28 for storage and retrieval for the duration of a session. In accordance with the above, if the information requested can be located in the cookie jar 28, another request can not be made to the StarOE 39. This mechanism cuts the time of re-tasting to process the request. Although the same information, for example, client application rights or rights for corporate identification, can be stored in the COUser object and maintained on the client platform as described above, usually a second check is made with the cookie jar 28 via the network server 24 in order to secure against a COUser object information violated or corrupted. In this way, rights are typically verified in two places: the client platform 10 via the COUser object and the network server 24 via the cookie jar 28. When a connection is established with the cookie jar 28, the server network 24 makes a request for the rights of a given session as shown at 230. The cookie jar 28 goes through the stored list of cookies, identifies the cookie for the sieve and re-logs the cookie to the network server 24 also shown at 230 The network server 24 typically converts the rights that are received in binary format, to right chain representation, and sends the rights chain back to the backplane that runs on the client platform 10. In addition, the server cookies 28 is used to handle beating transactions. The heartbeat transactions as described above are used to determine the continuity of the session and to identify the processes that have died abnormally as a result of a process failure, process crash or communications failure, for example. During a client session initialization, the cookie jar 28 generates a seed identification and establishes "beating" transactions for the customer's order. Subsequently, a heartbeat request is typically sent from a process running on a client platform to the network server 24, when a connection is established, as shown at 228. The network server 24 is connected to the cookie jar 28 and request heartbeat update for a given session. The cookie jar 28 searches for your stored cookie list, identifies the cookie for the session and updates the beat time. the cookie jar 28 then sends the network server 24 the beat with updated etatus as shown at 230. The network server 24 then sends the status back to the client platform process, also shown at 230. When a client wishes to dismiss, a farewell request transaction can be sent to the network server 24. The network server 24 then connects the cookie jar 28 and requests to dismiss the session as shown in 230 The cookie jar 28 identifies the cookie for the session and deletes the cookie. After removing the cookie, the cookie jar 28 sends a farewell status to the network server 24, which returns the status to the client platform. Another transaction requests are sent via the network server 24 and the cookie jar 28 as shown in Figure 59. Figure 25 is a data flow diagram of several transactions reported in the system of the present invention, typically when a client introduces a mouse oppression on an application link as shown at 231, a suitable transaction request stream is sent to the network server as shown at 232. The network server 24 typically decodes the transfer stream and connects to the cookie jar 28 to verify whether a given session is still valid as shown at 234. The cookie jar 28 identifies the cookie for the session and sends it back to the network server 24 as shown at 234. The server network 24 upon receiving the valid session connects to dispatcher 26 and sends the transaction request as shown at 236. When dispatcher 26 obtains the request, it also n can be connected to the cookie jar 28 to validate the session as shown at 238. The cookie jar 28 identifies the cookie for the session and sends it back to the dispenser 26 as shown at 238. The dispatcher 26, after receiving the valid connection connects to an object application server or representative 237, which may include StarOE, and sends the requested transaction to the object as shown at 235. The server or representative 237 processes the request and sends the reply again as current data which is sent back to the dispatcher 26 as shown at 235. The dispatcher 26 sends the data back to the network server 24 as shown in 236, which encodes and sends the data to the client platform as shown at 232, referred to as the home page 79 in Figure 59. The present invention includes a client communications unit to provide an eola interface from which the backplane and the ap lications can send menejee and requests or back end services. The client communications unit includes a client session unit and a client transfer unit. The client session unit and the transfer unit comprise classes used by client applications to create objects that handle communications to different representatives of applications and / or servers. Generally, entire communication processes begin with the creation of a client domain after a connection process. This starts through the connection process. The user registers on the user's network page with a username and password. During a connection process, the object of the class client session with COClientSession is created, and the COClientSession object passes the user name and password information in pair obtained from the connection process to an administrative service of the remote system that validates the pair. The following code instructions are implemented, for example, to start a session using the COClientSession class. COClientSession ss = new COClientSession (), - try. { H.H . setURL (urlString); H.H . logon ("j emith", "myPassword"), -} catch (COClientLogonException e). { ..} catch (MalformedURLExcpection e). { ... Additionally, the COClientSession object contains a reference to validate the Couser object associated with the user of the COClientSeseion object. The client object session also provides a session, where a client registers in the system at the beginning of the session, and if it is authenticated successfully, it is authorized to use the system until the session ends. The client object session at the same time provides a capacity to maintain session-specific information for the life / duration of the session. Generally, communications to and from the client are carried out on HTTPS using the protocols HTTP over an SSL encrypted channel. Each request / response HTTP is a separate TCP / IP connection, completely independent of all previous or future connections of the same server and client. Because HTTP is stateless, which means that each connection consists of a single request from the client which is reeponed by a single reply by a server, a novel method is provided to associate a given HTTP request with the logical session to the which belongs When a user authenticates when connecting via the administrative server of the system, the customer's object is given a "cookie", a unique code generated by the server that identifies a session. The domain key is typically encapsulated in a COWebCookie class, "public COWebCookie (int value).", Where the value represents a given cookie value. The object of the client session maintains this key and returns it to the server as part of the ubiquitous HTTP request. The network server maintains a "cookie jar" that is resident to the dispatcher server and that maps these keys of the assigned code. Additional authentication of each HTTPS request, which adds security to the overall process. In the preferred embodiment, typically only one cookie is sufficient for the entire session. Alternatively, a new cookie can be generated in each transaction, to add security. Moreover, the cookie jar can be shared among multiple physical servers in the event of a server failure. This mechanism prevents the sessions from falling due to a server failure. In addition, to allow the server software to detect client sessions that have "died", for example, that the client's session has been disconnected from the server without news because of a client-side crash or a network problem , the client application that uses the session object of the client "beats" throughout the predefined period, for example, one minute for the network server to "renew" the session key (or record). On the network server it in turn makes a request for a heartbeat transaction to the cookie jar. After receiving the request, the cookie jar service "marks" the session record with a time stamp indicating the most recent time the customer communicated with the server using the heartbeat. The cookie jar service is also alarmed, for a configurable period, to read through the cookie jar records (e-mail keys) and check the time stamps (indicating the time in which the customer last heard). ) against the current time. If the check log delta is larger than a predetermined amount of time, the cookie jar server clears the log, effectively causing the login key to die. Any subsequent transaction received with a dead key, for example, not existing in the cookie jar, has prohibited access through the protection wall. The heartbeat messages are typically enabled by invoking the object method COClientSeesion "public synchronized empty enable heartbeat (boolean enableHeartbeat)", where enable heartbeat is a flag to enable or disable the beating of a session. The heartbeat messages are typically transmitted periodically by first invoking a COClientSession object method "public synchronized empty fix heartbeat interval (length millisecondsinterval) where the heartbeat interval is set in milliseconds, and by the object method COClientSession" protected int startHeartbeat () ", where the heartbeat procedure begins as soon as the heartbeat interval is reached, the" beating "faults for a consecutive predefined period, for example, one hour, will result in the expiration of the session key.

Company security The security of the company is aimed at the security of the company network, and to the data maintained by the different applications of the company with respect to the open nature of the Internet and the various attacks of the seventh or data that will probably result from exposure to the Internet. The usual company security focuses on internal procedures and employees, since they represent the broadest exposure area. Strong passwords, unique user identifiers and physical security of workstations are applicable to both internal employees and external customers and users who will have access to the company's applications. It is noted that many of the features described above in relation to data encryption for communication security and session security are essential parts of enterprise security, and they cooperate with the architecture of the enterprise and with the software infrastructure to provide security for the company. For example, as will be described hereinafter in detail, the present invention uses strong symmetric key encoding to communicate through the thermosensitive walls to the application servers. This internal symmetric key encoding, when coupled with external public key encoding, provides an extra level of security for both the data and the software infrastructure. Figure 60 is a diagram that represents the architecture of the physical system 100. As shown in Figure 60, the seventh is divided into three major architectural divisions that include: (1) the client's workstation 20 that includes the mechanisms that enable client connection to secure network connectors 24; (2) A secure network area 17, known as the "DMZ" demilitarized zone set aside at the MCI site with a double protection wall between the public Internet 25 and the MCI Intranet to avoid potentially hostile attacks to the client; and, (3) the mid-range Intranet servers of the enterprise 30 and the seven legacy host computers 40 comprising the business application and end-of-life business logic. As illustrated in Figure 60, it includes a double or complex protective wall system that creates a "demilitarized zone" (DMZ) between two guard walls 25a, 25b. In the preferred embodiment, one of the thermosensitive walls 25 includes specific door filtration carriers, which can only be connected to a designated port in a dispatcher server within the demilitarized zone. The dispatcher server connects to an authentication server, and through a representative protection wall to the servers and applications. This ensures that even if a remote user ID and password is hacked, the only guaranteed access is that of the network servers 24 or intermediate data and privileges authorized for that user. In addition, the pirate may not connect directly to the company's server to the company's Intranet, thus ensuring the integrity of the internal company's system. Even with a stolen password, the pirate may not connect to other ports, root directories or applications within the company's system. The demilitarized zone acts as a double protection wall for the company's Intranet because network servers located in the demilitarized zone never store or calculate sensitive customer data. The servers of the network only put the data in a convenient form for the display for the client's network browser. Since the servers in the demilitarized zone network do not store client data, there is a much smaller opportunity for the client's information to be threatened in the event of a breach of security. As previously described, the client access mechanism is a client workstation 20 that employs a network browser 14 to provide access to the networkMCI Interact system via the public Internet 15. When a subscriber connects to the site of the network networkMCI Interact introducing the appropriate URL, establishes a secure TCP / IP communication link 22 to one of several servers in the network 24 located inside a first protection wall 29a in demilitarized zone 17. preferably at least two servers in the network be provided to be able to overcome faults. In the preferred embodiment of the invention, the system employs SSL encryption so that communications in both directions between the subscriber and the sevenma networkMCI Interact are secure. In the preferred embodiment, all secure network servers in demilitarized zone 24 are preferably DEC 4100 systems having Unix or NT based operating systems for running services such as HTTPS, FTP, and Telnet over TCP / IP. Network servers can be interconnected through an Ethernet local area network running at 100 Mbit / second or greater, preferably with the deployment of switches within Ethernet networks to improve bandwidth utilization. One of these switching units includes as part of the network architecture is a HydraWEB® 45 unit, manufactured by HydraWEB Technologies, Inc., which provides, the demilitarized zone with a virtual IP address so that the HTTPS request of the e-writer is received. The Internet will always be received. The HydraWEB® 45 unit implements a load balancing algorithm that allows intelligent packet routing and provides optimal reliability and performance ensuring accessibility to the "most available" server. Particularly it oversees all aspects of the health of the network server from the use of the central processing unit, to the use of memory, to the available change space so that Internet / Intranet networks can increase their hit speed and reduce the costs of administering the network server. In this way, resource utilization is maximized and bandwidth (production) is improved. It should be understood that a redundant HydraWEB® unit can be implemented in a running / standby configuration with heartbeat message between the two units (not shown). Moreover, the architecture of the seventh of the present invention supports a scalable network server, both in vertical and horizontal directions. Additionally, the architecture is such that new secure network servers 24 can be easily added as the requirements and use of the client increase. The use of HydraWEB® allows for better load distribution when necessary to match performance requirements. As shown in Figure 60, the most available server 24 receives HTTPS requests from the subscriber, for example, from the HydraWEB® 45 over a connection 35a and generates the appropriate coded messages to route the request to the network server mid-range of Suitable intranet over the connection 35b, router 55 and connection 23. Via the HydraWEB® 45 unit, a TCP / IP connection 38 links the secure network server 24 to the Intranet dispatcher server 26. In addition as' it is shown in the demilitarized zone 17 there is a second server 52 which has its own connection to the public Internet via a TCP / IP connection 32. This server provides real-time seeionee administration for e-subscribers of the networkMCI Interact real-time monitoring system. An additional TCP / IP connection 48 links this second network server 52 to the Intranet Dispatch Server 26. More particularly, as shown further in Figure 60, the physical architecture for the system of the present invention includes two routers: a first router 55 for routing encrypted subscriber messages from a secure network server 24 to a dispatcher server 26 located inside of the second protection wall 25b; and, a second router 65 for routing encrypted subscriber messages from the second network server 52 to the dispatcher server 26 within the second protection wall. Although not shown, each of the routers 55, 65 may additionally route signals through a series of other routers before eventually being routed to the nMCI Interact 26 dispatcher server. In operation, each of the secure servers 24 functions to decode the client's message, preferably via the SSL implementation, and unwrap the session key and verify the user domain from the authenticated COUser object in the greeting. After establishing that the request has come from a valid user and mapping the request to its associated session, the secure network servers 24 will re-encode the request using symmetric RSA encoding and send it over a second secure electronic connection 23 to the echever 26 in of the Intranet of the company. Figures 61 (a) and 61 (b) are schematic illustrations showing the message format passed between dispatcher 26 and the relevant representative of the relevant application, (Figure 61 (a)) and the message format passed between the specific representative from the application back to the dispatcher 26 (Figure 61 (b)). As shown in Figure 61 (a), messages between dispatcher and representatives in both directions start with a common header 140 to allow the collection of common code to process messages. A first portion of the header includes the protocol version 141 which may comprise a datum byte to identify the protocol control of the protocol, ie, the same message format, and is intended to avoid unintentional mismatches in versions of the dispatcher. and the representatives. The next portion includes the length of the message 142, which, preferably, is a 32-bit integer that provides the total length of the jog including all the headers. Next is the flag / ping portion 143 that is intended to support a connectivity test for the dispatcher-representative connection. for example, when this flag is not zero, the representative immediately replies with an echo of the supplied header. There should be no attempt to connect to processes outside the representative, for example, back end application services. The next portion indicates the key of session 144 which is the only session key or "cookie" provided by the network browser and used to uniquely identify the server in the search engine. As described above, since the software adapted to the communications client is capable of supporting various types of transport mechanisms, the following portion of the header of the common protocol indicates the type / message mechanism 145 which may be one of four values that they indicate one of the following four mechanisms and types of messages: (1) synchronous transaction, for example, a binary zero; (2) asynchronous request, for example, a binary one; (3) Asynchronous scrutiny / reply, for example, a two binary; (4) volume transfer, for example, a three binary. Additionally, the header section of the common protocol includes a serial number indication assigned to the dispatcher 146 that is unique through all dispatching processes and needs to be coordinated through the processes (such as the network cookie (see above)). ), and in addition, it is used to allow overcoming faults and process migration and allows multiplexer control between the representatives and dispatcher, if desired. A field 147 indicates whether the state is not used in the request header but is used as in the reply header to indicate the success or failure of the requested transaction. More complete error data will be included in the specific error message returned. Status field 147 is included to maintain consistency between requests and responses. as shown in Figure 61 (a), the specific messages of the representative 148 are the metadata message requests from the requesting client of reports and can be transmitted via synchronous, asynchronous, or volume transfer mechanisms. Likewise, representatives-specific responses are metadata response messages 149 again, capable of being transmitted via a synchronous, asynchronous, or volume transfer transport mechanism. It should be understood that representatives of the application server may already reside in the 26-MHz dispatcher server, or, preferably, may be residents in the middle-tier application servers 30, that is, the front-end dispatcher code may locate resident representatives. on other servers. As mentioned, the representative validation process includes syntactic analysis input requests, analyzing them, and confirming that they include valid formatted messages for the service with acceptable parameters. If necessary, the message is translated into an underlying message or network protocol. If no errors are found, the representative then handles the communication with the middle level server to actually get the request answered. The application representative supports specific translation of the application and communication with the back end application server for both network server messages (originating from java applet) and their application server messages. For example, to perform the verification, translation, and communication functions, the report manager server, the report scheduler server, and the input box server representatives (Figure 10) each employ C ++ objects representing front end and components . For example, a utils.c program and a C ++ component library is provided to implement functions / general objects. Several C ++ parser objects are invoked that are part of an object class and used as a repository for the RM metadata and analyze the string it receives. The class has a built-in member function that reads the string that contains the data to store. After the message is received, the analyzer object is created in the RMDispatcher. c object which is a file that contains the business logic to handle metadata messages in the back end. Use the services of a RMParser class. After determining that the client has sent a valid message, the appropriate member function is invoked to handle the request. The invocation is presented in MCIRMServerSocket. c when an input message is received and it is determined that it is not a Talarían message. RMSErverSocket. c is a class that implements the management feature of meneajee in the reporter server. The public inheritance is ee from the MCIServerSocket in order to create a specific inetance of this object. This object is created in the main cycle and called when a maneuver needs to be sent and received, - a socket class. c that implements client type subsystems under Unix, using, for example, TCP / IP or TCP / UDP. Socket c is inherited by ClientSocket .C:: Socket (theSocketType, thePortNumber) and ServerSocket .C:: Socket (theSocketType, thePortNumber) when the ClientSocket or ServerSocket is created. A ServerSocket class. c implements client-type sockets under Unix using either TCP / IP or TCP / UDP. ServerSocket .c is inherited by RMServerSocket when RMServerSocket is created. An InboxParser class. c is used as a repository for the RM metadatoe. The "connect" member function of the string clause that contains the data to store and the class analyzes the string it receives. After a message has been received, the MCIInboxParser object is created in inboxutl.c which is a file that contains the functions that process the input box requests, that is, Add, Delete, Enlist, Extract from memory and Update. Additional objects / classes include: Environ. c that provides access to the UNIX environment; Proceee.c that provides a mechanism to deposit slave processes in the UNIX environment; Daemon.c to allow a process to become a daemon; Exception.c for section handling in C ++ program; and, RMlog.c to facilitate registering RM. In addition, the client ESQL code is provided for the RM / database interface that includes the ESQC C (Informix) interface stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, and GPL messages. The functions call stored procedures according to the message, and the response is built into the functions depending on the stored values of the stored procedures. A mainsql.c program provides the ESQL C interface for message from the report manager and the report viewer. Outbound communications (server-to-client) follow the inverse route, that is, the representatives feed responses to the decoder / dispatcher server 26 and communicate them to the demilitarized zone network servers 24 over the socket connection. The network servers 26 will send the information to the client 10 using SSL. The logical message format returned to the client from the middle-tier server is shown as follows: | TCP / IP coding ¡http | Response network response dispatcher response from representative i i i i where "¡" for a logical protocol level, and protocols are nested from left to right.

Although in the invention have been shown and described particularly with respect to the preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail can be made in the present without departing from the spirit and scope of the invention. the invention.

Claims (109)

1. An integrated system for providing a plurality of communications network management services and products over the public Internet, service and network management products accessible from a client workstation employing a client browser associated with the client and capable of of receiving network-based communications from a communications server company, the system comprising: (a) one or more secure network servers to manage one or more sessions of secure clients over the Internet in response to the client's input into the system, each secure network server supporting secure communications with the client's workstation, - (b) a plurality of client applications integrated within a network-based graphical user interface and copied from a secure network server in accordance with the default rights of the client, each of the client's applications to provide an int Integrated client interface with the graphical interface of the networked network and allowing interactive communications with one or more communication network management resources provided by the communications service company via a network secure server; and, (c) each secure network server that supports communication of requested messages entered by the client via the client interface to one or more network management resources capable of providing a desired network management function of communications, - where the one or more remote application resources processes the requested messages and provides responses to one or more secure network servers to securely copy to the client browser and display via the integrated client interface, thereby enabling a client to manage sue valoree in communication network.

The integrated system as claimed in claim 1, wherein the one or more secure network servers supports a secure socket layer communications protocol that includes secure socket connections for cryptic language encrypted communication between the secure search engine. client and secure network server, the secure server also provides session management that includes identification, validation, rights and encoding in cryptic language of the client to link the session with the client.

3. The integrated seventh as claimed in claim 2, further comprising a dispatcher server for communicating with a secure network server and a plurality of remote application resources, the dispatcher server providing verification of system access and generation of representative for system resources after the client's rights have been verified.

4. The integrated system as claimed in claim 2, wherein the seventh includes digital certificates to authenticate a secure network server to the client network browser.

The integrated system as claimed in claim 2, wherein the graphical user interface based on copied network comprises a backplane object copied with, and released by the graphical user interface based on network, the backplane of the object capable of launching the one or more client applications after initiation by the client, the object of the foreground plan also enables the communications of interaplications between the client's applications and also with the backplane object, whereby the plan object The client applications interoperate with each other to provide the integrated client interface to a plurality of communication network management products and services to which the client subscribes.

The integrated system as claimed in claim 5, wherein a network management resource comprises a server for providing a client authentication function for copying an ealuating object that is to be launched by the graphical user interface based on in network, the greeting object capable of accepting greeting transactions from the client and creating a session object to communicate with the first server to provide client authentication, whereby after the successful validation of the client, the greeting object sends a order to the authentication server to send the one or more applications of the client and the graphical user interface displayed on the network that has the backplane object.

7. The integrated system as claimed in claim 6, further comprising: a user object to represent a current client, the user object also communicates with the authentication server to determine the rights of the client to the services of administration of network enabled communications network, through which the backplane uses the rights to display via the integrated interface only those services and products enabled by network to which the user has the privilege.

8. The integrated system as claimed in claim 7, wherein a client application is invoked directly by the backplane object when the user selects the service associated with the client application, the selected client application is executed in a independent frame of the window of the search engine of the network.

9. The integrated system as claimed in claim 7, wherein the client application is a program launched from the search window created by the backplane.

The integrated system as claimed in claim 7, wherein the backplane object maintains the session information received from a network management resource in static memory for the duration of a session, and enables the client application. to have access to the static memory, which eliminates the need for each of the client's applications to communicate with the remote network administration resources once the information has been obtained.

11. The integrated system as claimed in claim 7, further comprising a set of common graphical user interface objects to enable client applications and the backplane to provide common view and feel features of computer window management desktop.

The integrated system as claimed in claim 10, wherein a network management resource comprises a server for providing a client data reporting management function comprising a data base for maintaining a report inventory associated with a client, and a client application that includes: a report requester application that enables the creation and scheduling of specific client reports related to the use of their commuted communications networks and that initiates the generation of report request messages for the one or more network management resources via the integrated interface; and, an application of observer of reports that enables the display of the reports according to the reporting options to which the client is entitled.

13. The integrated system as claimed in claim 12, wherein the report manager server has access to report elements from the database in accordance with a received report request message, and generates a response message which includes a description of the metadata of the reporting elements to be included in said report, whereby specific data of the client from a recureo of network administration and the description of the metadata of the report elements selected by the client they use to generate a complete report for the presentation to the client via the integrated interface.

14. The integrated seventh as claimed in claim 13, wherein the report requester application enables the personalization of report elements that are included in the client's report, the server to provide a client authentication function that provides the report elements capable of being customized according to the client's rights to the application of the requestor of reports when a report request message is generated.

15. The integrated system as claimed in claim 13, wherein a network management resource further comprises a report scheduler system for initiating the periodic generation of reports from other network administration recourages at a frequency specified by the client.

16. The integrated seventh as claimed in claim 15, wherein a network management resource includes a data base for storing and maintaining data from customer-specific reports that are to be reported to the customer, and a cash server centralized input to receive a report availability response from the report administration server that includes a metadatoe subscription to generate the report, the input box server copies the specific customer report data stored and the metadata description associated with the report data to said customer work station via a secure network server for the generation and pre-presentation of the client's report via the integrated interface.

17. The integrated system as claimed in claim 16, a client application comprises an input box client application launched by the backplane to store a notification alert received from the inbox server, the client application of the input box that receives and presents the alert notification to the customer via the integrated interface.

18. The integrated seventh as claimed in claim 17, wherein the application of the input box client further includes a scrolling string to detect an input message from the input box server via a secure first connection, the string of counting also initiates a new rope after the detection of the input maneuver, where the new string starts and listens to a second secure connection to detect new messages, while the counting string receives the input message on a secure first connection, whereby multiple messages can be copied simultaneously as they are detected.

19. The integrated seventh as claimed in claim 16, wherein the database for storing and maintaining the client-specific report data further comprises a predefined directory associated with each of the one or more network administration resources, wherein each of the one or more network management resources stores the report data and notification alert data to its respective predefined directory on the inbox server.

20. The integrated system as claimed in claim 16, wherein a network administration resource provides a call detail and price reporting function with price to provide customer-specific data regarding the use of a customer's switched communications network.

21. The integrated system as claimed in claim 20, wherein the network management resource that provides a detailed call data reporting function with price comprises: a system for extracting detailed call data records from the billing systems that generate detailed records of calls with specific price to a communication network of a client, a schedule to collect the details of calls with prices extracted for storage in a database storage device, - and a decision support server to receive customer request messages for price details of call details, the decision support server has access to call detail data with specific price of the customer from the base storage device of data and transmit the data of details of calls with specific price of the client to the AC server Input ja in accordance with the client's request.

22. The integrated system as claimed in claim 21, wherein the report option includes executing a predefined report at a predetermined frequency, the seventh reporter communicates a push to the decision support e-server to execute a predefined report to the default frequency, each of the predefined reports being updated with recent details of call details with specific customer prices available at runtime.

23. The integrated system as claimed in claim 16, wherein a network management resource provides a call detail data reporting function with near real-time price to provide specific data of the client relative to the time of the call. The customer's commuted communication network, receiving the service of detail reporting of calls at a price of the customer's request for the details of the customer's specific priceless call details and transmitting the details of the call details without specific price of the client. to the cashier server according to the customer's request.

24. The integrated system as claimed in claim 23, wherein a report option includes executing a data report of call details with no price defined at a predetermined frequency, the seventh reporter communicates a link to a report server Call details data with no price to obtain recent details of call details without customer-specific price.

25. The integrated system as claimed in claim 23, wherein a network management recoupment comprises: a seven to generate statistical data based on real-time call data obtained from a circuit switched communications network, being generated the statistical data according to the rights of the client; and »a client application to integrate the statistical data retrieved within a graphical user-interface network-based interface for presentation to the client via the integrated interface, the graphical user interface based on network being updated to contain statistical data in time intervals specified by the client.

26. The integrated system as claimed in claim 25, wherein the customer's right includes the specification of the one or more toll-free numbers associated with the customer's communications network for which statistical data are to be generated.

27. The integrated system as claimed in claim 26, wherein the system for generating statistical data includes a script mechanism to initiate the update of the graphical user inferió based on network with the most recent statistical data.

28. The integrated system as claimed in claim 25, wherein the network management resource comprises: a communications network configuration device for maintaining an inventory of customer network call routing plans and details of the plans of routing associated calls, and connecting to a plurality of network control elements to configure a customer communications network in accordance with a desired call routing plan; and, a network management server to receive messages from client requests to access the details of the call routing plans from the diepoeitive of the communication network configuration, retrieving the details of the call routing plan from agreement with the customer's rights, and copying the details of the call routing plan for the customer via the integrated interface.

29. The integrated system as claimed in claim 28, wherein the application of the reporter enables the generation of ropes that specify the modification of the client of the call routing plan, receiving the administration server of the network via the messages the integrated interface and translating the modification request received in commands to enter them in the network configuration die, whereby the commands are sent to the network control elements to configure the client network according to the request.

30. The integrated system as claimed in claim 29, wherein the modification request message includes a unique client identifier that enables the copying of specific call routing plan details associated with the customer identifier.

31. The integrated system as claimed in claim 30, wherein a client request message includes an order to modify an existing client network call routing plan for a predetermined period of time, by enabling the administration server of the client. network, the client network automatically reverts to a corresponding call routing plan configured before the invocation of the order at the reversion time specified by the client.

32. The integrated system as claimed in claim 31, wherein the client request message includes an order to modify a percentage assignment of routed call traffic to a network number used in a particular call routing plan during a call. predetermined time period, enabling the network administration server to allocate call traffic routed to a number to automatically revert to a corresponding percentage assignment specified before the invocation of the order at the reversion time specified by the client.

33. The integrated system as claimed in claim 28, wherein the network management resource comprises: a client's switched data circuit network, and, a device for periodically polling customer switches of the circuit network of switched data to obtain network performance data related to it and temporarily store the performance data of the network, - The integrated seventh also comprises: a broadband network server to receive customer request messages to report network performance data, retrieve network performance data in accordance with the client's right and copy the data. of performance of the network to the client for presentation via the integrated interface.

34. The integrated seventh as claimed in claim 33, wherein the report observer application enables the deployment of broadband network reports according to selected customer reporting options, the options of the customer report include the specification of view graphs, tabular, and maps of the performance data of the network.

35. The integrated system as claimed in claim 34, wherein the application of the report observer includes support for the simultaneous multiple-bandwidth reporting of the performance data of the specific broadband network.

36. The integrated system as claimed in claim 35, wherein the customer's switched data network generates alarm status indications, with the broadband network server receiving alarm status indications in relation to the customer's network. and communicating the alarm status data to the client workstation and the integrated interface.

37. The integrated system as claimed in claim 36, wherein the application of the requestor of reports enables the generation of messages that specify the performance thresholds of the network to enable the reports of the behavior of the specific data network via the interface integrated

38. The integrated system as claimed in claim 37, wherein the reporter observer supports the display of a graphical view comprising an area map view having indicators representing locations of a customer data network. The report observer application enables the client to select the indicators in the graphical representation and provide a textual view of the performance characteristics of the network related to the physical circuits eoported in the place of the selected network.

39. The integrated system as claimed in claim 38, wherein the physical circuits supported at the selected network site include permanent virtual circuits.

40. The integrated system as claimed in claim 33, wherein a network management recirculation includes a system to provide an alarm management function that includes a device for deriving performance alarms based on efficiency data collected on performance. from a customer data network; The integrated system also includes: an event monitor server to receive and store the network's performance features and the alarms derived from the bypass device, and communicate the performance statistics of the network and the derived alarms for the presentation to the client via the integrated interface.

41. The integrated seventh as claimed in claim 40, wherein the application of the report requestor also enables clients to define and present network performance thresholds that specify the formation of specific network behavior reports via the network. integrated interface, the event monitor server enables filtering of network alarms and performance statistics according to the threshold defined by the client for presentation to the client at the client workstation.

42. The integrated seventh as claimed in claim 41, wherein the application of the report requestor also enables the clients to define and introduce problem detection procedures for specific alarms or circuits in relation to the data network via the interface integrated

43. The integrated system as claimed in claim 42, wherein a client application associated with the event monitor server enables clients to acknowledge a network alarm, via the integrated j interface, comprising the server event monitor a process for automatically launching the problem detection procedure after an acknowledgment of the alarm associated with the problem detection procedure.

44. The integrated seventh as claimed in claim 28, wherein a network management resource includes a system for generating billing documents related to the communication management services provided by the communications service company; The integrated system also comprises: a client application copied from the secure network server to enable the selection and pre-presentation of invoice documents according to the client's rights, the client application also generates a bill request message in response to the customer's selection of a specific invoice option and send the invoice request message via the secure network server; and an invoice application server to maintain a database of image files associated with billing documents for the application service and receive the invoice request message, the invoice application server has access to the database as response to a request message, generates a reply message that includes an invoice document selected from the client, and copies the reply response to the client's workstation, whereby the client's selected invoice document is formatted from a convenient way for its visualization via the integrated client interface.

45. The integrated seventh as claimed in claim 44, wherein the database of the image files further includes an object database, the invoice application server further comprising: a conversion process for forming image images; documents defining the key information needed to retrieve documents from the communications application service and compress the documents for storage; and storage process to load the compressed documents in the object database.

46. The integrated system as claimed in claim 45, wherein the database of image files also includes an index database, the invoice application server further includes index loading process for storing the bookmarks of indexes that indicate the compressed documents in the index database.

47. The integrated system as claimed in claim 28, wherein a network management resource further comprises a system for providing a circuit-switched call center management function, the integrated system also comprising: a copied client application From the secure network server to enable a client to monitor, define, and manipulate call routing parameters, the client application also formats the parameters defined by the client in client message transactions and communicates the client's message tranactions to the secure server over the secure connection, - and, a routing machine device to maintain call routing rules and to connect with the plurality of network control elements to direct routing and call reception data statistics, the Routing machine also uses the rules, data statistics, and parameters of defined by the client to determine where to route the calls, through which the client control of routing calls via the integrated interface is enabled.

48. The integrated seventh as claimed in claim 47, further comprising a representative server for processing a plurality of transaction requests received from the client application via the secure server by opening a connection to the routing machine device by retrieving information related to the request for tranecting and sending the information back to the client's application via the secure server, and where the client's application presents the information to the client at the client's workstation.

49. The integrated system as claimed in claim 48, further comprising one or more databases for storing the data statistics generated by the routing machine device and the plurality of network control elements, the one or more databases reside within the representative server, the proxy server also processes locally predetermined transaction requests retrieving information related to transaction requests from one or more databases and sends the information to the client's application. .. f

50. The integrated system as claimed in claim 3, wherein the administration of seeionee provided by the secure server includes a generation of network cookies in each instance of client identification to link a session with the client through a plurality of communications. of discrete clients in the session to verify the client with the dispatcher server in each transmission in said session.

51. The integrated seventh as claimed in claim 50, wherein the cookie is generated by a program in a separate server during a right communication, after the identification and authentication of the client.

52. The integrated seventh as claimed in claim 51, wherein the secure socket layer of the client's network browser encodes in cryptic language client identification, authentication and session management cookie during each transmission.

53. The integrated seven as claimed in claim 52, wherein the session cookies provide simultaneous session management for a plurality of system resource platforms.

54. The integrated system as claimed in claim 53, which further includes encryption in RSA cryptic language for the transmission of all client data between the secure network server and the dispatcher server, and encryption in SSL cryptic language for transmission. of all customer data between the secure network server and the client's network browser.

55. The integrated system as claimed in claim 54, wherein each client request from the network browser is encoded in cryptic language with a public key provided by the communication network, and each of the client requests includes a client cookie encoded in cryptic language for client authentication.

56. The integrated system as claimed in claim 28, which further comprises: a client application copied from the secure network server to enable a client to generate ticket problems that are to be processed by a ticket resolution entity; and, a service request application server to receive requests for ticket information from a customer, translate the requests into commands to retrieve information from problem tickets from the diepoeitive configuration of the communications network, and copy response messages that they include the problem ticket information requested from the customer via the integrated interface.

57. The integrated system as claimed in claim 28, further comprising: a client application copied from the secure network server to enable the client to manage and schedule network administration features outside of the aociated limit with the network of customer communication, - and, an out-of-limit network administration server to receive requests for off-limit network management features associated with the customer's network that include call party numbers, dial plans, card number, call and sets of customer identification codes, or, combinations thereof, translate the requests received in the command to retrieve the information of the characteristics of the network management out of limit from the configuration device of the communication network, and copy the response messages that include the information of the characteristics and network management beyond the limit requested from the client via the integrated interface.

58. A method for enabling client management of their communications network values via the public Internet, including provision of a plurality of services and products accessible from a client workstation using the client network browser associated with a client. client capable of receiving network-based communications from the provision of the communications service that provides the products and services, the method comprising the steps of: (a) enabling interactive communications between the system and the client over the public Internet with a protocol oriented to the object invoked from within the client network browser, the protocol supporting the identification of the client, the authentication and a determination of network rights for the client; (b) administering a plurality of client sessions on the public Internet with a secure network server, providing the secure network server encryption in cryptic language of the site and administration of the client session, administration of the session includes the steps to identify, validate, and determine the client's rights within the network; (c) initiating the copying of a network-based user graphical interface from the secure network server, the network-based graphical user interface capable of launching one or more of a plurality of client applications available to a client in accordance with default client rights, (d) provide an integrated client interface within the network-based graphical user interface after launching a selected client application, enabling the client interface interactive communication of request messages with one or more of a plurality of communication network management resources capable of providing a selected communication network management function; (e) a communication network management resource that receives the request messages, generates a representative request corresponding to a request message, provides responses according to the request, and communicates these replies to the secure network server for the copy secure to the client's workstation for viewing via the integrated interface, whereby the client's management of their communication network administration values via the public Internet is enabled.

59. The method as claimed in claim 58, wherein the secure network server supports a secure sockets layer communications protocol, the secure network server supports the securee connections for the encoded communication in cryptic language between the Client network browser and secure network server, the secure server also provides session management including identification, client validation, and session management to link the session with the client.

60. The method as claimed in claim 58, further comprising providing a dispatcher server to communicate with a secure network server and each of < a plurality of network administration resources, the dispatcher server verifies access to the system and the representative generation for system resources after the rights of the client are verified.

61. The method as claimed in claim 60, which also employs digital certificates to authenticate a 10 secure network server to the client network browser. PP

62. The method as claimed in the claim 60, wherein the graphical user interface based on copied network comprises a backplane object copied with, and launched by the graphical user interface based on network, the The backplane object launches the application programs of the client after the initiation by the client, the backplane object also enables the inter-application communications between the client's applications and also with the backplane object, whereby the object of The backplane and client applications interoperate with each other to provide the integrated client interface to a plurality of communication network management products and services subscribed by the client.

63. The method as claimed in the claim 25 62, wherein a network management resource comprises a server for providing a client authentication function, the method comprising: copying a greeting object to be launched by the network-based graphic user interface; accept the greeting transactions from the client and create a domain object to communicate with the authentication server to provide authentication to the client; and, after successful validation of the client, send a command to the authentication server to copy the one or more client applications and the network-based graphical user interface having a backplane object.

64. The method as claimed in claim 63, further comprising: providing a client object to represent a current client, the client object ee communicates with the authentication server to determine the rights of the client to the administration services of the client. network of communications enabled in network, by means of which the posterior plane uses the rights to exhibit via the integrated interface only those services enabled by network to which the client has the privilege.

65. The method as claimed in claim 64, which further includes the step of: executing a client application directly by the downstream object when the client selects a client application associated with a desired communication network management service , the e-selected client application is executed in a frame independent of a client finder window.

66. The method as claimed in claim 65, which further includes the step of: maintaining the session information received from a network administration recureo in eetática memory during the duration of a session, and enabling the client applications to have access to static memory, which eliminates the need for each of the client's applications to communicate with remote network administration resources servers once the information has been obtained.

67. The method as claimed in the claim 65, wherein the client applications use a common user interface graphical user interface and the backplane to provide common view and window management features of the desktop computer window.

68. The method as claimed in the claim 66, wherein a network management resource comprises a report management server to provide a management function for client data reports and a database for maintaining an inventory of the reports associated with a client, the method also includes: providing a client application requesting reports that enables the creation and programming of specific customer reports related to the use of their switched communication networks and initiate the generation of request reports for one or more of network administration resources via the integrated interface and provide a report observer application that enables the visualization of reports according to the reporting options to which the client is entitled

69. The method as claimed in the claim 68, which also includes: having access to elements of reports from the database of the inventory reports according to a received report request message; and, generate a response message that includes a description of metadata of report elements that are to be included in the report, whereby the client-specific data from a network administration resource and the description of the metadata of The elements of the report selected by the client are used to generate a complete report for the presentation to the client via the integrated interface.

70. The method as claimed in the claim 68, where the application of requestor of reports enables the customization of the elements of reports that are included in the report to the client, providing the authentication server the elements of reports capable of being customized according to the rights of the client to the application of the requestor of reports when a report request move is generated.

71. The method as claimed in the claim 69, which also includes: providing a seventh report scheduler to initiate the periodic generation of reports from the network administration resources at a frequency specified by the client.

72. The method as claimed in the claim 71, where a network administration resource includes a database to store and maintain data from client-specific reports that are to be reported to the client, and, a centralized inbox server to receive a report availability response from the report management server that includes a description of metadata to display the report, including the method: copy the data of the specific report of the stored client and the description of the metadata associated with the data of the report from the cashier server entry to the client workstation via the secure network server for the generation and pre-presentation of a client report via the integrated interface. •

73. The method as claimed in claim 5, wherein the entry box server stores a notification alert received from a network administration resource that a generated report is available, including the method: a 10-entry cash client application from the backplane to receive and present • the customer notification alert via the integrated interface.

74. The method as claimed in claim 73, further comprising: implementing a scrolling string in the application of the input box client to detect an input message from the input box server via a secure first connection , - start a new rope after detection 20 of the input jog, where the new string starts and listens on a second secure connection to detect new messages, while the counting string receives the input message on a secure first connection, whereby multiple copies can be copied 25 messages simultaneously as detected.

75. The method as claimed in claim 74, which further includes: defining a previously defined directory in the input box server and a database of data storage of specific reports, with a predefined directory attached to each of the one or more network management resources, each of the network administration resources stores report data and notification alert data in its respective predefined directory on the inbox server.

76. The method as claimed in claim 74, wherein the network management facility provides a process for reporting call detail data with a price to provide customer-specific data related to the use of a dial-up communication network. client, comprising the procedure of reporting detail data of calls with price the steps of: extracting records of detail data of calls from the collection systems that generate records of details of calls with specific price to a communication network of the client, collect the logs of details of calls with extracted prices for storage in a database storage device, - and implement the decision support server to receive data request request from the customer of details of calls with price, have access to the detail data of calls with specific price of the client from the device of a storage of database, and transmit the details data of calls with specific price from the client to the cashier of the entry box according to the request of the client.

77. The method as claimed in claim 76, further comprising: executing a predefined report at a predetermined frequency, the report scheduler system communicates a message to the decision support server to execute the predefined report at the predetermined frequency, each predefined report is updated with recent details of call details with specific customer price available at a runtime.

78. The method as claimed in claim 74, wherein a network management recourage provides a call detail data reporting function with near real-time price to provide detail data of customer-specific calls with no price. relation to the use of a client's switched communications network, comprising the method: providing a server with detailed data reports of calls without price to receive customer request messages for details of call details without price, - obtain details data of calls without specific price of the client, - and transmitting details of specific call data of the customer to the cashier server according to the customer's request.

79. The method as claimed in claim 78, wherein a report option includes executing a detail data report of priceless calls defined by the client at a predetermined frequency, communicating to the reporting program system a message to the server of Data detail data reports without price to obtain the recent details of call details without specific price of the client.

80. The method as claimed in claim 78, wherein a network management recoupment comprises a system for generating statistical data based on real-time call data obtained from the circuit switched communication network, the statistical data being generated. in accordance with the rights of the client, including the method: integrate the statistical data recovered within a graphical user interface based on a network for presentation to the client via the integrated interface, with the graphical visual interface based on updated network to contain statistical data at intervals of time • specified by the client. 5

81. The method as claimed in the claim 80, which also includes specifying one or more toll-free numbers associated with the customer's communications network for which statistical data will be generated.

82. The method as claimed in claim 10 80, which further comprises: implementing a writing mechanism to initiate the updating of the visual graphic interface networked with the most recent statistical data.

83. The method as claimed in claim 15, wherein a network management resource comprises a communication network configuration device for maintaining an inventory of client network call routing plans and details of the routing plan. of associated calls, and connect with a plurality of network control elements 20 to configure a customer communications network in accordance with a desired call routing plan; The method further comprises: providing a network administration server to receive customer request messages to have 25 access to the details of the call routing plan from the communication network configuration device; retrieve the details of the call routing plan according to the rights of the client, - and, copy the details of the routing plan 5 calls for presentation to the customer via the integrated interface.

84. The method as claimed in claim 83, which also comprises: generating a request from the client that 10 specify the modification of the routing plan client ^ P calls, the network administration server receiving the request messages via the integrated interface and translating the received change request into commands to be entered into the network configuration device, - and, 15 send the commands to the network control elements to configure the client's network according to the request.

85. The method as claimed in claim 84, wherein a customer request message includes a 20 unique client identifier that enables the copying of specific call routing plan details and associated with the customer's identifier.

86. The method as claimed in claim 83, further comprising: generating a customer request message including an order to modify an existing customer network call routing plan for a specified period of time, enabling the network administration server the client network to automatically revert to a corresponding call routing plan configured before the invocation of the order at the reversion time specified by the client.

87. The method as claimed in claim 83, further comprising: generating a customer request message including an order to modify a percentage of call traffic and routing to a network number used in a call routing plan particular for a predetermined period of time, enabling the network administration server to allocate call traffic routed to the number to automatically revert to a specific corresponding percentage assignment prior to invocation of the order at a reversion time specified by the customer.

88. The method as claimed in claim 83, wherein a network management resource comprises: a switched data circuit network of the client; and, a device for periodically scanning network switches of the switched data circuit network to obtain network performance data related thereto and temporarily storing the network performance data, further comprising the method: providing a network server broadband to receive customer request messages to report network performance data; recover network performance data from temporary storage in accordance with customer rights; and, copy the network performance data to the client for presentation via the integrated interface.

89. The method as claimed in claim 88, which further comprises: enabling the deployment of broadband network reports in accordance with selected customer reporting options, the client report options include specification of vistae graph, tabularee and of maps of the performance data of the network.

90. The method as claimed in claim 88, wherein the report observer application includes supporting multiple simultaneous graphs reports of data specific to the performance of the broadband network.

91. The method as claimed in claim 88, wherein the customer switched data network generates alarm status indications, the broadband network server receiving the alarm status indications in relation to the customer's network and communicating the alarm status data to the client workstation via the integrated interface.

92. The method as claimed in claim 91, further comprising the step of generating client request messages that specify network performance thresholds to enable reporting of the behavior of the specific data network via the integrated interface.

93. The method as claimed in claim 92, wherein the report observer supports the display of a graphical view comprising an area map view having indicators representing locations of a customer data network, including the method Enable the client to select the indicators in the graphic representation and provide a textual view of the performance characteristics of the network related to physical circuits supported in the place of the selected network.

94. The method as claimed in claim 88, wherein a network management resource includes a system for providing an alarm management function that includes a device for deriving performance alarms based on performance statistics collected on the performance of a customer data network, -including in addition to the method: provide an event monitor server to receive and store the network's performance data and the derived alarms from the derivative device, and communicate the performance statistics of the network and the derived alarms for the pre-presentation to the client via the integrated interface.

95. The method as claimed in claim 94, which also enables the clients to define and present network performance thresholds by specifying the specific network behavior report via the integrated interface, the event monitor server filters the alarms of the network and the performance statistics according to the threshold defined by the client for presentation to the client at the customer's workstation.

96. The method as claimed in claim 95, which further enables clients to define and introduce problem detection procedures for specific alarms or circuits in relation to the data network via the integrated interface.

97. The method as claimed in claim 96, which provides a client application to enable clients to acknowledge a network alarm, via the integrated interface, by automatically launching the event monitor server and a detection procedure. problem after recognition of the associated alarm with the problem detection procedure.

98. The method as claimed in claim 72, wherein a network management resource includes a system for generating invoice documents related to the communication network administration services provided by the communication service company, further comprising the method: copy a client application from the secure network server to enable the selection and preelection of invoice documents according to the client's right, - generate customer request e-mails that include the selection of the client from a specific invoice option; provide an invoice application server to maintain a database of image files associated with billing documents for the application service, the invoice application server: receive the invoice request message from the client; have access to the database in response to the request message; generate a response message that includes an invoice document selected by the customer, - copy the response message to the client workstation, - and, format the customer's selected invoice document in a convenient manner for deployment via the interface of integrated client. •

99. The method as claimed in claim 5, wherein the data bank of the image files further includes a database object, the invoice application server further: converts the invoice documents into images; defines the key information needed to 10 retrieve documents from the resource application service of • management of communications network and compress the documents for storage; and load the compressed documents in the object database. 15

100. The method as claimed in the claim 99, wherein the database of image files further includes an index database, the method further includes storing index pointers to indicate the compressed documents in the index database.

101. The method as claimed in the claim 72, wherein the network management resource further comprises a seventh to provide a circuit-switched call center management function, the method further comprising: copying a client application from the secure network server to enable a client to monitor, define, and manipulate call routing parameters, the client application also formats parameters defined by the client in client message transactions and communicates the client message transactions to the secure server over the secure connection; provides a routing machine device to maintain call routing rules and connect with the plurality of network control elements to direct call routing and receive data statistics, the routing machine device also uses the rules, the data statistics, and the parameters defined by the client to determine where to route the calls, by means of which the call routing client control is enabled via the integrated interface.

102. The method as claimed in claim 101, further comprising: processing a plurality of transaction requests received from the client application via the secure server by opening a connection to the router machine device; and, retrieve information related to the transaction request and send the information back to the client's application via the secure server, presenting the customer's application the information to the client at the customer's workstation via the integrated interface.

103. The method as claimed in claim 102, further comprising: providing one or more databases for storing the data statistics generated by the routing machine device and the plurality of network control elements, the one or more databases operating together with a representative server to process locally predetermined transaction requests by retrieving information related to the transaction requests from the one or more database, and sending the information to the client's application .

104. The method as claimed in claim 60, further comprising the step of generating a network cookie on each client identification facility to link a client to the client through a plurality of discrete client communications on the site. to verify the client to the dispatcher server in each transmission in the session.

105. The method as claimed in the claim 104, where the cookie is generated by a program on a separate server during a communication of rights, after the identification and authentication of the client.

106. The method as claimed in the claim 105, which also includes: coding in cryptic language client identification, authentication and session management cookie during each transmission.

107. The method as claimed in the claim 106, wherein session cookies provide simultaneous session management for a plurality of the system's resource platforms.

108. The method as claimed in the claim 107, which also includes coding in cryptic language the transmission of all client data between the secure network server and the dispatcher server using encryption in cryptic RSA language, and coding in cryptic language the transmission of all client data between the server Secure network and client network server using encrypted SSL cryptic language.

109. The method as claimed in the claim 108, which also includes coding in cryptic language each client request from the network browser with a public key provided by the communications network, and each of the client requests includes a client cookie encoded in cryptic language for the client. client authentication.