Patent Grant
6956845
1. Field of the Invention
The present invention relates in general to telecommunications management, and more particularly to a web-based application for controlling routing of inbound toll free telephone calls through a telecommunications network for automatic call distribution to service centers or other operations.
2. Background Art
Major telecommunications service entities, e.g., MCI, AT&T, and Sprint, presently provide network planning and configuration products for monitoring multiple systems or call centers to their customers predominantly through a Windows-based graphical user interface resident on their computer workstations. For example, MCI's configuration management and AT&T's routing control service both provide 3270 emulation packages that offer the customer the ability to dynamically control the routing of their toll free services. Via the existing products, customers may specify routing conditions such as a sequence of alternate sites or trunk groups where calls may be routed if a primary site is busy and already handling maximum calls allowed. Alternate routes are then searched in specified order looking for a site to take a call. Other products offer the ability to queue calls until a customer site is able to take a call. The length of the gueue may be defined by a customer. Yet other products offer customers load balancing ability throughout a network, from a PC-based workstation at their sites.
MCI currently provides its customers with a call manager workstation for providing various call routing management capabilities, including the ability to: provision toll free numbers, destinations, automatic call distributor (ACD) information, automatic number identification (ANI) lists, routing groups, caller entered digits (CED) lists and user defined variables; display individual and agent group data; display termination cause values which are numeric codes that relate to a specific reason for routing a call, e.g., time out, normal routing, etc.; display system and application alarms; and display graphic or tabular ACD and regular peg-count data.
With the existing products, however, service entity customers typically need to directly dial-up, e.g., via a modem, or, alternatively, via dedicated communication lines, e.g., ISDN, T-1, etc., to the entity's application and database servers, and initiate the network management application through the graphical user interface (GUI). Frequently, a dial-up modem and communications software interact with each other in many ways which are not always predictable to a custom application, requiring extensive troubleshooting and problem solving for an enterprise desiring to make a legacy system available to the customer, particularly where various telephone exchanges, dialing standards or signal standards are involved.
In addition, the aforementioned software is very hardware specific, and customers generally have a wide range of workstation vendors, which requires extensive inventory for distribution, and generally, intensive customer hand holding through initial setup and installation before reliable and secure sessions are possible. If the customer's hardware platform changes through an upgrade, many of these issues need renegotiation. Accordingly, it is highly desirable to integrate the existing call management client-server application in a Web-based platform which provides expedient, comprehensive and more secure data access and reporting services to customers from any Web browser on any computer workstation anywhere in the world.
The present invention is one component of an integrated suite of customer network management and report applications using the Internet and a World Wide Web (“WWW” or “Web”) Web browser paradigm. Introduced to the communications industry as the “networkMCI Interact,” the integrated suite of Web-based applications provides an invaluable tool for enabling customers of a telecommunications enterprise to manage their telecommunication assets, quickly and securely, from anywhere in the world. In addition, the present invention has a capacity of functioning outside the integrated suite, i.e., as a standalone entity.
The popularity of the public Internet provides a measure of platform independence for the customer, as the customer can run his/her own Internet Web browser and utilize his/her own platform connection to the Internet to enable service. This resolves many of the platform hardware and connectivity issues in the customer's favor, and lets the customer choose their own platform and operating system. Web-based programs can minimize the need for training and support since they utilize existing client software, i.e. a Web browser, which the user has already installed and already knows how to use. Moreover, there is no longer a need to produce and distribute voluminous hard copies of documentation, including software user guides. Further, if the customer later changes that platform, then, as soon as the new platform is Internet enabled, service is restored to the customer. The connectivity and communications software burden is thus resolved in favor of standard and readily available hardware and the browser and dial-up software used to obtain the public Internet connection.
An Internet delivered paradigm obviates many of the installation and configuration problems involved with initial setup and configuration of a customer workstation, since the custom application required to interface with the legacy system can be delivered via the public Internet and run within a standard Web browser, reducing application compatibility issues to browser compatibility issues.
For the enterprise, the use of off-the-shelf Web browsers by the customer significantly simplifies the enterprise burden by limiting the client development side to screen layouts and data presentation tools that use a common interface enabled by the web browser. Software development and support resources are thus available for the delivery of the enterprise legacy services and are not consumed by a need for customer support at the workstation level.
The present invention is directed to a call routing management application, including a routing management workstation, referred to herein as a call manager webstation (CMWS), which allows authorized customers to control toll free routing and monitor call center statuses. The terms call manager and call manager webstation will be used herein after and will refer to a system providing a call routing management capabilities. Via a web-based interface, customers may create and manage routing rules which may be applied on an individual call basis, monitor one or more call center automatic call distributor (ACD) agent groups, and view alarms. The present invention also provides reporting, data extract, and bulk data loading capabilities via a web-based interface.
The application features provided by the present invention include rules writing, testing and installation in which users are enabled to write rules for routing of toll free calls. Rules may load balance based on the call center capacity and route based on a calling number, caller-entered digits, or call termination quotas.
Furthermore, using the routing provision feature provided by the present invention, users may define tables and lists for use in routing rules. These tables include called numbers, destination labels, ACD agent groups, quota schemes, and ANI and/or CED translation tables.
Moreover, with the graphic data displays and alarms features provided by the present invention, users may view near real-time displays of call center ACD statistics and peg counts based on routing rules. Peg counts generally refer to a number of times an action or condition occurs. With the reports and data extracts feature, users may run provision and statistical reports on provisioning and statistical data as well as view, print, or extract files for further analysis.
The present invention also includes a user and business hierarchy maintenance feature for providing users with appropriate privileges with the ability to define business hierarchies, e.g., corporate or account group, to create and maintain user identifiers (ids), and to assign data access privileges.
In addition, the present invention supports multiple language displays, e.g., Canadian French, and a branding feature which enables use of call routing management capabilities internationally, e.g., in a North America service offering.
For providing the above functionalities, the present invention includes front-end client browser software including a web browser, HTML files including files within which scripts written in JavaScript client scripting language are embedded, and Java application and applet codes, which are executed on the customer's desktop system, i.e., a workstation. The Java classes providing the user interface include user and business hierarchy, call by call application, graphic data display, alarm manager, and reporting/data extraction, each of which provides a corresponding application feature supported by the present invention. The above client browser software physically resides on a web server and is downloaded dynamically to the customer's system via their web browser and an Internet connection.
The present invention also includes one or more web server(s) located in a demilitarized zone (DMZ) which is bounded by firewalls, for providing secure communications between the customer's workstation and the call manager webstation back-end systems. In addition, the web servers provide the state and session managements for the customer sessions. The web server classes implementing the web server functionalities include a session authentication manager for managing a customer session, and a transaction manager for receiving the web client transaction messages and communicating them to the back-end servers.
The present invention also includes a proxy server for servicing the client transactions which are communicated over the Internet via the web servers by interfacing with the systems implementing the routing engine and network elements which provide and direct various call routing procedures. The back-end also includes a plurality of databases having near real-time network statistics data and alarms extracted from the routing engine and/or network elements for providing reporting functionality to the customers at the client workstation. The proxy server is generally responsible for receiving and reformatting the web client transactions into commands compatible with the routing engine which may be implemented in a host system, and also for the reverse process, i.e., receiving the routing engine transactions and reformatting them into web client message transactions for transmitting them to the web client via the web servers, thereby providing services to both the web client and the routing engine. It should be further noted that the routine engine need not be implemented in a large scale mainframe system. Rather, the routing engine may be supported by various processors having a wide range of processing capabilities.
Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.
Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which like reference numbers indicate identical or functionally similar elements, and in which:
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 No. 09/159,695, 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 herein below. A detailed description of each of these common components can be found in related co-pending U.S. patent application No. 09/159,695, entitled INTEGRATED CUSTOMER INTERFACE SYSTEM FOR COMMUNICATIONS NETWORK MANAGEMENT, the disclosure of which is incorporated herein by reference thereto.
A third or back-end tier 18 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 U.S. Pat. No. 6,115,040, 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 management functions. The system is capable of delivering to customers the functionality appropriate to their product mix.
The Customer Browser 20 is a browser enabled and includes client applications responsible for presentation and front-end services. Its functions include providing a user interface of various MCI services and supporting communications with MCI's Intranet web server cluster 24. As illustrated in
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.
As shown in
The backplane 12 and the client applications use a browser 14 such as the Microsoft Explorer versions 4.0.1 or higher for an access and distribution mechanism. Although the backplane in 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 54a, 54b, 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 U.S. Pat. No. 6,115,040, entitled PHICAL USER INTERFACE FOR WEB ENABLED APPLICATIONS.
As shown in
The DMZ is a special secure network area set aside exclusively for potentially hostile customer access. All DMZ equipment is physically isolated and firewalled from the enterprise Intranet. Similarly, the DMZ equipment is firewalled and obscured from hostile attacks from the public Internet, except for limited Web browser access to the Web servers which are located in the DMZ. The customer's Web browser connects to a Web server in the DMZ which in turn acts as a proxy to extract select information from midrange servers located in the enterprise Intranet. A customer never directly connects to servers in the enterprise, thus ensuring internal enterprise system security and integrity.
The DMZ acts as a double firewall for enterprise Intranet from the public Internet because the Web servers located in the DMZ never store or compute actual customer sensitive data. The Web servers only put the data into 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.
As described in greater detail in co-pending U.S. patent application No. 09/159,695, entitled SECURE CUSTOMER INTERFACE FOR WEB-BASED DATA MANAGEMENT, the contents and disclosure of which are 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
As illustrated in
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
The network architecture of
As partially shown in
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.
As described herein, and in greater detail in co-pending U.S. patent application No. 09/159,695, 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 Traffic View Server 334, 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 supports spreadsheet presentation, a variety of graph and chart type presentations, 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.
A common database may be maintained to hold the common configuration data which may be used by the GUI applications and by the mid-range servers. Such common data includes but are not 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 manages the data base for the common configuration of data.
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 is typically resident in a Report Manager server database and managed by the report manager.
The Infrastructure component of the nMCI Reporting system includes mechanisms for providing secure communications regardless of the data content being communication. As described in detail above-references, co-pending U.S. patent application 09/159,695, 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 Manger. The order entry functionally is extended to additionally support 11) Event Monitor; 12) Service Inquiry; 13) Outbound Network Manger; and, 14) Online Invoicing.
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 mechanisms 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 No. 09/159,515, the client-tier software is organized into a “component” architecture supporting such applications as inbox fetch and inbox management, report viewer and report requestor, 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 Manger, Service Inquiry and Online invoicing.
The call manager system or the present invention provides sophisticated mechanisms, e.g., intelligent call routing, for all center customers to control delivery of toll free calls from the telecommunications enterprise network to call centers, including call centers having multiple ACDs. Particularly, using the system of the present invention, the customers have the ability to define routing rules which, on an individual call basis, determine the best place to route incoming toll free calls. A high level overview of the call manager system environment is illustrated in FIG. 6. The call manager system generally includes: a service control point (SCP) 610, for providing call manager routing features, known as “call by call” routing; an intelligent routing host (IR host) 612; and client workstations, i.e., call manager webstation client 360. The COP 610 is a routing engine which essentially maintains call routing rules and uses those rules to determine where to route the calls. The SCP 610 shown and described hereinafter, is used as an example of a system implementing the routing engine. It should be noted that the routing engine implementation is not limited to and need not reside in a mainframe system. Rather, the routing engine may also be supported by various types of processors having a wide range of processing capability.
A typical call processing flow for a call received from a caller 622 includes routing requests and responses from the enterprise switches 624 through data access points (DAPs) 616 and remote data gateways (RDGs) 618 into and out of the SCP 610. The DAP 616 executes a routing plan by translating a toll free number passed by the switch 624 into a network number, and maps it to an address. The RDG 618 provides a standard gateway allowing communication between the SCP 610 and the enterprise's backbone network. The translated network number is then communicated to the SCP 610 via the RDG 618.
Data collection and storage of ACD-based statistics from customer call centers and network statistics are supported by DAP traffic statistics (DTS) 614, and the IR host 612. The DTS collects network routing statistics from the DAP 616 and passes them to the IR host 612. The IR host 612 stores routing statistics from DTS 614 and the ACD 620. The ACD 620 data statistics are collected for each ACD 620 and normalized by the IR host 612, and provided to the routing engine, e.g., SCP 610. When the SCP 610 receives a routing request, the SCP 610 typically determines the best location to route a call by modeling each call center using periodic Automatic Call Distributor (ACD) 620 data statistics to keep the model in line with what is actually going on at each location.
Upon completion of call processing according to a customer routing plan, the DAP 616 passes routing instructions to the switch 624 for setting up the call to a customer's ACD 620. The ACD 620 balances the load of calls based upon customer defined rules such as the “busy-ness” of a call center. Calls may be distributed evenly using a “round robin” techniques, or directed in which calls are routed based on a percentage allotted to each destination identifier. Voice communications are carried from the switch 624 to the ACD 620 which terminates the call at the appropriate trunk or destination identifier.
The routing capabilities supported by SCP 610 include a termination selection based upon one or more of the following: initial list of eligible destinations, destinations eliminated from consideration based upon tested conditions, artificially biased evaluation criteria, percent allocation, and manipulation of user-defined peg-counter variables. The SCP 610 also supports the routing and blocking of incoming calls using event-level data based on one or more of the following characteristics: day of the week, day of year, preference of destination choices, time of day, membership of the automatic number identification (ANI) or caller entered digits (CED) in a defined list of values, load balancing and/or availability at specific destinations, user-defined quota schemes, user-defined peg-counters, preference of destination choices, and artificial bias of load balancing algorithms.
The Call Manager Integrated Data Server(s) (CMIDS) 640 are included to provide a front-end functionality to the routing engine, e.g., SCP 610, and off-load various workstation-related processing from the routing engine. In addition, the CMIDS 640 may directly access data stored on the IR host or on other data servers. Further details of the CMIDS 640 will be described with references to
The call manager system of the present invention further includes one or more web servers 632 for providing browser-based customer connections from the World Wide Web (WWW or Web). The call manger web server 632 passes the customer connections through to the SCP 610 via the CMIDS 640, and thus delivers the call manager functionality to the call manager webstation client 630 via a standard web browser and the Internet.
The call manager webstation 630 may be any hardware/software platform connected to the public Internet and running a supported web browser, e.g., Internet Explorer V4.01. The call manager webstation 620 is typically owned and maintained by the customer. The call manager webstation 630 includes a web-based graphical user interface (GUI) application which enables the customers to define their call terminations, and provision routing rules and associated tabular data to control routing by the SCP 610. The GUI application also presents alarms and near real time graphical displays of peg counts and ACD-based statistics. The application also provides reports and data extracts of historical data, including call detail records (CDRs), ACD-based statistic, and peg counts. In addition, user-id administration function including business hierarchy structures and function profiles may be performed via the call manager webstation's web-based GUI application.
As described above, the client webstation 630 provides a web-based graphical user interface (GUI) offering data management and data presentation features for the call manager system. The web-based front-end GUI is typically written using the Java programming language to insure platform independence. The client webstation 630 typically includes a web browser with Java applets for the interface for providing access to the call manager webstation application from a standard web browser, e.g., Internet Explorer V4.01. In addition, the networkMCI Interact common objects, described in the copending U.S. Pat. No. 6,115,040, the contents and disclosure of which are incorporated by reference as if fully set forth herein, are used for implementing many functions needed for client/server communications protocols. The Java applets generally reside on the web servers 632 and are dynamically downloaded to the client browsers (client webstations) 630 when the Uniform Resource Locator (URL) for the call manager webstation client GUI application is accessed.
The call manager webstation client GUI application of the system of the present invention is invoked by licking an icon labeled “call manager” (
Each call manager webstation application feature may be accessed through an icon button on a tool bar (
For providing the above features, the client browser includes class objects shown in FIG. 9.
In one embodiment of the invention, the communications from the client 630 and back-end (
In a preferred embodiment, a Netscape Server Application Program Interface (NSAPI) module may be used as an alternative to the CGI layer, the NSAPI module replacing the CGI-protocol communications layer between the client 630 and the web server 632. The web server 632 may be configured to pick up the NSAPI module and load and start up. Java client code 634 may be configured to refer to the NSAPI module. For example, the Java client may invoke a method to communicate directly with the NSAPI module that performs the same function as the CGI program. Using the NSAPI module enhances performance and messaging throughput. When the server 632 recognizes requests for the NSAPI module, it invokes a particular function in the module which performs essentially the same function as the CGI program. For example, a middle tier transaction handler, typically a message manager (msgmgr) and residing with the web servers 632, may be modified to use the NSAPI instead of the HTTP CGI. The advantage of NSAPI over CGI is that a new process need not be created whenever a request comes in from the web client 630.
In general, and as described above, the web server 632 provides a communication pass-through between the web client GUI application 630 and the back-end call manager integrated data server (CMIDS) 640 which may communicate with the routing engine, e.g., SCP.
The message manager 656 is typically a CGI program that is executed as a spawned process within the HTTP service manager 652 when a message transaction is received from the client via the POST method sent to the HTTPS port (443) 650. The HTTP service manager 652 spawns a process to run an instance of the message manager 656 each time it receives a message transaction from the client. Alternately, the message manager 656 may be implemented as a function in the NSAPI module as described above. The HTTP service manager 652 then invokes the message function in the NSAPI module. Both input and output streams are created by the message manager 656 to receive message data from the client 630 and to reply back to the client 630. The message manager 656 is generally responsible for the following: 1) accepting new user log in by allocating a new session key for a newly created session; 2) attaching a dispatcher and proxy header to the web client's message and forwarding the message to the proxy server 670; and receiving a routing engine, e.g., SCP, response message from the proxy server 670 and re-wrapping this message with dispatcher and proxy header and sending this formatted message to the web client 630. Message transactions are sent to the proxy server 670 over a new connection by opening a new TCP socket to the proxy server 670 whicle the original socket from the browser is blocking, waiting for a response from the web server 632.
Typically, communications to and from the client 630 take place over hyper-text transfer protocol secure (HTTPS), which uses hyper-text transfer protocol (HTTP) over a secure socket layer (SSL) encrypted channel. Applications may include web pages in the form of hyper-text markup language (HTML) files and Java applets 654 that are stored on the web server 632. The HTTP service manager 652 downloads the HTML files and Java applets 654 to the client 630 upon request via the HTTPS port 650, typically configured to port number 443. Each transaction from a client 630 is sent to the web server 632 in the form of a logical message that has been encrypted. The web server 632 decrypts the message and wraps the message with the user's information, including environment variables and a server-generated session identifier (id). The message is then encrypted and forwarded to the CMID 640, or alternately, as will be described below, to the proxy server component of the CMDI 640.
As described above, the message transactions created by the client 630 may be transmitted over HTTPS using the POST method defined within the HTTP protocol. Using the POST method, a specified CGI program and more specifically, an invoked message manager runs as a thread in the HTTP service manager 652. Message data is passed to the message manager 656 by opening an input stream and an output stream within the thread. As described previously, the HTTP service manager 652 spawns a message manager process 656 for each message transaction sent to web server 632. Each message transaction is a single request from the client 630 that is answered by a single replay from the web server 632.
The web server 632 also includes a session manager 658 and a session table 660 for providing session management functions including the authentication of various web requests. A session is defined as the amount of time between which a client 630 logs onto the web server 632 and when the client logs off. During a session, a client 630 may submit many message transactions to the web server 632. State data for each session is stored in the session table 660. Session entries are deleted from the session table 660 when a user logs off or when a session is aged. Each message transaction received by the web server 632 is associated with an active session. If a session no longer exists for a particular transaction, the message transaction is returned to the client 630 as rejected. The application then may prompt the user to login again.
Generally, the session table 660 is a table that has state information on all current client sessions that are active on the web server 632. When a client logs onto the web server 632 and is authenticated, the client is provided a “session id” which is a unique server-generated key. The client holds this and returns it to the server as part of subsequent message transaction. The session table 660 maintains a “session key table” which maps these keys to the associated session. The session table also includes a time stamp for each client session. A client sessions's time stamp is updated each time a message transaction containing the session id for the session is received. A session is aged if no message transactions belonging to the session are seen after a given amount of time. If so, the session, with its entry deleted from the session table 660, is logged off from the SCP 610.
The session manager 658 is generally responsible for monitoring all current client sessions. The session manager 658 typically monitors the sessions by accessing the session table 660 and checking the current time stamp values for each current session. If the time stamp value shows that a session has aged, the session entry for the aged session is cleared from the session table 660. Clearing the session entry forces any further message transactions associated with the session identifier to be rejected, requiring the user to restart the session.
For communications to and from the web client 630 and the back-end, the middle-tier web server 362 supports three types of transport mechanism which are provided by the networkMCI Interact platform: synchronous asynchronous, and bulk transfer. The Synchronous transaction type typically has a single TCP connection which is kept open until a full message reply has been retrieved. The Asynchronous transaction type is typically used for handling message transactions requiring a long delay in the back-end server response. A server process handling the message transaction responds back to the web client 630 immediately with a unique transaction identifier and then closes the connection. The web client 630 may then poll the web server 632 using the transaction identifier to determine when the original message transaction has completed. The bulk transfer type of transport mechanism is typically used for large data transfers which may be virtually unlimited in size.
In the embodiment shown in
In another embodiment, as will be described below with reference to the CMIDS 640 illustrated in
The proxy server 670 generally processes message transactions from the client 630 and is multithreaded to handle multiple message transactions simultaneously. The proxy server 670 is designed to process one type of message transaction or a set of message transactions. In this embodiment, routing of the messages to and from the proxy is handled by the message manager 656. The proxy server 670 also interacts with a database 672, e.g., Informix, to pass back information to be displayed by the client 630. The proxy server opens a connection to the SCP 610 to retrieve information about routing plans or report statistics by sending the SCP “man machine language” protocol (MML) commands. Upon retrieval, the proxy server 670 formats a response message which is sent back to the client webstation 630 so that it is displayed on the current web page. As the message reply is sent back to the client 630, each thread created by the proxy server 670 is completed. It should be noted that the proxy server 670 need not reside in the web servers 632. Instead, as will be described with reference to
The database 672 generally maintains information needed to translate the messages to and from the SCP 610. A message translation program written in 4GL access the database 672 when a message transaction is received. The program translates the message and sends the message to the SCP 610 for processing. After the message has been processed, the program translates the response and sends it back to the message manager 656. The proxy server 670 typically invokes an instance of the translation program for each message transaction it receives and processes. As noted above with reference to the proxy server, the database 672 may also alternately reside in the CMIDS with the proxy server.
In a first preferred embodiment, the present invention includes a data server, i.e., the CMIDS. In this embodiment, much of the functions of the proxy server are performed within the data server. More specifically, the proxy server 670 and the database 672 may be ported over to the CMIDS 640. The web server 672 communicates to the proxy in the CMIDS 640 which then communicates with the routing engine, e.g., SCP (
The proxy server 670 and the database 672 which were described with reference to the web server 632, may reside in the CMIDS 640. In addition, the CMIDS 640 may also include a session manager 658 and associated session table 660 for managing the client sessions. As described above, the proxy server 670 generally handles webstation client 630 requests passed from the web servers 632 by accepting message transactions from the webstation client 630 via the web servers 632, maintains logging information, sends the request to a session manager 658, and receives data from the back-end and forwards data to the web servers 632.
The session manager 658, residing in the CMIDS 640, receives data from the proxy server 670. The session manager 658 updates the sessions table 660, validates that the user has proper privilege to perform the task. The user validation function may be performed for the webstation client 630 also, in addition to a validation conducted by the networkMCI Interact StarOE authentication and entitlement system during the session log on.
The CMIDS 640 also may includes a routing engine formatter, a CMIDS transaction manager, and a routing engine port manager. The session manager 658 typically passes a transaction request received from the web server 632 to either the routing engine host formatter, or the CMID transaction manager. The routing engine host formatter module services transactions requiring SCP services to fulfill the request. The transactions originating from a webstation client 630, are translated to a correct MML format and sent to the routing engine port manager component.
The CMIDS transaction manager module services transactions that do not require the routing engine, e.g., SCP 610, i.e., the types of client request which may be serviced locally on CMIDS, including: obtaining NEMS alarm information, obtaining GDD information, and processing of user security. When the local processing is complete, results are sent back to the proxy server 670 component.
The routing engine port manager component of the CMIDS manages pools of session with one or more routing engines, e.g., SCPs 610. The routing engine port manager logs onto each session in a pool using a “generic” user id. Using a “generic” user id enables each session to access an individual user's data without having to log each user onto the SCP 610. MML commands for a particular user are sent to a SCP using any available session in the pool of “generic” session. After an MML command is sent and a response is received, the session is returned to the session pool and freed for use by the succeeding transactions. A session pool is defined as a set of sessions connected to one particular SCP 610. Therefore, the routing engine port manager component of CMIDS 640 supports multiple session pools for communicating with multiple SCPs 610.
The routing engine port manager also maintains the state of each session in each pool. The port manager generates a keep-alive-message whenever a session is idle to keep the SCP 610 connection from being dropped. If a session in a pool has failed, the routing engine port manager will try to reestablish the session and add it back into the pool when establishment is completed. The routing engine port manager determines the communication channel to use to access the SCP 610 and keeps a number of connections open to the SCP 610. Each message is sent to the SCP 610 and the channel blocked until a response is received.
The proxy 670 software component was described above with reference to FIG. 8. As shown, the proxy 670 may reside in the CMIDS, and provide the functionalities described above. The user account interface software component 643 generally maintains sessions with the SCPs and provides the functions of the routing engine port manager described above. The report handler process generally maintains databases 642a-c and provides reporting facilities. The CMIDS back-end interface 712 supports a number of interface mechanisms including MML and command line access to the SCP, common alarm and logging services, and data retrieval from the IR host.
Accordingly, as shown in step 752, when the customer 622 dials the toll-free number, the call goes to the network through the switch. At step 754, the call is passed from the switch to the DAP for translation. The DAP translates the toll-free number to a network number and maps it to an address readable by the RDG. NetCap 758 generally houses routing plans, destination labels, toll-free numbers, logical terminations, DAP-based details and trigger plans required for the call manager webstation system. Most of this data may be provisioned in NetCap 758 via the Toll Free Network Manager (TFNM) application service. The TFNM is described in detail in U.S. Pat. No. 6,115,040, contents and disclosure of which are incorporated by reference as if fully set forth herein. Seeing the trigger point and other DAP-based data provisioned from NetCap 758, the DAP passes the call to the RDG at step 756. At step 760, call statistics are saved in DAP traffic stations (DTS) for use in case of time-out or other failures. They are also stored within the IR host. At step 762, the RDG, with its ability to communication with the SCP, passes the network number and associated address to the call-by-call routing application on the SCP. Based on instructions in the rule set defined by the call manager webstation system customer, the call by call application selects the HSN ACD path group at step 764. At step 768, call by call application then selects the individual destination identifier within the ACD path based on the specified distribution method which may be either even/“round robin” or directed/percentage distribution. At step 770, the call is routed back through the RDG to the DAP. Then at step 772, the DAP routes the call to the ACD via the specified destination id or trunk. Specifically, referring back to the above illustrated example, calls received on Thursdays between 5:00 and 7:00 GMT may be set to be routed to Orlando, and accordingly the destination id is Orlando Central. The call by call routing application returns destination id “Orlando Central” to the network, which routes the call to the ACD via the Orlando Central destination id or trunk.
As described previously, the call manager client software uses the networkMCI Interact common objects (CO). Generally, the CO includes a library of objects that minimizes the replication of code, and provides a framework in which a family of Internet applications may be managed and created. This framework includes communications, I/O services to local resources, user authentication, internationalization, common look and feel, application management, and a model view controller (MVC) framework. The call manager client classes typically derive from the CO classes.
The application backplane architecture supports the plugging in of applications into one Java applet, which allows for one application's classes to use another's services. Accordingly, a COBackPlane class is derived from the Java applet class, and the networkMCI Interact backplane logic is implemented as an instance of the COBackPlane class. A class COApp acts like a Java applet, but does not derive from the Java Applet class. The COApps may be started and stopped from the class COBackPlane.
Each COApp frame is derived from a COAppframe, which has one or more COViews, a part of the standard MVC paradigm. The MVC paradigm allows for easy handling of multiple views of a data model. The model is a wrapper for an application data object. A controller is a lightweight event handling class, which translates GUI events into commands for the application. The view is one particular GUI representation of the model. In a MVC typical operation, views register with a model, allowing the updating of multiple views when the model changes. Each view has a controller, which handles the GUI events, and translates them into command descriptions. The model stores command descriptions, which for example, enables the undo and redo functionality in the application.
The call manager client application (CMApp) is preferably derived from the COApp class and may be launched by a backplane object that is typically derived from the COBackPlane class, including the networkMCI Interact backplane.
In a first embodiment of the present invention, the call manager client application is launched in a separate browser window from the one within which the networkMCI Interact backplane is running. For example, after validating that a customer's profile allows access to the call manager application, and after a customer clicks the call manager icon on the networkMCI Interact home page (FIG. 4), the networkMCI Interact backplane creates a separate browser window and populates the call manager webstation URL. The call manager webstation web server then downloads the call manager client application for execution within the new browser window.
In a second embodiment, the call manager webstation application may be launched as a standalone, i.e., outside the networkMCI Interact home page. For example, a customer may retrieve the web page the call manager webstation application directly from the client's web browser by pointing to the call manager webstation URL. The call manager webstation web server then downloads the call manager client application for execution, in a similar manner as the first embodiment described above.
The call manager client application downloaded from the server includes a CMBackPlane class which is applet derived from the COBackPlane class and which inherits the attributes of the COBackPlane class. The CMBackPlane is launched with the call manager webstation web page and provides backplane functionalities within the context of the call manager webstation application. The call manager client application also includes a aFeature class from which the CMFeature is derived. The CMFeature typically is invoked by the CMApp and provides an application specific functionality within the call manager application such as reporting, alarm management (NEM), graphical data display (GDD), and call by call application.
The browser typically starts the call routing management applet which launches a CMApp by calling its init method. The CMApp sets and displays a main toolbar which may be implemented using a view of a model in a MVC paradigm described above. When a user presses a button on the main toolbar to launch a feature, e.g., NEMS, Rules, etc., the CMAppView derived from the theMainToolbar class creates/activates the selected feature and initializes it. When the CMFeature is instantiated or started, it invokes a method to create a frame, the CMFeatureFrame, in which to run the selected feature.
As described above, the call manager webstation application allows authorized customers to manage their ACD data networks via a web-based interface. Specifically, customers are enabled to provision hierarchies for their business; control all routing of their toll-free traffic; create, modify or delete agent pools; manipulate capacity tables; and define quota schemes, value lists and schedule tables.
As described in reference to
At step 816, the customer is then presented with a call manager webstation application log on dialog, on which the customer enters the call manager webstation log on name and password. In addition, the customer may be presented with a change password dialog. This dialog implements a password expiration design feature supported by the present invention. Generally, for security reasons, a password is valid for a predetermined period of time. After that period, the customer must change to a new password.
In addition, multiple engines may be handled through the web client front-end and translation processing at the back-end. The front-end client application sends a command to retrieve a list of SCP names. The host information is stored at the back-end with the Informix database and, typically an SQL routine retrieves the available SCP. The proxy residing at the back-end returns a list of the available SCP to the front-end web GUI client application. The proxy generally maintains a “routing engine” list having SCP names and their IP addresses. Maintaining the list of routing engine names on the proxy allows for easy modification of routing engine names and IP addresses with no impact to the client code.
When the first-end web GUI client application receives the list, a list of routing engine names may be displayed in a drop-down list for the customer to select, or the customer may be prompted for the SCP desired. The selected routing engine name is sent along with a log in transaction having user name/password to the back-end, when the customer clicks a “log in” button from the log in dialog. The “establish-session” command is then sent to the back-end where the proxy may open a connection to that routing engine. The proxy maps the SCP name to the appropriate IP address and forwards the user log in request to the routing engine. The SCP id selected at log in is populated in the toolbar at the client webstation.
Referring back to
More specifically, by selecting the option at step 826, to manage a user and business hierarchy, via, e.g., the security button 882 (
By selecting the call by call application at step 830, for example, by clicking on an icon labeled “Provisioning” (
At step 832f, customers may specify and maintain call routing quotas for destinations. At step 832g, the customer is enabled to provision called numbers. For example, the customer creates a rule set associated with the called number. The rule set typically determines the location of the caller and selects the appropriate destination number for the nearest warehouse. At step 832h, the customer may provision value lists which are sets of related numeric values. They are typically used in rule sets to test the attributes of an incoming call to determine a characteristic of the call or caller. An attribute of the call (such as the ANI) is tested against a value list. If the value of the call structure matches an entry in the value list, then other rules are executed based on this logical condition. This feature is highly useful for non-English-speaking callers. At step 832i, the customer may provision translation tables. The translation tables include a highly flexible mechanism for performing a table lookup and returning a value that corresponds with the search argument. At steps 832j and 832k, the customers may maintain user variables such as setting up names for peg counters and rule variables and routing instructions.
By selecting the alarm manager option at step 834, for example, by clicking on an icon labeled “NEMS” (
Referring back to
Additional ACD statistical data which may be viewed and monitored via the tool bar (
Selecting the graphic data display option at step 842, for example, by clicking on an icon labeled “GDD” (
Selecting the service contact option at step 833, for example, by clicking on an icon labeled “Cust Service” (
The rules feature (
For enabling a rule writer to test a rule set, the rules feature provides a rules debugger/tester functionality which runs a rule set against a set of test data, i.e., call context, simulating call scenarios in which to test a rule set logic. This optional facility allows rule writers to check if their rule set exhibits the expected behavior, for example, before installing the rule set on the network. Moreover, because this test feature is purely optional, a rule writer need not run the rule testing functionality before the rule is installed.
When a customer, e.g., a rule writer, selects the debugger/tester feature option, a rules testing dialog appears. Via this dialog, a user may define a call context parameters for simulating call scenarios in which to test a rule set logic. The basic call context includes called-number, ANI, CED, carrier, date and time of the call. Optionally, the user may also modify the different parameters of destinations and quotas that may affect the load balancing.
In addition, an option to allow the database to be updated during the simulation is also provided. During the testing process, the customer may step through the simulation one line at a time or choose a “Run” command to run through the entire call all at once. Furthermore, during the simulation, the customer may select from various view tabs to view, including, a log view, a destination status view, a destination details view, a CDR view and a user variable view.
For executing the testing process, the debugger/tester uses the MML interface to the routing engine, i.e., the debugger/tester formulates the user actions to one or more MML commands and sends the translated command to the SCP. The SCP typically stores the state of testing (including the different views of the log), and manages the test execution.
Typically, a system status display 960 shown in
When the dialog first opens, an “ACT-DSP” message is sent to let the routing engine know that the user is ready to start receiving system status messages. An example of an MML message sent includes:
In order to limit the amount of message traffic having to be sent to and from the client, data for these messages may be included into one message, “get-sys-stat.” Preferably, the SCP sends the get-sys-stat message every 5 seconds. Each get-sys-stat is typically preceded by an “ru-alive” message that forces the back-end to read the socket for the latest date. When the user chooses to close the dialog, the messages are stopped by sending a canc-dsp message. An example of a canc-dsp message is shown below.
The system status display messages are automatically sent from the SCP, once the messages are turned on. The back-end typically stores this type of message received from the SCP until the client queries for it. System status messages are generally stored in the following tables:
stat_appl for REPT STAT appl messages,
stat_link for REPT STAT link messages,
stat_net for REPT STAT net messages,
and
stat_sysstat for REPT STAT sysstat messages.
A unique set of data is stored for each user currently performing a system status display. Subsequent messages received from the SCP typically overwrite previous data. For example, if the backend receives two (2) REPT STAT net messages before the client queries for the first, the second overwrites the first.
A user may select to perform host administrations by selecting the appropriate icon from the main tool bar (
For backing up server database to either a tape or a disk, a user may select a “Backup” option from the administration button menu and invoke the backup functionality. The client GUI application sends a “RTRV-BK-STATUS” message to check the status of the back-end. If a return message is not “INPROGRESS”, a dialog box is opened for enabling the user to select the backup medium, i.e., tape, or disk. When the user selects a tape or disk option and clicks the start button, a “START-BACKUP” message is sent to the back-end. Subsequently, “RTRV-BK-STATUS” messages are sent every 5 seconds to retrieve the current status of the backup processing. The timer continues to increment every second, and the progress bar is continuously updated until the return message “DONE” is received. On the other hand, if the “START-BACKUP” message fails, an appropriate error dialog id displayed.
In addition, once the backup progress starts, the close button's text changes to “Cancel.” Clicking the close or the cancel button while a backup is in progress prompts the user to cancel that backup. If the user selects yes, a CANC-BACKUP message is sent. Clicking the close button when a backup is not in progress closes the dialog box.
The ACD gateway administration provides the users the ability to view, create, delete and edit ACD gateways. The ACD collector administration function provides the user with the ability to view, create, delete and edit ACD collectors. When this option is selected, a dialog 980 shown in
The FMS gateway administration and the FMS collector administration options provide the ability to view, create, delete and edit FMS gateways and collectors, respectively. The FMS administration dialogs share the same dialog box with the above described ACD gateway and collector administration functionalities. The same messages, i.e., the “rtrv-acd-type”, and the “rtrv-acd-status”, are sent to the back-end but with different parameter types, e.g., “FSM” or “ACD.”
The present invention supports a branding functionality which allows users to open the call manager webstation application in a company specific context.
The present invention includes an internationalization feature, supporting local languages for text displays. This optional feature allows a user to open the call manager application in a language as set by the user. Subsequent texts and phrases are rendered in the language chosen. Typically, the call manager webstation application is opened with a default language as set by the operating system. The user is also given an option to select a language other than the default. A call manager applet typically determines the locale set for the operating system and launches the appropriate language version by including the locale as a parameter. For example, the parameter with a name “locale” may have one of the following values: “en_US” for English US, “en_CA” for English-Canada, and “fr_CA” for French Canada. The applet uses this value to set the locale for the system string and phrase resources.
CMResource handles the general resources of character encoding, numeric formatting and date formatting.
A resource bundle is typically loaded when a request is received. The static method COAppResource.getAppResource loads the bundle for a specific locale. CMResource provides the methods getStringResource and getMessageResource for delegating to the COAppResource bundle to retrieve the translated string or message. If a locale has not been set, the locale defaults to United States.
The COAppResource class generally handles retrieving static strings and/or constructing messages. The static method getAppResource( ) returns an application specific internationalization resource and is used by CMResource to instantiate the resource bundles for each functional area. The methods getStringResource and getMessageResource delegate to the resource specific CMXXXStrings or CMXXXPhrases for string or message lookup.
AppResource+“Strings”+“−”+language+“_”+country, where the AppResource is the name of the application resource, language is the language being translated, and the country uses predefined tags for country labels, e.g., US=United States.
An AppResource typically exists for each functional area within the webstation. In addition, there is a global list of resources that are common to many of the functional areas. For example, strings such as “OK”, “Cancel” which are used throughout the GUI, are typically placed in the global list. The class naming convention is “CMXXXStrings” 1044, where “XXX” represents the functional area, such as rules, GDD, NEMS and so on. In the case of the global string resources, this class is named CMAppStrings, in reference to the main class webstation.cmco.CMApp
Because translation of phrases generally may require more than one-to-one mappings of words, a different methodology is used.
While the invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention.
The present application is a continuation of U.S. patent application No. 09/159,506, filed Sep. 24, 1998, now U.S. Pat. No. 6,611,498, which claims the benefit of U.S. Provisional Patent Application No. 60/060,655, filed Sep. 26, 1997.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4160129 | Peyser et al. | Jul 1979 | A |
| 4345315 | Cadotte et al. | Aug 1982 | A |
| 4817050 | Komatsu et al. | Mar 1989 | A |
| 4823373 | Takahashi et al. | Apr 1989 | A |
| 4893248 | Pitts et al. | Jan 1990 | A |
| 4972504 | Daniel, Jr. et al. | Nov 1990 | A |
| 5041972 | Frost | Aug 1991 | A |
| 5075771 | Hashimoto | Dec 1991 | A |
| 5088052 | Spielman et al. | Feb 1992 | A |
| 5131020 | Liebesny et al. | Jul 1992 | A |
| 5136707 | Block et al. | Aug 1992 | A |
| 5208908 | Harrison et al. | May 1993 | A |
| 5223699 | Flynn et al. | Jun 1993 | A |
| 5228076 | Hopner et al. | Jul 1993 | A |
| 5245533 | Marshall | Sep 1993 | A |
| 5262760 | Iwamura et al. | Nov 1993 | A |
| 5285494 | Sprecher et al. | Feb 1994 | A |
| 5313598 | Yamakawa | May 1994 | A |
| 5315093 | Stewart | May 1994 | A |
| 5327486 | Wolff et al. | Jul 1994 | A |
| 5361259 | Hunt et al. | Nov 1994 | A |
| 5369571 | Metts | Nov 1994 | A |
| 5452446 | Johnson | Sep 1995 | A |
| 5490060 | Malec et al. | Feb 1996 | A |
| 5506893 | Buscher et al. | Apr 1996 | A |
| 5526257 | Lerner | Jun 1996 | A |
| 5533108 | Harris et al. | Jul 1996 | A |
| 5537611 | Rajagopal et al. | Jul 1996 | A |
| 5539734 | Burwell et al. | Jul 1996 | A |
| 5551025 | O'Reilly et al. | Aug 1996 | A |
| 5555290 | McLeod et al. | Sep 1996 | A |
| 5557668 | Brady | Sep 1996 | A |
| 5563805 | Arbuckle et al. | Oct 1996 | A |
| 5566351 | Crittenden et al. | Oct 1996 | A |
| 5586260 | Hu | Dec 1996 | A |
| 5602918 | Chen et al. | Feb 1997 | A |
| 5610915 | Elliott et al. | Mar 1997 | A |
| 5630066 | Gosling | May 1997 | A |
| 5650994 | Daley | Jul 1997 | A |
| 5659601 | Cheslog | Aug 1997 | A |
| 5694546 | Reisman | Dec 1997 | A |
| 5699528 | Hogan | Dec 1997 | A |
| 5710882 | Svennevik et al. | Jan 1998 | A |
| 5742763 | Jones | Apr 1998 | A |
| 5757900 | Nagel et al. | May 1998 | A |
| 5774660 | Brendel et al. | Jun 1998 | A |
| 5774670 | Montulli | Jun 1998 | A |
| 5787412 | Bosch et al. | Jul 1998 | A |
| 5790797 | Shimada et al. | Aug 1998 | A |
| 5790809 | Holmes | Aug 1998 | A |
| 5812750 | Dev et al. | Sep 1998 | A |
| 5825769 | O'Reilly et al. | Oct 1998 | A |
| 5825890 | Elgamal et al. | Oct 1998 | A |
| 5832519 | Bowen et al. | Nov 1998 | A |
| 5848233 | Radia et al. | Dec 1998 | A |
| 5848396 | Gerace | Dec 1998 | A |
| 5848399 | Burke | Dec 1998 | A |
| 5867495 | Elliott et al. | Feb 1999 | A |
| 5870558 | Branton, Jr. et al. | Feb 1999 | A |
| 5875236 | Jankowitz et al. | Feb 1999 | A |
| 5875296 | Shi et al. | Feb 1999 | A |
| 5877759 | Bauer | Mar 1999 | A |
| 5881237 | Schwaller et al. | Mar 1999 | A |
| 5883948 | Dunn | Mar 1999 | A |
| 5884032 | Bateman et al. | Mar 1999 | A |
| 5884312 | Dustan et al. | Mar 1999 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5907681 | Bates et al. | May 1999 | A |
| 5909679 | Hall | Jun 1999 | A |
| 5909682 | Cowan et al. | Jun 1999 | A |
| 5915001 | Uppaluru | Jun 1999 | A |
| 5920542 | Henderson | Jul 1999 | A |
| 5923016 | Fredregill et al. | Jul 1999 | A |
| 5923756 | Shambroom | Jul 1999 | A |
| 5930764 | Melchione et al. | Jul 1999 | A |
| 5930804 | Yu et al. | Jul 1999 | A |
| 5933142 | LaStrange et al. | Aug 1999 | A |
| 5937165 | Schwaller et al. | Aug 1999 | A |
| 5938729 | Cote et al. | Aug 1999 | A |
| 5949976 | Chappelle | Sep 1999 | A |
| 5953389 | Pruett et al. | Sep 1999 | A |
| 5956714 | Condon | Sep 1999 | A |
| 5958016 | Chang et al. | Sep 1999 | A |
| 5960411 | Hartman et al. | Sep 1999 | A |
| 5961602 | Thompson et al. | Oct 1999 | A |
| 5963925 | Kolling et al. | Oct 1999 | A |
| 5966695 | Melchione et al. | Oct 1999 | A |
| 5970467 | Alavi | Oct 1999 | A |
| 5974396 | Anderson et al. | Oct 1999 | A |
| 5974441 | Rogers et al. | Oct 1999 | A |
| 5982864 | Jagadish et al. | Nov 1999 | A |
| 5982891 | Ginter et al. | Nov 1999 | A |
| 5983350 | Minear et al. | Nov 1999 | A |
| 5987134 | Shin et al. | Nov 1999 | A |
| 5987523 | Hind et al. | Nov 1999 | A |
| 5991733 | Aleia et al. | Nov 1999 | A |
| 5991746 | Wang | Nov 1999 | A |
| 5991806 | McHann, Jr. | Nov 1999 | A |
| 5995948 | Whitford et al. | Nov 1999 | A |
| 5999525 | Krishnaswamy et al. | Dec 1999 | A |
| 5999965 | Kelly | Dec 1999 | A |
| 5999972 | Gish | Dec 1999 | A |
| 5999973 | Glitho et al. | Dec 1999 | A |
| 6003079 | Friedrich et al. | Dec 1999 | A |
| 6006265 | Rangan et al. | Dec 1999 | A |
| 6011844 | Uppaluru et al. | Jan 2000 | A |
| 6012090 | Chung et al. | Jan 2000 | A |
| 6014647 | Nizzari et al. | Jan 2000 | A |
| 6014702 | King et al. | Jan 2000 | A |
| 6018768 | Ullman et al. | Jan 2000 | A |
| 6021409 | Burrows | Feb 2000 | A |
| 6023762 | Dean et al. | Feb 2000 | A |
| 6029182 | Nehab et al. | Feb 2000 | A |
| 6031904 | An et al. | Feb 2000 | A |
| 6032132 | Nelson | Feb 2000 | A |
| 6032184 | Cogger et al. | Feb 2000 | A |
| 6041325 | Shah et al. | Mar 2000 | A |
| 6041357 | Kunzelman et al. | Mar 2000 | A |
| 6044144 | Becker et al. | Mar 2000 | A |
| 6044362 | Neely | Mar 2000 | A |
| 6049602 | Foladare et al. | Apr 2000 | A |
| 6049786 | Smorodinsky | Apr 2000 | A |
| 6052450 | Allison et al. | Apr 2000 | A |
| 6058170 | Jagadish et al. | May 2000 | A |
| 6058381 | Nelson | May 2000 | A |
| 6064667 | Gisby et al. | May 2000 | A |
| 6065059 | Shieh et al. | May 2000 | A |
| 6065116 | Isaacson et al. | May 2000 | A |
| 6072493 | Driskell et al. | Jun 2000 | A |
| 6073105 | Sutcliffe et al. | Jun 2000 | A |
| 6073122 | Wool | Jun 2000 | A |
| 6073241 | Rosenberg et al. | Jun 2000 | A |
| 6078891 | Riordan et al. | Jun 2000 | A |
| 6078924 | Ainsbury et al. | Jun 2000 | A |
| 6084953 | Bardenheuer et al. | Jul 2000 | A |
| 6085171 | Leonard | Jul 2000 | A |
| 6085190 | Sakata | Jul 2000 | A |
| 6088451 | He et al. | Jul 2000 | A |
| 6088796 | Cianfrocca et al. | Jul 2000 | A |
| 6091808 | Wood et al. | Jul 2000 | A |
| 6094655 | Rogers et al. | Jul 2000 | A |
| 6104704 | Buhler et al. | Aug 2000 | A |
| 6104716 | Crichton et al. | Aug 2000 | A |
| 6105131 | Carroll | Aug 2000 | A |
| 6108700 | Maccobee et al. | Aug 2000 | A |
| 6108782 | Fletcher et al. | Aug 2000 | A |
| 6112238 | Boyd et al. | Aug 2000 | A |
| 6112242 | Jois et al. | Aug 2000 | A |
| 6115040 | Bladow et al. | Sep 2000 | A |
| 6115458 | Taskett | Sep 2000 | A |
| 6115693 | McDonough et al. | Sep 2000 | A |
| 6115737 | Ely et al. | Sep 2000 | A |
| 6118780 | Dunn et al. | Sep 2000 | A |
| 6119109 | Muratani et al. | Sep 2000 | A |
| 6122258 | Brown | Sep 2000 | A |
| 6130933 | Miloslavsky | Oct 2000 | A |
| 6131095 | Low et al. | Oct 2000 | A |
| 6131116 | Riggins et al. | Oct 2000 | A |
| 6134584 | Chang et al. | Oct 2000 | A |
| 6144727 | Mashinsky | Nov 2000 | A |
| 6145001 | Scholl et al. | Nov 2000 | A |
| 6154744 | Kenner et al. | Nov 2000 | A |
| 6161102 | Yanagihara et al. | Dec 2000 | A |
| 6161126 | Wies et al. | Dec 2000 | A |
| 6161128 | Smyk | Dec 2000 | A |
| 6163597 | Voit | Dec 2000 | A |
| 6173311 | Hassett et al. | Jan 2001 | B1 |
| 6182113 | Narayanaswami | Jan 2001 | B1 |
| 6205456 | Nakao | Mar 2001 | B1 |
| 6212506 | Shah et al. | Apr 2001 | B1 |
| 6212546 | Starkovich et al. | Apr 2001 | B1 |
| 6212558 | Antur et al. | Apr 2001 | B1 |
| 6240450 | Sharples et al. | May 2001 | B1 |
| 6275490 | Mattaway et al. | Aug 2001 | B1 |
| 6282281 | Low | Aug 2001 | B1 |
| 6286050 | Pullen et al. | Sep 2001 | B1 |
| 6292481 | Voit et al. | Sep 2001 | B1 |
| 6295551 | Roberts et al. | Sep 2001 | B1 |
| 6337858 | Petty et al. | Jan 2002 | B1 |
| 6377993 | Brandt et al. | Apr 2002 | B1 |
| 6715080 | Starkovich et al. | Mar 2004 | B1 |
| 6760844 | McCarthy et al. | Jul 2004 | B1 |
| 6782425 | Germscheid et al. | Aug 2004 | B1 |
| 20010001014 | Akins, III et al. | May 2001 | A1 |
| 20010003828 | Peterson et al. | Jun 2001 | A1 |
| 20040139178 | Mendez et al. | Jul 2004 | A1 |
| Number | Date | Country |
|---|---|---|
| 0 747 841 | Dec 1996 | EP |
| 0 809 387 | May 1997 | EP |
| 09064870 | Mar 1997 | JP |
| WO9711443 | Mar 1997 | WO |
| 9718515 | May 1997 | WO |
| WO 9723988 | Jul 1997 | WO |
| WO 9819472 | May 1998 | WO |
| WO 9901826 | Jan 1999 | WO |
| 0011573 | Mar 2000 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20020054587 A1 | May 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60060655 | Sep 1997 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09159506 | Sep 1998 | US |
| Child | 09945589 | US |
