US20060129499A1 - Integrated proxy interface for web based data management reports - Google Patents

Integrated proxy interface for web based data management reports Download PDF

Info

Publication number
US20060129499A1
US20060129499A1 US11/348,798 US34879806A US2006129499A1 US 20060129499 A1 US20060129499 A1 US 20060129499A1 US 34879806 A US34879806 A US 34879806A US 2006129499 A1 US2006129499 A1 US 2006129499A1
Authority
US
United States
Prior art keywords
report
data
server
customer
reporting
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/348,798
Inventor
Curtis Combar
Carol Devine
William Flentje
Robert Pfister
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Verizon Patent and Licensing Inc
Original Assignee
MCI LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MCI LLC filed Critical MCI LLC
Priority to US11/348,798 priority Critical patent/US20060129499A1/en
Publication of US20060129499A1 publication Critical patent/US20060129499A1/en
Assigned to WORLDCOM, INC. reassignment WORLDCOM, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI WORLDCOM, INC.
Assigned to MCI, LLC reassignment MCI, LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: MCI, INC.
Assigned to VERIZON BUSINESS GLOBAL LLC reassignment VERIZON BUSINESS GLOBAL LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI, LLC
Assigned to MCI, INC. reassignment MCI, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: WORLDCOM, INC.
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERIZON BUSINESS GLOBAL LLC
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: VERIZON BUSINESS GLOBAL LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/04Billing or invoicing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/18Delegation of network management function, e.g. customer network management [CNM]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99939Privileged access

Definitions

  • the present invention relates generally to information delivery systems and, particularly, to a novel, World Wide Web/Internet-based, telecommunications network data management reporting and presentation service for customers of telecommunications service entities.
  • Telecommunications service entities e.g., MCI, AT&T, Sprint, and the like, presently provide for the presentation and dissemination of customer account and network data management information to their customers predominantly by enabling customers (clients) to directly dial-up, e.g., via a modem, to the entity's application servers to access their account information, or, alternatively, via dedicated communication lines, e.g., ISDN, T-1, etc., enabling account information requests to be initiated through their computer workstation running, for example, a Windows-based graphical user interface.
  • the requests are processed by the entity's application servers, which retrieves the requested customer information, e.g., from one or more databases, processes and formats the information for downloading to the client's computer workstation.
  • unpriced call detail data pertains to a customer's telecommunications traffic, i.e., number usage. This type of data is provided in near real-time, and is used by network managers to make business decisions regarding their telecommunications networks.
  • MCI ServiceView MCI ServiceView
  • TrafficView MCI ServiceView
  • One of these applications referred to as “TrafficView”
  • TrafficView server provides network traffic analysis/monitor information as provided from an MCI TrafficView server.
  • customers are provided with unpriced call detail data, e.g., relating to their toll free networks.
  • the current TrafficView architecture is organized primarily as a batch midrange-based server data delivery mechanism with the data being typically “canned” delivered at predetermined times with predetermined formats. Additional trending, analysis, and data management functionality is maintained by the customers in workstation-based software provided to customers for installation at customer sites on their PCS.
  • the present invention is directed to a novel Intranet/Internet/Web-based data management system that provides a common GUI enabling the requesting, customizing, scheduling and viewing of various types of reports pertaining to customer's telecommunications network traffic, i.e., unpriced “traffic view” data.
  • the Intranet/Internet/Web-based data management system comprises a Web-based, client-server application that enables customers to access their own relevant unpriced network traffic data information timely, rapidly and in a secure manner through the a client GUI.
  • a client server application infrastructure enables processing, generation, and reporting of customer's real-time and rated inbound and outbound telecommunications traffic for network management, call center management and customer calling pattern analysis functions.
  • the system further employs a platform-independent, i.e., JAVA-based, network centric GUI client presentation layer and an objects/dispatcher/proxy layer access architecture.
  • a platform-independent, i.e., JAVA-based, network centric GUI client presentation layer and an objects/dispatcher/proxy layer access architecture i.e., JAVA-based, network centric GUI client presentation layer and an objects/dispatcher/proxy layer access architecture.
  • the telecommunications data management/system architecture is integrated with a novel Web/Internet-based reporting tool, referred to as “StarWRS”, described in co-pending U.S. patent application Ser. No. ______ (D#11050).
  • the StarWRS web-based reporting tool comprises a layer functioning to enable customers to request reporting functionality across the Internet.
  • This report request functionality includes routing requests to appropriate databases, e.g., real-time reporting requests will be satisfied by real-time database.
  • the interface provides customers with the ability to schedule and prioritize reports, format report request result sets, and provides for load balancing, report request validation, query generation and execution. Through a common GUI, customers are enabled to access their own unmetered network traffic data, i.e., usage analysis data.
  • a Web/Internet based reporting system for communicating call detail information relating to traffic pertaining to a customer's telecommunications network to a client workstation via an integrated interface
  • a client browser application located at the client workstation for enabling interactive Web based communications with the reporting system, the client workstation identified with a customer and providing the integrated interface
  • at least one secure server for managing client sessions over the Internet, the secure server supporting a secure socket connection enabling encrypted communication between the browser application client and the secure server
  • a report manager server in communication with at least one secure server for maintaining an inventory of reporting items associated with a customer, the reporting items comprising report data types and report customization features for reports to be generated for the customer
  • a data retrieval device for retrieving customer specific data from the customer's telecommunications network at pre-determined times
  • a requestor application enabling the customer to communicate a data report request message via the integrated interface to the report manager server, the request message comprising a metadata description of particular reporting items to be retrieved
  • FIG. 1 illustrates the software architecture component comprising a three-tiered structure
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system
  • FIG. 3 is an illustrative example of a backplane architecture schematic
  • FIG. 4 illustrates an example client GUI presented to the client/customer as a browser web page
  • FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture
  • FIG. 6 is a block diagram depicting the physical architecture of the StarWRS component 200 of the networkMCI Interact system
  • FIG. 7 is a schematic diagram depicting the nMCI Interact Traffic View system 500 for reporting customer's unpriced call detail data substantially in real-time;
  • FIG. 8 is an general flow diagram of the process by which the TVS server 550 gets data.
  • FIG. 9 is a detailed flow diagram depicting the internal TVS server processes for receiving customer TVS enablement data from order entry and CORE systems;
  • FIG. 10 is a high-level diagram depicting TCR data flow between processes internal to the TVS server
  • FIG. 11 is a high-level flow diagram depicting TVS report generation process
  • FIGS. 12 ( a )- 12 ( d ) illustrate the end-to-end process 700 for fulfilling unpriced call detail data report requests
  • FIG. 13 illustrates a logical message format sent from the client browser to the desired middle tier server for a particular application
  • FIGS. 14 ( a ) and 14 ( b ) are schematic illustrations showing the message format passed between the Dispatcher server and the application specific proxy ( FIG. 14 ( a )) and the message format passed between the application specific proxy back to the Dispatcher server ( FIG. 14 ( b )).
  • the present invention is one component of an integrated suite of customer network management and report applications using a Web browser paradigm.
  • nMCI Interact networkMCI Interact system
  • Such an integrated suite of Web-based applications provides an invaluable tool for enabling customers to manage their telecommunication assets, quickly and securely, from anywhere in the world.
  • nMCI Interact system architecture is basically organized as a set of common components comprising the following:
  • FIG. 1 is a diagrammatic illustration of the software architecture component in which the present invention functions.
  • a first or client tier 10 of software services are resident on a customer work station 10 and provides customer access to the enterprise system, having one or more downloadable application objects directed to front end business logic, one or more backplane service objects for managing sessions, one or more presentation services objects for the presentation of customer options and customer requested data in a browser recognizable format and a customer supplied browser for presentation of customer options and data to the customer and for internet communications over the public Internet.
  • applications are directed to front end services such as the presentation of data in the form of tables and charts, and data processing functions such as sorting and summarizing in a manner such that multiple programs are combined in a unified application suite.
  • a second or middle tier 12 is provided having secure web servers and back end services to provide applications that establish user sessions, govern user authentication and their entitlements, and communicate with adaptor programs to simplify the interchange of data across the network.
  • a third or back end tier 15 having applications directed to legacy back end services including database storage and retrieval systems and one or more database servers for accessing system resources from one or more legacy hosts.
  • the customer workstation includes client software capable of providing a platform-independent, browser-based, consistent user interface implementing objects programmed to provide a reusable and common GUI abstraction and problem-domain abstractions. More specifically, the client-tier software is created and distributed as a set of Java classes including the applet classes to provide an industrial strength, object-oriented environment over the Internet.
  • Application-specific classes are designed to support the functionality and server interfaces for each application with the functionality delivered through the system being of two-types: 1) cross-product, for example, inbox and reporting functions, and 2) product specific, for example, toll free network management or Call Manager functions.
  • the system is capable of delivering to customers the functionality appropriate to their product mix.
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system including: the Customer Browser (a.k.a. the Client) 20 ; the Demilitarized Zone (DMZ) 17 comprising a Web Servers cluster 24 ; the MCI Intranet Dispatcher Server 26 ; and the MCI Intranet Application servers 30 , and the data warehouses, legacy systems, etc. 40 .
  • the Customer Browser a.k.a. the Client
  • DMZ Demilitarized Zone
  • the Customer Browser 20 is browser enabled and includes client applications responsible for presentation and front-end services. Its functions include providing a user interface to various MCI services and supporting communications with MCI's Intranet web server cluster 24 .
  • client tier software is responsible for presentation services to the customer and generally includes a web browser 14 and additional object-oriented programs residing in the client workstation platform 20 .
  • the client software is generally organized into a component architecture with each component generally comprising a specific application, providing an area of functionality.
  • the applications generally are integrated using a “backplane” services layer 12 which provides a set of services to the application objects which provide the front end business logic and manages their launch.
  • the networkMCI Interact common set of objects provide a set of services to each of the applications such as: 1) session management; 2) application launch; 3) inter-application communications; 4) window navigation among applications; 5) log management; and 6) version management.
  • the primary common object services include: graphical user interface (GUI); communications; printing; user identity, authentication, and entitlements; data import and export; logging and statistics; error handling; and messaging services.
  • GUI graphical user interface
  • FIG. 3 is a diagrammatic example of a backplane architecture scheme illustrating the relationship among the common objects.
  • the backplane services layer 12 is programmed as a Java applet which can be loaded and launched by the web browser 14 .
  • a typical user session starts with a web browser 14 creating a backplane 12 , after a successful logon.
  • the backplane 12 presents a user with an interface for networkMCI Interact application management.
  • a typical user display provided by the backplane 12 may show a number of applications the user is entitled to run, each application represented by buttons depicted in FIG. 3 as buttons 58 a,b,c selectable by the user. As illustrated in FIG.
  • FIG. 3 shows graphical user interface objects 56 a,b created and used by a respective application 54 a,b for its own presentation purposes.
  • FIG. 4 illustrates an example client GUI presented to the client/customer as a browser web page 80 providing, for example, a suite 70 of network management reporting applications including: MCI Traffic Monitor 72 ; an alarm monitor 73 ; a Network Manager 74 and Intelligent Routing 75 . Access to network functionality is also provided through Report Requester 76 , which provides a variety of detailed reports for the client/customer and a Message Center 77 for providing enhancements and functionality to traditional e-mail communications.
  • Report Requester 76 provides a variety of detailed reports for the client/customer and a Message Center 77 for providing enhancements and functionality to traditional e-mail communications.
  • the browser resident GUI of the present invention implements a single object, COBackPlane which keeps track of all the client applications, and which has capabilities to start, stop, and provide references to any one of the client applications.
  • the backplane 12 and the client applications use a browser 14 such as the Microsoft Explorer versions 4.01 or higher for an access and distribution mechanism.
  • a browser 14 such as the Microsoft Explorer versions 4.01 or higher for an access and distribution mechanism.
  • the client applications are generally isolated from the browser in that they typically present their user interfaces in a separate frame, rather than sitting inside a Web page.
  • COBackPlane 12 is an application backplane which launches the applications 54 a , 54 b , typically implemented as COApp.
  • COBackPlane 12 is generally implemented as a Java applet and is launched by the Web browser 14 . This backplane applet is responsible for launching and closing the COApps.
  • the backplane When the backplane is implemented as an applet, it overrides standard Applet methods init( ), start( ), stop( ) and run( ).
  • the backplane applet obtains a COUser user context object.
  • the COUser object holds information such as user profile, applications and their entitlements.
  • the user's configuration and application entitlements provided in the COUser context are used to construct the application toolbar and Inbox applications.
  • launchApp( ) method When an application toolbar icon is clicked, a particular COApp is launched by launchApp( ) method.
  • the launched application then may use the backplane for inter-application communications, including retrieving Inbox data.
  • the COBackPlane 12 includes methods for providing a reference to a particular COApp, for interoperation.
  • the COBackPlane class provides a getApp( ) method which returns references to application objects by name. Once retrieved in this manner, the application object's public interface may be used directly.
  • the aforesaid objects will communicate the data by establishing a secure TCP messaging session with one of the DMZ networkMCI Interact Web servers 24 via an Internet secure communications path 22 established, preferably, with a secure sockets SSL version of HTTPS.
  • the DMZ networkMCI Interact Web servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session. After establishing that the request has come from a valid user and mapping the request to its associated session, the DMZ Web servers 24 will re-encrypt the request using symmetric encryption and forward it over a second connection 23 to the dispatch server 26 inside the enterprise Intranet.
  • a networkMCI Interact session is designated by a logon, successful authentication, followed by use of server resources, and logoff.
  • the world-wide web communications protocol uses HTTP, a stateless protocol, each HTTP request and reply is a separate TCP/IP connection, completely independent of all previous or future connections between the same server and client.
  • the nMCI Interact system is implemented with a secure version of HTTP such as S-HTTP or HTTPS, and preferably utilizes the SSL implementation of HTTPS.
  • the preferred embodiment uses SSL which provides a cipher spec message which provides server authentication during a session.
  • the preferred embodiment further associates a given HTTPS request with a logical session which is initiated and tracked by a “cookie jar server” 28 to generate a “cookie” which is a unique server-generated key that is sent to the client along with each reply to a HTTPS request.
  • the client holds the cookie and returns it to the server as part of each subsequent HTTPS request.
  • either the Web servers 24 , the cookie jar server 28 or the Dispatch Server 26 may maintain the “cookie jar” to map these keys to the associated session.
  • a separate cookie jar server 28 as illustrated in FIG. 2 has been found desirable to minimize the load on the dispatch server 26 .
  • This form of session management also functions as an authentication of each HTTPS request, adding an additional level of security to the overall process.
  • one of the DMZ Web servers 24 decrypts and verifies the user session, it forwards the message through a firewall 25 b over a TCP/IP connection 23 to the dispatch server 26 on a new TCP socket while the original socket 22 from the browser is blocking, waiting for a response.
  • the dispatch server 26 will unwrap an outer protocol layer of the message from the DMZ services cluster 24 , and will reencrypt the message with symmetric encryption and forward the message to an appropriate application proxy via a third TCP/IP socket 27 . While waiting for the proxy response all three of the sockets 22 , 23 , 27 will be blocking on a receive.
  • the wrappers are examined to reveal the user and the target middle-tier (Intranet application) service for the request.
  • a first-level validation is performed, making sure that the user is entitled to communicate with the desired service.
  • the user's entitlements in this regard are fetched by the dispatch server 26 from StarOE server 49 at logon time and cached.
  • Each application proxy is an application specific daemon which resides on a specific Intranet server, shown in FIG. 2 as a suite of mid-range servers 30 .
  • Each Intranet application server of suite 30 is generally responsible for providing a specific back-end service requested by the client, and, is additionally capable of requesting services from other Intranet application servers by communicating to the specific proxy associated with that other application server.
  • an application server not only can offer its browser a client to server interface through the proxy, but also may offer all its services from its proxy to other application servers.
  • the application servers requesting service are acting as clients to the application servers providing the service. Such mechanism increases the security of the overall system as well as reducing the number of interfaces.
  • the network architecture of FIG. 2 may also include a variety of application specific proxies having associated Intranet application servers including: a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing; an Inbox proxy for the Inbox application server 31 , which functions as a container for completed reports, call detail data and marketing news messages, a Report Manager Proxy capable of communicating with a system-specific Report Manager server 32 for generating, managing and scheduling the transmission of customized reports including, for example: call usage analysis information provided from the StarODS server 33 ; network traffic analysis/monitor information provided from the Traffic view server 34 ; virtual data network alarms and performance reports provided by Broadband server 35 ; trouble tickets for switching, transmission and traffic faults provided by Service Inquiry server 36 ; and toll free routing information provided by Toll Free Network Manager server 37 .
  • a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing
  • an Inbox proxy for the Inbox application server 31 which functions as a container for completed reports, call detail data and marketing news messages
  • each Intranet server of suite 30 communicates with one or several consolidated network databases which include each customer's network management information and data.
  • the Services Inquiry server 36 includes communication with MCI's Customer Service Management legacy platform 40 ( a ).
  • Such network management and customer network data is additionally accessible by authorized MCI management personnel.
  • other legacy platforms 40 ( b ), 40 ( c ) and 40 ( d ) may also communicate individually with the Intranet servers for servicing specific transactions initiated at the client browser.
  • the illustrated legacy platforms 40 ( a )-( d ) are illustrative only and it is understood other legacy platforms may be interpreted into the network architecture illustrated in FIG. 2 through an intermediate midrange server 30 .
  • Each of the individual proxies may be maintained on the dispatch server 26 , the related application server, or a separate proxy server situated between the dispatch server 26 and the midrange server 30 .
  • the relevant proxy waits for requests from an application client running on the customer's workstation 10 and then services the request, either by handling them internally or forwarding them to its associated Intranet application server 30 .
  • the proxies additionally receive appropriate responses back from an Intranet application server 30 . Any data returned from the Intranet application server 30 is translated back to client format, and returned over the internet to the client workstation 10 via the Dispatch Server 26 and at one of the web servers in the DMZ Services cluster 24 and a secure sockets connection.
  • the resultant response header and trailing application specific data are sent back to the client browser from the proxy, the messages will cascade all the way back to the browser 14 in real time, limited only by the transmission latency speed of the network.
  • the networkMCI Interact middle tier software includes a communications component offering three (3) types of data transport mechanisms: 1) Synchronous; 2) Asynchronous; and 3) Bulk transfer. Synchronous transaction is used for situations in which data will be returned by the application server 40 quickly. Thus, a single TCP connection will be made and kept open until the full response has been retrieved.
  • Asynchronous transaction is supported generally for situations in which there may be a long delay in application server 40 response.
  • a proxy will accept a request from a customer or client 10 via an SSL connection and then respond to the client 10 with a unique identifier and close the socket connection. The client 10 may then poll repeatedly on a periodic basis until the response is ready. Each poll will occur on a new socket connection to the proxy, and the proxy will either respond with the resultant data or, respond that the request is still in progress. This will reduce the number of resource consuming TCP connections open at any time and permit a user to close their browser or disconnect a modem and return later to check for results.
  • Bulk transfer is generally intended for large data transfers and are unlimited in size. Bulk transfer permits cancellation during a transfer and allows the programmer to code resumption of a transfer at a later point in time.
  • FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture 10 .
  • the system is divided into three major architectural divisions including: 1) the customer workstation 20 which include those mechanisms enabling customer connection to the Secure web servers 24 ; 2) a secure network area 17 , known as the DeMilitarized Zone “DMZ” set aside on MCI premises double firewalled between the both the public Internet 25 and the MCI Intranet to prevent potentially hostile customer attacks; and, 3) the MCI Intranet Midrange Servers 30 and Legacy Mainframe Systems 40 which comprise the back end business logic applications.
  • DMZ DeMilitarized Zone
  • the present invention includes a double or complex firewall system that creates a “demilitarized zone” (DMZ) between two firewalls 25 a , 25 b .
  • one of the firewalls 29 includes port specific filtering routers, which may only connect with a designated port address.
  • router 49 (firewall 25 ( a )) may connect only to the addresses set for the HydraWeb® (or web servers 24 ) within the DMZ
  • router 55 (firewall 25 ( b )) may only connect to the port addresses set for the dispatch server 26 within the network.
  • the dispatch server 26 connects with an authentication server, and through a proxy firewall to the application servers.
  • the hijacker may not directly connect to any enterprise server in the enterprise intranet beyond the DMZ, thus ensuring internal company system security and integrity. Even with a stolen password, the hijacker may not connect to other ports, root directories or application servers within the enterprise system, and the only servers that may be sabotaged or controlled by a hacker are the web servers 24 .
  • the DMZ 17 acts as a double firewall for the enterprise intranet because of the double layer of port specific filtering rules. Further, the web servers 24 located in the DMZ never store or compute actual customer sensitive data. The web servers only transmit the data in a form suitable for display by the customer's web browser. Since the DMZ web servers do not store customer data, there is a much smaller chance of any customer information being jeopardized in case of a security breach.
  • firewalls or routers 47 , 49 are a combination of circuit gateways and filtering gateways or routers using packet filtering rules to grant or deny access from a source address to a destination address. All connections from the internal application servers are proxied and filtered through the dispatcher before reaching the web servers 24 . Thus it appears to any remote site, that the connection is really with the DMZ site, and identity of the internal server is doubly obscured. This also prevents and direct connection between any external and any internal network or intranet computer.
  • the filtering firewalls 25 ( a ), ( b ) may also pass or block specific types of Internet protocols.
  • FTP can be enabled only for connections to the In-Box server 31 , and denied for all other destinations.
  • SMTP can also be enabled to the In-Box server, but Telnet denied.
  • the In-box server 31 is a store and forward server for client designated reports, but even in this server, the data and metadata are separated to further secure the data, as will be described.
  • the customer access mechanism is a client workstation 20 employing a Web browser 14 for providing the access to the networkMCI Interact system via the public Internet 15 .
  • a secure TCP/IP communications link 22 is established to one of several Web servers 24 located inside a first firewall 25 a in the DMZ 17 .
  • Preferably at least two web servers are provided for redundancy and failover capability.
  • the system employs SSL encryption so that communications in both directions between the subscriber and the networkMCI Interact system are secure.
  • all DMZ Secure Web servers 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.
  • the web servers may be interconnected by a fast Ethernet LAN running at 100 Mbit/sec or greater, preferably with the deployment of switches within the Ethernet LANs for improved bandwidth utilization.
  • One such switching unit included as part of the network architecture is a HydraWEB® unit 45 , manufactured by HydraWEB Technologies, Inc., which provides the DMZ with a virtual IP address so that subscriber HTTPS requests received over the Internet will always be received.
  • the Hydraweb unit 45 implements a load balancing algorithm enabling intelligent packet routing and providing optimal reliability and performance by guaranteeing accessibility to the “most available” server. It particularly monitors all aspects of web server health from CPU usage, to memory utilization, to available swap space so that Internet/Intranet networks can increase their hit rate and reduce Web server management costs. In this manner, resource utilization is maximized and bandwidth (throughput) is improved. It should be understood that a redundant Hydraweb® unit may be implemented in a Hot/Standby configuration with heartbeat messaging between the two units (not shown). Moreover, the networkMCI Interact system architecture affords web server scaling, both in vertical and horizontal directions. Additionally, the architecture is such that new secure web servers 24 may be easily added as customer requirements and usage increases.
  • the most available Web server 24 receives subscriber HTTPS requests, for example, from the HydraWEBTM 45 over a connection 44 a and generates the appropriate encrypted messages for routing the request to the appropriate MCI Intranet midrange web server over connection 44 b , router 55 and connection 23 .
  • a TCP/IP connection 38 links the Secure Web server 24 with the MCI Intranet Dispatcher server 26 .
  • a second RTM server 52 having its own connection to the public Internet via a TCP/IP connection 48 .
  • this RTM server provides real-time session management for subscribers of the networkMCI Interact Real Time Monitoring system.
  • An additional TCP/IP connection 48 links the RTM Web server 52 with the MCI Intranet Dispatcher server 26 .
  • a third router 65 is provided for routing encrypted subscriber messages from the RTM Web server 52 to the Dispatcher server 26 inside the second firewall.
  • each of the routers 55 , 65 may additionally route signals through a series of other routers before eventually being routed to the nMCI Interact Dispatcher server 26 .
  • each of the Secure servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session from the COUser object authenticated at Logon.
  • the Secure Web servers 24 After establishing that the request has come from a valid user and mapping the request to its associated session, the Secure Web servers 24 will re-encrypt the request using symmetric RSA encryption and forward it over a second secure socket connection 23 to the dispatch server 26 inside the enterprise Intranet.
  • the data architecture component of networkMCI Interact reporting system is focused on the presentation of real time (un-priced) call detail data, such as provided by MCI's TrafficView Server 34 , and priced call detail data and reports, such as provided by MCI's StarODS Server 33 in a variety of user selected formats.
  • All reporting is provided through a Report Requestor GUI application interface which support spreadsheet, a varity of graph and chart type, or both simultaneously.
  • the spreadsheet presentation allows for sorting by any arbitrary set of columns.
  • the report viewer may also be launched from the inbox when a report is selected.
  • Report management related data is also generated which includes 1) report profiles defining the types of reports that are available, fields for the reports, default sort options and customizations allowed; and 2) report requests defining customer specific report requests including report type, report name, scheduling criteria, and subtotal fields. This type of data will be resident in an Inbox server database and managed by the Inbox server.
  • the Infrastructure component of the nMCI Reporting system includes means for providing secure communications regardless of the data content being communicated.
  • the nMCI Interact system security infrastructure includes: 1) authentication, including the use of passwords and digital certificates; 2) public key encryption, such as employed by a secure sockets layer (SSL) encryption protocol; 3) firewalls, such as described above with reference to the network architecture component; and 4) non-repudiation techniques to guarantee that a message originating from a source is the actual identified sender.
  • One technique employed to combat repudiation includes use of an audit trail with electronically signed one-way message digests included with each transaction.
  • Order Entry Another component of the nMCI Interact infrastructure includes order entry, which is supported by the Order Entry (“StarOE”) server.
  • the general categories of features to be ordered include: 1) Priced Reporting; 2) Real-time reporting; 3) Priced Call Detail; 4) Real Time Call Detail; 5) Broadband SNMP Alarming; 6) Broadband Reports; 7) Inbound RTM; 8) Outbound RTM; 9) Toll Free Network Manager; and 10) Call Manager.
  • the order entry functionality is extended to additionally support 11) Event Monitor; 12) Service Inquiry; 13) Outbound Network Manager; 14) Portfolio; and, 15) Client View.
  • the Self-monitoring infrastructure component for nMCI Interact is the employment of mid-range servers that support SNMP alerts at the hardware level.
  • all software processes must generate alerts based on process health, connectivity, and availability of resources (e.g., disk usage, CPU utilization, database availability).
  • the Metrics infrastructure component for nMCI Interact is the employment of means to monitor throughput and volumes at the Web servers, dispatcher server, application proxies and mid-range servers. Metrics monitoring helps in the determination of hardware and network growth.
  • the client tier 10 is organized into a component architecture, with each component providing one of the areas of functionality.
  • the client-tier software is organized into a “component” architecture supporting such applications as inbox fetch and inbox management, report viewer and report requester, TFNM, Event Monitor, Broadband, Real-Time Monitor, and system administration applications.
  • Further functionality integrated into the software architecture includes applications such as Outbound Network Manager, Call Manager, Service Inquiry and Client View.
  • those components associated with the Client GUI front end including a report requestor client application 212 , a report viewer client application 215 and, an Inbox client application 210 which implement the logical processes associated with a “Java Client”, i.e., employs Java applets launched from the backplane ( FIG. 3 ) that enable the display and creation of reports and graphs based on the fields of the displayed reports, and, allows selection of different reporting criteria and options for a given report; and,
  • Unix stream sockets using the TCP/IP protocol suite are deployed to listen for client connections on a well-known port number on the designated host machine.
  • Client processes e.g., report requester 212 , desiring to submit requests connect to RM 250 via the dispatcher 26 by providing the port number and host name associated with RM 250 .
  • a Talarian smart socket connection 254 is provided for particular back-end server 400 providing priced reporting data.
  • Request messages received by the RM server are translated into a “metadata” format and validated by a parser object built into a report manager proxy 250 ′ that services requests that arrive from the GUI front-end. If the errors are found in the metadata input, the RM 250 will return an error message to the requesting client.
  • the report manager server additionally utilizes a database 258 , such as provided by Informix, to provide accounting of metadata and user report inventory.
  • a database 258 such as provided by Informix
  • an SQL interface is utilized to access stored procedures used in processing requests and tracking customer reports.
  • C++ tools and other tools such as Rogue Wave's tools.h++ are additionally implemented to perform metadata message parsing validation and translation functions.
  • the Report Manager server 250 additionally includes the scheduling information, however, a report scheduler server component passes report requests to the back-end fulfilling servers 400 , 500 at the scheduled times.
  • the Report Scheduler (“RS”) server component 260 is, in the preferred embodiment, a perpetually running Unix daemon that deploys the TCP/IP protocol to send report requests to the back-end fulfilling servers such as the StarODS server 400 , TVS server 500 , and receive their responses. More particularly, the RS server 260 is a Unix server program that is designed to handle and process report requests to the fulfilling servers by deploying Unix stream sockets using the TCP/IP protocol suite, sending the request for customized reports to client connections on a well-known port number on the designated host machine. As shown in FIG. 6 , interface socket connections 264 , 266 are shown interfacing with respective back end servers 400 and 500 .
  • report requests are published by the RS server 260 to a pre-defined subject on the Talarian Server.
  • Talarian SmartSockets 4.0 another daemon process is necessary that uses Talarian C++ objects to connect their message queue and extract all messages for a given subject for storage in a database table contained in database 263 .
  • Each message includes the track number of the report that was requested from the fulfilling server.
  • the report scheduler server 260 interfaces directly with the Report Manager server 250 to coordinate report request scheduling and processing. It should be understood that the respective report management and scheduling functions could be performed in a single server.
  • the Inbox Server component 270 serves as the repository where the completed user report data is stored, maintained, and eventually deleted and is the source of data that is uploaded to the client user via the dispatcher over a secure socket connection 272 between the Web server and the browser. It is also a Unix program that is designed to handle and process user requests submitted in meta data format using an Informix database.
  • the Report Manager server 250 communicates the corresponding report metadata to the Inbox server 270 over socket connection 274 as shown in FIG. 6 .
  • the metadata will be stored in the Inbox server database 273 along with the report results. Thus, if the meta data is required to be changed, it will not interfere with the information needed to display the reports contained in the Inbox. Additionally, as shown in FIG. 6 , the Inbox server interfaces with the report scheduler to coordinate execution and presentation of reports.
  • the StarOE server 280 is the repository of user pick lists and user reporting entitlements as shown in database 283 . Particularly, it is shown interfacing with the Inbox server 270 and report scheduler servers 260 .
  • the Report Manager does not interface with or contain metadata for StarOE. It will, however, include information in the report metadata that will tell the Report Requestor it needs to get information (i.e., Pick Lists) from StarOE server 285 .
  • a common database may be maintained to hold the common configuration data which can be used by the GUI applications and by the mid-range servers.
  • Such common data will include but not be limited to: customer security profiles, billing hierarchies for each customer, general reference data (states, NPA's, Country codes), and customer specific pick lists: e.g., ANI's, calling cards, etc.
  • An MCI Internet StarOE server will manage the data base for the common configuration of data.
  • the above-mentioned Inbox client application 210 functions as an interface between the client software and the Inbox server 270 for presenting to the customer the various type of reports and messages received at the Inbox including all completed reports, call detail, and marketing news messages.
  • the messages for the user in the inbox are sorted by type (report, call detail, alarms) and then by report type, report name, date, and time.
  • the Inbox client application uses the services of the backplane ( FIG. 3 ) to launch other applications as needed to process report messages.
  • the inbox will also use the services of the data export objects to provide a save/load feature for inbox messages, and, is used to provide a user-interface for software upgrade/download control.
  • Inbox messages are generated by the versioning services of the backplane; actual downloads will be accomplished by a request through the inbox.
  • the inbox client is able to receive information on multiple threads to allow a high priority message to get through even if a large download is in progress.
  • the browser is configured to allow more than one network connection simultaneously, i.e., the polling thread on the client uses a separate connection to check for new messages, and starts a new thread on a new connection when a new message is detected. In this way, multiple messages may be downloaded simultaneously.
  • the Report Requestor application 212 is a GUI Applet enabling user interaction for managing reports and particularly includes processes supporting: the creation, deletion, and editing of the user's reports; the retrieval and display of reports based on selected criteria; the display of selected option data; and the determination of entitlements which is the logical process defining what functionality a user can perform on StarWRS.
  • the Report requestor additionally enables a user to specify the frequency of report generation, e.g., periodically, or as “one-shots” to be performed at a later time.
  • the report scheduler service maintains a list of requested reports for a given user, and forwards actual report requests to the appropriate middle-tier servers at the appropriate time. Additional functionality is provided to enable customers to manage their inventory, e.g., reschedule, change, or cancel (delete) report requests.
  • the report requestor utilizes the platform client JAVA code to communicate with the report manager server.
  • the Report Requestor uses StarOE client Java code.
  • Report Requestor JAVA applets implementing the above-described report requester functionality are downloaded to the customer's workstation in the form of a cab file after initial login.
  • the Report Viewer application 215 is a GUI Applet enabling a user to analyze and display the data and reports supplied from the fulfilling servers such as StarODS 400 , Traffic View (“TVS”) 500 , and other systems such as Broadband and toll free network manager.
  • the Report Manager 250 includes and provides access to the metadata which is used to tell the Report Requestor what a standard report should look like and the “pick-list” options the user has in order for them to customize the standard report. It is additionally used to tell the Report Viewer client how to display the report, what calculations or translations need to be performed at the time of display, and what further customization options the user has while viewing the report.
  • report data management functionality by defining what operations can be performed on the spreadsheet including the moving of columns, column suppression, column and row single and multiple selection, import and export of spreadsheet data, printing of spreadsheet, etc
  • reports can be presented without report-specific presentation code.
  • these metadata descriptions function like the catalog in a relational database, describing each row of a result set returned from the middle tier as an ordered collection of columns.
  • Each column has a data type, a name, and a desired display format, etc.
  • Column descriptive information will be stored in an object, and the entire result set will be described by a list of these objects, one for each column, to allow for a standard viewer to present the result set, with labeled columns. Nesting these descriptions within one another allows for breaks and subtotaling at an arbitrary number of levels.
  • the same metadata descriptions may be used to provide common data export and report printing services. When extended to describe aggregation levels of data within reporting dimensions, it can even be used for generic rollup/drilldown spreadsheets with “just-in-time” data access.
  • the metadata data type may include geographic or telecommunications-specific information, e.g., states or NPAs.
  • the report viewer may detect these data types and provide a geographic view as one of the graph/chart types.
  • the traffic view system (“TVS”) 500 of the present invention comprises a Traffic View Server 550 which functions to store network call detail records (CDRs) and statistics, generate reports and deliver reports and/or call detail to the customer via the StarWRS Web Reporting System, and, supplies on-line customer access to call detail and hourly statistics that aid the customer in Network management, call center management and customer calling pattern analysis.
  • CDRs network call detail records
  • statistics are generated for the following totals: minutes, attempts, completes, incompletes, other, dto (direct termination overflow), short calls, didn't wait, didn't answer, tcc, and equipment failures.
  • a generalized statistics engine (GSE) component 504 receives all records that are considered to be a toll free (800/8xx, etc) call from the NIC and also employs the same sequencing of groups of records to ensure that no data is lost. Should the GSE be unavailable, the NIC will queue the data for later delivery. The GSE component 504 further filters toll-free calls to only process calls that match a subscriber list which is maintained by an order entry OE process on the GSE (not shown) that accepts add & delete requests from TVS via a messaging interface 507 as shown in FIG. 7 .
  • the GSE component then formats the CDRs, i.e., enhances the call records, from the form as originally provided at the switch, into a normalized form to allow for a common record format regardless of the type of switch that created the record, or the exact call record type. For example, different network switches generate different call detail records, e.g., call detail record, enhanced call detail records, etc., which denote differences in toll-free services and features.
  • This type of call detail record generated by GSE component is herein referred to as a TCR (Translated Call Record).
  • Groups of TCRs are sent from the GSE to TVS via TCP/IP.
  • TVS has safely stored that record it sends an acknowledgment to the GSE 504 so that the GSE may dispose of the group.
  • GSE queues data to be sent later.
  • initial customer provisioning occurs at either the Corporate Order Entry system 223 (CORE) or the StarOE server 285 component of MCI Interact.
  • CORE 223 transmits daily to the TVS server 550 via Network Data Mover (NDM) files which comprise information about new reports for TVS to create, and where to send those reports, e.g., FAX, E-Mail, or US Mail.
  • NDM Network Data Mover
  • a GSE_OE process 524 is invoked to forward the order, e.g., toll-free number, from the reference database onto a DEC Message QueueTM “DMQ” 526 a .
  • a GSE_OE_SEND process 527 is invoked to keep a TCP/IP socket open to the GSE process so that the pending order may be forwarded to the GSE 504 via a TCP/IP interface.
  • the GSE will invoke the GSE_OE_SEND process 527 to send an order response to a DMQ 526 b , where it will be accessed by the GSE_OE process 524 .
  • the GSE_OE process 524 will confirm that the number has been provisioned within the TVS server and will update the reference database accordingly by removing the order from a pending order list. Invocation of the GSE_OE process and the GSE_OE_SEND process enables tracking of new customer orders, i.e., new toll-free network numbers for which CDR data is to be collected.
  • requests to enable TrafficView customers are received in real-time from StarOE 285 via TCP/IP.
  • StarOE specifies what general categories of reports can be requested for a given nMCI Interact subscriber. These categories include: 1) reports that only require data aggregation; 2) reports that require call detail records to be collected; and 3) real-time monitor (RTM) reports. This is provisioned into the reference database 551 for future verification of requests from the nMCI Interact platform.
  • a subscription request is sent to the GSE 504 via the GSE_OE and GSE_OE-SEND process to start collecting TrafficView data pertaining to that toll-free number.
  • This request is sent by placing a request onto the DMQ queue 526 a , and the GSE_SEND_OE process 527 then forwards this request to the GSE 504 via a TCP/IP interface.
  • the content and format of an “order entry” message generated by the TVS server for requesting unpriced traffic data from the GSE is provided in Appendix H.
  • the GSE selects all TCR's for TVS enabled customers and places them in a SAVE storage queue, e.g., Versant or Talarian, for subsequent distribution to the TVS server.
  • an input feed from the calling area database component 508 provides the TVS server 550 with reference data including state and country information for mapping NPA/NXX (Numbering Plan Area/Number Exchange) to city name and state code, and, for mapping country codes to country names.
  • Data is transported from the CADB database 518 to the TVS server via a network data mover (“NDM”) or FTP via interface 519 .
  • NDM network data mover
  • TVS receives three NDM feeds: 1) a Trunk Type Master feed 516 used in Un-priced Reporting to map enhanced voice service/dedicated access line (EVS/DAL) information to specific service locations; 2) an automatic number identification (“ANI”) feed 517 also used in Unpriced Reporting to map EVS/DAL information to specific service locations; and, 3) a switch mapping feed 518 to map the switch ID (per Network control system) to the billing representations of the same switch.
  • Trunk Type Master feed 516 used in Un-priced Reporting to map enhanced voice service/dedicated access line (EVS/DAL) information to specific service locations
  • ANI automatic number identification
  • switch mapping feed 518 to map the switch ID (per Network control system) to the billing representations of the same switch.
  • the StarOE server 285 then messages the Traffic View Server 550 in real time via TCP/IP that the number has been added for Unpriced Reporting.
  • the TVS additionally messages the GSE component 505 in real time to immediately initiate the collection of call detail for that number, as will be described in greater detail herein. Due to latency inherent in the fulfillment process, customers may select and receive daily reports after CDR collection begins.
  • reports and reporting frequencies are available.
  • reports are available in hourly, daily, weekly, and monthly frequencies.
  • Standard reports that may be generated from stored Toll Free hourly statistics include, but are not limited to: Summary by Toll Free Number and Hour which is available in the following frequencies (Ad-hoc “A”, Daily “D”, Weekly “W”, and Monthly “M”); Summary by Toll Free Number and Date(A,D,W,M); Summary by Toll Free Number and day of week (“DOW”) (A,W,M); Summary by Toll Free Number and Week (A,M); Summary by Toll Free Number and NPA (A,D,W,M); Summary by Toll Free Number, Service Location and Hour(A,D,W,M); Summary by Toll Free Number, Service Location and Date (A,D,W,M); Summary by Toll Free Number, Service Location and DOW (A,W,M); Summary by Toll Free Number, Service Location and Week (A,M); Summary by Service Location and Hour (A,D,W,W); Summary by Service Location and Hour (A,D,W,W); Summary by Service Location and Hour (A,D,W,M); Summary by Service Location and Hour
  • the Toll Free Summary Reports generally comprise three sections: Summary, Incomplete Call Analysis, and Network Customer Blocked Analysis (other category breakdown).
  • the Termination Summaries include three types of termination reports: Toll Free by Location, i.e., showing termination summary and incomplete call analysis by service location for a specific Toll Free number; By Location, i.e., by service location across all Toll Free numbers terminating to the same service location; and, Location by Toll Free, i.e., for a specific service location, shows each Toll Free number terminating to this location.
  • the originating NPA/Country Code summary reports provide information by NPA and Country for each Toll Free number attached to the report.
  • the nMCI Interact Exception reports includes: Call Detail by Originating ANI (A,D,W,M); Call Detail by ID Code (A,D,W,M); Call Detail by NCR Indicator (A,D,W,M); Call Detail by Originating State (A,D,W,M); Call Detail by Disposition (A,D,W,M); Call Detail by Service Location (A,D,W,M); Payphone Summary (A,M).
  • Downloadable nMCI interact Call Detail reports includes Traffic view call detail (available as ad-hoc and daily) and Outbound traffic view call detail data (available as ad-hoc, daily and weekly).
  • the TVS system 550 receives a request in real-time from the nMCI Interact StarOE component 285 to begin collecting call detail records for a particular TVS/Unpriced reporting customer, which number had been previously assigned during the order entry process.
  • this information is entered in StarOE tables where it is stored for a predetermined period subsequent to termination of the number.
  • the predetermined period of time e.g., seven days
  • the numbers scheduled for service deletion are passed to TVS via TCP/IP connectivity in real time.
  • TVS instructs the GSE 504 in real time to stop collecting CDRs for these numbers.
  • the TCR_DISTRIB process 566 reads groupings of records and distributes a record based on the toll-free number associated with that record in the following manner:
  • the reference database 551 contains information on which toll-free number belongs in which CDR database associated with the TVS server, records are grouped for each CDR database 561 a , 561 b , . . . , 561 n , to which they belong.
  • the reference database 551 additionally flags which numbers are to have statistics collected for them.
  • an additional group of records is created and may be routed to a DMQ Queue 553 b which inputs these records into a statistics “stats” counter process 570 for statistics processing, as will be described in greater detail herein.
  • each group is written to it's DMQ queue 554 a , 554 b , . . .
  • TCRs are rolled up into statistics records.
  • the stats counter 570 keeps counts of the following: summary information about each toll free number for an hour; summary information about each toll free number and termination for an hour; and, summary information about each toll free number and origination NPA for an hour.
  • These statistics are kept in memory for a pre-determined amount of time, e.g., one hour. As matching records come in, statistics are updated. At the end of the time period, these records are written to the statistics database 571 , and particularly high speed electronic data drives.
  • the statistics that are gathered for each subscriber's toll-free number in the TVS system of the invention include: total completions, total call duration, total attempts, total switch control call, total Network Control System (NCS) blocked, total NCS rejected, total network blocked (all routes busy), total supp code blocked, and out-of-band blocked.
  • NCS Network Control System
  • the summary table processing algorithm in Appendix I details the collection of these statistics by the GSE and the TVS summary table processing.
  • statistics gathered for NP table processign include: originating NPA, total attempts per NPA, total calls completed (tcc) per NPA, total call not delivered (blocked) per NPA, total attempts for International Originations, tcc for International Originations (“IO”), total calls not delivered (blocked) for IO.
  • call statistics for terminations inlcude termination type, termination address, total completions, total call duration, and call dispositions indicating the cause of an incomplete call including: total short calls, total didn't write, and total didn't answer.
  • stats_counter 570 contains processes that read TCR's from a DMQ queue, and create statistics records for input to “c_tables” in the statistics database 571 .
  • Appendix I depicts the algorithms implemented in TVS stats_counter process 570 for generating statistics data tables so that TCR records may be processed in batches.
  • the processes include: a summary table process which process generates statistics for call summary data; a NPA table process; Country table process and Termination table process.
  • the stats_counter 570 enables multiple processes to be run at the same time on the same machine.
  • the stats databases are organized as a series of configurable tables, e.g., “C_Tables” 572 , which are temporary tables that the stats counters first insert records to: These tables are identical to normal statistics tables with the exception that they include a field for the date in them.
  • a pending_stats_list table and stats_table_usage_list table are used to keep track of what data is in the C_tables, and to drive the movement of data from the C_tables to a more permanent database tables 574 .
  • stats_counter process 570 when the stats_counter process 570 starts, it performs a check of the set of “c_tables” by inserting its process name in the used_by_process field of the stats_table_usage_list table. If the stats_counter process unexpectantly dies, it reclaims the tables previously used by searching the stats_table_usage_list for tables marked with it's process name. The stats_counter process adds an entry into the pending_stats_list every time it creates stats for a new day. The usage_flag is initially set to “1” in that table.
  • stats_counter processes marks all of the usage_flag entries to “2”, and modifies the value of the used_by_process field in the stats_table_usage_list to “MOVER”.
  • the stats_counter process searches the stats_table_usage_list for another set of tables to use for the next hours counting. If the stats_counter process cannot find a set of tables, it aborts. To avoid this, there is extra sets of “c_tables” configured with entries in the stats_table_usage_list.
  • Table 1 depicts an example pending_stats_list table which comprises a directory of what the stats_counter is working on, or finished with. Each record represents a name of a c_table that contains statistics, and dates that are contained in this c_table.
  • the report generator process, and on-line access use this table to determine if there is any data in the c_tables that they may be interested in, and what the table name is.
  • the Stats_counter processes insert records into this table, and data_mover processes 573 , shown in FIG. 10 , remove entries from this table.
  • TABLE 1 pending_stats_list table description Column Type Usage data_month_day Integer date in form YYYYMMDD e.g.
  • Table 2 depicts an example stats_table_usage_list table which comprises a list of all the c_tables that are configured and used by the stats_counter processes and data_mover processes to allocate tables amongst themselves. The number of records in this table remains static.
  • Stats_counter processes 570 update the “used_by_process” field with their process name when they are in control of that table. At the top of the hour, they may change the used_by_process to “MOVER”, and attempt to find another table that is unallocated. The movers change the used_by_process name to “NONE” when they have completed moving data from that c_table.
  • stats_table_usage_list table description Column Type Usage table_type character type of statistics data “SUMMARY” (16) “TERMINATION” “NPA” or “COUNTRY” table_name character exact name of table in use e.g. (16) “C_NPA_03” used_by_process character process name of the stats_counter or (16) “MOVER” to indicate what processes are currently using this table. “NONE” if this table is unused.
  • reports may be triggered by two possible sources: Scheduled report setup by a CORE order; and, real time report requests as forwarded from the report request/Report Manager Server 250 .
  • the report generation process is hereinafter described with respect to real-time reports from the StarWRS system.
  • a report manager proxy process 250 ′′ gathers information about the reports to be generated from the reference database 551 by determining whether the report request may be fulfilled by statistics processing, or the CDR's. If CDR's are needed, a determination is then made as to which database contains the necessary data. Additionally determined is whether the needed CDR data to fulfill the request spans a long period of time, e.g., several days.
  • the requests are sent from the report manager proxy process 250 ′′ to the appropriate DMQ queue 554 a , 554 b , . . . , 554 n , or 553 b where they are queued up for report generation.
  • the destination of the report e.g., StarWRS Inbox server 270 , fax, U.S. mail, etc.
  • the requested data is gathered based on the metadata request, analyzed, and formatted by various corresponding detail report generator processes indicated in FIG. 11 as processes 559 a , . . . , 559 n .
  • FIG. 11 it should be understood that reference data that originates from CADB and COMS may be necessary to complete these reports.
  • the TVS server is provided with an additional set of queues and report generator processes for each of the CDR processing to allow longer reports to not interfere with shorter reports.
  • the data is formatted in a comma separated value (CSV) format and are input to a finished report files database 582 whereupon, an inbox server interface process 583 FTPs the report to the nMCI Interact Inbox Server 270 .
  • the Inbox interface will particularly input the completed report to the pre-defined directory in the Inbox database.
  • the Inbox is notified via TCP/IP that the report is complete by the Inbox Interface process and that the appropriate metadata is available for report presentation via the report viewer.
  • the requested report is destined for MCI Mail delivery (Fax, Mail, US Mail): then the data is formatted with headers, page breaks, line numbers into a report that is saved to a file. The report is then sent to an Internet Gateway 279 , e.g., the MCI Mail Internet Gateway directly from the detail report generators 559 a , . . . , 559 n for delivery by MCI Mail. Once the file is successfully sent it is deleted, thus allowing for report generation to continue when the MCI Mail Internet Gateway is not available.
  • MCI Mail Internet Gateway e.g., the MCI Mail Internet Gateway directly from the detail report generators 559 a , . . . , 559 n for delivery by MCI Mail.
  • this request is translated by the StarWRS component into a metadata file which is sent to TVS in the manner described herein.
  • Users schedule reports for execution using the Report Scheduler in StarWRS in the manner as described in co-pending U.S. patent application Ser. No. ______ (D#11050).
  • the StarWRS Report Scheduler component 260 creates a metadata message comprising this information which file is passed to TVS in real time. The TVS then uses this file to formulate a query and runs the report for the scheduled time period.
  • TVS After TVS runs the report, TVS sends the report to the Inbox server component 270 of StarWRS immediately after they are completed.
  • a user first establishes communication with the DMZ Web server at step 602 and logs on to the nMCI Interact system by entering the user's name and password onto a logon dialog box, as indicated at step 604 .
  • an application running on the backplane directs a “Validate User Message” common object to the StarOE server 280 via the web server and dispatcher servers ( FIG. 2 ) to direct the StarOE server 280 to perform security validation and authenticate the user ID and password in the manner as described in commonly owned, co-pending U.S. patent application Ser. No.
  • a “Get User Application Request” message is communicated to the StarOE server via the backplane from the report requestor which queries the Informix database to obtain a list of authorized applications, i.e., services, for the user and which determines which buttons on the home page are active, thus controlling their access to products.
  • This information is downloaded by a GUI applet that is executed via the Backplane ( FIG. 3 ) and incorporated into the home page that is presented to the user as indicated at steps 612 - 614 .
  • An exemplary home page screen display 80 is shown in FIG. 4 which provides a list of icons 70 representing the possible options available to the user according to that customer's entitlements.
  • Appendix H of co-pending U.S. patent application Ser. No. ______ provides the format and content of the nMCI Interact common objects downloaded to the Report Requestor client application to enable web-based reporting.
  • the Report Requestor first asks for common objects for a user's default timezone, language and currency.
  • the Report Requestor objects are invoked to retrieve from StarOE the various customer entitlements relating to security, geographical hierarchy, billing hierarchy, and paging and e-mail notification, as further shown in Appendix H.
  • the steps 615 and 616 indicate the selection and presentation of the Report Requestor display which presents the reporting options to a user in accordance with that user's entitlements as determined at previous step 610 .
  • the icons for applications the user has security access to are shown bolded.
  • an Unpriced Reporting icon is automatically enabled when the home page appears.
  • a StarWRS report requester web page is presented to the customer.
  • the backplane object allows the user access to the Report Requestor front end if the user is so authorized.
  • a client unpriced reporting application is downloaded to the customer who is presented with the unpriced reporting dialog screen (not shown). It is from this screen that the user is presented with unpriced reporting options to view/retrieve completed reports via the StarWRS Inbox, as indicated at step 620 ( FIG. 12 ( b )), or create a new report or, modify an existing unpriced call detail data report.
  • the user is enabled to edit an existing report maintained in the report manager inventory, generate a new report, copy an existing report, or delete an existing report.
  • the user may enter the desired reporting options including: 1) the report product including toll-free, MCI Vision, and MCI Vnet options; 2) the report category which includes options for: analyzing traffic, call center, call detail, checking calling frequencies, financial, marketing, monitoring usage, and telecommunications categories for toll-free, Vnet and Vision customers; 3) the report type which includes unpriced call detail data or traffic data options; and 4) a report direction and which includes inbound, outbound, or both directions.
  • user selection of the report product, report category, report type, and report direction is indicated at step 620 .
  • the user may select the report format associated with a reporting category.
  • a report had already been created and maintained in the report manager inventory (database), it will be displayed in a report inventory field.
  • step 626 If an existing report is selected at step 626 based on the report product, category, type, etc., then the user is prompted at step 628 to select from among the following options: a report edit option, as shown at step 635 ; a report delete option, in which case the selected report will be deleted at steps 638 and 639 ; and, a report copy option, in which case an existing report will be copied, e.g., for subsequent editing, as shown at steps 640 and 641 .
  • a report edit option as shown at step 635
  • a report delete option in which case the selected report will be deleted at steps 638 and 639
  • a report copy option in which case an existing report will be copied, e.g., for subsequent editing, as shown at steps 640 and 641 .
  • a user is enabled to select customization options as indicated at step 630 , FIG. 7 ( b ) from a new dialog screen that is presented to the user showing all the report customization categories for building a new report and/or editing an existing report. From this screen and related report building dialog boxes, all of the initial values for retrieving the MetaData, customization options and GUI builder options from the report manager server 250 necessary to build (edit) a report are provided in accordance with the user's entitlements.
  • a user may provide the following customization and report builder options: general customization options; layout customization options; access customization options; hierarchy customization options; geographic customization options; and, notification customization options.
  • the Report Requestor client application 212 gains access to the Metadata stored at the Report Manager server 250 through messaging. Particularly, as hereinafter described, a message generated by the Report Requestor in accordance with the user request is first received by the report manager proxy 250 ′.
  • the report manager proxy comprises a set of tools in the form of reusable objects, preferably written in C++ code, or the like. For example, a parser object tool is employed to decompose the Metadata messages sent by the report requester 212 to validate the message. If errors are found in the Metadata input, the RM will return an error message to the requesting client. If the Metadata passes the validation tests, the request type is then determined and the appropriate service will be invoked after which a standard response is sent back to the requesting client.
  • the Report Manager 250 implements stored procedures to translate the message, perform the request, and send the information back to the Report Requestor 212 which uses the metadata to determine what a standard report should look like, the customization options the user has, and the types of screens that should be used for the various options (i.e., single selection, multiple selections, etc.). It is understood that the selection of available standard template reports is based on the user's entitlements.
  • the following list provides the types of requests that may be initiated by the Report Requestor 212 and the responses performed by the Report Manager 250 : 1) Get/Send report template list (GRTL/SRTL)—which request retrieves the list of all standard report templates for all products and is used only to obtain general report information, e.g., report title, description, etc.; 2) Get/Send report template detail (GRTD/SRTD)—which request retrieves the details of a specific standard report template; 3) Get/Send user report list (GURL/SURL)—which request retrieves the list of all user reports for the report format selected from a user report table and is used only as a request for general report information, e.g., report title, status, etc.; 4) Get/Send user report detail (GURD/SURD)—which request retrieves the details of a specific user's report; 5) Add report definition/Acknowledgment (ARD/ARDA)—which requests addition of a user-created report to a user report table.
  • the report is a scheduled report, this request is also communicated to the fulfilling server at the time the report is due; 6) Delete report definition/Acknowledgment (DRD/DRDA)—which request deletes a user-created report from the user table; 7) Copy report definition/Acknowledgment (CRD/CRDA)—which request creates a duplication of the report the user is editing (other than the report title) and creates a new report ID for it; 8) Update Reporting Schedule/Acknowledgment (URS/URSA)—which request updates the scheduling information on a report without having to send a Delete and Add request; and, 9) Get Pick List/Acknowledgment (GPL/GPLA)—which request enables the Report Requestor 212 to get a pick list provided by StarOE server.
  • DDRD/DRDA Delete report definition/Acknowledgment
  • CCD/CRDA Copy report definition/Acknowledgment
  • URS/URSA Update Reporting Schedule/Acknowled
  • the interface message sent to the RM server 250 from the report requestor via the Dispatcher server 24 comprises a three to four character message acronym followed by request specific parameters.
  • TABLE 3 Parameter Parameter Acceptable Name Type Required Value Request 3 or 4 Yes Msg acronym Characters Data Characters No parms . . .
  • Table 4 illustrates the interface message format returned by the RM server 250 .
  • the response message to be returned in Metadata format preferably includes a four character message acronym followed by an error code.
  • a successful request (or a request acknowledgment) generates a response with an error code of “0”. Additional data specific to the response follows this error code. If any server receives a message which is not known, the response message will echo the message acronym back along with an appropriate error code.
  • Appendix A provides a series of tables containing the content for each metadata message request that can be sent by the report requestor 212 for each of the enumerated user requests, in addition to the content of the corresponding metadata message responses by the RM server 250 .
  • an example metadata format is as follows:
  • the GRTL message is received by the StarWRS proxy server application 250 ′ to enable the RM server 250 to perform the query into the RM Informix database having the data associated with the request.
  • a WRSApp object is launched.
  • the WRSApp object creates a DataManager object to guide the data and which initiates a CommunicationManager object to manage all communication between the client and the server.
  • the CommunicationManager utilizes a RptManagerMsg object to create: 1) a GRTL; 2) a WRSCommWrapper for direct communication with the backend; and, 3) a WRSReportManagerUtilParser to format the data returned.
  • the Report Manager creates a Dispatcher object, which contains the business logic for handling metadata messages at the back-end and utilizes the services of a RMParser class.
  • the appropriate member function is invoked to service the request.
  • the Report Manager Upon receiving the message, the Report Manager creates the Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • RMParser Parser object
  • ⁇ RptCategoryDescription#n ⁇ RptTitle#n.n, RptTemplateID#n.n, RptCategoryType#n.n>, ⁇ RptTitle#n.n, RptTemplateID#n.n, RptCategoryType#n.n>>>
  • RptID# indicates a standard report template ID
  • RptTitle# indicates the standard report template title
  • RptCategory# indicates the report category, e.g. Monitor Usage, Analysis Traffic, Historical, Executive Summary, Call Detail, etc.
  • RptDescript indicates the standard report template description displayed to the user.
  • the SRTL message is sent from the StarWRS RM proxy server to the report requestor for presentation to the customer.
  • the SRTL response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Report Manager Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SRTL message back to the client.
  • the GRTD request message request is sent having content shown in the table in Appendix A.
  • the Report ID field indicates an existing report that a user may wish to edit.
  • the MetaTreeData Label fields include such values as General, Report Name, Report Description, Scheduled Execution, etc.
  • the MetaCtrlInfo MetaField Value fields may be blank or may contain the selection options available to the user. This information is taken from the report template database.
  • this process entails invoking the Communication Manager object to communicate with the RM server in order to obtain a SURL metadata message.
  • the CommunicationManager utilizes the RptManagerMsg object to create: 1) a GURL, 2) a WRSCommWrapper for direct communication with the backend, and, 3) a WRSReportManagerUtilParser to format the data returned.
  • the parser returns a hash table containing the User Report List.
  • the Report Manager creates an Dispatcher object that contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class.
  • the appropriate member function is invoked to service the request.
  • the Report Manager upon receiving a message, creates a Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • RMParser Parser object
  • ⁇ UserRptCategory#n ⁇ UserRptTitle#n, UserRptID#n, activeflag, report type, statusdate>>>> wherein for each user report category, there is a list of reports where each entry contains a UserRptID# indicating a user-defined report template ID, a UserRptTitle# indicating the user's report template title, and a UserRptCategory# indicating the user report category.
  • the SURL response is built inside an esql wrapper function after obtaining the necessary information through a stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SURL message back to the client.
  • the GURD message is sent having data as contained in the table shown in Appendix A.
  • a Communication Manager object is invoked to communicate with the RM server in order to obtain a SURD metadata message.
  • the CommunicationManager object first utilizes the RptManagerMsg object to create: 1) a GURD metadata message, 2) a WRSCommWrapper for direct communication with the backend, and 3) the RSReportManagerUtilParser to format the data returned.
  • the parser organizes the data into a series of nodes which are utilized to create the report builder tree on the report requestor customization screen.
  • the Report Manager server creates the MCIDispatcher object which contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request.
  • the Report Manager upon receiving a message, creates the Parser object (RMParser) which takes the message apart, invokes a validation object which validates the message and builds a response inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SURD/SRTD message back to the client.
  • This response thus may include the report information having detailed items including: UserReportID (UserID), User's report name (UserName), product (UserProd), Threshold (UserThreshold
  • ARD ⁇ USERID jeanvnet2
  • NAME Payphone Summary TVS Inbound
  • THRESHOLD ⁇ >
  • END 199808111200>
  • the report manager server 250 responds to the Report Requestor with the processing results.
  • a new User Report ID is assigned and returned by RM.
  • the user may make changes to the Report Title, the Report Description, the Report-scheduling, the 800 numbers and thresholds.
  • customers may provide additional customization options including: number of rows, report columns, access codes, access types, billing location, geographic location, paging notification, and e-mail notification.
  • an WRSEdit Screen is launched to provide the editing capabilities which are available for the report format.
  • WRSedit guides the screens through the process of retrieving the screens' data. Some of the screens need data which has not yet been retrieved, such as 800 numbers or geographic locations.
  • GPL get pick list
  • the CommunicationManager utilizes the RptManagerMsg object to create the GPL, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to format the data returned.
  • the Report Manager server creates the MCIDispatcher object and invokes the MCIRMParser class.
  • the appropriate member function is invoked to service the request.
  • the Report Manager upon receiving a message, creates the Parser object (RMParser) which takes the message apart and a validation object is invoked which validates the message.
  • the response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the GPLA message back to the client.
  • FIG. 12 ( c ) describes the next step 650 of presenting the user with report run and save options.
  • the user may select a save and exit report option, or a save and run report option.
  • an WRSEdit object enables a WRSScnMgr object to save the report to the RM server.
  • the WRSScnMgr object launches each screens save method which communicates with the DataManager object to place the screens data in its corresponding WRSNode.
  • the WRSScnMgr object calls the DataManager object's SaveReport method to build a hash table to contain all of the report's data.
  • the CommunicationManager utilizes the RptManagerMsg object to create the ARD metadata message from the hash table, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to handle any errors thrown by the server.
  • the Report Manager creates the Dispatcher object, and utilizes the services of the RMParser class and validation objects. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request.
  • the response is built 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.
  • the selected report type and reporting criteria are sent to the Report Manager.
  • the report is marked as scheduled and saved in a user_table in the Report Scheduler server 260 via the report Manager.
  • the Report Scheduler server 260 sends the ARD message to the fulfilling server which queues the report and runs the report at the specified time(s), as indicated at step 665 , and as described herein with reference to FIG. 11 .
  • the following sequence of operations are performed: First, in response to receipt of the ARD message, e.g., submitted to the fulfilling server by the Report Scheduler, the fulfilling server completes the report and compresses the report/data, as indicated at step 670 . Then, the report/data is “pushed”, implementing FTP, to the fulfilling server's directory on the Inbox server 270 , as indicated at step 673 .
  • the TVS server 550 is responsible for generating unique file names within their directory on the Inbox server 270 .
  • the following directory and file naming conventions used for reports generated by the TrafficView server are labeled inbox ⁇ files ⁇ TVs with text files having the suffix *.txt or *.txt_zip (compressed), and comma separated files having a suffix *.csv or *.csv_zip (compressed).
  • the fulfilling server verifies that the FTP process was successful, as indicated at step 676 , and, at step 679 , a notification is sent by the fulfilling server to the Report Manager to notify the Report Manager server 250 of the location of a scheduled report. This is accomplished by using a “NRL” metadata message.
  • Appendix B provides a table comprising the Notify Report Location parameters used for the NRL Metadata messaging sent by a fulfilling server to the RM Server 250 when a requested report is complete.
  • Appendix B Also provided in Appendix B is the acknowledgment table sent back to the fulfilling server in response.
  • the NRL message received by the RM server 250 includes parameters verifying whether or not the FTP process was successful. If it was successful, then the fulfilling server messages the Inbox that the file has been transmitted successfully by transmitting the report name (filename) and location. When the fulfilling server encounters a problem executing a report, a notification is sent to the Report Manager. Particularly, an error flag is placed in the status field of the User_report by the Report Manager which is displayed to the user during Report Request. The error message description will be placed in a text file and FTP'd to the fulfilling server's report location on the Inbox server (e.g., ⁇ inbox ⁇ files ⁇ TVs) by the fulfilling server.
  • step 679 once the RM server 250 has received the NRL message from the fulfilling server, it verifies the file's presence, as indicated at step 682 .
  • the RM server 250 then builds a metadata file, e.g., by compressing the appropriate metadata (for displaying the report) into a .MTD file, as indicated at step 685 .
  • This .MTD file is utilized by the Report Viewer to know how to display the report.
  • the Report Manager server creates a file including the metadata using the same file name as the report/data file, but having the following suffix: *.mtd or *.mtd_zip indicating a metadata or compressed metadata file, respectively.
  • Appendix F details the parameters that are passed in the GET METADATA messaging for indicating to the Report Viewer how to display a requested report.
  • the RM ftp's the .MTD file to the Inbox server, as indicated at step 688 , FIG. 12 ( d ).
  • the RM server additionally updates the User_report table status field with a status “C” indicating completion, as indicated at step 691 .
  • the RM server 250 then adds the report to the user's Inbox, as indicated at step 693 .
  • Appendix C provides a table showing the fields for the metadata messaging between the RM server 250 and the Inbox server 270 for adding an item into the StarWRS system Inbox server 270 , and the respective acknowledgment message format back from the Inbox server.
  • the “LOC” field includes information about where the report data is located.
  • the report is now available for viewing, downloading, saving, or printing by the user, as indicated at step 695 , and as described in further detail in co-pending U.S. patent application Ser. No. ______ (D#11041), entitled MULTI-THREADED WEB BASED IN-BOX FOR REPORT MANAGEMENT, the contents and disclosure of which are incorporated by reference as if fully set forth herein.
  • the nMCI Interact Message Center icon 77 may be selected which will cause the display of a web page including the message center dialog window.
  • a user may select from among three tabs, one of which, a reports tab, enables the retrieval of both a data file and a metadata file from the Inbox Server corresponding to those reports that have been run and available for customer viewing.
  • Information provided for display by the message center display 325 is provided by the User_table which keeps track of the status of all reports for a particular user. By double-clicking a chosen report, a report viewer application is enabled to display the chosen report on a web-page.
  • the Report Viewer 215 interfaces with the user's Inbox 210 for presenting to the customer the various type of reports received at the Inbox. It should be understood that all Report Requestor and Report Viewer applications communicate with the RM server 250 through the use of the common object communication classes.
  • the Inbox server 270 interface with the Inbox Client 210 supports messaging that enables the User to remove an item from the Inbox, e.g., delete a report, or, to delete all items from the Inbox, e.g., for a particular Enterprise and User ID as well as other associated reports.
  • Appendix G illustrates the parameters used in the metadata messaging between the Inbox client and the Inbox server.
  • the List “L” message is a synchronous request for a list of all Inbox items for a specific user.
  • the Inbox fetch “F” function is a bulk transfer request that enables bulk transfer of the requested file to the Inbox client.
  • the user may simply select to save the report and exit.
  • the ARD message is sent from the Report Requestor client to the RM server and is saved in the RM inventory database for subsequent execution. Consequently, the report is flagged as incomplete in the User_table and may not be run until a run option for that report is chosen. Otherwise, the report may be immediately scheduled if the user selects the save and run button.
  • Metadata messaging is used throughout the various components of the StarWRS system 200 .
  • the format of an interface message that is sent to the Report Scheduler server is identical to the format as shown in Table 3 as is the interface messaging format returned by the RS server 260 in Table 2.
  • a variation of the process outlined in FIG. 12 ( c ) occurs at step 660 , whereby the ARD request is instead sent from the report scheduler to the fulfilling server at the programmed frequency.
  • the Report scheduler server 260 sends an ARD request to the fulfilling server in a metadata message format having parameters as included in the Add Report Definition table in Appendix D.
  • the fulfilling server Upon processing of the metadata message, the fulfilling server will respond to the report Scheduler with an acknowledgment of the command, and the process outlined in FIGS. 12 ( c ) and 12 ( d ) is executed.
  • the messages created by the client Java software are transmitted to the StarWeb (DMZ) Server 24 over HTTPS.
  • the DMZ Web servers 24 decrypt a request, authenticate and verify the session information.
  • the logical message format from the client to the Web server is shown as follows:
  • where “
  • FIG. 13 illustrates a specific message sent from the client browser to the desired middle tier server for the particular application. As shown in FIG.
  • the client message 340 includes an SSL encryption header 342 and a network-level protocol HTTP/POST header 344 which are decrypted by the DMZ STarWeb Server(s) 24 to access the underlying message; a DMZ Web header 346 which is used to generate a cookie 341 and transaction type identifier 343 for managing the client/server session; a dispatcher header 345 which includes the target proxy identifier 350 associated with the particular type of transaction requested; proxy specific data 355 including the application specific metadata utilized by the target proxy to form the particular messages for the particular middle tier server providing a service; and, the network-level HTTP/POST trailer 360 and encryption trailer 365 which are also decrypted by the DMZ Web server layer 24 .
  • the request After establishing that the request has come from a valid user and mapping the request to its associated session, the request is then forwarded through the firewall 25 over a socket connection 23 to one or more decode/dispatch servers 26 located within the corporate Intranet 30 .
  • the messaging sent to the Dispatcher will include the user identifier and session information, the target proxy identifier, and the proxy specific data.
  • the decode/dispatch server 26 authenticates the user's access to the desired middle-tier service.
  • the StarWeb server forwards the Dispatcher header and proxy-specific data to the Dispatcher, “enriched” with the identity of the user (and any other session-related information) as provided by the session data/cookie mapping, the target proxy identifier and the proxy-specific data.
  • the dispatch server 26 receives the requests forwarded by the Web server(s) 24 and dispatches them to the appropriate application server proxies. Particularly, as explained above with respect to FIG. 6 , the dispatch server 26 receives request messages forwarded by the DMZ Web servers and dispatches them to the appropriate server proxies. The message wrappers are examined, revealing the user and the target middle-tier service for the request.
  • a first-level validation is performed, making sure that the user is entitled to communicate with the desired service.
  • the user's entitlements in this regard are fetched by the dispatch server from Order Entry server 280 at logon time and cached.
  • the message is then forwarded to the desired service's proxy, which, in the accordance with the principles described herein, comprises: 1) a report manager proxy 250 ′ corresponding to the RM Server 250 , 2) a report scheduler proxy 260 ′ corresponding to the RS Server 260 , and 3) an inbox server proxy 270 ′ corresponding to the Inbox Server 270 .
  • Each of these proxy processes further performs: a validation process for examining incoming requests and confirming that they include validly formatted messages for the service with acceptable parameters; a translation process for translating a message into an underlying message or networking protocol; and, a management process for managing the communication of the specific customer request with the middle-tier server to actually get the request serviced. Data returned from the middle-tier server is translated back to client format, if necessary, and returned to the dispatch server as a response to the request.
  • FIGS. 14 ( a ) and 14 ( b ) are schematic illustrations showing the message format passed between the Dispatcher 26 and the application specific proxy ( FIG. 14 ( a )) and the message format passed between the application specific proxy back to the Dispatcher 26 ( FIG. 14 ( b )).
  • all messages between the Dispatcher and the proxies begin with a common header 110 to allow leverage of common code for processing the messages.
  • a first portion of the header includes the protocol version 115 which may comprise a byte of data for identifying version control for the protocol, i.e., the message format itself, and is intended to prevent undesired mismatches in versions of the dispatcher and proxies.
  • the next portion includes the message length 120 which, preferably, is a 32-bit integer providing the total length of the message including all headers.
  • the echo/ping flag portion 122 that is intended to support a connectivity test for the dispatcher-proxy connection. For example, when this flag is non-zero, the proxy immediately replies with an echo of the supplied header. There should be no attempt to connect to processes outside the proxy, e.g. the back-end application services.
  • the next portion indicates the Session key 125 which is the unique session key or “cookie” provided by the Web browser and used to uniquely identify the session at the browser.
  • the next portion of the common protocol header indicates the message type/mechanism 130 which may be one of four values indicating one of the following four message mechanisms and types: 1) Synchronous transaction, e.g., a binary 0; 2) Asynchronous request, e.g., a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) bulk transfer, e.g., a binary 3.
  • the common protocol header section includes an indication of dispatcher-assigned serial number 135 that is unique across all dispatcher processes and needs to be coordinated across processes (like the Web cookie (see above)), and, further, is used to allow for failover and process migration and enable multiplexing control between the proxies and dispatcher, if desired.
  • a field 140 indicates the status is unused in the request header but is used in the response header to indicate the success or failure of the requested transaction. More complete error data will be included in the specific error message returned. The status field 140 is included to maintain consistency between requests and replies.
  • the proxy specific messages 375 are the metadata message requests from the report requestor client and can be transmitted via synchronous, asynchronous or bulk transfer mechanisms.
  • the proxy specific responses are metadata response messages 380 again, capable of being transmitted via a synch, asynch or bulk transfer transport mechanism.
  • the application server proxies can either reside on the dispatch server 26 itself, or, preferably, can be resident on the middle-tier application server, i.e., the dispatcher front end code can locate proxies resident on other servers.
  • the proxy validation process includes parsing incoming requests, analyzing them, and confirming that they include validly formatted messages for the service with acceptable parameters. If necessary, the message is translated into an underlying message or networking protocol. A list of Report Manager and Inbox proxy error messages can be found in Appendix E. If no errors are found, the proxy then manages the communication with the middle-tier server to actually get the request serviced.
  • the application proxy supports application specific translation and communication with the back-end application server for both the Web Server (java applet originated) messages and application server messages.
  • the Report Manager server, the Report Scheduler server and Inbox server proxies each employ front end proxy C++ objects and components.
  • a utils.c program and a C++ components library is provided for implementing general functions/objects.
  • Various C++ parser objects are invoked which are part of an object class used as a repository for the RM metadata and parses the string it receives.
  • the class has a build member function which reads the string which includes the data to store. After a message is received, the parser object is created in the RMDispatcher.c object which is a file comprising the business logic for handling metadata messages at the back-end. It uses the services of an RMParser class.
  • RMSErverSocket.c is a class implementing the message management feature in the Report Manager server. Public inheritance is from MCIServerSocket in order to create a specific instance of this object. This object is created in the main loop and is called when a message needs to be sent and received; a Socket.c class implementing client type sockets under Unix using, e.g., TCP/IP or TCP/UDP.
  • Socket.C is inherited by ClientSocket.C:: Socket(theSocketType, thePortNum) and ServerSocket.C:: Socket(theSocketType, thePortNum) when ClientSocket or ServerSocket is created.
  • a ServerSocket.c class 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.c class used as a repository for the RM Metadata. The class' “build” member function reads the string which includes the data to store and the class parses the string it receives.
  • the MCIInboxParser object is created in inboxutl.c which is a file comprising the functions which process the Inbox requests, i.e, Add, Delete, List, Fetch and Update.
  • Additional objects/classes include: Environ.c which provides access to a UNIX environment; Process.c which provides a mechanism to spawn slave processes in the UNIX environment; Daemon.c for enabling a process to become a daemon; Exception.c for exception handling in C++ programs; and, RMlog.c for facilitating RM logging.
  • custom ESQL code for RM/database interface includes the ESQC C interface (Informix) stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, and GPL messages.
  • the functions call the stored procedures according to the message, and the response is built inside the functions depending on the returned values of the stored procedures.
  • a mainsql.c program provides the ESQL C interface for messages from the report manager and report viewer.

Abstract

An Intranet/Internet/Web-based data management tool that provides a common GUI enabling the requesting, customizing, scheduling and viewing of various types of unpriced call detail data reports pertaining to a customer's telecommunications network traffic. The Intranet/Internet/Web-based reporting system tool comprises a novel Web-based, client-server application that enables customers to access their own relevant data information timely, rapidly and accurately through a client GUI. A traffic view server is provided that enables periodic acquisition of data from the customer's telecommunications network at a user-specified frequency and configured to meet real-time traffic reporting requirements. The system infrastructure provided enables secure initiation, acquisition, and presentation of unpriced call detail and statistical data reports to customers.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The following patent application is based on and claims the benefit of U.S. Provisional Patent Application Ser. No. 60/060,655, filed Sep. 26, 1997.
  • FIELD OF THE INVENTION
  • The present invention relates generally to information delivery systems and, particularly, to a novel, World Wide Web/Internet-based, telecommunications network data management reporting and presentation service for customers of telecommunications service entities.
  • BACKGROUND OF THE INVENTION
  • Telecommunications service entities, e.g., MCI, AT&T, Sprint, and the like, presently provide for the presentation and dissemination of customer account and network data management information to their customers predominantly by enabling customers (clients) to directly dial-up, e.g., via a modem, to the entity's application servers to access their account information, or, alternatively, via dedicated communication lines, e.g., ISDN, T-1, etc., enabling account information requests to be initiated through their computer workstation running, for example, a Windows-based graphical user interface. The requests are processed by the entity's application servers, which retrieves the requested customer information, e.g., from one or more databases, processes and formats the information for downloading to the client's computer workstation.
  • Some types of data, e.g., “unpriced” call detail data pertains to a customer's telecommunications traffic, i.e., number usage. This type of data is provided in near real-time, and is used by network managers to make business decisions regarding their telecommunications networks. As an example, the assignee telecommunications carrier MCI Corporation provides an MCI ServiceView (“MSV”) product line for its business customers which includes several client-server based data management applications. One of these applications, referred to as “TrafficView”, provides network traffic analysis/monitor information as provided from an MCI TrafficView server. Particularly, with respect to MCI's TrafficView system, customers are provided with unpriced call detail data, e.g., relating to their toll free networks.
  • The current TrafficView architecture is organized primarily as a batch midrange-based server data delivery mechanism with the data being typically “canned” delivered at predetermined times with predetermined formats. Additional trending, analysis, and data management functionality is maintained by the customers in workstation-based software provided to customers for installation at customer sites on their PCS.
  • While effective for its purpose, the current data management and presentation architecture are limited in that reports generated are of a narrow view, and are delivered at predetermined times with predetermined formats. These prior art reporting systems do not enable the generation of ad-hoc reports. Moreover, legacy platforms containing reporting data are reaching the architectural limits of scalability in terms of the total customers they can support, total online data they can present, total historical data they can keep and type and number of applications they can support. This simply is not sufficient for an increasing number of customers who, to remain competitive, are required to have updated and real-time access to their data to enable them to make their critical business decisions quicker. Moreover, there are a variety of independent data management tools and legacy reporting systems having disparate systems and infrastructures providing little or no cross application interoperability and data sharing, thus, requiring customers to use separate applications to gain access to their data.
  • It would thus be highly desirable to provide a data management product that is a Web-based (Internet and Intranet) client-server application for providing customers with information relating to their telecommunications network traffic and usage in a variety of detailed report formats.
  • It would additionally be highly desirable to provide a Web-based (Internet and Intranet) data management tool having a Web-based client-server application which provides expedient and secure data access and reporting services to customers in real-time, from any web browser on any computer workstation anywhere in the world.
  • SUMMARY OF THE INVENTION
  • The present invention is directed to a novel Intranet/Internet/Web-based data management system that provides a common GUI enabling the requesting, customizing, scheduling and viewing of various types of reports pertaining to customer's telecommunications network traffic, i.e., unpriced “traffic view” data. The Intranet/Internet/Web-based data management system comprises a Web-based, client-server application that enables customers to access their own relevant unpriced network traffic data information timely, rapidly and in a secure manner through the a client GUI. A client server application infrastructure enables processing, generation, and reporting of customer's real-time and rated inbound and outbound telecommunications traffic for network management, call center management and customer calling pattern analysis functions.
  • The system further employs a platform-independent, i.e., JAVA-based, network centric GUI client presentation layer and an objects/dispatcher/proxy layer access architecture.
  • Particularly, the telecommunications data management/system architecture is integrated with a novel Web/Internet-based reporting tool, referred to as “StarWRS”, described in co-pending U.S. patent application Ser. No. ______ (D#11050).
  • The StarWRS web-based reporting tool comprises a layer functioning to enable customers to request reporting functionality across the Internet. This report request functionality includes routing requests to appropriate databases, e.g., real-time reporting requests will be satisfied by real-time database. Additionally, the interface provides customers with the ability to schedule and prioritize reports, format report request result sets, and provides for load balancing, report request validation, query generation and execution. Through a common GUI, customers are enabled to access their own unmetered network traffic data, i.e., usage analysis data.
  • In accordance with the principles of the present invention, there is provided a Web/Internet based reporting system for communicating call detail information relating to traffic pertaining to a customer's telecommunications network to a client workstation via an integrated interface comprising: a client browser application located at the client workstation for enabling interactive Web based communications with the reporting system, the client workstation identified with a customer and providing the integrated interface; at least one secure server for managing client sessions over the Internet, the secure server supporting a secure socket connection enabling encrypted communication between the browser application client and the secure server; a report manager server in communication with at least one secure server for maintaining an inventory of reporting items associated with a customer, the reporting items comprising report data types and report customization features for reports to be generated for the customer; a data retrieval device for retrieving customer specific data from the customer's telecommunications network at pre-determined times; and, a requestor application enabling the customer to communicate a data report request message via the integrated interface to the report manager server, the request message comprising a metadata description of particular reporting items to be retrieved, the metadata description of particular reporting items being forwarded to the retrieval device, and the retrieval device obtaining customer specific data in accordance with the metadata request, whereby customer-specific retrieved data and the metadata description of the reporting items are communicated to the client workstation and utilized to generate a completed report for presentation to the customer.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Further features and advantages of the invention will become more readily apparent from a consideration of the following detailed description set forth with reference to the accompanying drawings, which specify and show preferred embodiments of the invention, wherein like elements are designated by identical references throughout the drawings and in which:
  • FIG. 1 illustrates the software architecture component comprising a three-tiered structure;
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system;
  • FIG. 3 is an illustrative example of a backplane architecture schematic;
  • FIG. 4 illustrates an example client GUI presented to the client/customer as a browser web page;
  • FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture;
  • FIG. 6 is a block diagram depicting the physical architecture of the StarWRS component 200 of the networkMCI Interact system;
  • FIG. 7 is a schematic diagram depicting the nMCI Interact Traffic View system 500 for reporting customer's unpriced call detail data substantially in real-time;
  • FIG. 8 is an general flow diagram of the process by which the TVS server 550 gets data.
  • FIG. 9 is a detailed flow diagram depicting the internal TVS server processes for receiving customer TVS enablement data from order entry and CORE systems;
  • FIG. 10 is a high-level diagram depicting TCR data flow between processes internal to the TVS server;
  • FIG. 11 is a high-level flow diagram depicting TVS report generation process;
  • FIGS. 12(a)-12(d) illustrate the end-to-end process 700 for fulfilling unpriced call detail data report requests;
  • FIG. 13 illustrates a logical message format sent from the client browser to the desired middle tier server for a particular application; and,
  • FIGS. 14(a) and 14(b) are schematic illustrations showing the message format passed between the Dispatcher server and the application specific proxy (FIG. 14(a)) and the message format passed between the application specific proxy back to the Dispatcher server (FIG. 14(b)).
  • DETAILED DESCRIPTION OF THE INVENTION
  • The present invention is one component of an integrated suite of customer network management and report applications using a Web browser paradigm. Known as the networkMCI Interact system (“nMCI Interact”) such an integrated suite of Web-based applications provides an invaluable tool for enabling customers to manage their telecommunication assets, quickly and securely, from anywhere in the world.
  • As described in co-pending U.S. patent application Ser. No. ______ (D#11038), the nMCI Interact system architecture is basically organized as a set of common components comprising the following:
  • 1) an object-oriented software architecture detailing the client and server based aspect of nMCI Interact;
  • 2) a network architecture defining the physical network needed to satisfy the security and data volume requirements of the networkMCI System;
  • 3) a data architecture detailing the application, back-end or legacy data sources available for networkMCI Interact; and
  • 4) an infrastructure covering security, order entry, fulfillment, billing, self-monitoring, metrics and support.
  • Each of these common component areas will be generally discussed hereinbelow. A detailed descriptions of each of these components can be found in a related, co-pending U.S. patent application Ser. No. 00/000,000 (Attorney Docket 11038) entitled INTEGRATED CUSTOMER INTERFACE SYSTEM FOR COMMUNICATIONS NETWORK MANAGEMENT, the disclosure of which is incorporated herein by reference thereto.
  • FIG. 1 is a diagrammatic illustration of the software architecture component in which the present invention functions. A first or client tier 10 of software services are resident on a customer work station 10 and provides customer access to the enterprise system, having one or more downloadable application objects directed to front end business logic, one or more backplane service objects for managing sessions, one or more presentation services objects for the presentation of customer options and customer requested data in a browser recognizable format and a customer supplied browser for presentation of customer options and data to the customer and for internet communications over the public Internet. Additionally applications are directed to front end services such as the presentation of data in the form of tables and charts, and data processing functions such as sorting and summarizing in a manner such that multiple programs are combined in a unified application suite.
  • A second or middle tier 12, is provided having secure web servers and back end services to provide applications that establish user sessions, govern user authentication and their entitlements, and communicate with adaptor programs to simplify the interchange of data across the network.
  • A third or back end tier 15 having applications directed to legacy back end services including database storage and retrieval systems and one or more database servers for accessing system resources from one or more legacy hosts.
  • Generally, as explained in co-pending U.S. patent application Ser. No. ______ (D#11040), entitled GRAPHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS, the disclosure of which is incorporated herein by reference thereto, the customer workstation includes client software capable of providing a platform-independent, browser-based, consistent user interface implementing objects programmed to provide a reusable and common GUI abstraction and problem-domain abstractions. More specifically, the client-tier software is created and distributed as a set of Java classes including the applet classes to provide an industrial strength, object-oriented environment over the Internet. Application-specific classes are designed to support the functionality and server interfaces for each application with the functionality delivered through the system being of two-types: 1) cross-product, for example, inbox and reporting functions, and 2) product specific, for example, toll free network management or Call Manager functions. The system is capable of delivering to customers the functionality appropriate to their product mix.
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system including: the Customer Browser (a.k.a. the Client) 20; the Demilitarized Zone (DMZ) 17 comprising a Web Servers cluster 24; the MCI Intranet Dispatcher Server 26; and the MCI Intranet Application servers 30, and the data warehouses, legacy systems, etc. 40.
  • The Customer Browser 20, is browser enabled and includes client applications responsible for presentation and front-end services. Its functions include providing a user interface to various MCI services and supporting communications with MCI's Intranet web server cluster 24. As illustrated in FIG. 3, and more specifically described in the above-mentioned, co-pending U.S. patent application Ser. No. ______ entitled GRAPHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS, the client tier software is responsible for presentation services to the customer and generally includes a web browser 14 and additional object-oriented programs residing in the client workstation platform 20. The client software is generally organized into a component architecture with each component generally comprising a specific application, providing an area of functionality. The applications generally are integrated using a “backplane” services layer 12 which provides a set of services to the application objects which provide the front end business logic and manages their launch. The networkMCI Interact common set of objects provide a set of services to each of the applications such as: 1) session management; 2) application launch; 3) inter-application communications; 4) window navigation among applications; 5) log management; and 6) version management.
  • The primary common object services include: graphical user interface (GUI); communications; printing; user identity, authentication, and entitlements; data import and export; logging and statistics; error handling; and messaging services.
  • FIG. 3 is a diagrammatic example of a backplane architecture scheme illustrating the relationship among the common objects. In this example, the backplane services layer 12 is programmed as a Java applet which can be loaded and launched by the web browser 14. With reference to FIG. 3, a typical user session starts with a web browser 14 creating a backplane 12, after a successful logon. The backplane 12, inter alia, presents a user with an interface for networkMCI Interact application management. A typical user display provided by the backplane 12 may show a number of applications the user is entitled to run, each application represented by buttons depicted in FIG. 3 as buttons 58 a,b,c selectable by the user. As illustrated in FIG. 3, upon-selection of an application, the backplane 12 launches that specific application, for example, Service Inquiry 54 a or Alarm Monitor 54 b, by creating the application object. In processing its functions, each application in turn, may utilize common object services provided by the backplane 12. FIG. 3 shows graphical user interface objects 56 a,b created and used by a respective application 54 a,b for its own presentation purposes.
  • FIG. 4 illustrates an example client GUI presented to the client/customer as a browser web page 80 providing, for example, a suite 70 of network management reporting applications including: MCI Traffic Monitor 72; an alarm monitor 73; a Network Manager 74 and Intelligent Routing 75. Access to network functionality is also provided through Report Requester 76, which provides a variety of detailed reports for the client/customer and a Message Center 77 for providing enhancements and functionality to traditional e-mail communications.
  • As shown in FIGS. 3 and 4, the browser resident GUI of the present invention implements a single object, COBackPlane which keeps track of all the client applications, and which has capabilities to start, stop, and provide references to any one of the client applications.
  • The backplane 12 and the client applications use a browser 14 such as the Microsoft Explorer versions 4.01 or higher for an access and distribution mechanism. Although the backplane is initiated with a browser 14, the client applications are generally isolated from the browser in that they typically present their user interfaces in a separate frame, rather than sitting inside a Web page.
  • The backplane architecture is implemented with several primary classes. These classes include COBackPlane, COApp, COAppImpl, COParm. and COAppFrame classes. COBackPlane 12 is an application backplane which launches the applications 54 a, 54 b, typically implemented as COApp. COBackPlane 12 is generally implemented as a Java applet and is launched by the Web browser 14. This backplane applet is responsible for launching and closing the COApps.
  • When the backplane is implemented as an applet, it overrides standard Applet methods init( ), start( ), stop( ) and run( ). In the init( ) method, the backplane applet obtains a COUser user context object. The COUser object holds information such as user profile, applications and their entitlements. The user's configuration and application entitlements provided in the COUser context are used to construct the application toolbar and Inbox applications. When an application toolbar icon is clicked, a particular COApp is launched by launchApp( ) method. The launched application then may use the backplane for inter-application communications, including retrieving Inbox data.
  • The COBackPlane 12 includes methods for providing a reference to a particular COApp, for interoperation. For example, the COBackPlane class provides a getApp( ) method which returns references to application objects by name. Once retrieved in this manner, the application object's public interface may be used directly.
  • The use of a set of common objects for implementing the various functions provided by the system of the present invention, and particularly the use of browser based objects to launch applications and pass data therebetween is more fully described in the above-referenced, copending application GRAPHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS.
  • As shown in FIG. 2, the aforesaid objects will communicate the data by establishing a secure TCP messaging session with one of the DMZ networkMCI Interact Web servers 24 via an Internet secure communications path 22 established, preferably, with a secure sockets SSL version of HTTPS. The DMZ networkMCI Interact Web servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session. After establishing that the request has come from a valid user and mapping the request to its associated session, the DMZ Web servers 24 will re-encrypt the request using symmetric encryption and forward it over a second connection 23 to the dispatch server 26 inside the enterprise Intranet.
  • As described in greater detail in co-pending U.S. patent Application Ser. No. ______ (D#11043) entitled SECURE CUSTOMER INTERFACE FOR WEB-BASED DATA MANAGEMENT, the contents and disclosure of which is incorporated by reference as if fully set forth herein, a networkMCI Interact session is designated by a logon, successful authentication, followed by use of server resources, and logoff. However, the world-wide web communications protocol uses HTTP, a stateless protocol, each HTTP request and reply is a separate TCP/IP connection, completely independent of all previous or future connections between the same server and client. The nMCI Interact system is implemented with a secure version of HTTP such as S-HTTP or HTTPS, and preferably utilizes the SSL implementation of HTTPS. The preferred embodiment uses SSL which provides a cipher spec message which provides server authentication during a session. The preferred embodiment further associates a given HTTPS request with a logical session which is initiated and tracked by a “cookie jar server” 28 to generate a “cookie” which is a unique server-generated key that is sent to the client along with each reply to a HTTPS request. The client holds the cookie and returns it to the server as part of each subsequent HTTPS request. As desired, either the Web servers 24, the cookie jar server 28 or the Dispatch Server 26, may maintain the “cookie jar” to map these keys to the associated session. A separate cookie jar server 28, as illustrated in FIG. 2 has been found desirable to minimize the load on the dispatch server 26. 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 FIG. 2, after one of the DMZ Web servers 24 decrypts and verifies the user session, it forwards the message through a firewall 25 b over a TCP/IP connection 23 to the dispatch server 26 on a new TCP socket while the original socket 22 from the browser is blocking, waiting for a response. The dispatch server 26 will unwrap an outer protocol layer of the message from the DMZ services cluster 24, and will reencrypt the message with symmetric encryption and forward the message to an appropriate application proxy via a third TCP/IP socket 27. While waiting for the proxy response all three of the sockets 22, 23, 27 will be blocking on a receive. Specifically, once the message is decrypted, the wrappers are examined to reveal the user and the target middle-tier (Intranet application) service for the request. A first-level validation is performed, making sure that the user is entitled to communicate with the desired service. The user's entitlements in this regard are fetched by the dispatch server 26 from StarOE server 49 at logon time and cached.
  • If the requestor is authorized to communicate with the target service, the message is forwarded to the desired service's proxy. Each application proxy is an application specific daemon which resides on a specific Intranet server, shown in FIG. 2 as a suite of mid-range servers 30. Each Intranet application server of suite 30 is generally responsible for providing a specific back-end service requested by the client, and, is additionally capable of requesting services from other Intranet application servers by communicating to the specific proxy associated with that other application server. Thus, an application server not only can offer its browser a client to server interface through the proxy, but also may offer all its services from its proxy to other application servers. In effect, the application servers requesting service are acting as clients to the application servers providing the service. Such mechanism increases the security of the overall system as well as reducing the number of interfaces.
  • The network architecture of FIG. 2 may also include a variety of application specific proxies having associated Intranet application servers including: a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing; an Inbox proxy for the Inbox application server 31, which functions as a container for completed reports, call detail data and marketing news messages, a Report Manager Proxy capable of communicating with a system-specific Report Manager server 32 for generating, managing and scheduling the transmission of customized reports including, for example: call usage analysis information provided from the StarODS server 33; network traffic analysis/monitor information provided from the Traffic view server 34; virtual data network alarms and performance reports provided by Broadband server 35; trouble tickets for switching, transmission and traffic faults provided by Service Inquiry server 36; and toll free routing information provided by Toll Free Network Manager server 37.
  • As partially shown in FIG. 2, it is understood that each Intranet server of suite 30 communicates with one or several consolidated network databases which include each customer's network management information and data. In the present invention the Services Inquiry server 36 includes communication with MCI's Customer Service Management legacy platform 40(a). Such network management and customer network data is additionally accessible by authorized MCI management personnel. As shown in FIG. 2, other legacy platforms 40(b), 40(c) and 40(d) may also communicate individually with the Intranet servers for servicing specific transactions initiated at the client browser. The illustrated legacy platforms 40(a)-(d) are illustrative only and it is understood other legacy platforms may be interpreted into the network architecture illustrated in FIG. 2 through an intermediate midrange server 30.
  • Each of the individual proxies may be maintained on the dispatch server 26, the related application server, or a separate proxy server situated between the dispatch server 26 and the midrange server 30. The relevant proxy waits for requests from an application client running on the customer's workstation 10 and then services the request, either by handling them internally or forwarding them to its associated Intranet application server 30. The proxies additionally receive appropriate responses back from an Intranet application server 30. Any data returned from the Intranet application server 30 is translated back to client format, and returned over the internet to the client workstation 10 via the Dispatch Server 26 and at one of the web servers in the DMZ Services cluster 24 and a secure sockets connection. When the resultant response header and trailing application specific data are sent back to the client browser from the proxy, the messages will cascade all the way back to the browser 14 in real time, limited only by the transmission latency speed of the network.
  • The networkMCI Interact middle tier software includes a communications component offering three (3) types of data transport mechanisms: 1) Synchronous; 2) Asynchronous; and 3) Bulk transfer. Synchronous transaction is used for situations in which data will be returned by the application server 40 quickly. Thus, a single TCP connection will be made and kept open until the full response has been retrieved.
  • Asynchronous transaction is supported generally for situations in which there may be a long delay in application server 40 response. Specifically, a proxy will accept a request from a customer or client 10 via an SSL connection and then respond to the client 10 with a unique identifier and close the socket connection. The client 10 may then poll repeatedly on a periodic basis until the response is ready. Each poll will occur on a new socket connection to the proxy, and the proxy will either respond with the resultant data or, respond that the request is still in progress. This will reduce the number of resource consuming TCP connections open at any time and permit a user to close their browser or disconnect a modem and return later to check for results.
  • Bulk transfer is generally intended for large data transfers and are unlimited in size. Bulk transfer permits cancellation during a transfer and allows the programmer to code resumption of a transfer at a later point in time.
  • FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture 10. As shown in FIG. 5, the system is divided into three major architectural divisions including: 1) the customer workstation 20 which include those mechanisms enabling customer connection to the Secure web servers 24; 2) a secure network area 17, known as the DeMilitarized Zone “DMZ” set aside on MCI premises double firewalled between the both the public Internet 25 and the MCI Intranet to prevent potentially hostile customer attacks; and, 3) the MCI Intranet Midrange Servers 30 and Legacy Mainframe Systems 40 which comprise the back end business logic applications.
  • As illustrated in FIG. 5, the present invention includes a double or complex firewall system that creates a “demilitarized zone” (DMZ) between two firewalls 25 a, 25 b. In the preferred embodiment, one of the firewalls 29 includes port specific filtering routers, which may only connect with a designated port address. For example, router 49 (firewall 25(a)) may connect only to the addresses set for the HydraWeb® (or web servers 24) within the DMZ, and router 55 (firewall 25(b)) may only connect to the port addresses set for the dispatch server 26 within the network. In addition, the dispatch server 26 connects with an authentication server, and through a proxy firewall to the application servers. This ensures that even if a remote user ID and password are hijacked, the only access granted is to one of the web servers 24 or to intermediate data and privileges authorized for that user. Further, the hijacker may not directly connect to any enterprise server in the enterprise intranet beyond the DMZ, thus ensuring internal company system security and integrity. Even with a stolen password, the hijacker may not connect to other ports, root directories or application servers within the enterprise system, and the only servers that may be sabotaged or controlled by a hacker are the web servers 24.
  • The DMZ 17 acts as a double firewall for the enterprise intranet because of the double layer of port specific filtering rules. Further, the web servers 24 located in the DMZ never store or compute actual customer sensitive data. The web servers only transmit the data in a form suitable for display by the customer's web browser. Since the DMZ web servers do not store customer data, there is a much smaller chance of any customer information being jeopardized in case of a security breach. In the preferred embodiment, firewalls or routers 47,49 are a combination of circuit gateways and filtering gateways or routers using packet filtering rules to grant or deny access from a source address to a destination address. All connections from the internal application servers are proxied and filtered through the dispatcher before reaching the web servers 24. Thus it appears to any remote site, that the connection is really with the DMZ site, and identity of the internal server is doubly obscured. This also prevents and direct connection between any external and any internal network or intranet computer.
  • The filtering firewalls 25(a), (b) may also pass or block specific types of Internet protocols. For example, FTP can be enabled only for connections to the In-Box server 31, and denied for all other destinations. SMTP can also be enabled to the In-Box server, but Telnet denied. The In-box server 31 is a store and forward server for client designated reports, but even in this server, the data and metadata are separated to further secure the data, as will be described.
  • As previously described, the customer access mechanism is a client workstation 20 employing a Web browser 14 for providing the access to the networkMCI Interact system via the public Internet 15. When a subscriber connects to the networkMCI Interact Web site by entering the appropriate URL, a secure TCP/IP communications link 22 is established to one of several Web servers 24 located inside a first firewall 25 a in the DMZ 17. Preferably at least two web servers are provided for redundancy and failover capability. In the preferred embodiment of the invention, the system employs SSL encryption so that communications in both directions between the subscriber and the networkMCI Interact system are secure.
  • In the preferred embodiment, all DMZ Secure Web servers 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. The web servers may be interconnected by a fast Ethernet LAN running at 100 Mbit/sec or greater, preferably with the deployment of switches within the Ethernet LANs for improved bandwidth utilization. One such switching unit included as part of the network architecture is a HydraWEB® unit 45, manufactured by HydraWEB Technologies, Inc., which provides the DMZ with a virtual IP address so that subscriber HTTPS requests received over the Internet will always be received. The Hydraweb unit 45 implements a load balancing algorithm enabling intelligent packet routing and providing optimal reliability and performance by guaranteeing accessibility to the “most available” server. It particularly monitors all aspects of web server health from CPU usage, to memory utilization, to available swap space so that Internet/Intranet networks can increase their hit rate and reduce Web server management costs. In this manner, resource utilization is maximized and bandwidth (throughput) is improved. It should be understood that a redundant Hydraweb® unit may be implemented in a Hot/Standby configuration with heartbeat messaging between the two units (not shown). Moreover, the networkMCI Interact system architecture affords web server scaling, both in vertical and horizontal directions. Additionally, the architecture is such that new secure web servers 24 may be easily added as customer requirements and usage increases.
  • As shown in FIG. 5, the most available Web server 24 receives subscriber HTTPS requests, for example, from the HydraWEB™ 45 over a connection 44 a and generates the appropriate encrypted messages for routing the request to the appropriate MCI Intranet midrange web server over connection 44 b, router 55 and connection 23. Via the Hydraweb unit 45, a TCP/IP connection 38 links the Secure Web server 24 with the MCI Intranet Dispatcher server 26.
  • Further as shown in the DMZ 17 is a second RTM server 52 having its own connection to the public Internet via a TCP/IP connection 48. As described in co-pending U.S. patent application Ser. No. ______, (D# 11045) entitled INTEGRATED PROXY INTERFACE FOR WEB BASED TELECOMMUNICATIONS MANAGEMENT TOOLS, incorporated by reference as if fully set forth herein, this RTM server provides real-time session management for subscribers of the networkMCI Interact Real Time Monitoring system. An additional TCP/IP connection 48 links the RTM Web server 52 with the MCI Intranet Dispatcher server 26. As further shown in FIG. 5, a third router 65 is provided for routing encrypted subscriber messages from the RTM Web server 52 to the Dispatcher server 26 inside the second firewall. 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 Dispatcher server 26. In operation, each of the Secure servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session from the COUser object authenticated at Logon.
  • After establishing that the request has come from a valid user and mapping the request to its associated session, the Secure Web servers 24 will re-encrypt the request using symmetric RSA encryption and forward it over a second secure socket connection 23 to the dispatch server 26 inside the enterprise Intranet.
  • As described herein, and in greater detail in co-pending U.S. patent application Ser. No. ______ (D# 11038), the data architecture component of networkMCI Interact reporting system is focused on the presentation of real time (un-priced) call detail data, such as provided by MCI's TrafficView Server 34, and priced call detail data and reports, such as provided by MCI's StarODS Server 33 in a variety of user selected formats.
  • All reporting is provided through a Report Requestor GUI application interface which support spreadsheet, a varity of graph and chart type, or both simultaneously. For example, the spreadsheet presentation allows for sorting by any arbitrary set of columns. The report viewer may also be launched from the inbox when a report is selected.
  • Report management related data is also generated which includes 1) report profiles defining the types of reports that are available, fields for the reports, default sort options and customizations allowed; and 2) report requests defining customer specific report requests including report type, report name, scheduling criteria, and subtotal fields. This type of data will be resident in an Inbox server database and managed by the Inbox server.
  • The Infrastructure component of the nMCI Reporting system includes means for providing secure communications regardless of the data content being communicated. As described in detail in above-referenced, co-pending U.S. patent application Ser. No. ______ (D#11043), the nMCI Interact system security infrastructure includes: 1) authentication, including the use of passwords and digital certificates; 2) public key encryption, such as employed by a secure sockets layer (SSL) encryption protocol; 3) firewalls, such as described above with reference to the network architecture component; and 4) non-repudiation techniques to guarantee that a message originating from a source is the actual identified sender. One technique employed to combat repudiation includes use of an audit trail with electronically signed one-way message digests included with each transaction.
  • Another component of the nMCI Interact infrastructure includes order entry, which is supported by the Order Entry (“StarOE”) server. The general categories of features to be ordered include: 1) Priced Reporting; 2) Real-time reporting; 3) Priced Call Detail; 4) Real Time Call Detail; 5) Broadband SNMP Alarming; 6) Broadband Reports; 7) Inbound RTM; 8) Outbound RTM; 9) Toll Free Network Manager; and 10) Call Manager. The order entry functionality is extended to additionally support 11) Event Monitor; 12) Service Inquiry; 13) Outbound Network Manager; 14) Portfolio; and, 15) Client View.
  • The Self-monitoring infrastructure component for nMCI Interact is the employment of mid-range servers that support SNMP alerts at the hardware level. In addition, all software processes must generate alerts based on process health, connectivity, and availability of resources (e.g., disk usage, CPU utilization, database availability).
  • The Metrics infrastructure component for nMCI Interact is the employment of means to monitor throughput and volumes at the Web servers, dispatcher server, application proxies and mid-range servers. Metrics monitoring helps in the determination of hardware and network growth.
  • To provide the areas of functionality described above, the client tier 10 is organized into a component architecture, with each component providing one of the areas of functionality. As explained in further detail in co-pending U.S. patent application Ser. No. ______ (Atty. D# 11040), the client-tier software is organized into a “component” architecture supporting such applications as inbox fetch and inbox management, report viewer and report requester, TFNM, Event Monitor, Broadband, Real-Time Monitor, and system administration applications. Further functionality integrated into the software architecture includes applications such as Outbound Network Manager, Call Manager, Service Inquiry and Client View.
  • The present invention focuses on the client and middle-tier service and application proxy components that enable customers to request, specify, customize, schedule and receive their unpriced telecommunications network traffic call detail data and account information in the form of reports that are generated by a back-end application server. Referred to herein as “StarWRS,” this WWW/Internet Reporting System 200, as shown in FIG. 6, comprises the following components and messaging interfaces:
  • 1) those components associated with the Client GUI front end including a report requestor client application 212, a report viewer client application 215 and, an Inbox client application 210 which implement the logical processes associated with a “Java Client”, i.e., employs Java applets launched from the backplane (FIG. 3) that enable the display and creation of reports and graphs based on the fields of the displayed reports, and, allows selection of different reporting criteria and options for a given report; and,
  • 2) those middle-tier server components enabling the above-mentioned reporting functionality including: a Report Manager server 250, a Report scheduler server 260, and an Inbox Server 270. Also shown in FIG. 6 are the system Order Entry client application 280 and a corresponding Order Entry Server 285 supporting the StarWRS reporting functionality as will be described.
  • Each of these components will now be described with greater particularity hereinbelow.
  • The Report Manager (“RM”) server 250 is an application responsible for the synchronization of report inventory with the back-end “Fulfilling” servers 400, 500; retrieval of entitlements, i.e., a user's security profiles, and report pick list information, i.e., data for user report customization options, from the system Order Entry server 280; the transmission of report responses or messages to the Dispatcher server 26 (FIG. 6); the maintenance of the reporting databases; and, the management of metadata used for displaying reports. In the preferred embodiment, the RM server 250 employs a Unix daemon that passively listens for connect requests from the GUI client applications and other back-end servers and deploys the TCP/IP protocol to receive and route requests and their responses. Particularly, Unix stream sockets using the TCP/IP protocol suite are deployed to listen for client connections on a well-known port number on the designated host machine. Client processes, e.g., report requester 212, desiring to submit requests connect to RM 250 via the dispatcher 26 by providing the port number and host name associated with RM 250. For particular back-end server 400 providing priced reporting data, a Talarian smart socket connection 254 is provided. Request messages received by the RM server are translated into a “metadata” format and validated by a parser object built into a report manager proxy 250′ that services requests that arrive from the GUI front-end. If the errors are found in the metadata input, the RM 250 will return an error message to the requesting client. If the metadata passes the validation tests, the request type will be determined and data will be retrieved in accordance with the meta data request after which a standard response will be sent back to the requesting client. As shown in FIG. 6, interface sockets 252 are shown connecting the Dispatcher server 26 and the RM server 250 and, other socket connections 254, 256 are shown interfacing with respective back end servers 400 and 500. In one embodiment, server 400 provides a customer's priced billing data through a Talarian smart socket messaging interface 254 to the Report Manager. Particularly, as described in commonly owned, co-pending U.S. patent application Ser. No. ______ (COS-97-093), a back-end billing mainframe application known as the StarODS server provides such priced call detail data. Additionally, as shown in FIG. 6 and described in commonly owned, co-pending U.S. patent application Ser. No. ______ (D#11567), the contents and disclosure of which are incorporated by reference as if fully set forth herein, call detail data is FTP'd directly to the Inbox Server and a message is sent to the report manager server 250 from the Traffic View server (“TVS”) 500. Although not shown in FIG. 6 it should be understood that the RM 250 server can manage reporting data for customer presentation from other back-end and legacy servers including, e.g., Broadband, Toll Free Network Management, and Event Monitor servers, etc. in order to present to a customer these types of network management and reporting data.
  • The report manager server additionally utilizes a database 258, such as provided by Informix, to provide accounting of metadata and user report inventory. Preferably, an SQL interface is utilized to access stored procedures used in processing requests and tracking customer reports. A variety of C++ tools and other tools such as Rogue Wave's tools.h++ are additionally implemented to perform metadata message parsing validation and translation functions.
  • The Report Manager server 250 additionally includes the scheduling information, however, a report scheduler server component passes report requests to the back- end fulfilling servers 400, 500 at the scheduled times.
  • Particularly, the Report Scheduler (“RS”) server component 260 is, in the preferred embodiment, a perpetually running Unix daemon that deploys the TCP/IP protocol to send report requests to the back-end fulfilling servers such as the StarODS server 400, TVS server 500, and receive their responses. More particularly, the RS server 260 is a Unix server program that is designed to handle and process report requests to the fulfilling servers by deploying Unix stream sockets using the TCP/IP protocol suite, sending the request for customized reports to client connections on a well-known port number on the designated host machine. As shown in FIG. 6, interface socket connections 264, 266 are shown interfacing with respective back end servers 400 and 500. In the case of priced billing data from StarODS 400, report requests are published by the RS server 260 to a pre-defined subject on the Talarian Server. When handling other incoming messages published by back end servers using Talarian SmartSockets 4.0, another daemon process is necessary that uses Talarian C++ objects to connect their message queue and extract all messages for a given subject for storage in a database table contained in database 263. Each message includes the track number of the report that was requested from the fulfilling server.
  • From the report requestor interface, the user may specify the type of reporting, including an indication of the scheduling for the report, e.g., hourly, daily, weekly or monthly. For priced data the user has the option of daily, weekly, or monthly. For real-time, or unpriced data, the user has the option of hourly, daily, weekly or monthly. The report scheduler interface additionally enables a user to specify a pager or E-mail account so that an e-mail or pager message may be sent to indicate when a requested report is in the Inbox server 270.
  • As shown in FIG. 6, the report scheduler server 260 interfaces directly with the Report Manager server 250 to coordinate report request scheduling and processing. It should be understood that the respective report management and scheduling functions could be performed in a single server.
  • The Inbox Server component 270 serves as the repository where the completed user report data is stored, maintained, and eventually deleted and is the source of data that is uploaded to the client user via the dispatcher over a secure socket connection 272 between the Web server and the browser. It is also a Unix program that is designed to handle and process user requests submitted in meta data format using an Informix database. Once report results are received from the StarODS 400 and TVS 500 and any other back-end or fulfilling servers (not shown), the Report Manager server 250 communicates the corresponding report metadata to the Inbox server 270 over socket connection 274 as shown in FIG. 6. The metadata will be stored in the Inbox server database 273 along with the report results. Thus, if the meta data is required to be changed, it will not interfere with the information needed to display the reports contained in the Inbox. Additionally, as shown in FIG. 6, the Inbox server interfaces with the report scheduler to coordinate execution and presentation of reports.
  • The StarOE server 280 is the repository of user pick lists and user reporting entitlements as shown in database 283. Particularly, it is shown interfacing with the Inbox server 270 and report scheduler servers 260. The Report Manager does not interface with or contain metadata for StarOE. It will, however, include information in the report metadata that will tell the Report Requestor it needs to get information (i.e., Pick Lists) from StarOE server 285.
  • A common database may be maintained to hold the common configuration data which can be used by the GUI applications and by the mid-range servers. Such common data will include but not be limited to: customer security profiles, billing hierarchies for each customer, general reference data (states, NPA's, Country codes), and customer specific pick lists: e.g., ANI's, calling cards, etc. An MCI Internet StarOE server will manage the data base for the common configuration of data.
  • With regard to the front-end client GUI components, the above-mentioned Inbox client application 210 functions as an interface between the client software and the Inbox server 270 for presenting to the customer the various type of reports and messages received at the Inbox including all completed reports, call detail, and marketing news messages. Preferably, the messages for the user in the inbox are sorted by type (report, call detail, alarms) and then by report type, report name, date, and time.
  • Particularly, the Inbox client application uses the services of the backplane (FIG. 3) to launch other applications as needed to process report messages. The inbox will also use the services of the data export objects to provide a save/load feature for inbox messages, and, is used to provide a user-interface for software upgrade/download control. Inbox messages are generated by the versioning services of the backplane; actual downloads will be accomplished by a request through the inbox.
  • In the preferred embodiment, the inbox client is able to receive information on multiple threads to allow a high priority message to get through even if a large download is in progress. Typically, the browser is configured to allow more than one network connection simultaneously, i.e., the polling thread on the client uses a separate connection to check for new messages, and starts a new thread on a new connection when a new message is detected. In this way, multiple messages may be downloaded simultaneously.
  • The Report Requestor application 212 is a GUI Applet enabling user interaction for managing reports and particularly includes processes supporting: the creation, deletion, and editing of the user's reports; the retrieval and display of reports based on selected criteria; the display of selected option data; and the determination of entitlements which is the logical process defining what functionality a user can perform on StarWRS. In the preferred embodiment, the Report requestor additionally enables a user to specify the frequency of report generation, e.g., periodically, or as “one-shots” to be performed at a later time. As described herein, the report scheduler service maintains a list of requested reports for a given user, and forwards actual report requests to the appropriate middle-tier servers at the appropriate time. Additional functionality is provided to enable customers to manage their inventory, e.g., reschedule, change, or cancel (delete) report requests.
  • In the preferred embodiment, the report requestor utilizes the platform client JAVA code to communicate with the report manager server. To communicate with the StarOE for user security, hierarchy, paging and e-mail, etc. the Report Requestor uses StarOE client Java code. Report Requestor JAVA applets implementing the above-described report requester functionality, are downloaded to the customer's workstation in the form of a cab file after initial login.
  • The Report Viewer application 215 is a GUI Applet enabling a user to analyze and display the data and reports supplied from the fulfilling servers such as StarODS 400, Traffic View (“TVS”) 500, and other systems such as Broadband and toll free network manager. Particularly, the Report Manager 250 includes and provides access to the metadata which is used to tell the Report Requestor what a standard report should look like and the “pick-list” options the user has in order for them to customize the standard report. It is additionally used to tell the Report Viewer client how to display the report, what calculations or translations need to be performed at the time of display, and what further customization options the user has while viewing the report. It additionally includes a common report view by executing a GUI applet that is used for the display and graphing of report data and particularly, is provided with spreadsheet management functionality that defines what operations can be performed on the spreadsheet including the moving of columns, column suppression, column and row single and multiple selection, import and export of spreadsheet data, printing of spreadsheet, etc. It is also provided with report data management functionality by defining what operations can be performed on the data displayed in a spreadsheet including such dynamic operations as sorting of report data, sub-totaling of report data, etc. Furthermore, the report viewer 215 is provided with functionality enabling the interpretation of Meta Data; and, functionality enabling communication with the Backplane (FIG. 3). The Report Viewer application 215 additionally accepts messages telling it to display an image or text that may be passed by one of the applications in lieu of report data (e.g., Invoice, Broadband report, etc.)
  • All reporting is provided through the Report Viewer interface which supports text displays, a spreadsheet, a variety of graphic and chart types, or both spreadsheet/graph simultaneously. The spreadsheet presentation allows for sorting by any arbitrary set of columns. The report viewer 215 is launched from the inbox client 210 when a report is selected.
  • By associating each set of report data which is downloaded via the Inbox server 270 with a “metadata” report description object, reports can be presented without report-specific presentation code. At one level, these metadata descriptions function like the catalog in a relational database, describing each row of a result set returned from the middle tier as an ordered collection of columns. Each column has a data type, a name, and a desired display format, etc. Column descriptive information will be stored in an object, and the entire result set will be described by a list of these objects, one for each column, to allow for a standard viewer to present the result set, with labeled columns. Nesting these descriptions within one another allows for breaks and subtotaling at an arbitrary number of levels.
  • The same metadata descriptions may be used to provide common data export and report printing services. When extended to describe aggregation levels of data within reporting dimensions, it can even be used for generic rollup/drilldown spreadsheets with “just-in-time” data access.
  • The metadata data type may include geographic or telecommunications-specific information, e.g., states or NPAs. The report viewer may detect these data types and provide a geographic view as one of the graph/chart types.
  • Referring now to FIG. 7, the traffic view system (“TVS”) 500 of the present invention comprises a Traffic View Server 550 which functions to store network call detail records (CDRs) and statistics, generate reports and deliver reports and/or call detail to the customer via the StarWRS Web Reporting System, and, supplies on-line customer access to call detail and hourly statistics that aid the customer in Network management, call center management and customer calling pattern analysis. For real time (unpriced) data, statistics are generated for the following totals: minutes, attempts, completes, incompletes, other, dto (direct termination overflow), short calls, didn't wait, didn't answer, tcc, and equipment failures.
  • The process by which the TVS server 550 gets data is now explained in greater detail with reference to FIGS. 7 and 8. As shown, call records are created by a network switch 501. An AP (Adjunct processor) or Storage and Verification Elements (“SAVE”) platform 502 is co-located with each switch and receives all the call records from the switch as soon as possible after a call disconnects. The AP/SAVE sends all the call records to a (Network Information Concentrator (NIC) 503 where records are grouped together and those groupings numbered for a more efficient network utilization. If the NIC determines that it is missing a gap in the numbers, it will request the AP/SAVE resend that group of data to ensure that no data is lost. Should the NIC be unavailable 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 disconnected (hangs up) and distributes records to clients that match a certain criteria.
  • A generalized statistics engine (GSE) component 504 receives all records that are considered to be a toll free (800/8xx, etc) call from the NIC and also employs the same sequencing of groups of records to ensure that no data is lost. Should the GSE be unavailable, the NIC will queue the data for later delivery. The GSE component 504 further filters toll-free calls to only process calls that match a subscriber list which is maintained by an order entry OE process on the GSE (not shown) that accepts add & delete requests from TVS via a messaging interface 507 as shown in FIG. 7. The GSE component then formats the CDRs, i.e., enhances the call records, from the form as originally provided at the switch, into a normalized form to allow for a common record format regardless of the type of switch that created the record, or the exact call record type. For example, different network switches generate different call detail records, e.g., call detail record, enhanced call detail records, etc., which denote differences in toll-free services and features. This type of call detail record generated by GSE component is herein referred to as a TCR (Translated Call Record).
  • Groups of TCRs are sent from the GSE to TVS via TCP/IP. When TVS has safely stored that record it sends an acknowledgment to the GSE 504 so that the GSE may dispose of the group. Should TVS not be available to receive data, GSE queues data to be sent later.
  • As shown in FIG. 7, in the preferred embodiment, initial customer provisioning occurs at either the Corporate Order Entry system 223 (CORE) or the StarOE server 285 component of MCI Interact. As shown in FIG. 9, CORE 223 transmits daily to the TVS server 550 via Network Data Mover (NDM) files which comprise information about new reports for TVS to create, and where to send those reports, e.g., FAX, E-Mail, or US Mail. In the NMCI Interact TrafficView Server 550, a CORE FEED process 523 provisions reporting order and profiles into a reference database 551, and sets up scheduled reports to work on the next boundary, e.g., hourly, daily reports at midnight the next complete day, weekly reports at the end of the next week, monthly reports at the end of the month, etc. If this report requires Call detail records, as opposed to aggregated data, a CDR database is selected based on weighted values for the existing database. If a request contains a toll-free number that has not been provisioned with the GSE, a GSE_OE process 524 is invoked to forward the order, e.g., toll-free number, from the reference database onto a DEC Message Queue™ “DMQ” 526 a. A GSE_OE_SEND process 527 is invoked to keep a TCP/IP socket open to the GSE process so that the pending order may be forwarded to the GSE 504 via a TCP/IP interface. Once the order has been provisioned in GSE the GSE may start to collect CDRs based on the requested toll-free number. In response, the GSE will invoke the GSE_OE_SEND process 527 to send an order response to a DMQ 526 b, where it will be accessed by the GSE_OE process 524. The GSE_OE process 524, in turn, will confirm that the number has been provisioned within the TVS server and will update the reference database accordingly by removing the order from a pending order list. Invocation of the GSE_OE process and the GSE_OE_SEND process enables tracking of new customer orders, i.e., new toll-free network numbers for which CDR data is to be collected.
  • As further shown in FIGS. 7 and 9, in the preferred embodiment, requests to enable TrafficView customers are received in real-time from StarOE 285 via TCP/IP. Generally, StarOE specifies what general categories of reports can be requested for a given nMCI Interact subscriber. These categories include: 1) reports that only require data aggregation; 2) reports that require call detail records to be collected; and 3) real-time monitor (RTM) reports. This is provisioned into the reference database 551 for future verification of requests from the nMCI Interact platform. If a request contains a toll-free number that has not been provisioned with the GSE, a subscription request is sent to the GSE 504 via the GSE_OE and GSE_OE-SEND process to start collecting TrafficView data pertaining to that toll-free number. This request is sent by placing a request onto the DMQ queue 526 a, and the GSE_SEND_OE process 527 then forwards this request to the GSE 504 via a TCP/IP interface. In the preferred embodiment, the content and format of an “order entry” message generated by the TVS server for requesting unpriced traffic data from the GSE is provided in Appendix H. In accordance with this messaging, the GSE selects all TCR's for TVS enabled customers and places them in a SAVE storage queue, e.g., Versant or Talarian, for subsequent distribution to the TVS server.
  • As further shown in FIG. 7, an input feed from the calling area database component 508 (“CADB”) provides the TVS server 550 with reference data including state and country information for mapping NPA/NXX (Numbering Plan Area/Number Exchange) to city name and state code, and, for mapping country codes to country names. Data is transported from the CADB database 518 to the TVS server via a network data mover (“NDM”) or FTP via interface 519.
  • A further input feed from the Global Information Repository “GIR” component 511 provides the TVS server with International toll-free number terminations on a periodic basis.
  • From the circuit order management system (“COMS”) component 515, TVS receives three NDM feeds: 1) a Trunk Type Master feed 516 used in Un-priced Reporting to map enhanced voice service/dedicated access line (EVS/DAL) information to specific service locations; 2) an automatic number identification (“ANI”) feed 517 also used in Unpriced Reporting to map EVS/DAL information to specific service locations; and, 3) a switch mapping feed 518 to map the switch ID (per Network control system) to the billing representations of the same switch.
  • As further shown in the FIG. 7, unpriced data collection process begins with the placement of an order for unpriced reporting with the customer's account team. Specifically, the account team places the order in real time using an ordering system component. In a periodic process, this order information is transmitted to OEHubs 224, e.g., via e-mail which later inputs the necessary service and reporting flags to the StarOE component 285, via messaging interface 226. The OEHubs 224 further adds new customers to the corporate order entry (“CORE”) system component 223, which provides customer billing hierarchy information used by the StarWRS system. The new customer hierarchy information is extracted by the CORE system 223, and is available for pickup by the StarOE server 285 via messaging interface 227.
  • The StarOE server 285 then messages the Traffic View Server 550 in real time via TCP/IP that the number has been added for Unpriced Reporting. The TVS additionally messages the GSE component 505 in real time to immediately initiate the collection of call detail for that number, as will be described in greater detail herein. Due to latency inherent in the fulfillment process, customers may select and receive daily reports after CDR collection begins.
  • In accordance with the invention, a wide variety of reports and reporting frequencies are available. In the preferred embodiment, reports are available in hourly, daily, weekly, and monthly frequencies.
  • Types of TVS reports that are available to customers include: Standard reports; Summary reports; Termination Reports; Exception reports; and, unpriced call detail. For example, Standard reports that may be generated from stored Toll Free hourly statistics include, but are not limited to: Summary by Toll Free Number and Hour which is available in the following frequencies (Ad-hoc “A”, Daily “D”, Weekly “W”, and Monthly “M”); Summary by Toll Free Number and Date(A,D,W,M); Summary by Toll Free Number and day of week (“DOW”) (A,W,M); Summary by Toll Free Number and Week (A,M); Summary by Toll Free Number and NPA (A,D,W,M); Summary by Toll Free Number, Service Location and Hour(A,D,W,M); Summary by Toll Free Number, Service Location and Date (A,D,W,M); Summary by Toll Free Number, Service Location and DOW (A,W,M); Summary by Toll Free Number, Service Location and Week (A,M); Summary by Service Location and Hour (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, Toll Free Number and Hour (A,D,W,M); Summary by Service Location, Toll Free Number and Date(A,D,W,M); Summary by Service Location, Toll Free Number and DOW (A,W,M); Summary by Service Location, Toll Free Number and Week (A,M). The Toll Free Summary Reports generally comprise three sections: Summary, Incomplete Call Analysis, and Network Customer Blocked Analysis (other category breakdown). The Termination Summaries include three types of termination reports: Toll Free by Location, i.e., showing termination summary and incomplete call analysis by service location for a specific Toll Free number; By Location, i.e., by service location across all Toll Free numbers terminating to the same service location; and, Location by Toll Free, i.e., for a specific service location, shows each Toll Free number terminating to this location. The originating NPA/Country Code summary reports provide information by NPA and Country for each Toll Free number attached to the report.
  • Additionally available are what are called Call Detail Exception Reports/images which provide reporting information pertaining to the following: Completion Rate and Retry (A,D,W,M); Completion Rate and Retry with Queue Abandonment (A,D,W,M); Lost Caller and Retry (A,D,M); Lost Caller and Retry with Queue Abandonment (A,D,M); Most Frequent Calling Numbers (A,D,W,M); Most Frequent Calling NPA/NXX (A,D,W,M); Most Frequent Calling Country (A,D,W,M).
  • The nMCI Interact Exception reports (images) includes: Completion Rate and Retry (A,D,W,M); Completion Rate and Retry with Queue Abandonment (A,D,W,M); Lost Caller and Retry (A,D,M); Lost Caller and Retry with Queue Abandonment (A,D,M); Most Frequent Calling Numbers (A,D,W,M); Most Frequent Calling NPA/NXX (A,D,W,M); and, Most Frequent Calling Country (A,D,W,M). The nMCI Interact Exception reports (data) includes: Call Detail by Originating ANI (A,D,W,M); Call Detail by ID Code (A,D,W,M); Call Detail by NCR Indicator (A,D,W,M); Call Detail by Originating State (A,D,W,M); Call Detail by Disposition (A,D,W,M); Call Detail by Service Location (A,D,W,M); Payphone Summary (A,M). Downloadable nMCI interact Call Detail reports includes Traffic view call detail (available as ad-hoc and daily) and Outbound traffic view call detail data (available as ad-hoc, daily and weekly).
  • As mentioned, via TCP/IP messaging, the TVS system 550 receives a request in real-time from the nMCI Interact StarOE component 285 to begin collecting call detail records for a particular TVS/Unpriced reporting customer, which number had been previously assigned during the order entry process. When a customer discontinues Unpriced Reporting for a number, this information is entered in StarOE tables where it is stored for a predetermined period subsequent to termination of the number. After the predetermined period of time, e.g., seven days, the numbers scheduled for service deletion are passed to TVS via TCP/IP connectivity in real time. After receiving this information, TVS instructs the GSE 504 in real time to stop collecting CDRs for these numbers.
  • FIG. 10 illustrates a generalized block diagram detailing the internal TVS data acquisition processes. As shown in FIG. 10, a TVS server “GSE_TCR_RCVR” process 564 receives a group of TCR records from the GSE component 504. The GSE_TCR_RCVR process 564 inserts that group into a DMQ (DecMessageQueue) queue 553 a that provides a guaranteed message delivery. Upon successful storing of a record into the DMQ queue 553 a, the GSE_TCR_RCVR process 564 sends an acknowledgment to the GSE component 504 so that it may delete that group. If TVS fails to acknowledge this group after a predetermined timeframe, the GSE continues to resend this group until an acknowledgment is received. The TCR_DISTRIB process 566 reads groupings of records and distributes a record based on the toll-free number associated with that record in the following manner:
  • First, as the reference database 551 contains information on which toll-free number belongs in which CDR database associated with the TVS server, records are grouped for each CDR database 561 a, 561 b, . . . , 561 n, to which they belong. The reference database 551 additionally flags which numbers are to have statistics collected for them. Thus, an additional group of records is created and may be routed to a DMQ Queue 553 b which inputs these records into a statistics “stats” counter process 570 for statistics processing, as will be described in greater detail herein. When all the records in the group have been read, each group is written to it's DMQ queue 554 a, 554 b, . . . , 554 n associated with its destination database CDR Database 561 a, 561 b, . . . , 561 n. For instance, via a TCR Poster process 555 a, records destined for CDR database 561 a are forwarded from the DMQ Queue 554 a. Particularly, each CDR poster process 555 a, 555 b, . . . , 555 n reads data from it's corresponding DMQ Queue and formats & stores those records in their database.
  • With further regard to the stats counter 570 shown in FIG. 10, TCRs are rolled up into statistics records. Specifically, the stats counter 570 keeps counts of the following: summary information about each toll free number for an hour; summary information about each toll free number and termination for an hour; and, summary information about each toll free number and origination NPA for an hour. These statistics are kept in memory for a pre-determined amount of time, e.g., one hour. As matching records come in, statistics are updated. At the end of the time period, these records are written to the statistics database 571, and particularly high speed electronic data drives.
  • The statistics that are gathered for each subscriber's toll-free number in the TVS system of the invention include: total completions, total call duration, total attempts, total switch control call, total Network Control System (NCS) blocked, total NCS rejected, total network blocked (all routes busy), total supp code blocked, and out-of-band blocked. The summary table processing algorithm in Appendix I details the collection of these statistics by the GSE and the TVS summary table processing.
  • Additionally, statistics gathered for NP table processign include: originating NPA, total attempts per NPA, total calls completed (tcc) per NPA, total call not delivered (blocked) per NPA, total attempts for International Originations, tcc for International Originations (“IO”), total calls not delivered (blocked) for IO.
  • Additionally, call statistics for terminations inlcude: termination type, termination address, total completions, total call duration, and call dispositions indicating the cause of an incomplete call including: total short calls, total didn't write, and total didn't answer.
  • With more particularity regarding the statistics database design, and, in further view of FIG. 10, the stats_counter 570 contains processes that read TCR's from a DMQ queue, and create statistics records for input to “c_tables” in the statistics database 571.
  • Appendix I depicts the algorithms implemented in TVS stats_counter process 570 for generating statistics data tables so that TCR records may be processed in batches. As shown, the processes include: a summary table process which process generates statistics for call summary data; a NPA table process; Country table process and Termination table process. The stats_counter 570 enables multiple processes to be run at the same time on the same machine. To allow an arbitrary number of Stats_Counter processes, the stats databases are organized as a series of configurable tables, e.g., “C_Tables” 572, which are temporary tables that the stats counters first insert records to: These tables are identical to normal statistics tables with the exception that they include a field for the date in them. In accordance with the provision of C_tables, a pending_stats_list table and stats_table_usage_list table are used to keep track of what data is in the C_tables, and to drive the movement of data from the C_tables to a more permanent database tables 574.
  • Particularly, when the stats_counter process 570 starts, it performs a check of the set of “c_tables” by inserting its process name in the used_by_process field of the stats_table_usage_list table. If the stats_counter process unexpectantly dies, it reclaims the tables previously used by searching the stats_table_usage_list for tables marked with it's process name. The stats_counter process adds an entry into the pending_stats_list every time it creates stats for a new day. The usage_flag is initially set to “1” in that table. At the top of the hour, for example, the stats_counter processes marks all of the usage_flag entries to “2”, and modifies the value of the used_by_process field in the stats_table_usage_list to “MOVER”. The stats_counter process then searches the stats_table_usage_list for another set of tables to use for the next hours counting. If the stats_counter process cannot find a set of tables, it aborts. To avoid this, there is extra sets of “c_tables” configured with entries in the stats_table_usage_list.
  • Table 1 depicts an example pending_stats_list table which comprises a directory of what the stats_counter is working on, or finished with. Each record represents a name of a c_table that contains statistics, and dates that are contained in this c_table. The report generator process, and on-line access use this table to determine if there is any data in the c_tables that they may be interested in, and what the table name is. The Stats_counter processes insert records into this table, and data_mover processes 573, shown in FIG. 10, remove entries from this table.
    TABLE 1
    pending_stats_list table description
    Column Type Usage
    data_month_day Integer date in form YYYYMMDD e.g. 19960822
    table_type Character type of statistics data “SUMMARY”
    (16) “TERMINATION” “NPA” or
    “COUNTRY”
    usage_flag Tinyint 1 - table in use by stats_counter
    2 - table contains data ready for access
    table_name Character exact name of table in use e.g.
    (16) “C_NPA_03”
  • Table 2 depicts an example stats_table_usage_list table which comprises a list of all the c_tables that are configured and used by the stats_counter processes and data_mover processes to allocate tables amongst themselves. The number of records in this table remains static. Stats_counter processes 570 update the “used_by_process” field with their process name when they are in control of that table. At the top of the hour, they may change the used_by_process to “MOVER”, and attempt to find another table that is unallocated. The movers change the used_by_process name to “NONE” when they have completed moving data from that c_table.
    TABLE 2
    stats_table_usage_list table description
    Column Type Usage
    table_type character type of statistics data “SUMMARY”
    (16) “TERMINATION” “NPA” or
    “COUNTRY”
    table_name character exact name of table in use e.g.
    (16) “C_NPA_03”
    used_by_process character process name of the stats_counter or
    (16) “MOVER” to indicate what processes
    are currently using this table. “NONE”
    if this table is unused.
  • In the preferred embodiment, there are four types of movers are currently configured to run: NPA, summary, country, and termination. Each type of mover looks in the pending_stats_list for the name of the “c_table” of the same type with a usage_flag of “21”, for instance, and the earliest date. The mover then transfers the data for this date from the “c_table” to appropriate the permanent table. When the data transfer is finished, the matching record in pending_stats_list is deleted. If there are no more entries for this “c_table” in pending_stats_list, the mover process takes the precautionary step of searching the “c_table” for additional data that was not noted in pending_stats_list. Entries are then added to pending_stats_list for any data found in the “c_table”. If no additional data is found, used_by_process in stats_table_usage_list is changed from “MOVER” to “NONE” for this “c_table”.
  • The interaction between StarWRS web-based reporting system and TVS system 550 will now be explained in greater detail with respect to FIG. 11. In the preferred embodiment, reports may be triggered by two possible sources: Scheduled report setup by a CORE order; and, real time report requests as forwarded from the report request/Report Manager Server 250. The report generation process is hereinafter described with respect to real-time reports from the StarWRS system.
  • As mentioned, requests are received in real-time from the Report Manager Server 250 which either passes on-demand reports from an end-user, or reports that it has internally scheduled via Report scheduler server 260. In the TVS server 550, a report manager proxy process 250″ gathers information about the reports to be generated from the reference database 551 by determining whether the report request may be fulfilled by statistics processing, or the CDR's. If CDR's are needed, a determination is then made as to which database contains the necessary data. Additionally determined is whether the needed CDR data to fulfill the request spans a long period of time, e.g., several days. Once these determinations are made, the requests are sent from the report manager proxy process 250″ to the appropriate DMQ queue 554 a, 554 b, . . . , 554 n, or 553 b where they are queued up for report generation.
  • For the scenario requiring generation of call detail data reports, i.e., those requiring Call detail records, the destination of the report, e.g., StarWRS Inbox server 270, fax, U.S. mail, etc., is determined from the reference database 551. Then, the requested data is gathered based on the metadata request, analyzed, and formatted by various corresponding detail report generator processes indicated in FIG. 11 as processes 559 a, . . . , 559 n. Although not shown in FIG. 11, it should be understood that reference data that originates from CADB and COMS may be necessary to complete these reports. Furthermore, although not shown, the TVS server is provided with an additional set of queues and report generator processes for each of the CDR processing to allow longer reports to not interfere with shorter reports.
  • In the detail report generator processes, the data is formatted in a comma separated value (CSV) format and are input to a finished report files database 582 whereupon, an inbox server interface process 583 FTPs the report to the nMCI Interact Inbox Server 270. The Inbox interface will particularly input the completed report to the pre-defined directory in the Inbox database. Particularly, the Inbox is notified via TCP/IP that the report is complete by the Inbox Interface process and that the appropriate metadata is available for report presentation via the report viewer.
  • If the requested report is destined for MCI Mail delivery (Fax, Mail, US Mail): then the data is formatted with headers, page breaks, line numbers into a report that is saved to a file. The report is then sent to an Internet Gateway 279, e.g., the MCI Mail Internet Gateway directly from the detail report generators 559 a, . . . , 559 n for delivery by MCI Mail. Once the file is successfully sent it is deleted, thus allowing for report generation to continue when the MCI Mail Internet Gateway is not available.
  • An identical process is implemented for those customer report requests for aggregate data, i.e., statistics. However, the data that is gathered and analyzed is retrieved from a summary report generator process 581 which retrieves the requested report data from the statistics database 571 upon a receipt of a report request from the DMQ 553 b.
  • As described herein, when the user requests call detail for a particular period of time, this request is translated by the StarWRS component into a metadata file which is sent to TVS in the manner described herein. Users schedule reports for execution using the Report Scheduler in StarWRS in the manner as described in co-pending U.S. patent application Ser. No. ______ (D#11050). When the user has completed report selection, modifications and scheduling, the StarWRS Report Scheduler component 260 creates a metadata message comprising this information which file is passed to TVS in real time. The TVS then uses this file to formulate a query and runs the report for the scheduled time period.
  • After TVS runs the report, TVS sends the report to the Inbox server component 270 of StarWRS immediately after they are completed.
  • An overview of the report request/scheduling process 600 implemented by StarWRS web-based reporting component 200 will now be described herein in view of FIGS. 12(a)-12(d) as follows:
  • As shown in the process flow diagram of FIG. 12(a), a user first establishes communication with the DMZ Web server at step 602 and logs on to the nMCI Interact system by entering the user's name and password onto a logon dialog box, as indicated at step 604. Then, at steps 606-608, an application running on the backplane directs a “Validate User Message” common object to the StarOE server 280 via the web server and dispatcher servers (FIG. 2) to direct the StarOE server 280 to perform security validation and authenticate the user ID and password in the manner as described in commonly owned, co-pending U.S. patent application Ser. No. ______ (D#11043), entitled AUTHENTICATION AND ENTITLEMENT OF WEB BASED DATA MANAGEMENT PROGRAMS, the contents and disclosure of which is incorporated by reference herein. It is understood that all communication to the StarOE server is via TCP/IP with a Unix process listening on a known TCP port. The StarOE server acts as a proxy when messages are sent from the Dispatcher server 26 and supports synchronous transactions. All data and security information is accessed by direct queries to a StarOE server database 283, such as provided by Informix. Once a user is logged on, the Web Server 24 (FIGS. 2 and 6) requests a current list of authorized applications from the StarOE server 285 as indicated at steps 608 and 610. Particularly, as described in co-pending U.S. patent application Ser. No. ______ (D#11042), the contents and disclosure of which is incorporated by reference herein, a “Get User Application Request” message is communicated to the StarOE server via the backplane from the report requestor which queries the Informix database to obtain a list of authorized applications, i.e., services, for the user and which determines which buttons on the home page are active, thus controlling their access to products. This information is downloaded by a GUI applet that is executed via the Backplane (FIG. 3) and incorporated into the home page that is presented to the user as indicated at steps 612-614. An exemplary home page screen display 80 is shown in FIG. 4 which provides a list of icons 70 representing the possible options available to the user according to that customer's entitlements.
  • Appendix H of co-pending U.S. patent application Ser. No. ______ (D#11050) provides the format and content of the nMCI Interact common objects downloaded to the Report Requestor client application to enable web-based reporting. As shown in above-referenced Appendix H, the Report Requestor first asks for common objects for a user's default timezone, language and currency. The Report Requestor objects are invoked to retrieve from StarOE the various customer entitlements relating to security, geographical hierarchy, billing hierarchy, and paging and e-mail notification, as further shown in Appendix H.
  • As further shown in FIG. 12(a), the steps 615 and 616 indicate the selection and presentation of the Report Requestor display which presents the reporting options to a user in accordance with that user's entitlements as determined at previous step 610. It should be understood that in the preferred embodiment, the icons for applications the user has security access to are shown bolded. Thus, for a customer subscribing to nMCI Interact Unpriced Reporting, an Unpriced Reporting icon is automatically enabled when the home page appears.
  • At step 614, upon selection of a Report Requestor icon 76 from the home page screen display 80 of FIG. 4, a StarWRS report requester web page is presented to the customer. The backplane object allows the user access to the Report Requestor front end if the user is so authorized. As shown at step 615, a client unpriced reporting application is downloaded to the customer who is presented with the unpriced reporting dialog screen (not shown). It is from this screen that the user is presented with unpriced reporting options to view/retrieve completed reports via the StarWRS Inbox, as indicated at step 620 (FIG. 12(b)), or create a new report or, modify an existing unpriced call detail data report.
  • Particularly, from this dialog screen, the user is enabled to edit an existing report maintained in the report manager inventory, generate a new report, copy an existing report, or delete an existing report. When creating a new report or editing an existing report, the user may enter the desired reporting options including: 1) the report product including toll-free, MCI Vision, and MCI Vnet options; 2) the report category which includes options for: analyzing traffic, call center, call detail, checking calling frequencies, financial, marketing, monitoring usage, and telecommunications categories for toll-free, Vnet and Vision customers; 3) the report type which includes unpriced call detail data or traffic data options; and 4) a report direction and which includes inbound, outbound, or both directions. Referring to the flow chart of FIG. 12(b), user selection of the report product, report category, report type, and report direction, is indicated at step 620. Additionally, at step 625, the user may select the report format associated with a reporting category.
  • In accordance with the user report selections, if a report had already been created and maintained in the report manager inventory (database), it will be displayed in a report inventory field. Referring back to FIG. 12(b), at step 626, a determination is made as to whether an existing report from inventory is selected. If an existing report is not selected then the user is prompted to generate a new report according to customization options that the user is entitled for the selected report product, category, type, etc., as indicated at step 630. If an existing report is selected at step 626 based on the report product, category, type, etc., then the user is prompted at step 628 to select from among the following options: a report edit option, as shown at step 635; a report delete option, in which case the selected report will be deleted at steps 638 and 639; and, a report copy option, in which case an existing report will be copied, e.g., for subsequent editing, as shown at steps 640 and 641.
  • Whether creating a new report or editing an existing report, the user is enabled to select customization options as indicated at step 630, FIG. 7(b) from a new dialog screen that is presented to the user showing all the report customization categories for building a new report and/or editing an existing report. From this screen and related report building dialog boxes, all of the initial values for retrieving the MetaData, customization options and GUI builder options from the report manager server 250 necessary to build (edit) a report are provided in accordance with the user's entitlements. As described in greater detail in co-pending U.S. patent application Ser. No. ______ (D#11050), a user may provide the following customization and report builder options: general customization options; layout customization options; access customization options; hierarchy customization options; geographic customization options; and, notification customization options.
  • As mentioned above with respect to FIG. 6, the Report Requestor client application 212 gains access to the Metadata stored at the Report Manager server 250 through messaging. Particularly, as hereinafter described, a message generated by the Report Requestor in accordance with the user request is first received by the report manager proxy 250′. In the preferred embodiment, the report manager proxy comprises a set of tools in the form of reusable objects, preferably written in C++ code, or the like. For example, a parser object tool is employed to decompose the Metadata messages sent by the report requester 212 to validate the message. If errors are found in the Metadata input, the RM will return an error message to the requesting client. If the Metadata passes the validation tests, the request type is then determined and the appropriate service will be invoked after which a standard response is sent back to the requesting client.
  • The Report Manager 250 implements stored procedures to translate the message, perform the request, and send the information back to the Report Requestor 212 which uses the metadata to determine what a standard report should look like, the customization options the user has, and the types of screens that should be used for the various options (i.e., single selection, multiple selections, etc.). It is understood that the selection of available standard template reports is based on the user's entitlements.
  • The following list provides the types of requests that may be initiated by the Report Requestor 212 and the responses performed by the Report Manager 250: 1) Get/Send report template list (GRTL/SRTL)—which request retrieves the list of all standard report templates for all products and is used only to obtain general report information, e.g., report title, description, etc.; 2) Get/Send report template detail (GRTD/SRTD)—which request retrieves the details of a specific standard report template; 3) Get/Send user report list (GURL/SURL)—which request retrieves the list of all user reports for the report format selected from a user report table and is used only as a request for general report information, e.g., report title, status, etc.; 4) Get/Send user report detail (GURD/SURD)—which request retrieves the details of a specific user's report; 5) Add report definition/Acknowledgment (ARD/ARDA)—which requests addition of a user-created report to a user report table. If the report is a scheduled report, this request is also communicated to the fulfilling server at the time the report is due; 6) Delete report definition/Acknowledgment (DRD/DRDA)—which request deletes a user-created report from the user table; 7) Copy report definition/Acknowledgment (CRD/CRDA)—which request creates a duplication of the report the user is editing (other than the report title) and creates a new report ID for it; 8) Update Reporting Schedule/Acknowledgment (URS/URSA)—which request updates the scheduling information on a report without having to send a Delete and Add request; and, 9) Get Pick List/Acknowledgment (GPL/GPLA)—which request enables the Report Requestor 212 to get a pick list provided by StarOE server.
  • In a preferred embodiment, as shown in Table 3, the interface message sent to the RM server 250 from the report requestor via the Dispatcher server 24 comprises a three to four character message acronym followed by request specific parameters.
    TABLE 3
    Parameter Parameter Acceptable
    Name Type Required Value
    Request
    3 or 4 Yes Msg acronym
    Characters
    Data Characters No
    parms . . .
  • Table 4 illustrates the interface message format returned by the RM server 250.
    TABLE 4
    Parameter Parameter Acceptable
    Name Type Required Value
    Response Char (4) Yes Msg acronym
    Error Code Char (4) Yes 0 = OK or
    error
    Data Char # No
    parms . . .
  • As shown in Table 4, the response message to be returned in Metadata format preferably includes a four character message acronym followed by an error code. A successful request (or a request acknowledgment) generates a response with an error code of “0”. Additional data specific to the response follows this error code. If any server receives a message which is not known, the response message will echo the message acronym back along with an appropriate error code.
  • Appendix A provides a series of tables containing the content for each metadata message request that can be sent by the report requestor 212 for each of the enumerated user requests, in addition to the content of the corresponding metadata message responses by the RM server 250. As an example, when a user requests a list of all standard report templates that can be created for a specified product, category, and product type, e.g., toll free unpriced data, an example metadata format is as follows:
      • GRTL<PRODUCT=V,DATATYPE=D,DATACAT=U,IO=O>
        where GRTL is the message name, the PRODUCT indicates the product type, e.g., V=Vnet, C=CVNS, S=Vision, T=toll free, F=Traffic view, etc. DATATYPE indicates the data type, e.g. R=reports, D=call detail, etc., and DATACAT represents the report category, e.g., P=priced, U=unpriced.
  • In the hereinafter described manner, the GRTL message is received by the StarWRS proxy server application 250′ to enable the RM server 250 to perform the query into the RM Informix database having the data associated with the request. Specifically, after selecting the Report Requester from the browser or the Toolbar, a WRSApp object is launched. At its creation, the WRSApp object creates a DataManager object to guide the data and which initiates a CommunicationManager object to manage all communication between the client and the server. The CommunicationManager utilizes a RptManagerMsg object to create: 1) a GRTL; 2) a WRSCommWrapper for direct communication with the backend; and, 3) a WRSReportManagerUtilParser to format the data returned. In response, the Report Manager creates a Dispatcher object, which contains the business logic for handling metadata messages at the back-end and utilizes the services of a RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. Upon receiving the message, the Report Manager creates the Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • In response to the GRTL message, the data returned by the Report Manager server 250 for this particular request may include the following data in metadata format as follows:
    SRTL<ERROR=0, REPORTS = <RptCategoryDescription1
    =<RptTitle1.1, RptTemplateID1.1, RptCategoryType1.1>,
    <RptTitle1.2, RptTemplateID1.2, RptCategoryType1.2>>,
    <RptCategoryDescription2 =<RptTitle2.1,
    RptTemplateID2.1, RptCategoryType2.1>, <RptTitle2.2,
    RptTemplateID2.2, RptCategoryType2.2>>, ...
    <RptCategoryDescription#n=<RptTitle#n.n,
    RptTemplateID#n.n, RptCategoryType#n.n>, <RptTitle#n.n,
    RptTemplateID#n.n, RptCategoryType#n.n>>>

    wherein RptID# indicates a standard report template ID, RptTitle# indicates the standard report template title, RptCategory# indicates the report category, e.g. Monitor Usage, Analysis Traffic, Historical, Executive Summary, Call Detail, etc.; and, RptDescript indicates the standard report template description displayed to the user. Thus, for each Report Template Category, there will be the list of reports with each entry containing a Report Template Title, a Report Template Description and the Report Template ID.
  • The SRTL message is sent from the StarWRS RM proxy server to the report requestor for presentation to the customer. Specifically, the SRTL response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Report Manager Informix database. The Report Manager creates the RMServerSocket object and sends the SRTL message back to the client.
  • To retrieve details of the standard report template, the GRTD request message request is sent having content shown in the table in Appendix A. When specified, the Report ID field indicates an existing report that a user may wish to edit.
  • The SRTD response generated by the RM server is formatted in metadata as follows:
    < Report Template ID=ID#,
    NODE1=<node level1, label value1, assigned unique screen
    identification1, >,
    NODE2=<node level2, label value2, assigned unique screen
    identification2, <control ID2.1, field value2.1, data
    location2.1>, <control ID2.2, field value2.2, data
    location2.2>, <..,..,..>>,
    NODE#n=<node level#n, label value#n, assigned unique
    screen identification#n, <control ID#n.1, field
    value#n.1, data location#n.1>, <control ID#n.2, field
    value#n.2, data location#n.2>>
  • In the SRTD message, the MetaTreeData Label fields include such values as General, Report Name, Report Description, Scheduled Execution, etc. The MetaCtrlInfo MetaField Value fields may be blank or may contain the selection options available to the user. This information is taken from the report template database.
  • As another example, when a report request is submitted to retrieve a full list of user created reports from a user report table, i.e., a template list for a particular report product, category, and type, the example metadata format is as follows:
    GURL<USERID=jeanvnet2,RPTTMPID=1,ENTPID=00022924,
    PRODUCT=T,DATACAT=U>

    with UserID and ReportTemplateID fields specified. Specifically, this process entails invoking the Communication Manager object to communicate with the RM server in order to obtain a SURL metadata message. The CommunicationManager utilizes the RptManagerMsg object to create: 1) a GURL, 2) a WRSCommWrapper for direct communication with the backend, and, 3) a WRSReportManagerUtilParser to format the data returned. The parser returns a hash table containing the User Report List. At the RM server, the Report Manager creates an Dispatcher object that contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. The Report Manager, upon receiving a message, creates a Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • In response to the GURL request, the data returned is taken from a user report table in the RM server database. The generic SURL message in Metadata format returned by the RM server 250 includes the following information:
    REPORTS = <UserRptCategory1 = <UserRptTitle1,
    UserRptID1, activeflag, report type, statusdate >>,
    <UserRptCategory2 = <UserRptTitle2, UserRptID2,
    activeflag, report type, statusdate>>,...
    <UserRptCategory#n = <UserRptTitle#n, UserRptID#n,
    activeflag, report type, statusdate>>>

    wherein for each user report category, there is a list of reports where each entry contains a UserRptID# indicating a user-defined report template ID, a UserRptTitle# indicating the user's report template title, and a UserRptCategory# indicating the user report category. Specifically, the SURL response is built inside an esql wrapper function after obtaining the necessary information through a stored procedure from the Informix database. The Report Manager creates the RMServerSocket object and sends the SURL message back to the client.
  • To retrieve the details of a specific user's report, the GURD message is sent having data as contained in the table shown in Appendix A. Specifically, when the user selects a report from the Inventory List on the Report Requestor, a Communication Manager object is invoked to communicate with the RM server in order to obtain a SURD metadata message. The CommunicationManager object first utilizes the RptManagerMsg object to create: 1) a GURD metadata message, 2) a WRSCommWrapper for direct communication with the backend, and 3) the RSReportManagerUtilParser to format the data returned. The parser organizes the data into a series of nodes which are utilized to create the report builder tree on the report requestor customization screen. Later this data will be extracted from the node and used to construct the screen related to the node. The Report Manager server creates the MCIDispatcher object which contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. The Report Manager, upon receiving a message, creates the Parser object (RMParser) which takes the message apart, invokes a validation object which validates the message and builds a response inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database. The Report Manager creates the RMServerSocket object and sends the SURD/SRTD message back to the client. The responsive SURD metadata message corresponding to a retrieve user report detail (GURD) request has the following metadata syntax:
    < Report Template ID=ID#,
    NODE1=<node level1, label value1, assigned unique screen
    identification1, >,
    NODE2=<node level2, label value2, assigned unique screen
    identification2, <control ID2.1, field value2.1, data
    location2.1>, <control ID2.2, field value2.2, data
    location2.2>, <..,..,..>>,
    NODE#n=<node level#n, label value#n, assigned unique
    screen identification#n, <control ID#n.1, field
    value#n.1, data location#n.1>, <control ID#n.2, field
    value#n.2, data location#n.2>, <..,..,..>>,

    This response thus may include the report information having detailed items including: UserReportID (UserID), User's report name (UserName), product (UserProd), Threshold (UserThreshold), User Report Description (UserDescript), Report Columns (UserFields), Report column headings (UserHeaders), and, in addition, customization options with fields indicating, inter alia, columns to display (UserHeaders), user-defined criteria (UserCriteria), a sort order (UserOrder) and scheduling selections (UserSched), the last update of this report (UserLastUpdate) and, the Report status (if adhoc) (UserStatus), etc.
  • If a request is made to add a user-created report to a User_report table maintained by the RM Server 250, the ARD metadata message having fields defined in the table provided in Appendix A is processed by the RM server 250. An example message in metadata format to initiate the addition of a user-created report for TVS Inbound data is as follows:
    ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=75,NAME=
    Payphone Summary TVS Inbound,PRODUCT=T,CATEGORY=Standard
    Report,THRESHOLD=<>,SCHEDULE=A<START=199808010000,
    END=199808111200>,RANGETYPE=1,SCHEDTYPE=A,
    TIMEZONE=45,NDIALED=<8886520001˜8886520002>,
    DESCRIPTION=Summarizes Payphone
    Calls by Toll Free Number,ACTIVE=1,
    MMADDR=jean.jerzak@mci.com,MMTEXT= Message is
    in,PGT=a,PGPIN=0000000,PGTXT=654654654, EMAIL=1,PAGE=1,
    LANG=1234, CURR=2345>
  • An example message in metadata format to initiate the addition of a user-created report for TVS Outbound data is as follows:
    ARD<USERID=jeanvnet2,ENTPID=00022924,STDRPTID=76,
    NAME=Outbound Traffic CallDetail,PRODUCT=V,
    CATEGORY=Call Detail,THRESHOLD=<>, SCHEDULE=D<>,
    SCHEDTYPE=R,TIMEZONE=45,BILLING=NODE<<22924,PRS UAT
    MASTER>>NODE<<22926,PRS FUTURE RELEASE C HQ>>NODE
    <<22927,PRS FUTURE RELEASE A HQ>>NODE<<22928,5/92
    RELEASE HQ>> NODE<<22929,PRS FUTURE RELEASE B
    HQ>>NODE<<22940,PRS FUTURE RELEASE DHQ>>NODE<<25702,
    91000012CNA NAME>>,OACCESS=<2˜13>, DESCRIPTION=
    Outbound traffic call detail.,
    COLUMNS=<44˜67˜62˜36˜61˜58˜63˜64˜66˜65>,ACTIVE=1,
    PGT=b,PGPIN=3342423,PGTXT=Your report is ready!,EMAIL=0,
    PAGE=1, LANG=1234,CURR=2345>

    In these examples, the “NAME” field refers to the Report Name (e.g., city summary); the “PRODUCT” field refers to the report product (Vision); the “THRESHOLD” field refers to the record count; the “DESCRIPTION” field refers to the report description; the “COLUMNS” refers to the number of columns specified for a report by the user; the “BILLING” field refers to the specified report billing entitlement, i.e., billing hierarchy; the “IACCESS” field refers to the inbound access type and the “OACCESS” refers to the outbound access; the “SORTBY” field indicates the report column sorting customization with “A” indicating column(s) having data to be sorted in ascending order and, “D” indicating column(s) having data to be sorted in descending order; the “SCHEDULE” field referring to the scheduling type, e.g., with “A” indicating an ad-hoc report, and the user specified date range on which to report as indicated by the “START” and “END” fields, and additionally, the scheduling frequency information in the case of a recurring report; the SUBTOTALCOLUMNS field, referring to the report columns having data to be subtotaled; and, the “EMAIL” and “PAGE” fields indicating reporting notification via e-mail or paging, respectively.
  • Furthermore, for each of the metadata messages in Appendix A, including the Delete Report Definition (DRD), copy report definition (CRD), and update report scheduling (URS) messages, the report manager server 250 responds to the Report Requestor with the processing results. In the case of a copy report, a new User Report ID is assigned and returned by RM. When editing an existing report, e.g., a TVS (traffic) or StarODS (priced call data) report, the user may make changes to the Report Title, the Report Description, the Report-scheduling, the 800 numbers and thresholds. For StarODS priced call data reports, customers may provide additional customization options including: number of rows, report columns, access codes, access types, billing location, geographic location, paging notification, and e-mail notification. More specifically, when the user selects a report from the inventory list or a new report, an WRSEdit Screen is launched to provide the editing capabilities which are available for the report format. WRSedit guides the screens through the process of retrieving the screens' data. Some of the screens need data which has not yet been retrieved, such as 800 numbers or geographic locations. These screens manage the requests to the DataManager object to create the get pick list (GPL) message (Appendix A), which launches the CommunicationManager object to perform this task. The CommunicationManager utilizes the RptManagerMsg object to create the GPL, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to format the data returned. In response, the Report Manager server creates the MCIDispatcher object and invokes the MCIRMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. The Report Manager, upon receiving a message, creates the Parser object (RMParser) which takes the message apart and a validation object is invoked which validates the message. The response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database. The Report Manager creates the RMServerSocket object and sends the GPLA message back to the client.
  • Having described the functionality of selecting and/or generating a report and customizing it, reference is now had to FIG. 12(c) which describes the next step 650 of presenting the user with report run and save options. Particularly, in the preferred embodiment, the user may select a save and exit report option, or a save and run report option. In either scenario, an WRSEdit object enables a WRSScnMgr object to save the report to the RM server. The WRSScnMgr object launches each screens save method which communicates with the DataManager object to place the screens data in its corresponding WRSNode. Once all of the WRSNode objects have been updated, the WRSScnMgr object calls the DataManager object's SaveReport method to build a hash table to contain all of the report's data. The CommunicationManager utilizes the RptManagerMsg object to create the ARD metadata message from the hash table, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to handle any errors thrown by the server. The Report Manager creates the Dispatcher object, and utilizes the services of the RMParser class and validation objects. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. The response is built 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 is submitted the selected report type and reporting criteria are sent to the Report Manager.
  • As illustrated in FIG. 12(c), at step 655, in reference to user selection of a Save and Run report option, the report is marked as scheduled and saved in a user_table in the Report Scheduler server 260 via the report Manager. Subsequently, as indicated at step 660, the Report Scheduler server 260 sends the ARD message to the fulfilling server which queues the report and runs the report at the specified time(s), as indicated at step 665, and as described herein with reference to FIG. 11.
  • Generally, whether the report is to be currently run for immediate ad hoc reporting, or, is scheduled for normal scheduled reporting, the following sequence of operations, as indicated at steps 670-695, FIGS. 12(c)-21(d), are performed: First, in response to receipt of the ARD message, e.g., submitted to the fulfilling server by the Report Scheduler, the fulfilling server completes the report and compresses the report/data, as indicated at step 670. Then, the report/data is “pushed”, implementing FTP, to the fulfilling server's directory on the Inbox server 270, as indicated at step 673. The TVS server 550, is responsible for generating unique file names within their directory on the Inbox server 270. For example, the following directory and file naming conventions used for reports generated by the TrafficView server are labeled inbox\files\TVs with text files having the suffix *.txt or *.txt_zip (compressed), and comma separated files having a suffix *.csv or *.csv_zip (compressed). The fulfilling server then verifies that the FTP process was successful, as indicated at step 676, and, at step 679, a notification is sent by the fulfilling server to the Report Manager to notify the Report Manager server 250 of the location of a scheduled report. This is accomplished by using a “NRL” metadata message.
  • Appendix B provides a table comprising the Notify Report Location parameters used for the NRL Metadata messaging sent by a fulfilling server to the RM Server 250 when a requested report is complete. An example NRL message sent from the TVS server 500 to the RM server 250 is as follows:
    NRL<TYPE=traffic, ENTPID=00022924, USERID=jeanvnet2,
    STDRPTID=25,USERRPTID=699, REQUESTID=32185, COMPRESS=0,
    LOC=/inbox/files/TVS/902507996STDRPTID25.CSV,
    FSIZE=198369,REPORT TITLE=Simulated Report Title,
    PRESORTED=1, CATEGORY=R>
  • Also provided in Appendix B is the acknowledgment table sent back to the fulfilling server in response.
  • In the preferred embodiment, the NRL message received by the RM server 250 includes parameters verifying whether or not the FTP process was successful. If it was successful, then the fulfilling server messages the Inbox that the file has been transmitted successfully by transmitting the report name (filename) and location. When the fulfilling server encounters a problem executing a report, a notification is sent to the Report Manager. Particularly, an error flag is placed in the status field of the User_report by the Report Manager which is displayed to the user during Report Request. The error message description will be placed in a text file and FTP'd to the fulfilling server's report location on the Inbox server (e.g., \inbox\files\TVs) by the fulfilling server.
  • Referring to FIG. 12(d), step 679, once the RM server 250 has received the NRL message from the fulfilling server, it verifies the file's presence, as indicated at step 682. The RM server 250 then builds a metadata file, e.g., by compressing the appropriate metadata (for displaying the report) into a .MTD file, as indicated at step 685. This .MTD file is utilized by the Report Viewer to know how to display the report. The Report Manager server creates a file including the metadata using the same file name as the report/data file, but having the following suffix: *.mtd or *.mtd_zip indicating a metadata or compressed metadata file, respectively.
  • Appendix F details the parameters that are passed in the GET METADATA messaging for indicating to the Report Viewer how to display a requested report. For example, a GET METADATA message corresponding to an unpriced TVS fulfilling server report is as follows:
    <METADATA=<CRITERIA=<Name=UsageSummary292{circumflex over ( )}ADescription=
    This report summarizes calls based on call type.{circumflex over ( )}A
    Report_Level=<INBOUND<<90000001,90000001><NA,NA><NA,NA>>
    INBOUND<<90000002,90000002><,><,>>>{circumflex over ( )}AOptions={circumflex over ( )}AScheduling
    _Information={circumflex over ( )}AOne_Time={circumflex over ( )}ADates=<06/01/199800:00/˜07/01/199800:
    :00,>{circumflex over ( )}ATimezone=EST,Lang=1234,Curr=2345>DEFAULT_GRAPH
    _MODE=0{circumflex over ( )}ADEFAULT_GRAPH_TYPE=0{circumflex over ( )}ADEFINE_X_AXIS=0
    {circumflex over ( )}AX_AXIS_COLUMN= {circumflex over ( )}ADEFAUL T_Y_COLUMNS=<>{circumflex over ( )}A
    COLUMN_DISPLAY_ORDER=<105{circumflex over ( )}A114{circumflex over ( )}A67{circumflex over ( )}A62{circumflex over ( )}A36{circumflex over ( )}A61{circumflex over ( )}A58{circumflex over ( )}A63{circumflex over ( )}A64
    {circumflex over ( )}A66{circumflex over ( )}A65>{circumflex over ( )}ASORT_ALLOWED=1{circumflex over ( )}APRESORTED=0{circumflex over ( )}A
    PRESUBTOTALED=1{circumflex over ( )}ATOTALMODE=0{circumflex over ( )}ASORT_COLUMN S=<105A>{circumflex over ( )}A
    SUBTOTAL_COLUMNS=<>{circumflex over ( )}ASELECTED_SECTION=0{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=105{circumflex over ( )}A
    COLUMN_LABEL=Usage Description{circumflex over ( )}ADATATYPE=S{circumflex over ( )}ADECIMAL=0{circumflex over ( )}A
    HIDEABLE=1{circumflex over ( )}AGRAPHABLE=0{circumflex over ( )}AWIDTH=20{circumflex over ( )}ACALCULATE=0{circumflex over ( )}A
    CALCULATE_EXPRESSION=>{circumflex over ( )}AMETACOLUMN=<META_COLUMN_ID=114{circumflex over ( )}A
    COLUMN_LABEL=Range/DistanceDescription{circumflex over ( )}ADATATYPE=S{circumflex over ( )}ADECIMAL
    =0{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=0{circumflex over ( )}AWIDTH=20{circumflex over ( )}ACALCULATE=0{circumflex over ( )}A
    CALCULATE_EXPRESSION=>{circumflex over ( )}AMETACOLUMN=<META_COLUMN_ID=67{circumflex over ( )}A
    COLUMN_LABEL=Calls{circumflex over ( )}ADATATYPE=I{circumflex over ( )}ADECIMAL=0{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}A
    GRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>
    {circumflex over ( )}AMETACOLUMN=<META_COLUMN_ID=62{circumflex over ( )}ACOLUMN_LABEL=% Calls{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over ( )}A
    CALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=36{circumflex over ( )}ACOLUMN_LABEL=Minutes{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=8{circumflex over ( )}A
    CALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=61{circumflex over ( )}ACOLUMN_LABEL=% Min{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}A
    WIDTH=5{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=58{circumflex over ( )}ACOLUMN_LABEL=Amount{circumflex over ( )}ADATATYPE
    =C{circumflex over ( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}A
    GRAPHABLE=1{circumflex over ( )}AWIDTH=7{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>
    {circumflex over ( )}AMETACOLUMN=<META_COLUMN_ID=63{circumflex over ( )}ACOLUMN_LABEL=% Amt{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=1{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=5{circumflex over ( )}A
    CALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=64{circumflex over ( )}ACOLUMN_LABEL=Avg Min/Call
    {circumflex over ( )}ADATATYPE=N{circumflex over ( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}A
    WIDTH=12{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=66{circumflex over ( )}ACOLUMN_LABEL=Avg
    Amt/Call{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}AWIDTH=12
    {circumflex over ( )}A CALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>{circumflex over ( )}A
    METACOLUMN=<META_COLUMN_ID=65{circumflex over ( )}ACOLUMN_LABEL=Avg Amt/Min{circumflex over ( )}A
    DATATYPE=N{circumflex over ( )}ADECIMAL=2{circumflex over ( )}AHIDEABLE=1{circumflex over ( )}AGRAPHABLE=1{circumflex over ( )}A
    WIDTH=11{circumflex over ( )}ACALCULATE=0{circumflex over ( )}ACALCULATE_EXPRESSION=>>>
    *<METADATA= <CRITERIA= <Name=My Report, Total=Totals
    are located at the bottom of the report.,
    Description=My report description,
    Number_Dialed=<800#1, 800#2, 800#n>,
    Scheduling_Information= Recurring, Dates= Monthly>>
    DEFAULT_GRAPH_MODE=1, DEFAULT_GRAPH_TYPE=1,
    DEFINE_X_AXIS=1, X_AXIS_COLUMN=2,
    DEFAULT_Y_COLUMNS=<5,6>,
    COLUMN_DISPLAY_ORDER=<1,2,3,4,5,6>,
    COLUMN_STORED_ORDER=<4,3,2,5,6,1>, SORT_ALLOWED=1,
    PRESORTED = 1, TOTALMODE=3, SUBTOTCOL=<5,6>, SELECTED
    SECTION=1, METACOLUMN=<META_COLUMN_ID=1,
    COLUMN_LABEL=name, DATATYPE=S, DECIMAL=0, HIDEABLE=1,
    GRAPHABLE=0, WIDTH=10, CALCULATE=1,
    CALCULATE_EXPRESSION=<4 / 7>>>>
  • Once the metadata file corresponding to the requested report is build by the Report Manager, the RM ftp's the .MTD file to the Inbox server, as indicated at step 688, FIG. 12(d). The RM server additionally updates the User_report table status field with a status “C” indicating completion, as indicated at step 691.
  • Once the Report Manager has updated the status field, the RM server 250 then adds the report to the user's Inbox, as indicated at step 693.
  • Appendix C provides a table showing the fields for the metadata messaging between the RM server 250 and the Inbox server 270 for adding an item into the StarWRS system Inbox server 270, and the respective acknowledgment message format back from the Inbox server. In the “A” message found in Appendix C, the “LOC” field includes information about where the report data is located. For example, a metadata message indicating to the Inbox server that an unpriced TVS fulfilling server report is available is shown as:
    A<CATEGORY=R,TYPE=traffic,REQUESTID=32197,USERID=
    LynneLevy2,RPTID=150,PRIORITY=,COMPRESS=0,UNOTIFY=
    0,MMADDR=,MMTEXT=,PGT=,PGPIN=,PGTXT=,RPTCATEGORY=
    Service Location & Hour,
    LOC=/inbox/files/testTVS/902512294STDRPTID10.CSV,
    ENTPID=10324488,RQSTDT1998-01-02
    15:18,FSIZE=3705,RPTTITLE=summary by Service
    Location and Hour,MSIZE=3322>

    Particularly, the RM server supplies a metadata “A” message to the Inbox indicating the FTP file location. Via the report viewer, the report is now available for viewing, downloading, saving, or printing by the user, as indicated at step 695, and as described in further detail in co-pending U.S. patent application Ser. No. ______ (D#11041), entitled MULTI-THREADED WEB BASED IN-BOX FOR REPORT MANAGEMENT, the contents and disclosure of which are incorporated by reference as if fully set forth herein. Particularly, as shown in the exemplary nMCI home page in FIG. 4, the nMCI Interact Message Center icon 77 may be selected which will cause the display of a web page including the message center dialog window. From the message center dialog windoe, a user may select from among three tabs, one of which, a reports tab, enables the retrieval of both a data file and a metadata file from the Inbox Server corresponding to those reports that have been run and available for customer viewing. Information provided for display by the message center display 325 is provided by the User_table which keeps track of the status of all reports for a particular user. By double-clicking a chosen report, a report viewer application is enabled to display the chosen report on a web-page.
  • Referring back to FIG. 6, the Report Viewer 215 interfaces with the user's Inbox 210 for presenting to the customer the various type of reports received at the Inbox. It should be understood that all Report Requestor and Report Viewer applications communicate with the RM server 250 through the use of the common object communication classes.
  • Particularly, as shown in FIG. 6, the Inbox server 270 interface with the Inbox Client 210 supports messaging that enables the User to remove an item from the Inbox, e.g., delete a report, or, to delete all items from the Inbox, e.g., for a particular Enterprise and User ID as well as other associated reports.
  • Appendix G illustrates the parameters used in the metadata messaging between the Inbox client and the Inbox server. Particularly, the List “L” message is a synchronous request for a list of all Inbox items for a specific user. The Inbox fetch “F” function is a bulk transfer request that enables bulk transfer of the requested file to the Inbox client.
  • Referring back to FIG. 12(b), after editing or modifying an existing report, the user may simply select to save the report and exit. In this case, the ARD message is sent from the Report Requestor client to the RM server and is saved in the RM inventory database for subsequent execution. Consequently, the report is flagged as incomplete in the User_table and may not be run until a run option for that report is chosen. Otherwise, the report may be immediately scheduled if the user selects the save and run button.
  • As described, Metadata messaging is used throughout the various components of the StarWRS system 200. The format of an interface message that is sent to the Report Scheduler server is identical to the format as shown in Table 3 as is the interface messaging format returned by the RS server 260 in Table 2. Thus, in the case of automatic recurring reports, a variation of the process outlined in FIG. 12(c) occurs at step 660, whereby the ARD request is instead sent from the report scheduler to the fulfilling server at the programmed frequency. Particularly, when a report is required to be run, the Report scheduler server 260 (FIG. 6) sends an ARD request to the fulfilling server in a metadata message format having parameters as included in the Add Report Definition table in Appendix D. Upon processing of the metadata message, the fulfilling server will respond to the report Scheduler with an acknowledgment of the command, and the process outlined in FIGS. 12(c) and 12(d) is executed.
  • As mentioned herein with respect to FIG. 2, the messages created by the client Java software are transmitted to the StarWeb (DMZ) Server 24 over HTTPS. For incoming (client-to-server) communications, the DMZ Web servers 24 decrypt a request, authenticate and verify the session information. The logical message format from the client to the Web server is shown as follows:
    || TCP/IP || encryption || http || web header ||
    dispatcher header || proxy-specific data ||

    where “||” separates a logical protocol level, and protocols are nested from left to right. FIG. 13 illustrates a specific message sent from the client browser to the desired middle tier server for the particular application. As shown in FIG. 13, the client message 340 includes an SSL encryption header 342 and a network-level protocol HTTP/POST header 344 which are decrypted by the DMZ STarWeb Server(s) 24 to access the underlying message; a DMZ Web header 346 which is used to generate a cookie 341 and transaction type identifier 343 for managing the client/server session; a dispatcher header 345 which includes the target proxy identifier 350 associated with the particular type of transaction requested; proxy specific data 355 including the application specific metadata utilized by the target proxy to form the particular messages for the particular middle tier server providing a service; and, the network-level HTTP/POST trailer 360 and encryption trailer 365 which are also decrypted by the DMZ Web server layer 24.
  • After establishing that the request has come from a valid user and mapping the request to its associated session, the request is then forwarded through the firewall 25 over a socket connection 23 to one or more decode/dispatch servers 26 located within the corporate Intranet 30. The messaging sent to the Dispatcher will include the user identifier and session information, the target proxy identifier, and the proxy specific data. The decode/dispatch server 26 authenticates the user's access to the desired middle-tier service.
  • As shown in FIG. 13, the StarWeb server forwards the Dispatcher header and proxy-specific data to the Dispatcher, “enriched” with the identity of the user (and any other session-related information) as provided by the session data/cookie mapping, the target proxy identifier and the proxy-specific data. The dispatch server 26 receives the requests forwarded by the Web server(s) 24 and dispatches them to the appropriate application server proxies. Particularly, as explained above with respect to FIG. 6, the dispatch server 26 receives request messages forwarded by the DMZ Web servers and dispatches them to the appropriate server proxies. The message wrappers are examined, revealing the user and the target middle-tier service for the request.
  • A first-level validation is performed, making sure that the user is entitled to communicate with the desired service. The user's entitlements in this regard are fetched by the dispatch server from Order Entry server 280 at logon time and cached. Assuming that the Requestor is authorized to communicate with the target service, the message is then forwarded to the desired service's proxy, which, in the accordance with the principles described herein, comprises: 1) a report manager proxy 250′ corresponding to the RM Server 250, 2) a report scheduler proxy 260′ corresponding to the RS Server 260, and 3) an inbox server proxy 270′ corresponding to the Inbox Server 270. Each of these proxy processes further performs: a validation process for examining incoming requests and confirming that they include validly formatted messages for the service with acceptable parameters; a translation process for translating a message into an underlying message or networking protocol; and, a management process for managing the communication of the specific customer request with the middle-tier server to actually get the request serviced. Data returned from the middle-tier server is translated back to client format, if necessary, and returned to the dispatch server as a response to the request.
  • FIGS. 14(a) and 14(b) are schematic illustrations showing the message format passed between the Dispatcher 26 and the application specific proxy (FIG. 14(a)) and the message format passed between the application specific proxy back to the Dispatcher 26 (FIG. 14(b)). As shown in FIG. 14(a), all messages between the Dispatcher and the proxies, in both directions, begin with a common header 110 to allow leverage of common code for processing the messages. A first portion of the header includes the protocol version 115 which may comprise a byte of data for identifying version control for the protocol, i.e., the message format itself, and is intended to prevent undesired mismatches in versions of the dispatcher and proxies. The next portion includes the message length 120 which, preferably, is a 32-bit integer providing the total length of the message including all headers. Next is the echo/ping flag portion 122 that is intended to support a connectivity test for the dispatcher-proxy connection. For example, when this flag is non-zero, the proxy immediately replies with an echo of the supplied header. There should be no attempt to connect to processes outside the proxy, e.g. the back-end application services. The next portion indicates the Session key 125 which is the unique session key or “cookie” provided by the Web browser and used to uniquely identify the session at the browser. As described above, since the communications middleware is capable of supporting four types of transport mechanisms, the next portion of the common protocol header indicates the message type/mechanism 130 which may be one of four values indicating one of the following four message mechanisms and types: 1) Synchronous transaction, e.g., a binary 0; 2) Asynchronous request, e.g., a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) bulk transfer, e.g., a binary 3.
  • Additionally, the common protocol header section includes an indication of dispatcher-assigned serial number 135 that is unique across all dispatcher processes and needs to be coordinated across processes (like the Web cookie (see above)), and, further, is used to allow for failover and process migration and enable multiplexing control between the proxies and dispatcher, if desired. A field 140 indicates the status is unused in the request header but is used in the response header to indicate the success or failure of the requested transaction. More complete error data will be included in the specific error message returned. The status field 140 is included to maintain consistency between requests and replies. As shown in FIG. 14(a), the proxy specific messages 375 are the metadata message requests from the report requestor client and can be transmitted via synchronous, asynchronous or bulk transfer mechanisms. Likewise, the proxy specific responses are metadata response messages 380 again, capable of being transmitted via a synch, asynch or bulk transfer transport mechanism.
  • It should be understood that the application server proxies can either reside on the dispatch server 26 itself, or, preferably, can be resident on the middle-tier application server, i.e., the dispatcher front end code can locate proxies resident on other servers.
  • As mentioned, the proxy validation process includes parsing incoming requests, analyzing them, and confirming that they include validly formatted messages for the service with acceptable parameters. If necessary, the message is translated into an underlying message or networking protocol. A list of Report Manager and Inbox proxy error messages can be found in Appendix E. If no errors are found, the proxy then manages the communication with the middle-tier server to actually get the request serviced. The application proxy supports application specific translation and communication with the back-end application server for both the Web Server (java applet originated) messages and application server messages.
  • Particularly, in performing the verification, translation and communication functions, the Report Manager server, the Report Scheduler server and Inbox server proxies each employ front end proxy C++ objects and components. For instance, a utils.c program and a C++ components library, is provided for implementing general functions/objects. Various C++ parser objects are invoked which are part of an object class used as a repository for the RM metadata and parses the string it receives. The class has a build member function which reads the string which includes the data to store. After a message is received, the parser object is created in the RMDispatcher.c object which is a file comprising the business logic for handling metadata messages at the back-end. It uses the services of an RMParser class. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request. Invocation occurs in MCIRMServerSocket.C when an incoming message is received and is determined not to be a talarian message. RMSErverSocket.c is a class implementing the message management feature in the Report Manager server. Public inheritance is from MCIServerSocket in order to create a specific instance of this object. This object is created in the main loop and is called when a message needs to be sent and received; a Socket.c class implementing client type sockets under Unix using, e.g., TCP/IP or TCP/UDP. Socket.C is inherited by ClientSocket.C:: Socket(theSocketType, thePortNum) and ServerSocket.C:: Socket(theSocketType, thePortNum) when ClientSocket or ServerSocket is created. A ServerSocket.c class 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.c class used as a repository for the RM Metadata. The class' “build” member function reads the string which includes the data to store and the class parses the string it receives. After a message has been received, the MCIInboxParser object is created in inboxutl.c which is a file comprising the functions which process the Inbox requests, i.e, Add, Delete, List, Fetch and Update. Additional objects/classes include: Environ.c which provides access to a UNIX environment; Process.c which provides a mechanism to spawn slave processes in the UNIX environment; Daemon.c for enabling a process to become a daemon; Exception.c for exception handling in C++ programs; and, RMlog.c for facilitating RM logging. In addition custom ESQL code for RM/database interface is provided which includes the ESQC C interface (Informix) stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, and GPL messages. The functions call the stored procedures according to the message, and the response is built inside the functions depending on the returned values of the stored procedures. A mainsql.c program provides the ESQL C interface for messages from the report manager and report viewer.
  • Outgoing (server-to-client) communications follow the reverse route, i.e., the proxies feed responses to the decode/dispatch server and communicate them to the DMZ Web servers over the socket connection. The Web servers will forward the information to the client using SSL. The logical message format returned to the client from the middle tier service is shown as follows:
    || TCP/IP || encryption || http || web response ||
    dispatcher response || proxy-specific response ||

    where “||” separates a logical protocol level, and protocols nested from left to right.
  • The foregoing merely illustrates the principles of the present invention. Those skilled in the art will be able to devise various modifications, which although not explicitly described or shown herein, embody the principles of the invention and are thus within its spirit and scope.

Claims (31)

1.-19. (canceled)
20. A reporting system comprising:
a report manager configured to communicate with a browser over a secure session and to maintain a reporting item associated with a customer, the reporting item comprising a report data type or a report customization feature for a report to be generated; and
a data retrieval device configured to retrieve customer specific data from a network of the customer,
wherein the report manager is further configured to receive a request message comprising a metadata description of the reporting item, the metadata description of the reporting item being verified and forwarded to the data retrieval device for retrieval of the customer specific data,
wherein the report manager is further configured to use the customer specific data and the metadata description to dynamically generate the report.
21. A system according to claim 20, wherein the secure session is managed by a secure server, the secure server supporting a secure socket connection enabling encrypted communication with the browser.
22. A system according to claim 20, wherein the report is further determined based on a customization option and a user option.
23. A system according to claim 20, wherein the request message is generated by a requestor application and is verified to ensure valid formatting.
24. A system according to claim 23, wherein the requestor application provides presentation of a report request menu comprising a user selectable reporting option for the report in accordance with a predetermined customer entitlement.
25. A system according to claim 23, wherein the requestor application provides user selection of a specific reporting option for a desired report, and in response to the selection, generates the request message.
26. A system according to claim 20, wherein the data retrieval device is further configured to retrieve call detail information generated from an element of the network.
27. A system according to claim 20, wherein a requestor applet enables customer scheduling of report request metadata descriptions to be communicated from the report manager to the retrieval device.
28. A system according to claim 27, wherein a web server is configured to communicate with the browser and to provide a report requester applet capable of presenting the reporting item to the customer.
29. A system according to claim 20, wherein the customer specific data information relates to usage of the network.
30. A system according to claim 20, wherein the customer specific data information relates to unpriced traffic call detail data.
31. A system according to claim 20, wherein the retrieval device is further configured to generate statistical data based on retrieved customer-specific call detail data.
32. A system according to claim 20, wherein the retrieval device communicates call detail data in real-time to the browser.
33. A system according to claim 20, wherein a workstation is configured to run the browser and to interface a report viewing device for receiving the metadata description of a requested report type and corresponding retrieved customer specific data.
34. A method for providing reporting, the method comprising:
maintaining a reporting item associated with a customer, the reporting item comprising a report data type or a report customization feature for a report to be generated;
retrieving customer specific data from a network of the customer;
receiving a request message comprising a metadata description of the reporting item;
verifying the metadata description of the reporting item for retrieval of the customer specific data;
dynamically generating the report based on the customer specific data and the metadata description; and
communicating with a browser over a secure session to present the report.
35. A method according to claim 34, wherein the secure session is managed by a secure server, the secure server supporting a secure socket connection enabling encrypted communication with the browser.
36. A method according to claim 34, wherein the report is further generated based on a customization option and a user option.
37. A method according to claim 34, wherein the request message is generated by a requestor application and is verified to ensure valid formatting.
38. A method according to claim 37, wherein the requestor application provides presentation of a report request menu comprising a user selectable reporting option for the report in accordance with a predetermined customer entitlement.
39. A method according to claim 37, wherein the requestor application provides user selection of a specific reporting option for a desired report, and in response to the selection, generates the request message.
40. A method according to claim 34, further comprising:
retrieving call detail information generated from an element of the network.
41. A method according to claim 34, wherein a requester applet enables customer scheduling of report request metadata descriptions to be communicated from the report manager to the retrieval device.
42. A method according to claim 41, wherein a web server is configured to communicate with the browser and to provide a report requestor applet capable of presenting the reporting item to the customer.
43. A method according to claim 34, wherein the customer specific data information relates to usage of the network.
44. A method according to claim 34, wherein the customer specific data information relates to unpriced traffic call detail data.
45. A method according to claim 34, further comprising:
generating statistical data based on retrieved customer-specific call detail data.
46. A method according to claim 34, wherein the retrieval device communicates call detail data in real-time to the browser.
47. A method according to claim 34, wherein a workstation is configured to run the browser and to interface a report viewing device for receiving the metadata description of a requested report type and corresponding retrieved customer specific data.
48. A reporting system comprising:
means for maintaining a reporting item associated with a customer, the reporting item comprising a report data type or a report customization feature for a report to be generated;
means for retrieving customer specific data from a network of the customer;
means for receiving a request message comprising a metadata description of the reporting item;
means for verifying the metadata description of the reporting item for retrieval of the customer specific data;
means for dynamically generating the report based on the customer specific data and the metadata description; and
means for communicating with a browser over a secure session to present the report.
49. A system according to claim 48, wherein the metadata description includes a report description object for specifying presentation of the report and data export and reporting printing services.
US11/348,798 1997-09-26 2006-02-07 Integrated proxy interface for web based data management reports Abandoned US20060129499A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/348,798 US20060129499A1 (en) 1997-09-26 2006-02-07 Integrated proxy interface for web based data management reports

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US6065597P 1997-09-26 1997-09-26
US09/159,404 US7058600B1 (en) 1997-09-26 1998-09-24 Integrated proxy interface for web based data management reports
US11/348,798 US20060129499A1 (en) 1997-09-26 2006-02-07 Integrated proxy interface for web based data management reports

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/159,404 Continuation US7058600B1 (en) 1997-09-26 1998-09-24 Integrated proxy interface for web based data management reports

Publications (1)

Publication Number Publication Date
US20060129499A1 true US20060129499A1 (en) 2006-06-15

Family

ID=36569042

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/159,404 Expired - Lifetime US7058600B1 (en) 1997-09-26 1998-09-24 Integrated proxy interface for web based data management reports
US11/348,798 Abandoned US20060129499A1 (en) 1997-09-26 2006-02-07 Integrated proxy interface for web based data management reports

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/159,404 Expired - Lifetime US7058600B1 (en) 1997-09-26 1998-09-24 Integrated proxy interface for web based data management reports

Country Status (1)

Country Link
US (2) US7058600B1 (en)

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101201A1 (en) * 1999-03-23 2003-05-29 Saylor Michael J. System and method for management of an automatic OLAP report broadcast system
US20030194065A1 (en) * 1999-09-13 2003-10-16 Justin Langseth System and method for real-time, personalized, dynamic, interactive voice services for travel availability information
US20030204365A1 (en) * 2002-04-30 2003-10-30 Li-Hua Chen System and method for generating a report on an object
US20030208591A1 (en) * 2002-05-01 2003-11-06 Taylor William Scott System and method for proactive management of a communication network through monitoring a user network interface
US20040236844A1 (en) * 1999-11-15 2004-11-25 Lucent Technologies, Inc. Method and apparatus for remote audiovisual signal recording
US20050190897A1 (en) * 1999-09-13 2005-09-01 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services
US20050267868A1 (en) * 1999-05-28 2005-12-01 Microstrategy, Incorporated System and method for OLAP report generation with spreadsheet report within the network user interface
US20060026122A1 (en) * 2001-06-19 2006-02-02 Microstrategy Incorporated Report system and method using context-sensitive prompt objects
US20060265662A1 (en) * 2005-05-19 2006-11-23 Custom Credit Systems, L.P. System and method for generating and updating user interfaces of web-based applications
WO2008085175A1 (en) * 2007-01-12 2008-07-17 Secureach Systems, Inc. Method and system for communicating information
US20080170673A1 (en) * 2007-01-12 2008-07-17 Secureach Systems, Inc. Method and system for communicating information
US20080175167A1 (en) * 2007-01-24 2008-07-24 Cisco Technology, Inc. Method and system for identifying and reporting over-utilized, under-utilized, and bad quality trunks and gateways in internet protocol telephony networks
US20080215670A1 (en) * 2006-09-06 2008-09-04 Brandt Christian Redd Tracking usage and monitoring users of a distributed learning system
US20090106373A1 (en) * 2007-10-22 2009-04-23 Marcus Schmidt-Karaca Systems and methods to receive information from a groupware client
US20090106371A1 (en) * 2007-10-22 2009-04-23 Markus Schmidt-Karaca Systems and methods to generate business reports based on electronic mail messages
US20100332570A1 (en) * 2009-06-30 2010-12-30 Verizon Patent And Licensing Inc. Methods and systems for automatically customizing an interaction experience of a user with a media content application
US8051369B2 (en) 1999-09-13 2011-11-01 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services, including deployment through personalized broadcasts
US8130918B1 (en) 1999-09-13 2012-03-06 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services, with closed loop transaction processing
US20120084635A1 (en) * 2010-09-30 2012-04-05 Microsoft Corporation Parameterized template compression for binary xml
US8321411B2 (en) 1999-03-23 2012-11-27 Microstrategy, Incorporated System and method for management of an automatic OLAP report broadcast system
US20130007868A1 (en) * 2011-06-30 2013-01-03 Cable Television Laboratories, Inc. Zero sign-on authentication
US20130031485A1 (en) * 2011-07-29 2013-01-31 Pin Zhou Chen Mobile business intelligence dynamic adaptor
US20130167047A1 (en) * 2011-12-21 2013-06-27 Verizon Patent And Licensing Inc. Transaction services reporting system
US20140247936A1 (en) * 2013-03-04 2014-09-04 Avaya Inc. Systems and methods for managing reporting data on a hosted on-demand reporting system
WO2015070032A1 (en) * 2013-11-08 2015-05-14 Teamblind Inc. System and method for authentication
US20150215178A1 (en) * 2014-01-24 2015-07-30 Bank Of America Corporation Server inventory trends
US9208213B2 (en) * 1999-05-28 2015-12-08 Microstrategy, Incorporated System and method for network user interface OLAP report formatting
US20160021131A1 (en) * 2014-07-21 2016-01-21 David Paul Heilig Identifying stealth packets in network communications through use of packet headers
US9374475B1 (en) * 2015-02-09 2016-06-21 Octopus Ventures Inc. System for processing customer records
US9439072B2 (en) 2013-11-08 2016-09-06 Teamblind Inc. System and method for authentication
US20180374047A1 (en) * 2017-06-26 2018-12-27 Oracle Financial Services Software Limited Computing framework for compliance report generation
US10371744B2 (en) * 2012-04-11 2019-08-06 Advantest Corporation Method and apparatus for an efficient framework for testcell development

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2306814A1 (en) * 1997-11-20 1999-06-03 Xacct Technologies, Inc. Network accounting and billing system and method
US6985953B1 (en) * 1998-11-30 2006-01-10 George Mason University System and apparatus for storage and transfer of secure data on web
US8239445B1 (en) * 2000-04-25 2012-08-07 International Business Machines Corporation URL-based sticky routing tokens using a server-side cookie jar
US7266821B2 (en) * 2000-04-27 2007-09-04 Hyperion Solutions Corporation Method and apparatus for processing jobs on an enterprise-wide computer system
US6754825B1 (en) * 2000-06-30 2004-06-22 Palm Source, Inc. Secure authentication and authorization for transaction processing
US8972590B2 (en) 2000-09-14 2015-03-03 Kirsten Aldrich Highly accurate security and filtering software
US6754621B1 (en) * 2000-10-06 2004-06-22 Andrew Cunningham Asynchronous hypertext messaging system and method
CA2354372A1 (en) * 2001-02-23 2002-08-23 Efunds Corporation Electronic payment and authentication system with debit and identification data verification and electronic check capabilities
US8392527B2 (en) * 2001-06-04 2013-03-05 Hewlett-Packard Development Company L.P. System and method for requesting computer resources
CN1208732C (en) * 2002-02-01 2005-06-29 上海贝尔阿尔卡特移动通信系统有限公司 Concurrent event processing method and application system based on Web thereby
US20030149786A1 (en) * 2002-02-06 2003-08-07 Mark Duffy Efficient counter retrieval
US7370075B2 (en) * 2002-04-25 2008-05-06 Digital Evolution Method and apparatus for managing web services within a computer network system
US7421442B2 (en) * 2002-07-02 2008-09-02 American Express Travel Related Services Company, Inc. System and method for data capture and reporting
FR2843640B1 (en) * 2002-08-16 2010-03-19 Systeam PROCESS FOR GENERATING, TRANSMITTING AND PROCESSING DOCUMENTS
CN1230737C (en) * 2002-09-23 2005-12-07 华为技术有限公司 Device data polling dispatching method
US8195714B2 (en) 2002-12-11 2012-06-05 Leaper Technologies, Inc. Context instantiated application protocol
US7925246B2 (en) 2002-12-11 2011-04-12 Leader Technologies, Inc. Radio/telephony interoperability system
US7373408B2 (en) * 2003-02-08 2008-05-13 Hewlett-Packard Development Company, L.P. Network communication apparatus and method
JP4558340B2 (en) * 2003-02-20 2010-10-06 オセ−テクノロジーズ・ベー・ヴエー Print job processing system in a network
US20050033625A1 (en) * 2003-08-06 2005-02-10 International Business Machines Corporation Method, apparatus and program storage device for scheduling the performance of maintenance tasks to maintain a system environment
US20050102500A1 (en) * 2003-11-12 2005-05-12 International Business Machines Corporation System and method for integrating applications in different enterprises separated by firewalls
US8095658B2 (en) * 2004-05-07 2012-01-10 International Business Machines Corporation Method and system for externalizing session management using a reverse proxy server
US7823185B1 (en) 2005-06-08 2010-10-26 Federal Home Loan Mortgage Corporation System and method for edge management of grid environments
US20070067780A1 (en) * 2005-08-24 2007-03-22 Samsung Electronics Co., Ltd. Method and system for asynchronous eventing over the internet
US7877678B2 (en) * 2005-08-29 2011-01-25 Edgar Online, Inc. System and method for rendering of financial data
US8584199B1 (en) 2006-10-17 2013-11-12 A10 Networks, Inc. System and method to apply a packet routing policy to an application session
US8312507B2 (en) 2006-10-17 2012-11-13 A10 Networks, Inc. System and method to apply network traffic policy to an application session
US7636902B1 (en) * 2006-12-15 2009-12-22 Sprint Communications Company L.P. Report validation tool
EP2191446A4 (en) 2007-08-12 2012-06-06 Invoice Clearing System Inc System and method of offsetting invoice obligations
US9756114B2 (en) * 2007-11-23 2017-09-05 International Business Machines Corporation Asynchronous response processing in a web based request-response computing system
US20090150513A1 (en) * 2007-12-10 2009-06-11 At&T Knowledge Ventures, Lp Method and System for Gathering Network Data
US20090234753A1 (en) * 2008-03-17 2009-09-17 Yahoo! Inc. Agent-based customized online shopping
US8306200B2 (en) * 2008-07-17 2012-11-06 At&T Intellectual Property I, L.P. Method and apparatus for processing of a toll free call service alarm
US8363790B2 (en) 2008-07-17 2013-01-29 At&T Intellectual Property I, L.P. Method and apparatus for providing automated processing of a switched voice service alarm
US20110106677A1 (en) * 2008-08-08 2011-05-05 Elbizri Samer System and method of offsetting invoice obligations
US8825854B2 (en) * 2008-11-24 2014-09-02 Sap Ag DMZ framework
CN101997714A (en) * 2009-08-27 2011-03-30 华为技术有限公司 Time processing method, device and system
US9118618B2 (en) 2012-03-29 2015-08-25 A10 Networks, Inc. Hardware-based packet editor
US8863198B2 (en) 2012-08-17 2014-10-14 Flextronics Ap, Llc Television having silos that animate content source searching and selection
US11368760B2 (en) 2012-08-17 2022-06-21 Flextronics Ap, Llc Applications generating statistics for user behavior
US20160119675A1 (en) 2012-09-06 2016-04-28 Flextronics Ap, Llc Programming user behavior reporting
US9338225B2 (en) 2012-12-06 2016-05-10 A10 Networks, Inc. Forwarding policies on a virtual service network
US8954495B2 (en) 2013-01-04 2015-02-10 Netfilx, Inc. Proxy application with dynamic filter updating
US9992107B2 (en) 2013-03-15 2018-06-05 A10 Networks, Inc. Processing data packets using a policy based network path
WO2014179753A2 (en) 2013-05-03 2014-11-06 A10 Networks, Inc. Facilitating secure network traffic by an application delivery controller
US9942152B2 (en) 2014-03-25 2018-04-10 A10 Networks, Inc. Forwarding data packets using a service-based forwarding policy
US9584492B2 (en) * 2014-06-23 2017-02-28 Vmware, Inc. Cryptographic proxy service
US10268467B2 (en) 2014-11-11 2019-04-23 A10 Networks, Inc. Policy-driven management of application traffic for providing services to cloud-based applications
US10516743B1 (en) * 2015-03-24 2019-12-24 Quest Software Inc. Systems and methods for facilitating portable user sessions
US10419415B2 (en) * 2016-11-16 2019-09-17 Bank Of America Corporation Centralized authentication and reporting tool
EP3788485A1 (en) * 2018-05-04 2021-03-10 Citrix Systems, Inc. Systems and methods for an embedded browser
CN113434824A (en) * 2021-06-30 2021-09-24 平安科技(深圳)有限公司 Software service authorization management method, device, equipment and storage medium

Citations (117)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US139178A (en) * 1873-05-20 Improvement in polishing devices
US4727243A (en) * 1984-10-24 1988-02-23 Telenet Communications Corporation Financial transaction system
US4817050A (en) * 1985-11-22 1989-03-28 Kabushiki Kaisha Toshiba Database system
US4823373A (en) * 1986-10-16 1989-04-18 Oki Electric Industry Co., Ltd. Line switching control system for mobile communication
US4893248A (en) * 1987-02-06 1990-01-09 Access Corporation Monitoring and reporting system for remote terminals
US5088052A (en) * 1988-07-15 1992-02-11 Digital Equipment Corporation System for graphically representing and manipulating data stored in databases
US5208908A (en) * 1989-10-12 1993-05-04 International Business Machines Corporation Display system having a font cache for the temporary storage of font data
US5223699A (en) * 1990-11-05 1993-06-29 At&T Bell Laboratories Recording and billing system
US5285494A (en) * 1992-07-31 1994-02-08 Pactel Corporation Network management system
US5287270A (en) * 1989-08-14 1994-02-15 Compucom Communications Corp. Billing system
US5313598A (en) * 1989-12-19 1994-05-17 Hitachi, Ltd. Method for changing non-leaf entry in tree structure of OSI directory information by sequentially issuing OSI directory commands for the non-leaf entry and lower entries associated therewith in response to decoded change command
US5315093A (en) * 1992-02-05 1994-05-24 A. C. Nielsen Company Market research method and system for collecting retail store market research data
US5475836A (en) * 1987-04-01 1995-12-12 Lotus Development Corporation Interface for providing access to external data sources/sinks
US5481542A (en) * 1993-11-10 1996-01-02 Scientific-Atlanta, Inc. Interactive information services control system
US5483596A (en) * 1994-01-24 1996-01-09 Paralon Technologies, Inc. Apparatus and method for controlling access to and interconnection of computer system resources
US5490060A (en) * 1988-02-29 1996-02-06 Information Resources, Inc. Passive data collection system for market research data
US5491796A (en) * 1992-10-23 1996-02-13 Net Labs, Inc. Apparatus for remotely managing diverse information network resources
US5491779A (en) * 1992-04-03 1996-02-13 Bezjian; Richard D. Three dimensional presentation of multiple data sets in unitary format with pie charts
US5506893A (en) * 1993-02-19 1996-04-09 At&T Corp. Telecommunication network arrangement for providing real time access to call records
US5526257A (en) * 1994-10-31 1996-06-11 Finlay Fine Jewelry Corporation Product evaluation system
US5530744A (en) * 1994-09-20 1996-06-25 At&T Corp. Method and system for dynamic customized call routing
US5539734A (en) * 1994-07-21 1996-07-23 Newbridge Networks Corporation Method of maintaining PVC status packetized communication system
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method
US5608720A (en) * 1993-03-09 1997-03-04 Hubbell Incorporated Control system and operations system interface for a network element in an access system
US5610915A (en) * 1994-11-30 1997-03-11 Mci Communications Corporation System and method therefor of viewing call traffic of a telecommunications network
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5630066A (en) * 1994-12-20 1997-05-13 Sun Microsystems, Inc. System and method for locating object view and platform independent object
US5659601A (en) * 1995-05-09 1997-08-19 Motorola, Inc. Method of selecting a cost effective service plan
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
US5696906A (en) * 1995-03-09 1997-12-09 Continental Cablevision, Inc. Telecommunicaion user account management system and method
US5706502A (en) * 1996-03-25 1998-01-06 Sun Microsystems, Inc. Internet-enabled portfolio manager system and method
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5710882A (en) * 1995-06-29 1998-01-20 Telefonaktiebolaget Lm Ericsson Method and call set up server for setting up a call using a call handling portion and a connection handling portion to handle the call and the connection, respectively
US5710900A (en) * 1995-10-12 1998-01-20 Ncr Corporation System and method for generating reports from a computer database
US5721913A (en) * 1994-05-05 1998-02-24 Lucent Technologies Inc. Integrated activity management system
US5721903A (en) * 1995-10-12 1998-02-24 Ncr Corporation System and method for generating reports from a computer database
US5721908A (en) * 1995-06-07 1998-02-24 International Business Machines Corporation Computer network for WWW server data access over internet
US5727129A (en) * 1996-06-04 1998-03-10 International Business Machines Corporation Network system for profiling and actively facilitating user activities
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows
US5734709A (en) * 1992-01-27 1998-03-31 Sprint Communications Co. L.P. System for customer configuration of call routing in a telecommunications network
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5742762A (en) * 1995-05-19 1998-04-21 Telogy Networks, Inc. Network management gateway
US5742763A (en) * 1995-12-29 1998-04-21 At&T Corp. Universal message delivery system for handles identifying network presences
US5742768A (en) * 1996-07-16 1998-04-21 Silicon Graphics, Inc. System and method for providing and displaying a web page having an embedded menu
US5745754A (en) * 1995-06-07 1998-04-28 International Business Machines Corporation Sub-agent for fulfilling requests of a web browser using an intelligent agent and providing a report
US5754830A (en) * 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US5757900A (en) * 1995-06-02 1998-05-26 Bell Communications Research, Inc. System and method for single access database retrievals
US5764756A (en) * 1996-01-11 1998-06-09 U S West, Inc. Networked telephony central offices
US5768501A (en) * 1996-05-28 1998-06-16 Cabletron Systems Method and apparatus for inter-domain alarm correlation
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US5774670A (en) * 1995-10-06 1998-06-30 Netscape Communications Corporation Persistent client state in a hypertext transfer protocol based client-server system
US5819271A (en) * 1996-06-04 1998-10-06 Multex Systems, Inc. Corporate information communication and delivery system and method including entitlable hypertext links
US5832496A (en) * 1995-10-12 1998-11-03 Ncr Corporation System and method for performing intelligent analysis of a computer database
US5848396A (en) * 1996-04-26 1998-12-08 Freedom Of Information, Inc. Method and apparatus for determining behavioral profile of a computer user
US5860066A (en) * 1996-06-27 1999-01-12 Payment Systems For Credit Unions Inc. Imaging and workflow system
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network
US5870558A (en) * 1996-06-25 1999-02-09 Mciworldcom, Inc. Intranet graphical user interface for SONET network management
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5875296A (en) * 1997-01-28 1999-02-23 International Business Machines Corporation Distributed file system web server user authentication with cookies
US5875236A (en) * 1995-11-21 1999-02-23 At&T Corp Call handling method for credit and fraud management
US5877759A (en) * 1997-03-26 1999-03-02 Netscape Communications Corporation Interface for user/agent interaction
US5881237A (en) * 1996-09-10 1999-03-09 Ganymede Software, Inc. Methods, systems and computer program products for test scenario based communications network performance testing
US5884312A (en) * 1997-02-28 1999-03-16 Electronic Data Systems Corporation System and method for securely accessing information from disparate data sources through a network
US5884032A (en) * 1995-09-25 1999-03-16 The New Brunswick Telephone Company, Limited System for coordinating communications via customer contact channel changing system using call centre for setting up the call between customer and an available help agent
US5883948A (en) * 1995-06-19 1999-03-16 Lucent Technologies Inc. Method for automatic maintenance of a local number portability database
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5907681A (en) * 1997-10-20 1999-05-25 International Business Machines Corporation Intelligent method, apparatus and computer program product for automated refreshing of internet web pages
US5909682A (en) * 1996-12-30 1999-06-01 Mci Worldcom, Inc. Real-time device data management for managing access to data in a telecommunication system
US5909679A (en) * 1996-11-08 1999-06-01 At&T Corp Knowledge-based moderator for electronic mail help lists
US5915001A (en) * 1996-11-14 1999-06-22 Vois Corporation System and method for providing and using universally accessible voice and speech data files
US5930810A (en) * 1995-08-09 1999-07-27 Taylor Corporation Printing system with pre-defined user modifiable forms and local and remote printing
US5953389A (en) * 1993-11-16 1999-09-14 Bell Atlantic Network Services, Inc. Combination system for provisioning and maintaining telephone network facilities in a public switched telephone network
US5991733A (en) * 1996-03-22 1999-11-23 Hartford Fire Insurance Company Method and computerized system for managing insurance receivable accounts
US5999965A (en) * 1996-08-20 1999-12-07 Netspeak Corporation Automatic call distribution server for computer telephony communications
US6006242A (en) * 1996-04-05 1999-12-21 Bankers Systems, Inc. Apparatus and method for dynamically creating a document
US6012090A (en) * 1997-03-14 2000-01-04 At&T Corp. Client-side parallel requests for network services using group name association
US6014647A (en) * 1997-07-08 2000-01-11 Nizzari; Marcia M. Customer interaction tracking
US6014702A (en) * 1997-06-04 2000-01-11 International Business Machines Corporation Host information access via distributed programmed objects
US6018768A (en) * 1996-03-08 2000-01-25 Actv, Inc. Enhanced video programming system and method for incorporating and displaying retrieved integrated internet information segments
US6021409A (en) * 1996-08-09 2000-02-01 Digital Equipment Corporation Method for parsing, indexing and searching world-wide-web pages
US6023762A (en) * 1997-07-09 2000-02-08 Northern Telecom Limited Multi-view personalized communications agent
US6029182A (en) * 1996-10-04 2000-02-22 Canon Information Systems, Inc. System for generating a custom formatted hypertext document by using a personal profile to retrieve hierarchical documents
US6032184A (en) * 1995-12-29 2000-02-29 Mci Worldcom, Inc. Integrated interface for Web based customer care and trouble management
US6031904A (en) * 1996-10-23 2000-02-29 Nortel Networks Corporation Service order mechanism for telephone subscriber
US6032132A (en) * 1998-06-12 2000-02-29 Csg Systems, Inc. Telecommunications access cost management system
US6041325A (en) * 1997-10-09 2000-03-21 Alcatel Usa Sourcing, L.P. System and method for controlling access to a telephony database
US6041357A (en) * 1997-02-06 2000-03-21 Electric Classified, Inc. Common session token system and protocol
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system
US6044144A (en) * 1997-02-07 2000-03-28 Mci Communications Corp. Network call parking manager
US6049789A (en) * 1998-06-24 2000-04-11 Mentor Graphics Corporation Software pay per use licensing system
US6049602A (en) * 1997-09-18 2000-04-11 At&T Corp Virtual call center
US6052450A (en) * 1995-07-27 2000-04-18 British Telecommunications Public Limited Company Billing for communications usage
US6054667A (en) * 1997-07-25 2000-04-25 La Soudure Autogene Francaise Method of manufacturing metal tubes
US6058381A (en) * 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
US6058170A (en) * 1997-03-10 2000-05-02 At&T Corp Telephone billing with summary information
US6065002A (en) * 1996-10-31 2000-05-16 Systems And Computer Technology Corporation Simplified interface for relational database access using open database connectivity
US6065116A (en) * 1997-05-07 2000-05-16 Unisys Corporation Method and apparatus for configuring a distributed application program
US6065059A (en) * 1996-12-10 2000-05-16 International Business Machines Corporation Filtered utilization of internet data transfers to reduce delay and increase user control
US6072493A (en) * 1997-03-31 2000-06-06 Bellsouth Corporation System and method for associating services information with selected elements of an organization
US6094655A (en) * 1995-06-07 2000-07-25 International Business Machines Corporation Method of creating and using notes decision capsules
US6108782A (en) * 1996-12-13 2000-08-22 3Com Corporation Distributed remote monitoring (dRMON) for networks
US6161102A (en) * 1994-07-25 2000-12-12 Apple Computer, Inc. Method and apparatus for searching for information in a data processing system and for providing scheduled search reports in a summary format
US6173311B1 (en) * 1997-02-13 2001-01-09 Pointcast, Inc. Apparatus, method and article of manufacture for servicing client requests on a network
US6182113B1 (en) * 1997-09-16 2001-01-30 International Business Machines Corporation Dynamic multiplexing of hyperlinks and bookmarks
US6205456B1 (en) * 1997-01-17 2001-03-20 Fujitsu Limited Summarization apparatus and method
US6212506B1 (en) * 1997-09-16 2001-04-03 Nortel Networks Corporation Per call real time billing display
US6212558B1 (en) * 1997-04-25 2001-04-03 Anand K. Antur Method and apparatus for configuring and managing firewalls and security devices
US6212636B1 (en) * 1997-05-01 2001-04-03 Itt Manufacturing Enterprises Method for establishing trust in a computer network via association
US6212546B1 (en) * 1998-10-01 2001-04-03 Unisys Corporation Providing a modular gateway architecture which isolates attributes of the client and server systems into independent components
US6240450B1 (en) * 1995-10-16 2001-05-29 British Telecommunications Public Limited Company Network data visualization system and method for downloading visualization software to a user station after user authentication
US6292481B1 (en) * 1997-09-16 2001-09-18 Bell Atlantic Network Services, Inc. Inter-carrier signaling and usage accounting architecture for internet telephony
US6337858B1 (en) * 1997-10-10 2002-01-08 Nortel Networks Limited Method and apparatus for originating voice calls from a data network
US6377993B1 (en) * 1997-09-26 2002-04-23 Mci Worldcom, Inc. Integrated proxy interface for web based data management reports
US6715080B1 (en) * 1998-10-01 2004-03-30 Unisys Corporation Making CGI variables and cookie information available to an OLTP system

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136707A (en) 1988-10-28 1992-08-04 At&T Bell Laboratories Reliable database administration arrangement
US5131020A (en) 1989-12-29 1992-07-14 Smartroutes Systems Limited Partnership Method of and system for providing continually updated traffic or other information to telephonically and other communications-linked customers
JP2619962B2 (en) 1990-02-28 1997-06-11 株式会社日立製作所 Figure editing method and apparatus
US5222120A (en) 1990-04-23 1993-06-22 Mci Communications Corporation Long distance telephone switching system with enhanced subscriber services
ATE194238T1 (en) 1990-09-17 2000-07-15 Cabletron Systems Inc SYSTEM AND METHOD FOR MODELING A COMPUTER NETWORK
US5129152A (en) 1990-12-20 1992-07-14 Hughes Aircraft Company Fast contact measuring machine
US5812654A (en) 1992-01-27 1998-09-22 Sprint Communications Co. L.P. Telecommunications network routing
JP3175348B2 (en) 1992-11-06 2001-06-11 キヤノン株式会社 Communication device
US5452446A (en) 1992-11-12 1995-09-19 Spx Corporation Method and apparatus for managing dynamic vehicle data recording data by current time minus latency
US5586260A (en) 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
US5361259A (en) 1993-02-19 1994-11-01 American Telephone And Telegraph Company Wide area network (WAN)-arrangement
US5666481A (en) 1993-02-26 1997-09-09 Cabletron Systems, Inc. Method and apparatus for resolving faults in communications networks
WO1995015533A1 (en) 1993-11-30 1995-06-08 Burke Raymond R Computer system for allowing a consumer to purchase packaged goods at home
US5548726A (en) 1993-12-17 1996-08-20 Taligeni, Inc. System for activating new service in client server network by reconfiguring the multilayer network protocol stack dynamically within the server node
US5533108A (en) 1994-03-18 1996-07-02 At&T Corp. Method and system for routing phone calls based on voice and data transport capability
US5793762A (en) 1994-04-12 1998-08-11 U S West Technologies, Inc. System and method for providing packet data and voice services to mobile subscribers
US5566351A (en) 1994-06-20 1996-10-15 International Business Machines Corporation Adaptive polling system by generating sequence of polling signals whose magnitudes are functionally related to the occurrence of the busy signal
US5778377A (en) 1994-11-04 1998-07-07 International Business Machines Corporation Table driven graphical user interface
US5689645A (en) 1994-12-01 1997-11-18 Hewlett-Packard Co. Persistence specification system and method for producing persistent and transient submaps in a management station for a data communication network
US5787160A (en) 1994-12-08 1998-07-28 Mci Communications Corporation Intelligent routing of special service calls
US5781632A (en) 1995-02-08 1998-07-14 Odom; Gregory Glen Method and apparatus for secured transmission of confidential data over an unsecured network
JP3841366B2 (en) 1995-02-17 2006-11-01 富士通株式会社 Monitoring device load balancing processing system
JPH08235114A (en) 1995-02-28 1996-09-13 Hitachi Ltd Server access method and charge information managing method
US5649182A (en) 1995-03-17 1997-07-15 Reitz; Carl A. Apparatus and method for organizing timeline data
US5699403A (en) 1995-04-12 1997-12-16 Lucent Technologies Inc. Network vulnerability management apparatus and method
US5650994A (en) 1995-05-16 1997-07-22 Bell Atlantic Network Services, Inc. Operation support system for service creation and network provisioning for video dial tone networks
US5802320A (en) 1995-05-18 1998-09-01 Sun Microsystems, Inc. System for packet filtering of data packets at a computer network interface
US5692030A (en) 1995-05-31 1997-11-25 Mci Communications Corporation Electronic interface for exchange of trouble administration information in telecommunications
US5793964A (en) 1995-06-07 1998-08-11 International Business Machines Corporation Web browser system
US5826269A (en) 1995-06-21 1998-10-20 Microsoft Corporation Electronic mail interface for a network server
US5852812A (en) 1995-08-23 1998-12-22 Microsoft Corporation Billing system for a network
US5657390A (en) 1995-08-25 1997-08-12 Netscape Communications Corporation Secure socket layer application program apparatus and method
US5850517A (en) 1995-08-31 1998-12-15 Oracle Corporation Communication link for client-server having agent which sends plurality of requests independent of client and receives information from the server independent of the server
US5692181A (en) 1995-10-12 1997-11-25 Ncr Corporation System and method for generating reports from a computer database
US5826029A (en) 1995-10-31 1998-10-20 International Business Machines Corporation Secured gateway interface
US5778178A (en) 1995-11-13 1998-07-07 Arunachalam; Lakshmi Method and apparatus for enabling real-time bi-directional transactions on a network
JPH09204774A (en) 1995-12-22 1997-08-05 Hitachi Ltd Semiconductor memory
US5852810A (en) 1996-01-29 1998-12-22 Student Housing Network Geographic specific information search system and method
US5781550A (en) 1996-02-02 1998-07-14 Digital Equipment Corporation Transparent and secure network gateway
US5815665A (en) 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5835084A (en) 1996-05-01 1998-11-10 Microsoft Corporation Method and computerized apparatus for distinguishing between read and unread messages listed in a graphical message window
US5784058A (en) 1996-05-28 1998-07-21 Sun Microsystems, Inc. User-controllable persistent browser display pages
US5819225A (en) 1996-05-30 1998-10-06 International Business Machines Corporation Display indications of speech processing states in speech recognition system
US5799154A (en) 1996-06-27 1998-08-25 Mci Communications Corporation System and method for the remote monitoring of wireless packet data networks
US5938729A (en) 1996-07-12 1999-08-17 Microsoft Corporation System and method for monitoring server performance at a client computer
US5790780A (en) 1996-07-16 1998-08-04 Electronic Data Systems Corporation Analysis of failures in a computing environment
US5790789A (en) 1996-08-02 1998-08-04 Suarez; Larry Method and architecture for the creation, control and deployment of services within a distributed computer environment
US5845267A (en) 1996-09-06 1998-12-01 At&T Corp System and method for billing for transactions conducted over the internet from within an intranet
US5845067A (en) 1996-09-09 1998-12-01 Porter; Jack Edward Method and apparatus for document management utilizing a messaging system
US5937165A (en) 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US5796393A (en) 1996-11-08 1998-08-18 Compuserve Incorporated System for intergrating an on-line service community with a foreign service
US5848233A (en) 1996-12-09 1998-12-08 Sun Microsystems, Inc. Method and apparatus for dynamic packet filter assignment
US6286050B1 (en) * 1997-01-27 2001-09-04 Alcatel Usa Sourcing, L.P. System and method for monitoring and management of telecommunications equipment using enhanced internet access
US5923756A (en) 1997-02-12 1999-07-13 Gte Laboratories Incorporated Method for providing secure remote command execution over an insecure computer network
US6112238A (en) * 1997-02-14 2000-08-29 Webtrends Corporation System and method for analyzing remote traffic data in a distributed computing environment
US5844896A (en) 1997-02-26 1998-12-01 U S West, Inc. System and method for routing telephone calls
US6104704A (en) * 1997-03-20 2000-08-15 At&T Corp. Methods and apparatus for gathering and processing billing information for internet telephony
US5805803A (en) 1997-05-13 1998-09-08 Digital Equipment Corporation Secure web tunnel
US6084953A (en) * 1998-08-28 2000-07-04 Axicom Communications Group Inc. Internet assisted return call

Patent Citations (119)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US139178A (en) * 1873-05-20 Improvement in polishing devices
US4727243A (en) * 1984-10-24 1988-02-23 Telenet Communications Corporation Financial transaction system
US4817050A (en) * 1985-11-22 1989-03-28 Kabushiki Kaisha Toshiba Database system
US4823373A (en) * 1986-10-16 1989-04-18 Oki Electric Industry Co., Ltd. Line switching control system for mobile communication
US4823373B1 (en) * 1986-10-16 1999-08-24 Oki Electric Ind Co Ltd Line switching control system for mobile communication
US4893248A (en) * 1987-02-06 1990-01-09 Access Corporation Monitoring and reporting system for remote terminals
US5475836A (en) * 1987-04-01 1995-12-12 Lotus Development Corporation Interface for providing access to external data sources/sinks
US5490060A (en) * 1988-02-29 1996-02-06 Information Resources, Inc. Passive data collection system for market research data
US5088052A (en) * 1988-07-15 1992-02-11 Digital Equipment Corporation System for graphically representing and manipulating data stored in databases
US5325290A (en) * 1989-08-14 1994-06-28 Compucom Communications Corp. Billing system with data indexing
US5287270A (en) * 1989-08-14 1994-02-15 Compucom Communications Corp. Billing system
US5208908A (en) * 1989-10-12 1993-05-04 International Business Machines Corporation Display system having a font cache for the temporary storage of font data
US5313598A (en) * 1989-12-19 1994-05-17 Hitachi, Ltd. Method for changing non-leaf entry in tree structure of OSI directory information by sequentially issuing OSI directory commands for the non-leaf entry and lower entries associated therewith in response to decoded change command
US5223699A (en) * 1990-11-05 1993-06-29 At&T Bell Laboratories Recording and billing system
US5734709A (en) * 1992-01-27 1998-03-31 Sprint Communications Co. L.P. System for customer configuration of call routing in a telecommunications network
US5315093A (en) * 1992-02-05 1994-05-24 A. C. Nielsen Company Market research method and system for collecting retail store market research data
US5491779A (en) * 1992-04-03 1996-02-13 Bezjian; Richard D. Three dimensional presentation of multiple data sets in unitary format with pie charts
US5285494A (en) * 1992-07-31 1994-02-08 Pactel Corporation Network management system
US5491796A (en) * 1992-10-23 1996-02-13 Net Labs, Inc. Apparatus for remotely managing diverse information network resources
US5506893A (en) * 1993-02-19 1996-04-09 At&T Corp. Telecommunication network arrangement for providing real time access to call records
US5608720A (en) * 1993-03-09 1997-03-04 Hubbell Incorporated Control system and operations system interface for a network element in an access system
US5481542A (en) * 1993-11-10 1996-01-02 Scientific-Atlanta, Inc. Interactive information services control system
US5953389A (en) * 1993-11-16 1999-09-14 Bell Atlantic Network Services, Inc. Combination system for provisioning and maintaining telephone network facilities in a public switched telephone network
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows
US5483596A (en) * 1994-01-24 1996-01-09 Paralon Technologies, Inc. Apparatus and method for controlling access to and interconnection of computer system resources
US5721913A (en) * 1994-05-05 1998-02-24 Lucent Technologies Inc. Integrated activity management system
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
US5539734A (en) * 1994-07-21 1996-07-23 Newbridge Networks Corporation Method of maintaining PVC status packetized communication system
US6161102A (en) * 1994-07-25 2000-12-12 Apple Computer, Inc. Method and apparatus for searching for information in a data processing system and for providing scheduled search reports in a summary format
US5621727A (en) * 1994-09-16 1997-04-15 Octel Communications Corporation System and method for private addressing plans using community addressing
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5530744A (en) * 1994-09-20 1996-06-25 At&T Corp. Method and system for dynamic customized call routing
US5526257A (en) * 1994-10-31 1996-06-11 Finlay Fine Jewelry Corporation Product evaluation system
US5623601A (en) * 1994-11-18 1997-04-22 Milkway Networks Corporation Apparatus and method for providing a secure gateway for communication and data exchanges between networks
US5610915A (en) * 1994-11-30 1997-03-11 Mci Communications Corporation System and method therefor of viewing call traffic of a telecommunications network
US5630066A (en) * 1994-12-20 1997-05-13 Sun Microsystems, Inc. System and method for locating object view and platform independent object
US5696906A (en) * 1995-03-09 1997-12-09 Continental Cablevision, Inc. Telecommunicaion user account management system and method
US5659601A (en) * 1995-05-09 1997-08-19 Motorola, Inc. Method of selecting a cost effective service plan
US5742762A (en) * 1995-05-19 1998-04-21 Telogy Networks, Inc. Network management gateway
US5757900A (en) * 1995-06-02 1998-05-26 Bell Communications Research, Inc. System and method for single access database retrievals
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5745754A (en) * 1995-06-07 1998-04-28 International Business Machines Corporation Sub-agent for fulfilling requests of a web browser using an intelligent agent and providing a report
US5721908A (en) * 1995-06-07 1998-02-24 International Business Machines Corporation Computer network for WWW server data access over internet
US6094655A (en) * 1995-06-07 2000-07-25 International Business Machines Corporation Method of creating and using notes decision capsules
US5883948A (en) * 1995-06-19 1999-03-16 Lucent Technologies Inc. Method for automatic maintenance of a local number portability database
US5710882A (en) * 1995-06-29 1998-01-20 Telefonaktiebolaget Lm Ericsson Method and call set up server for setting up a call using a call handling portion and a connection handling portion to handle the call and the connection, respectively
US6052450A (en) * 1995-07-27 2000-04-18 British Telecommunications Public Limited Company Billing for communications usage
US5930810A (en) * 1995-08-09 1999-07-27 Taylor Corporation Printing system with pre-defined user modifiable forms and local and remote printing
US5884032A (en) * 1995-09-25 1999-03-16 The New Brunswick Telephone Company, Limited System for coordinating communications via customer contact channel changing system using call centre for setting up the call between customer and an available help agent
US5774670A (en) * 1995-10-06 1998-06-30 Netscape Communications Corporation Persistent client state in a hypertext transfer protocol based client-server system
US5710900A (en) * 1995-10-12 1998-01-20 Ncr Corporation System and method for generating reports from a computer database
US5721903A (en) * 1995-10-12 1998-02-24 Ncr Corporation System and method for generating reports from a computer database
US5870746A (en) * 1995-10-12 1999-02-09 Ncr Corporation System and method for segmenting a database based upon data attributes
US5832496A (en) * 1995-10-12 1998-11-03 Ncr Corporation System and method for performing intelligent analysis of a computer database
US6240450B1 (en) * 1995-10-16 2001-05-29 British Telecommunications Public Limited Company Network data visualization system and method for downloading visualization software to a user station after user authentication
US5875236A (en) * 1995-11-21 1999-02-23 At&T Corp Call handling method for credit and fraud management
US5602918A (en) * 1995-12-22 1997-02-11 Virtual Open Network Environment Corp. Application level security system and method
US5742763A (en) * 1995-12-29 1998-04-21 At&T Corp. Universal message delivery system for handles identifying network presences
US6032184A (en) * 1995-12-29 2000-02-29 Mci Worldcom, Inc. Integrated interface for Web based customer care and trouble management
US5764756A (en) * 1996-01-11 1998-06-09 U S West, Inc. Networked telephony central offices
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US6018768A (en) * 1996-03-08 2000-01-25 Actv, Inc. Enhanced video programming system and method for incorporating and displaying retrieved integrated internet information segments
US5991733A (en) * 1996-03-22 1999-11-23 Hartford Fire Insurance Company Method and computerized system for managing insurance receivable accounts
US5706502A (en) * 1996-03-25 1998-01-06 Sun Microsystems, Inc. Internet-enabled portfolio manager system and method
US5754830A (en) * 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US6006242A (en) * 1996-04-05 1999-12-21 Bankers Systems, Inc. Apparatus and method for dynamically creating a document
US5734831A (en) * 1996-04-26 1998-03-31 Sun Microsystems, Inc. System for configuring and remotely administering a unix computer over a network
US5848396A (en) * 1996-04-26 1998-12-08 Freedom Of Information, Inc. Method and apparatus for determining behavioral profile of a computer user
US5768501A (en) * 1996-05-28 1998-06-16 Cabletron Systems Method and apparatus for inter-domain alarm correlation
US5727129A (en) * 1996-06-04 1998-03-10 International Business Machines Corporation Network system for profiling and actively facilitating user activities
US5819271A (en) * 1996-06-04 1998-10-06 Multex Systems, Inc. Corporate information communication and delivery system and method including entitlable hypertext links
US5870558A (en) * 1996-06-25 1999-02-09 Mciworldcom, Inc. Intranet graphical user interface for SONET network management
US5860066A (en) * 1996-06-27 1999-01-12 Payment Systems For Credit Unions Inc. Imaging and workflow system
US5742768A (en) * 1996-07-16 1998-04-21 Silicon Graphics, Inc. System and method for providing and displaying a web page having an embedded menu
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6021409A (en) * 1996-08-09 2000-02-01 Digital Equipment Corporation Method for parsing, indexing and searching world-wide-web pages
US5999965A (en) * 1996-08-20 1999-12-07 Netspeak Corporation Automatic call distribution server for computer telephony communications
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5881237A (en) * 1996-09-10 1999-03-09 Ganymede Software, Inc. Methods, systems and computer program products for test scenario based communications network performance testing
US6029182A (en) * 1996-10-04 2000-02-22 Canon Information Systems, Inc. System for generating a custom formatted hypertext document by using a personal profile to retrieve hierarchical documents
US6031904A (en) * 1996-10-23 2000-02-29 Nortel Networks Corporation Service order mechanism for telephone subscriber
US6058381A (en) * 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
US6065002A (en) * 1996-10-31 2000-05-16 Systems And Computer Technology Corporation Simplified interface for relational database access using open database connectivity
US5909679A (en) * 1996-11-08 1999-06-01 At&T Corp Knowledge-based moderator for electronic mail help lists
US5915001A (en) * 1996-11-14 1999-06-22 Vois Corporation System and method for providing and using universally accessible voice and speech data files
US5867495A (en) * 1996-11-18 1999-02-02 Mci Communications Corporations System, method and article of manufacture for communications utilizing calling, plans in a hybrid network
US6065059A (en) * 1996-12-10 2000-05-16 International Business Machines Corporation Filtered utilization of internet data transfers to reduce delay and increase user control
US6108782A (en) * 1996-12-13 2000-08-22 3Com Corporation Distributed remote monitoring (dRMON) for networks
US5909682A (en) * 1996-12-30 1999-06-01 Mci Worldcom, Inc. Real-time device data management for managing access to data in a telecommunication system
US6205456B1 (en) * 1997-01-17 2001-03-20 Fujitsu Limited Summarization apparatus and method
US5875296A (en) * 1997-01-28 1999-02-23 International Business Machines Corporation Distributed file system web server user authentication with cookies
US6041357A (en) * 1997-02-06 2000-03-21 Electric Classified, Inc. Common session token system and protocol
US6044144A (en) * 1997-02-07 2000-03-28 Mci Communications Corp. Network call parking manager
US6173311B1 (en) * 1997-02-13 2001-01-09 Pointcast, Inc. Apparatus, method and article of manufacture for servicing client requests on a network
US5884312A (en) * 1997-02-28 1999-03-16 Electronic Data Systems Corporation System and method for securely accessing information from disparate data sources through a network
US6058170A (en) * 1997-03-10 2000-05-02 At&T Corp Telephone billing with summary information
US6012090A (en) * 1997-03-14 2000-01-04 At&T Corp. Client-side parallel requests for network services using group name association
US5877759A (en) * 1997-03-26 1999-03-02 Netscape Communications Corporation Interface for user/agent interaction
US6072493A (en) * 1997-03-31 2000-06-06 Bellsouth Corporation System and method for associating services information with selected elements of an organization
US6212558B1 (en) * 1997-04-25 2001-04-03 Anand K. Antur Method and apparatus for configuring and managing firewalls and security devices
US6212636B1 (en) * 1997-05-01 2001-04-03 Itt Manufacturing Enterprises Method for establishing trust in a computer network via association
US6065116A (en) * 1997-05-07 2000-05-16 Unisys Corporation Method and apparatus for configuring a distributed application program
US6014702A (en) * 1997-06-04 2000-01-11 International Business Machines Corporation Host information access via distributed programmed objects
US6014647A (en) * 1997-07-08 2000-01-11 Nizzari; Marcia M. Customer interaction tracking
US6023762A (en) * 1997-07-09 2000-02-08 Northern Telecom Limited Multi-view personalized communications agent
US6054667A (en) * 1997-07-25 2000-04-25 La Soudure Autogene Francaise Method of manufacturing metal tubes
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system
US6182113B1 (en) * 1997-09-16 2001-01-30 International Business Machines Corporation Dynamic multiplexing of hyperlinks and bookmarks
US6292481B1 (en) * 1997-09-16 2001-09-18 Bell Atlantic Network Services, Inc. Inter-carrier signaling and usage accounting architecture for internet telephony
US6212506B1 (en) * 1997-09-16 2001-04-03 Nortel Networks Corporation Per call real time billing display
US6049602A (en) * 1997-09-18 2000-04-11 At&T Corp Virtual call center
US6377993B1 (en) * 1997-09-26 2002-04-23 Mci Worldcom, Inc. Integrated proxy interface for web based data management reports
US6041325A (en) * 1997-10-09 2000-03-21 Alcatel Usa Sourcing, L.P. System and method for controlling access to a telephony database
US6337858B1 (en) * 1997-10-10 2002-01-08 Nortel Networks Limited Method and apparatus for originating voice calls from a data network
US5907681A (en) * 1997-10-20 1999-05-25 International Business Machines Corporation Intelligent method, apparatus and computer program product for automated refreshing of internet web pages
US6032132A (en) * 1998-06-12 2000-02-29 Csg Systems, Inc. Telecommunications access cost management system
US6049789A (en) * 1998-06-24 2000-04-11 Mentor Graphics Corporation Software pay per use licensing system
US6212546B1 (en) * 1998-10-01 2001-04-03 Unisys Corporation Providing a modular gateway architecture which isolates attributes of the client and server systems into independent components
US6715080B1 (en) * 1998-10-01 2004-03-30 Unisys Corporation Making CGI variables and cookie information available to an OLTP system

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8321411B2 (en) 1999-03-23 2012-11-27 Microstrategy, Incorporated System and method for management of an automatic OLAP report broadcast system
US9477740B1 (en) 1999-03-23 2016-10-25 Microstrategy, Incorporated System and method for management of an automatic OLAP report broadcast system
US20030101201A1 (en) * 1999-03-23 2003-05-29 Saylor Michael J. System and method for management of an automatic OLAP report broadcast system
US20050267868A1 (en) * 1999-05-28 2005-12-01 Microstrategy, Incorporated System and method for OLAP report generation with spreadsheet report within the network user interface
US9208213B2 (en) * 1999-05-28 2015-12-08 Microstrategy, Incorporated System and method for network user interface OLAP report formatting
US20160078003A1 (en) * 1999-05-28 2016-03-17 Microstrategy Incorporated System and method for network user interface report formatting
US8607138B2 (en) * 1999-05-28 2013-12-10 Microstrategy, Incorporated System and method for OLAP report generation with spreadsheet report within the network user interface
US10592705B2 (en) * 1999-05-28 2020-03-17 Microstrategy, Incorporated System and method for network user interface report formatting
US7881443B2 (en) 1999-09-13 2011-02-01 Microstrategy, Incorporated System and method for real-time, personalized, dynamic, interactive voice services for travel availability information
US8130918B1 (en) 1999-09-13 2012-03-06 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services, with closed loop transaction processing
US8094788B1 (en) 1999-09-13 2012-01-10 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services with customized message depending on recipient
US8051369B2 (en) 1999-09-13 2011-11-01 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services, including deployment through personalized broadcasts
US8995628B2 (en) 1999-09-13 2015-03-31 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services with closed loop transaction processing
US20030194065A1 (en) * 1999-09-13 2003-10-16 Justin Langseth System and method for real-time, personalized, dynamic, interactive voice services for travel availability information
US20050190897A1 (en) * 1999-09-13 2005-09-01 Microstrategy, Incorporated System and method for the creation and automatic deployment of personalized, dynamic and interactive voice services
US20040236844A1 (en) * 1999-11-15 2004-11-25 Lucent Technologies, Inc. Method and apparatus for remote audiovisual signal recording
US7925616B2 (en) * 2001-06-19 2011-04-12 Microstrategy, Incorporated Report system and method using context-sensitive prompt objects
US20060026122A1 (en) * 2001-06-19 2006-02-02 Microstrategy Incorporated Report system and method using context-sensitive prompt objects
US20030204365A1 (en) * 2002-04-30 2003-10-30 Li-Hua Chen System and method for generating a report on an object
US7225396B2 (en) * 2002-04-30 2007-05-29 Hong Fu Jin Precision Ind. (Shenzhen) Co., Ltd. System and method for generating a report on an object
US8411578B2 (en) 2002-05-01 2013-04-02 At&T Intellectual Property I, L.P. Systems and methods for proactive management of a communication network through monitoring a user network interface
US20110134783A1 (en) * 2002-05-01 2011-06-09 William Scott Taylor Systems and methods for proactive management of a communication network through monitoring a user network interface
US8611230B2 (en) 2002-05-01 2013-12-17 At&T Intellectual Property I, L.P. Systems and methods for proactive management of a communication network through monitoring a user network interface
US7899893B2 (en) * 2002-05-01 2011-03-01 At&T Intellectual Property I, L.P. System and method for proactive management of a communication network through monitoring a user network interface
US20030208591A1 (en) * 2002-05-01 2003-11-06 Taylor William Scott System and method for proactive management of a communication network through monitoring a user network interface
US20060265662A1 (en) * 2005-05-19 2006-11-23 Custom Credit Systems, L.P. System and method for generating and updating user interfaces of web-based applications
US20080215670A1 (en) * 2006-09-06 2008-09-04 Brandt Christian Redd Tracking usage and monitoring users of a distributed learning system
WO2008085175A1 (en) * 2007-01-12 2008-07-17 Secureach Systems, Inc. Method and system for communicating information
US8184781B2 (en) 2007-01-12 2012-05-22 Secureach Systems, Llc Method and system for communicating information
US20080170673A1 (en) * 2007-01-12 2008-07-17 Secureach Systems, Inc. Method and system for communicating information
US7836169B2 (en) * 2007-01-24 2010-11-16 Cisco Technology, Inc. Method and system for identifying and reporting over-utilized, under-utilized, and bad quality trunks and gateways in internet protocol telephony networks
US20080175167A1 (en) * 2007-01-24 2008-07-24 Cisco Technology, Inc. Method and system for identifying and reporting over-utilized, under-utilized, and bad quality trunks and gateways in internet protocol telephony networks
US8407297B2 (en) * 2007-10-22 2013-03-26 Sap Ag Systems and methods to receive information from a groupware client
US20090106371A1 (en) * 2007-10-22 2009-04-23 Markus Schmidt-Karaca Systems and methods to generate business reports based on electronic mail messages
US20090106373A1 (en) * 2007-10-22 2009-04-23 Marcus Schmidt-Karaca Systems and methods to receive information from a groupware client
US20100332570A1 (en) * 2009-06-30 2010-12-30 Verizon Patent And Licensing Inc. Methods and systems for automatically customizing an interaction experience of a user with a media content application
US8635255B2 (en) * 2009-06-30 2014-01-21 Verizon Patent And Licensing Inc. Methods and systems for automatically customizing an interaction experience of a user with a media content application
US20120084635A1 (en) * 2010-09-30 2012-04-05 Microsoft Corporation Parameterized template compression for binary xml
US20130007868A1 (en) * 2011-06-30 2013-01-03 Cable Television Laboratories, Inc. Zero sign-on authentication
US11178130B2 (en) 2011-06-30 2021-11-16 Cable Television Laboratories, Inc. Zero sign-on authentication
US8955078B2 (en) * 2011-06-30 2015-02-10 Cable Television Laboratories, Inc. Zero sign-on authentication
US9961067B2 (en) 2011-06-30 2018-05-01 Cable Television Laboratories, Inc. Zero sign-on authentication
US20130031485A1 (en) * 2011-07-29 2013-01-31 Pin Zhou Chen Mobile business intelligence dynamic adaptor
US9230281B2 (en) * 2011-12-21 2016-01-05 Verizon Patent And Licensing Inc. Transaction services reporting system
US20130167047A1 (en) * 2011-12-21 2013-06-27 Verizon Patent And Licensing Inc. Transaction services reporting system
US10371744B2 (en) * 2012-04-11 2019-08-06 Advantest Corporation Method and apparatus for an efficient framework for testcell development
US20140247936A1 (en) * 2013-03-04 2014-09-04 Avaya Inc. Systems and methods for managing reporting data on a hosted on-demand reporting system
US10026059B2 (en) * 2013-03-04 2018-07-17 Avaya Inc. Systems and methods for managing reporting data on a hosted on-demand reporting system
WO2015070032A1 (en) * 2013-11-08 2015-05-14 Teamblind Inc. System and method for authentication
US9439072B2 (en) 2013-11-08 2016-09-06 Teamblind Inc. System and method for authentication
US9483561B2 (en) * 2014-01-24 2016-11-01 Bank Of America Corporation Server inventory trends
US20150215178A1 (en) * 2014-01-24 2015-07-30 Bank Of America Corporation Server inventory trends
US20160021131A1 (en) * 2014-07-21 2016-01-21 David Paul Heilig Identifying stealth packets in network communications through use of packet headers
US10659478B2 (en) * 2014-07-21 2020-05-19 David Paul Heilig Identifying stealth packets in network communications through use of packet headers
US9374475B1 (en) * 2015-02-09 2016-06-21 Octopus Ventures Inc. System for processing customer records
US20180374047A1 (en) * 2017-06-26 2018-12-27 Oracle Financial Services Software Limited Computing framework for compliance report generation
US11544669B2 (en) * 2017-06-26 2023-01-03 Oracle Financial Services Software Limited Computing framework for compliance report generation

Also Published As

Publication number Publication date
US7058600B1 (en) 2006-06-06

Similar Documents

Publication Publication Date Title
US7058600B1 (en) Integrated proxy interface for web based data management reports
US6631402B1 (en) Integrated proxy interface for web based report requester tool set
US6714979B1 (en) Data warehousing infrastructure for web based reporting tool
US7225249B1 (en) Integrated systems for providing communications network management services and interactive generating invoice documents
US6515968B1 (en) Integrated interface for real time web based viewing of telecommunications network call traffic
US6745229B1 (en) Web based integrated customer interface for invoice reporting
US6473407B1 (en) Integrated proxy interface for web based alarm management tools
US6032184A (en) Integrated interface for Web based customer care and trouble management
US6381644B2 (en) Integrated proxy interface for web based telecommunications network management
US20020087383A1 (en) Integrated interface for web based customer care and trouble management
US20040193512A1 (en) Web based integrated customer interface for invoice reporting
WO1999015976A1 (en) Integrated proxy interface for web based report requester tool set

Legal Events

Date Code Title Description
AS Assignment

Owner name: MCI, LLC, VIRGINIA

Free format text: MERGER;ASSIGNOR:MCI, INC.;REEL/FRAME:032632/0244

Effective date: 20060106

Owner name: WORLDCOM, INC., MISSISSIPPI

Free format text: CHANGE OF NAME;ASSIGNOR:MCI WORLDCOM, INC.;REEL/FRAME:032632/0055

Effective date: 20000501

Owner name: VERIZON BUSINESS GLOBAL LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:MCI, LLC;REEL/FRAME:032632/0404

Effective date: 20061120

Owner name: MCI, INC., VIRGINIA

Free format text: MERGER;ASSIGNOR:WORLDCOM, INC.;REEL/FRAME:032632/0446

Effective date: 20040420

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:032734/0502

Effective date: 20140409

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:044626/0088

Effective date: 20140409