MXPA01012024A - Enterprise contact server with enhanced routing features. - Google Patents

Abstract

The present invention is an Enterprise Contact Server (100) that enables customers to submit call-back requests to agents (13) located at any one of a plurality of call centers (116) via the Internet (32), or virtually any other communications technology available.

Description

COMPANY CONTACT SERVER WITH IMPROVED ROUTE FEATURES The present invention relates to data communications, and more particularly, to a call center communications system of customers to the company in the telecommunications industry. In the telecommunications industry, call centers are used to provide customer and operator services for business customers. Traditionally, customers of these customer businesses make a phone call to a toll-free number to communicate with a customer service agent in a call center. Then they are served by telephone. Frequently, due to the limited number of agents in the call center and the large number of calls, the customer's call is placed in a queue until the agent is available. Many customers in the telecommunications industry interact with the Internet and the World Wide Web, and use the Web for a variety of business services. This presents a business opportunity to interact with clients who are familiar with the search in the network, presenting the client with a website and an opportunity to interact with the company. ~ telecommunications However, the World Wide Web is not an interactive medium, and it is mainly composed of many static HTML pages in any given Web site. Customers who search the web site may need to speak with a customer service agent, either regarding the web site and the information posted there, or with respect to other transactions with the telecommunications company. Many companies, including telecommunications companies, maintain call centers to interact with their customers. These call centers can provide employees for the introduction of orders for new orders, billing services to solve problems with invoices, shipments or returns, technical support, and problem vouchers for customers who have a large volume of transactions with the company. However, given the volume of customer calls, and the company's resources available to answer calls, most calls to the call center are put on hold by an automated call manager ("ACD") , and the initial interaction of the client is with an interactive voice response unit ("VRU"), which primarily aims to direct the call to the appropriate agent, and is not programmed to answer customer questions. This frequently leads to A .1 _l-U.-ft _! ____._ "& _ * - • - • - ****. ItilBi 1 Miiim i? R? i Mmmm? mm ^^^^^ ^ ^^ tMá ^ angry customers who are unable to resolve their doubts in a timely manner. The only means currently available to contact an agent of a call center of a company and not be put on hold, is to make a phone call and submit a request for a call back via the phone, or send a request by email to the "network master" of the network site. Current network services do not allow response calls to requests that are presented by the network or by other interactive means. The present invention is directed to a call routing system for a Network / company that allows the routing of messages, calls and data between call centers distributed throughout a Network / company. The call routing system for a Network / company in particular invokes a method for locating and reserving trained agents in one of a plurality of remote centers before initiating a call transfer or conference. The routing of messages, calls and data between call centers distributed throughout the Network / company is particularly enabled by implementing routing algorithms based on the agent's skills, agent availability, workflow states, and load balance to determine the path of the route. The routing system of Calls can be easily integrated with existing ACDs, as well as email, voice / video over the Internet protocol, the H.323 security gateway / gate, URL push services, and other distributed communication systems. Particularly, the present invention is directed to improvements in the architecture of the telecommunication call centers described in co-pending United States Patent Application Serial No. 08 / 976,162 assigned to the assignee of the present invention, and incorporated by reference herein. In the architecture of telecommunication call centers, a Company Contact Server is provided that allows enterprise-level processing and routing of both contact requests and incoming calls that originate from any source of communications, for example, standard PSTN telephony, Internet protocol telephony, the Web, and other HTTP media. "Enterprise level processing and routing" means that agents of any of a plurality of call centers that have a contact center server, can receive a contact request from a customer, and satisfy that request by placing a contact with the customer. client. A single means to make contact requests, such as a web page link or a telephone number, can be used to i «-l-U -..._-. __AtA__. fc - .. ^ | make contact requests that are supported by a plurality in call centers. In particular, each Company Contact Server performs the following functions: 1) it communicates with each 5 Call Center Contact Server; and, 2) tracks the states and availabilities of resources (e.g., agents) in each of a plurality of call centers. Specifically, each Central Contact Server sends event messages to the Company Contact Server 10 to continuously update the Company Contact Server with the current status and availability data. When a contact request is received, the Company Contact Server determines and selects a qualified agent available among the agents in the plurality of 15 call centers, and then send the contact request to the Center Contact Server that supports the selected agent. Advantageously, the present invention can also be used to route incoming calls, i.e. 20 those calls made to a call center via the PSTN, the Internet or another telephony network with Internet protocol, or virtually any means of communications, throughout the network, with the same system architecture used when processing and routing contact requests. This is, 25 contact requests are treated as calls from input, and the same system architecture, including the Enterprise Contact Server and plurality of Call Center Contact Servers, is used to process and route both. Figure 1 is a diagrammatic illustration of a logical communications network architecture that implements the enterprise contact server of the present invention. Figure 2 is a diagrammatic illustration of a physical network architecture, illustrating a possible implementation of the logical architecture of Figure 1. Figures 3 (a) - 3 (c) together comprise a flow diagram illustrating a process for perform a company-level routing of a contact request using the Company Contact Server of the invention. Figures 4 (a) - 4 (b) illustrate the process for making, processing, and routing incoming calls via the PSTN, or other similar means of communication to make an incoming call. Figure 5 is a diagrammatic illustration of the Business Contact Server of the present invention and the components with which it interacts. Figure 6 (a) illustrates an exemplary architecture of a "Click-n-Connect" system of enterprise 440. Figure 7 is a representative illustration of an HTML web page sample that allows a callback request. The jointly owned and co-pending US Patent Application No. 08 / 976,162 describes a computer system called a Contact Server, integrated with a novel telecommunications systems architecture, which allows customers to make requests. Contact a call center through any means of communication available, including the Internet, and receive contacts from an agent by any means of communication available. For the reason that requests can be made by different means via a telephone network, these applications are hereby interchangeably known as "contact requests" or "call back requests". For example, the described methodology captures contacts through an agent other than a call, instead a contact such as an HTTP session, for example. The Contact Server described in United States Patent No. 08 / 976,162 is used to provide "contact services" for customers separately from, in addition to and in conjunction with, any callback services provided by ACD and VRU. . The Contact Server can also receive contact requests directly from clients over a protocol network of Internet from a Web server, and distribute requests to qualified agents in agent workstations in the call center. The contact server can also reserve qualified agents for specific types of problems in order to satisfy the callback request. In the manner described in United States Patent No. 08 / 976,162, customers submit call back requests via the Internet, an intranet or other comparable Internet protocol network, and agents must satisfy requests by making calls from departure to customers via the ACD and PSTN. However, the Contact Server is designed to handle callback services in a manner that is independent of the communications network used. These call back services may include other methods for receiving and satisfying call back requests such as Internet voice telephony, Internet video, chat (conversation) or email communications. The call center contact server facilitates communications with other data sources, such as a database server, or other data resources, such as the company's mainframe computer. These data sources include components such as database servers that store and serve M +? ÉAMtMr rlHiá ** - -. **** * »",,.-.--. .., ^ Í ^^^^ data specific to any application and service are provided through the call center. For example, an implementation of the Contact Server and callback service is to improve a service that allows the company's external customers to see any problem voucher over the Internet or the Internet protocol network by accessing a database of problem vouchers. Alternatively, the Contact Server can access the company's multi-user computer system that provides problem voucher services to clients. The present invention is directed to architecture of communication systems that employ a company Contact Server that allows the routing of messages, calls, and data from multiple call centers distributed throughout a network / company. As will be described, the Enterprise Contact Server 100 together with a communications system architecture 101 provides contact services to customers over virtually any communications medium, for example, PSTN and the Internet. To make a contact request or an incoming call, a customer can use the standard telephone connected to the PSTN, a personal computer with Internet protocol telephony application connected to the Internet to make Internet protocol calls, or a computer i .i. i iiiTnr l i ii ti tiii i ^? M ^^ i m ^ m ^? ^? tM personal with a Web search engine to connect to the Web. The Internet is another means of communications for providing contact requests, and for providing contacts such as described in United States Patent No. 08 / 976,162. However, the exception is that contact requests that are collected by the Intranet Web server are sent to the Company Contact Server, rather than to a call center contact server. The figurative diagram of Figure 1 and the corresponding preferred physical architecture diagram of Figure 2 illustrate the communications system architecture 101 employing the Enterprise Contact server 100 of the invention. This communication system architecture 101 and the company contact server 100 provide an improved enterprise-level call contact routing service and request for initial calls from the public Internet 32 or the public telephone switching network 20 to any one of a plurality of call centers lia, llb, ..., Un. As shown in Figure 1, there is illustrated a single call center 10 having the following components: 1) an Automatic Call Distributor 12 ("ACD") that provides a telephony communication element that connects to a public network telephone switching ("PSTN") 20 via voice trunks 22 for incoming and outgoing telephone calls, queues, queuing, and distributing incoming calls between the plurality of agents; 2) a Call Center Contact Server 28 that supports resources (e.g., agents) in the call center in the manner as described in the co-pending U.S. Patent Application, number 08 / 976,162; 3) one or more agent work stations 14 that include a personal computer (PC) that executes customer-adapted communications and software and searcher capable of receiving call data from Contact Server 28, and connects to the Internet to Internet protocol telephony sessions and collaborative HTTP sessions on the web; 4) one or more sets of agents 13 used for telephone calls on the PSTN20 via the ACD 12; 5) a computer / telephony interface server ("CTI") 18, such as the "TServer" product offered by Genesys Corporation, which is connected to a CTI port of ACD 12 via link 26 and which provides event data received in the ACD to computers such as the agent workstations, VRU, and the Call Center Contact Server 28; and 6) a LAN 11 local area network (corresponding to the so-called "Call Center A") that provides data connectivity between the different call center components 10. Data interferences to the ACD are provided by the CTI server. Additionally, associated with call center 10 is a Enterprise Voice Response Unit ("VRU") 16 that executes specialized interactive voice response ("IVR") applications to provide automated client and operator services for callers. As shown in Figure 1, the VRU 16 has a separate voice link 24 to the PSTN 20 to allow direct connection to the local area network of the call center lia to send call data to the Center Contact Server 28 In this configuration, any call received on the PSTN 20 can be routed to any ACD to any call center. Although Figure 1 represents a Company VRU 16 associated with a single call center, it is understood that a Company VRU can be used for the plurality of other call centers. If the architecture is such that Enterprise VRU is located with each call center, then the Enterprise VRU is directly connected to the local area network of the call center; otherwise, a wide area network (WAN) can be used. In addition, a database server 34 is provided that represents and encompasses all databases related to the contact or callback service at the local call center level that includes: callback in which callback requests are stored and put into queues, agent status tables, and agent skill tables at the call center level. As shown in Figure 1, each local area network of the respective call center lia, llb, ..., lln is connected by a respective wide area network 34a, 34b, ..., 34n with an area network Local Centralized Data Center 31 to allow data transactions with the Enterprise Contact Server 100 of the invention. As a consequence, each Enterprise VRU 16 is also connected to the Data Center 31 via the wide area network. The modality shown in Figure 1 in which there is a VRU of Company 16 per call center, a call to a VRU of Private Company 16 can be routed to any call center to reach a qualified agent available via the local area network of the data center 31. In the preferred embodiment, the Enterprise Contact Server 100 is specialized software executed on a computer to allow enterprise-level routing of contact requests, so that agents in a plurality of call centers can meet customer contact requests from a single source (for example, web page) or to a single telephone number. According to the invention, each Server of ¿?, ** U HÍt? -M »L¡. ^ A ^. ^. 1 - .- - * - * - - ^ - ^" ^^. *., ^^ - s? ..

Center Contact 28 constantly sends event messages to the Enterprise Contact Server 100 these event messages are used by the Enterprise Contact Server 100 to track the current status and availability of each resource (agent) through the company. As shown in Figures 2 and 3, the Business Contact Server 100 is connected to a database 134 which includes: skill tables that identify the particular skill profile of each agent; and state tables that identify the current status of each agent. When a contact request is placed by a customer, it is sent to the Business Contact Server 100 which first investigates its skill tables to determine a qualified agent. When a qualified agent is found, the Enterprise Contact Server 100 then queries the status tables with the identified qualified agent to determine if that agent is currently available. If the qualified agent is not available, the Business Contact Server finds another qualified agent. It then sends the contact request data to the appropriate center Contact Server 28 that supports the call center in which the selected agent is located. Preferably, standard mid-range computers, such as the DEC Alpha 4100 or 8400 servers, can be used for the Enterprise Contact Server 100, the Database Server 134, as well as the Intranet Web Server 130, Firewall Server 140, and other data sources 136 to be described. To enable enhanced enterprise-level routing functionality, the communications system architecture 101 is also provided with a Enterprise Router 105 that functions as an intelligent call router ("ICR") which is a computer application that provides routing intelligent input calls, for example, in the manner described in commonly assigned, co-pending, United States Patent Application No. 08 / 796,840. Particularly, Enterprise Router 105 receives call routing requests, i.e., data messages, generated by an incoming call received in a PSTN switch, and processes the request to determine when to route the call. Based on the real-time status and availability data received by call centers, the ICR selects a qualified available destination (eg, agent) to which to route the call. In the preferred embodiment, Enterprise Router 105 is an application distinct from the Enterprise Contact Server, as shown in Figure 2 and is encompassed as a separate software application and database residing on another computer (different from the Business Contact Server 100). In this modality, the ld * * ^ * IMMIHi "__ ^^ * ,,, *.» * »* ~ ***? ***» **? ^ - "" *** ,, ..... tJ_ ,. " ^ __. _u _ ,, t._ _u Business Contact Server connects to the Business Router via an API 110 to allow the use of different types and offers of vendors from a Business Router, Alternatively, the Business Router 105 it can be a different software application and database that resides on the same computer as the Business Contact Server or, it can be integrated with the Business Contact Server application as a process or subsystem. Enterprise 105 provides enhanced functionality by allowing a call to be routed first to a VRU using only the DAP routing all calls for a single number to the VRU In the VRU an IVR application collects caller information that is used by the enterprise router to further solve the routing, in this way, a company can use the same telephone number for multiple services and differs from the prior art implementations in which calls are routed first by an ICR based solely on the data generated by the call, for example, DNI5, ANI, time of day, day of the week, etc., and where the call is only sent to the VRU if it needs to be queued. As further shown in Figure 2, a Web Server / Intranet 130 is also provided to support each of the business web sites, along with Java applications for use with the present invention.

As described herein, at least one * process is provided, encompassed by a Java application on the web server, which receives contact requests submitted by a client on the web and sends these contact requests to the Business Contact Server 100 for processing. The Firewall server 140 is a collection of components comprising a Data Management Zone ("DMZ") that provides an assured interface to the local area network of the data center 31 for public Internet users. It has an identical Web / Intranet Server process running on it; and it is from that Web Server (over the Firewall Server 140) that the Java applets are loaded into the client's personal computer and the web browser 42. Identical Java applets are loaded into agent workstations 140 from the Web Server 130 A Network CTI Server (such as the Genesys Network TServer) 118 is similar to the CTI server in call center 18, except that its application extends to the enterprise level. As shown in Figure 1, unlike the CTI server in the call center 18, the CTI server in the network 118 receives call routing requests from the data access point 125 ("DAP") via a remote access component. port interface 800 130 and distributes these requests among a plurality of call center CTI servers. The port component 800 130 particularly provides a data interface to the DAP for external call processing systems as described in co-pending US Patent Application No. 08 / 796,246, the content and description of which is incorporated by reference as fully presented herein. More particularly, for routing entry calls, the PSTN uses the DAP 125 which provides basic call routing for special service numbers. When a PSTN switch receives a call, a service request message is issued to the DAP which processes the DAP to determine a destination to which to route the call. Typically, the number is based on at least the dialed number and other data, for example, ANI, time of day, day of the week, etc. The business router 105, which is a form of an ICR, provides for improved call routing based on real-time data received from call centers. The data center 31 is a local area network that provides data connectivity between the web server 130 and the Internet 32 (via the DMZ), the Business Contact Server 100, the CTI Server of Network 118, and the plurality of call centers "a" - "n". Specifically, the data center local area network 31 is connected to each call center lia, llb, ..., lln by the wide area networks of respective call centers 34a, 34b, ..., 34n to provide a physical inferióase between the Server of Contact of Companies 100 and each contact center server 28. Figure 2 illustrates a possible physical implementation of the logical architecture of Figure 1 having a first Ethernet local area network lia 6 a second Ethernet local area network 31 providing connectivity data between the various computer components of the call center 10 described with respect to Figure 1. The intranet server 166 called Web Server 130, supports the website and TCP / IP communications for any service that is being supported by the center of calls, such as the website that allows customers to access a problem-solving database maintained on the database server 37. A client, generically illustrated at 42 in Figures 1 and 2, wishes making use of the invention will usually have a personal computer (PC) 44 which executes personalized communications and search engine software, for example, Microsoft Explorer or Netscape Navigator® or Communicator® for Internet protocol communications, and a telephone 46. Each agent workstation 14 also runs a web browser for Internet protocol communications, and such customer service workflow software. as ClarifyCO, to provide customer services. You can use Java applets in the practice of i1-.i-fc-ti., j._fe_ai. «M -.- Í-J - ,, .., ... ... ^ -._- - ^ .. ¿..? ^ ^^ fa ^ .. JL. ^ -.... A - .. fa_i. jjy invention to support the callback service and the applets and other features that are stored in and can be loaded within the local area network or wide area network of the company from the web server 130. As mentioned, it is from the firewall server 140 that it has a process web server that loads the Java applets to the personal computer of the client 44 and to the web browser. Identical Java applets are loaded in the agent workstations 14 from the web server 130 running on the Intranet. As mentioned, the company contact server 100, together with the communications system architecture 101 of Figure 1: supports additional communication means Internet protocol telephony, HTTP sessions, etc .; allows the use of the same platform for contact requests and incoming calls; and, allows the use of a single telephone number for multiple services by enabling the data access point ("DAP") to route all calls for a single number to a VRU that implements an IVR application to collect caller information which is You can use it to further solve the call routing. These scenarios are exemplified in the flow diagrams represented in Figures 3 (a) -3 (c) and 4 (a) -4 (b). Figures 3 (a) -3 (c) together comprise a diagram -U, i¿J-t - *, i__ÍI * ___ .. ** »* > ". ^^^ .__..., _ .. ^^. ^^ m ^. ^ ^. ^ .. ^ ..? M" .J k? . < of flow that illustrates a process to perform enterprise-level routing of a contact request using the Enterprise Contact Server. This shows a specific embodiment of the present invention, in which the callback service is implemented for a secured website that requires user authentication. In the company, the Business Contact Server will be used with a website that runs an application that allows customers to access the company's problem-solving system and view the status of their tickets. Therefore, each client has a user profile established in the profile database on the Database Server. It is from this database that the skill designators are obtained. A similar type of callback service can be implemented with the Business Contact Server for other applications, not all of which require login. Additionally, the Business Contact Server can be used to accept call back requests from sources other than the Internet. As shown in Figure 3 (a), in step 210, a customer registers on the website. The network server authenticates the user's identification of the client and its password against the client's user profile, which is stored in the database on the Database Server. If the client is authenticated, the web server sends the client search engine the HTML file that includes the main page of the web site. Immersed in this file are the Java applets that will be used to establish communications between the agent's workstation and the client's personal computer. Java applets perform other functions, such as providing a dialog box to initiate a contact request in step 210. Web server 130 maintains a session with the client browser over the Internet using cookies or other session maintenance technology. In this way, when the client submits a contact request, the web server can identify this client for the purpose of matching the contact request with a qualified agent. The client can now search the website. In the exemplary modality described, a client operates within a problem assessment system to see the status of their problem assessments. During the course of reviewing problem assessments, the need arises for a customer to communicate with a service repair (call center agent), for example, to raise a question or some other reason. In step 212, the client selects the contact request feature (call back), which is typically an HTML button on the web page. This t-áal-ii-í _. -i la-iiiii i¡ÉÍál-t-_t__l_ÉiÉ --- ^ l _? __ a ___ á-t | ^^ causes a dialog box to be presented to the client to incite him to give his name and his phone number for a return call . The return call telephone number can also include an extension, so if the customer is calling from a PBX and an operator (live or automated) answers the phone on the return call, the call center agent will know the extension needed to reach the customer. Additional information may be requested here as well, such as a customer identifier that can be used as a skill designator to match the call request back to a qualified agent. You can request a time to call back, to establish when the client would like to be called back. The callback time can be entered either as a specific clock time (ie, 3:00 pm this), or as a duration (that is, 20 minutes from now). Without a return call time entered, it is assumed that the customer is requesting a call back as soon as possible. In step 214, when the client makes the selected contact request and has completed the contact request dialog box and presses the entry key, the client finder sends the call request back to the center's web server. calls, Via the Internet as indicated in step 216. In step 218, the web server 130 receives the callback request and sends it to a Business Contact Server via the local area network of the data center 31. In addition of the information provided by the client in step 210, the web server includes in the contact request message that it sends to the company contact server: the client's Internet protocol address, the URL of the web page of which the request for return calls was selected, and the client's customer identifier. The client identifier is obtained from the user's profile of the client when the client registers in 'step 210. In this way, the client's Internet protocol address and URL will be provided to the agent workstation. In step 220, the Business Contact Server interrogates the skills database with the skill designator (i.e., the customer identifier) to find a qualified agent; that is, an agent enlisted with that particular skill designator. The Business Contact Server really identifies all the agents with that ability, so that if one agent is not currently available, another agent can be used. In step 222, the Contact Server consults the state table to find an available agent with the ....... _iaii4.iiii .__ experience level higher than the skill needed. These status tables are constantly updated with data that the Business Contact Server receives in event messages from each Contact Center Server. In step 224, a determination is made as to whether a qualified agent is available. If at step 224 it is determined that a qualified agent is not available, then the Enterprise Contact Server proceeds back to step 222 to consult the state table until a qualified agent is available. Alternatively, a queue / monitoring method can be established comprising the steps of: making the contact request in a call queue back on the database server 134; monitor the request queue for return call and status tables; and determining whether a qualified agent is available to take a call back request in queue, as described in co-pending US Patent Application No. 08 / 976,162. It should be understood that this queue / supervision step may include the step of applying business rules. If in step 224 it is determined that a qualified agent is available, then the Business Contact Server will send the contact request to the contact server of the center 28 of the call center that has the The qualified agent, that is, the call center A, as indicated in step 228. Then, in step 230, Figure 3 (b), the Contact Server sends the contact request. to the workstation of the selected agent 14 via the local area network of the call center, for example, the local area network lia. This request includes all the information entered by the client, as well as the Internet protocol address of the client and the URL of the web page from which the contact request was placed. The work station of the selected agent, when the contact request is received, displays on the screen the contact request in a window that shows the client's name, the number to call back, and perhaps other information entered by the client. The work station of the selected agent then processes the contact request, in a manner as described in copending U.S. Patent Application No. 08 / 976,162. For example, as shown in step 234, Figure 3 (b), this processing may involve: loading a common-port interface ("CGI") from the network server for execution on the agent workstation to launch the agent search engine. In this step, the URL is passed as a parameter to the CGI script which can then be used to build the same web page that the client was on when made the contact request. Referring to Figure 2, the search engine! The agent retrieves the web pages from a web server on the Intranet / Web server 30, while the client retrieves identical web pages from an identical web server on the Firewall server. Then, in step 238, a Java applet is loaded into the agent's browser from the Web Server on the Intranet Server. The client's internet protocol address is passed as a parameter by the CGI script. The agent search engine displays the same Web page as the client search engine. In step 240, the Java applet that was loaded in step 136 establishes and maintains TCP / IP communications between the agent's browser and the client's browser, using the client's Internet protocol address that was included in the client's request. return call sent to the agent workstation, and, in step 242, the contact server 28 sends a message to the CTI server to cause the ACD to place an outgoing call to the number of calls back from the client. As noted in reference to Figures 1 and 2, this can occur in any of several ways and at any of several points in the process. In the preferred embodiment, the Contact Server will send this message at the same time that it sends the contact request to the agent workstation, in step 234. Alternatively, the Contact Server can set a stopwatch in step 234. When the time is up, step 242 is triggered. In step 244 and in response to the message sent by the Contact Server in step 242, the ACD places an outbound call to the number of calls back from the client. The call is placed from the agent's telephone station, so that the agent's telephone line to the ACD is engaged during this process. The client may or may not answer, as determined in step 246. If the client answers, then in step 248a, both telephony sessions and TCP / IP communications proceed between the agent and the client. In step 250, the call is terminated and the client and the agent each hang up. Referring again to step 246, if the client does not answer, then in step 248b, a TCP / IP communication session can still proceed between the client and the agent. In fact, a conversation session on the line can replace a phone call. In step 252, the agent terminates the TCP / IP session.

In step 254, the Contact Server updates the status tables to show that the agent is now available. The Business Contact Server could also select only a call center that had a qualified agent available, without selecting the real agent. _._ LttJÉHfct a_J < , _fc¡fc, ttí sk, * .__ »_ *, * .. ~ ,,. * ..? £ i *? _. JU¡i? * ^^ J ^ át. -.- .- ^ J t ^ a. ^ .. A *? ^ ?, "-ato *. AA MßL i fofa The Company Contact Server will then send the contact request to the contact server of the selected call center, and the Center Contact Server will select it to the real agent. Referring again to Figure 3 (a), in an alternative embodiment, when the Enterprise Contact Server 100 receives a contact request in step 218, you can select a call center that has qualified agents. Other criteria can be used to select one of many call centers with qualified agents, such as a call center with the most qualified agents. The Business Contact Server can then send a status query to the call center contact server for that selected call center. The contact server in center 28 returns a response indicating whether a qualified agent is available. If so, that contact center server receives the contact request. If not, the Business Contact Server selects another call center. As yet another alternative mode, when the Business Contact Server 100 receives the contact request in step 218, it can select all call centers that have qualified agents. The Business Contact Server then sends a status query to the contact centers servers for all centers of calls. The first contact server in the center to return a positive response indicating that a qualified agent is available will receive the contact request. Figures 4 (a) -4 (b) illustrate the process for placing, processing, and routing incoming calls via the PSTN, or other similar communications medium to place an incoming call. In the process described, it is assumed that the received call is a free 1-800 call. As shown in step 310, Figure 4 (a), the customer first places a call to a call center. The call is carried by the PSTN switch which, in response, consults the DAP to determine where to route the call. The DAP performs a call processing application to resolve the routing to a business VRU. If a plurality of enterprise VRUs are used, the routing can be resolved for a single VRU, or up to a single port or groups of ports in a VRU, based on any of several criteria, eg., Dialed number, ANI, time of the day, day of the week, some charge balance, etc. Then, as indicated in step 316, the call is routed through the PSTN to the enterprise VRU, and, as indicated in step 318, an interactive voice response application in the VRU executes cord collecting information about the called . This information is used to determine a suitable destination for the call. As indicated in step 320, the VRU then sends a query message, including information collected from the caller, to the company contact server, which then consults the enterprise router, as indicated in step 322. As mentioned , the enterprise router can be a subsystem integrated with the Business Contact Server, or, preferably, it is a different process that can be executed on the same computer or on a different computer than the Business Contact Server. As indicated in step 324, the enterprise router then determines a suitable destination for the call, based on the necessary services, the agents' abilities, and the availability of agents. A destination can be a call center, a group of agents in a call center, or a particular agent in a call center. In the preferred embodiment, the resolution of a routing to a particular agent is a process that can be distributed between the enterprise router and a center contact server. That is, the routing parameters (used to determine where to send each incoming call or contact request) could be the same either in the company router or in each contact center server, or could be distributed among them. For example, the business router can perform high-level routing (for lúlluLL + ?? djM .. Mfc., you 4U¡t? * M + lt .ítfEaaBtJ.ja ^^ example, only to a call center) based on certain parameters, 'while the contact center 28 server resolves to route to a more detailed level (for example, to a particular agent) based on certain other parameters. For example, the company router could determine the skill set of an agent needed and call the center that has agents with that skill set, and have the call routed to that center. The center contact server in the center then determines a qualified agent available to handle the call. Then, as indicated in step 326, the Enterprise Contact Server returns a response to the VRU comprising the call data provided by the enterprise router. The type of data returned includes, but is not limited to, the following: data to route the call (for example, type of agent skill set needed to handle the call, which call center has this agent available), and data belonging to the caller or service (for example, identification of the payer of accounts, customer account data, options of the call to the selected one). Then, as indicated in step 328, Figure 8 (b), the enterprise VRU joins the data to the call and routes the call to the ACD of the destination of the selected call center. Concurrently, the VRU sends call data to the contact server of the destination call center. It should be understood that steps 322-324 provide a distinct advantage over the prior art in routing incoming calls. Since the VRU collects caller information to determine an appropriate destination for the call, the same telephone number can be used for multiple services. The routing resolution to a particular service is done through the Business Contact Server and the enterprise router, based on the information collected by the VRU, as opposed to first routing a call to its proper destination, based on the processing by the DAP and / or an ICR that is limited only to the information provided in data generated by the call, such as the dialed number and ANI. In this way, a single number can not be used for multiple services. Additionally, in view of Figure 8 (b), in step 332, the ACD receives the call, and in step 334, the ACD sends call data to the CTI server of the call center, which passes the data to the server contact center. It should be understood that these are not data that the VRU sends to the contact server of the center in step 328, but data received with a call on the PSTN, ie, dialed number, ANI, CIC, etc. In a manner as described in co-pending United States Patent Application No. 08 / 976,162, the call center contact server resolves to route to a single destination, that is, a selected agent, as indicated in step 336. The contact center server also reserves that agent, and updates its state tables 5 in accordance with this (to designate the agent as reserved). Finally, as indicated in step 338, the call is routed to the telephone apparatus of the selected agent. At that same moment, the server T sends an established message of event that identifies which agent is 10 sent the call. The Contact Server receives the notification, and in step 338 additionally routes the data that the contact center server received from the VRU (in step 328) for the workstation of the selected agent, which now has all the necessary information 15 to process the request. The contact center server updates its state tables in accordance with this (to designate that the agent is unavailable) as indicated in step 340, and sends an event message to the server d? Companies Contact in step 342 regarding the 20 state of non-availability of the selected agent. Figure 5 illustrates the interfaces of the process with the Enterprise Contact Server 100 within the architecture of the communication system. The fundamental software architecture is similar between the Server of 25 Business Contact 100 and the contact server of the center. The differences are implemented as new API function calls for message formation included within the agent collection module 90, and routing rules, which are incorporated into a configuration file and software code within the event processor and the router module. 95. For example, each time an event is processed by the Contact Server, for example, routing a call to an agent, the Contact Server sends an event message that is routed over a local area network from the call center lia, ..., lln and over the corresponding wide area network 34a, ... 34n to any "client" that has registered to receive this type of message. In particular, the Business Contact Server 100 is registered with the center's contact server for the reception of event messages. In this way, the Business Contact Server can keep track of the current status and capabilities of each call center resource, in order to make company-level routing of contact requests and incoming calls. Additionally, Contact Servers can register with each other to communicate certain messages. Although most of the API function calls between the center's contact servers are the same as those described in the United States Patent Application of North America! joint pending number 08 / 976,162, the formation of messages between each contact center server and the Business Contact Server makes use of additional API function calls. Additionally, since the 'Company Contact Server' rea Liza company routing between the multiple center contact servers, that is, the Business Contact Server sends contact requests to a call center contact server, and the API function calls are added to enable this. Appendix A provides agent / client API tables that list the events, the possible dates of each event, and the actions carried out by the Contact Server and the Server. Business Contact to update the table of previous states. Unlike the call center contact server, the Business Contact Server 100 is capable of routing contact requests to other contact servers by implementing both the routing rules employed by the event processor and the router module 95, as well as the parameters used to perform the routing. For example, in the input call routing scenario described above, in step 324 in Figure 8 (b), the parameters used for routing by the Business Contact Server differs from those used by a contact center server . Depending on an implementation Specifies, the Business Contact Server can route a contact request or call to a call center only, to a group of agents in a call center, or to a specific agent in a call center. The contact center server can ensure that the routing is resolved all the way to a specific agent, so that it picks up when the company contact server leaves it. Even in an example case when the Enterprise Contact Server 100 routes to a specific agent, that is, step 324 (Figure 4 (a)), the contact server of the center is still consulted by the ACD (via the TServer ) in step 334 under Figure 4 (b). This is because the center contact server knows which agent the call is to be routed based on information received in step 328, Figure 4 (b) which the ACD does not know. The center contact server is the one that actually sends the instructions to the ACD to route the call to the selected agent. Also, the center contact server needs to first ensure that the selected agent is available, before updating its "state" tables and sending an event message. [Please verify this and confirm the steps in Figures 4a-4b.] In the parameters used for routing, the Enterprise Contact Server 100 uses different rules routing rules are incorporated into a configuration file that is read by the event processor and routing module 95. The configuration file can be stored as a table in the ECS 134. database. The rules can also be incorporated into this code. source of the module, such as through a1 switching declaration or a nested if it is tree. Preferably, it is the combination of source code and configuration file that determines how the routing rules are implemented, i.e., how the Enterprise Contact Server 100 is going to route a contact request. In this way, these rules determine whether the Enterprise Contact Server 100 will route the call to a call center with qualified agents, or, to a real qualified agent that is currently available based on a query to the status tables. The architecture of the communication system that implements the company contact server 100 of the invention, can be used to provide return telephone calls. Specifically, the client visits the specified web site, which causes the callback applet to be loaded into the client's browser. The customer enters the phone number where he wants to receive a call back and then presses a "call me" button on the "web page display" (html) This action sends a request to the Business Contact Server 100 to insert the call back into a queue. The Enterprise Contact Server then sends a request to insert the call back to the appropriate premise contact server. The premise contact server responds with the average handling time for calls in this queue, which the Business Contact Server 100 sends back to the client. When an agent with the right skills is available, the call back is sent to the agent in the selected call center and a screen is triggered so that the available agent can preview the request before processing the call back. This results in a notification to the customer that the call is being processed. It also results in a request from the T server to connect an outgoing call between the agent's telephone apparatus and the customer who entered the telephone number through the ACD. In addition, the architecture of the communication system implemented by the Business Contact Server 100 of the invention can be used to provide telephone return calls. For example, when the agent is on the line with a client The agent's screen application displays the customer's information. The agent can determine the need to transfer the call to another call center. To accomplish this, the agent presses a transfer button (not shown) on the screen application and enter a number, for example, an 8xx number, of the call center to which the call is to be transferred. The agent additionally sees the data annexed to the call. Via the application of highlighted screens, an event transfer is made by which the call is sent to the premise contact server, which, in turn, sends the request to transfer the premise to the server T. The premise server T then transfer the call to the requested extension. The premise contact server also sends a transfer call to the Server. Business contact with an identifier for the call center that the phone call is being transferred. The transfer event will also contain the customer's identifier. The Business Contact Server 100 then sends the transfer event to the appropriate premise contact server, which preferably will have received the transferred call. The new premise contact server will deliver the transfer event to an agent with the appropriate skills and availability, along with the customer identifier. When the agent's displayed screen receives the transfer event, the client's deployment information will be displayed to the agent, as well as a message informing the agent that they are receiving a transfer call. The new premise server T will also deliver the transferred call to the same telephone handset of the agent. As shown in Figure 5, additional interfaces are provided to the Business Contact Server 100. Those interfaces include: an event tracker 96 for receiving and logging of all events in database 134 or data store, primarily for the purpose of tracking historical data and generating statistics; a port interface of Click-n-Connect 88 that allows Internet protocol traffic to become PSTN traffic; and, an H.323 89 port used to support video calls, as defined by industry standard H.323. This H.323 port is for the purpose of enabling a client to request a contact by an agent via a video conference, that is, over the Internet via an H.323 port. Since the Click-n-Connect port 88 and the H.323 port 89 are to support enhanced telephony communications for contacts, their interfaces are processed by the telephone processor of the Enterprise Contact Server 136. The additional connection with the Server Company Contact 'on an agent / call monitor 113 ("Monitor") that provides current and historical agent and call status displays, and various other 96 session tracker / initiator event server statistics; and, an interface with a workstation of the agent "Client Agent". Although in the preferred mode, the Business Contact Server does not connect directly with any of the subscribers' workstations, the Enterprise Contact Server is based on the software architecture of the contact center server, and as a consequence, supports one inferióase asi. In fact, the agent / call monitor can connect to the Contact Server of. Companies as an agent client. Figure 6 (a) illustrates an exemplary logical architecture of a company "Click-n-Connect" system 440. The Click-n-Connect 440 system allows a client 42 to consult a website to select an option to make contact with a call center agent with an Internet protocol phone call. When this option is selected, the Click-n-Connect 160 web server captures the client's Internet protocol address, establishes an Internet protocol telephony session with an Internet protocol port 145, for example, Netspeak, and starts a telephone call on the PSTN to a call center ACD using a pre-programmed 1-800 routing number. The call is routed to a qualified agent, who then engages in a PSTN-to-Internet phone call with the client. If a qualified agent is not available, the call is kept in a queue in ACD 12.

In the architecture represented in Figure 6 (a), only one voice telephony session can be established, and no synchronized HTTP sessions or multimedia collaboration such as push URLs are supported. Also, a customer can not place a call back request. Figure 6 (b) illustrates the logical architecture of Click-n-Connect using the Business Contact Server 100 and the call center contact server 28. Although this service can be supported by a single contact center server. calls as described in co-pending US Patent Application No. 08 / 976,162, the Business Contact Server 100 adds to this service the features and benefits previously described. Specifically, when a client selects the Click-n-Connect action of a web page, the web server 130 sends a message to the Business Contact Server ("Network Contact Server") 100. The Business Contact Server selects a qualified agent available (or a call center with a qualified agent available), and send a message to that agent center contact server 28 to reserve (or select and reserve) an agent. The Business Contact Server 100 also establishes an Internet Protocol telephony session with the Internet protocol port 145, and initiates a call to the ACD 12. Router calls to the agent selected,? who then gets hooked on a phone call with the client. Likewise, the agent can get hooked in other sessions, such as HTTP synchronized on the web. If no qualified agent is available, then the Business Contact Server 100 submits a contact request to itself, and routes that request to a selected call center contact server. The advantages that the Enterprise Contact Server 100 introduces for this application are: different voice telephone call sessions are supported; a client call is not queued in the ACD if no agent is available; and, multiple call centers can be used to take calls or contact requests. It should be understood that the Business Contact Server and the communications architecture of the invention can be used as a network dispatch service 400 that allows the company's customers to view problem assessment information via the web site. Specifically, if a customer has a question regarding a problem assessment, press an option on the web page, which issues a contact request to a call center agent that supports the system for which the problem assessment was submitted . With the Business Contact Server 100 and the systems architecture of the invention, contact requests can be distributed among multiple call centers. Thus, when a contact request option is selected by a client, a client return call (Java) applet runs on the client's computer, as described in the United States Patent Application. joint slope number 08 / 976,162. A contact request is sent to the Java callback server on the web server 130, which sends the contact request to the Business Contact Server 100. The Business Contact Server 100 consults its skill and status tables, from the described in this, and selects a call center or call center agent to which to send the contact request. Send the contact request to the contact server of the center that supports the selected call center. The contact center server assigns an agent and routes the contact request data to the agent workstation. The agent can then initiate an HTTP session synchronized with the client, via the Java data server, as described in co-pending United States Patent Application No. 08 / 976,162. Figure 7 is a representative illustration of a sample of HTML 408 web page. Typically, a web browser such as Microsoft Explorer® or Netscape Navigator® or Communicator® displays an HTML web page such as the one shown in Figure 7, loading an HTML arclaim from a web server specified in the URL. Additional pages can be displayed at the top of the HTML 408 webpage by Java applets that are also loaded from the web server and run in a client browser. Figure 7 shows two separate tables that are superimposed on the html web page 408: a "problem assessment" box "410; and a "contact me" box 458, which allows a request for a call back. These two frames are controlled by Java applets loaded from the web server. The "Proof Slogans" appraisal box 410 is an example of what a customer can see on their website before the request for return calls is made. This table 410 also illustrates an example of how a customer can request to be synchronized by an agent by pushing the "synchronize with agent" button 4 L2. The mechanism of synchronizing / pushing, and pulling are explained in detail with reference to copending U.S. Patent Application No. 08 / 976,162. The "contact me" frame 458 is controlled by a Java applet that runs in the client browser. This Java applet handles the screen interface of calls back with the user and at the same time handles communications with the call server back to a web server. The following paragraphs describe a detailed example of how a Java call back applet can work when connecting to the user and a server. Description of a Java callback applet that runs in a client browser: 1. Initialize all data parameters. 2. Obtain connection / exit of the hostess (ie, server called back). 3. Obtain host parameters and port addresses for plug-in communications. 4. Build the "contact me" screen and display it on the client's current screen. 5. Handle input events from the client's screen; that is, input by mouse, input by keyboard. 5.1. If the input event is a mouse pulse in the Name field, display the message, "enter your name". 5.2. If the input event is a mouse pulse in a phone number field, it displays the message, "write your phone number." 5.3. If the entry event is a contact-method field and the contact method chosen is "telephone", enable the fields of the telephone number and extension on the client's screen; for all the E ^ ^^^^^^^^^^^^^ i ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ telephone number and extension. 5.4. If the button pulse event call me, then check if all the input parameters were written. 5.4.1. If the input parameters are missing, display the message "there is not enough information to complete the call"; and go back to step 5, and handle more input. 5.4.2. If all the input parameters are entered, proceed to step 6. 6. Analyze the input parameters grammatically. 7. If the contact method chosen is "Agent / client in conversation on the line", include the CGI script name in the URL path that will be sent over a socket to the call back server; the packet input parameters in a buffer and write the interemmedia memory over the socket connection to the callback server. 8. If the contact method used is email "E-Mail", include the email address of the client in a send buffer; write buffer on the socket. 9. If the contact method chosen is "telephone", include the customer's phone number in a send buffer; Write about the socket. 9.1. Wait for the return server to send confirmation that the call has been placed. 9.1.1. If confirmation of the call back server does not arrive in a defined period of time, display message, "there has been an error to receive confirmation that your call has been placed", on the customer's screen. 10. Listen on the socket server messages call back (a new string). 10.1. If the message received from the return call server is "Server Contact Down", it displays a message on the client's screen, "The callback function is not available". 10.2. If the message received from the return call server is "Contact Server up," the message is displayed, "to speak with a representative, please press the contact me button. We will gladly call you regarding your inquiries. service. " 10.3. If the received message is "Event", a grammatical analysis of the received message is made and similar types are compared. 10. 3.1. If the type of event is "Insert call back", the message displayed, "Thank you for using the MCI web call back service. Your call has been placed and an MCI technical specialist is going to contact you now. " 10.3.2. If the event type is "Delete the call back", the message is displayed, "Your call has been canceled". 10.4. Continue in step 10. Description of the callback server that runs on the web server: One of the functions of this callback server is to interact with the callback applet. 1. Open connection with the contact server. 2. If there is no connection, set a "Contact server down" parameter, message in packet in a buffer and send to the call back applet. 3. If the connection exists, set a parameter message "Contact server up", to a buffer and send the call back applet. 4. Open the connection with the call back applet. (A new chain). "5. Accept data from the call back applet. 6. ! Analyze the message of the callback applet. 6.1. If a callback service was requested, call the JContactClient class with the fixed event type in "InsertCallBack". 6.2. If cancellation of the call back service is requested, call the JContactClient class with the fixed event type in "DeleteCallBack". The foregoing only illustrates the principles of the present invention. Those skilled in the art will be able to imagine various modifications which, although not explicitly described or shown herein, incorporate the principles of the invention and are thus within their spirit and scope. fe______ ..jjj_t ».j .._ ¿a,. , -i ... i. éíÉU & b »á? * ¿^ ¿< ? Iii- ~ sii * l3, & t APPENDIX A Class CContaptEvent: The CContactEvent class is an enclosing class that wraps socket and TServer data. The class includes 25 protected member variables: He is useful _-___ faith_t__s__. ^^ ** & ^ i. * 6 k ^. ** at * J ^ &? u ^ ^^ "^ m¿0l¿ tißkiiiÁ.

CContactEvent functions: 10 Constructors: The class includes two constructors. The first is a standard default constructor that does not take parameters and does not perform additional tasks. The second constructor takes a CString parameter that is delimited pipeline ("I"). This constructor constructs the variables 15 members calling the GetKeyValue (...) function to analyze the CString parameter data passed to it. void SetVaria3le_Va-T¡e (...): The CContactEvent class includes 25 functions to set, or assign the value of each member variable, one function per variable. Each function 20 takes a parameter of the same type as the member variable to which it corresponds, sets the variable, and has a return gap. type GetVariableName (): The CContactEvent class also includes 25 functions to obtain, or return, the 25 value of each member variable, a function corresponding to each variable. These functions do not take any parameter, and it returns the value stored within the corresponding member variable. CString Get ^ ocketString (): This function returns an "I" CString delimited by key value pairs to send a socket to a listener / server. The pairs of key values that the function delimits are member variables of the CContactEvent class. The function will test each member variable to determine if it is populated. If it is populated, it will add the variable key and its data to the returning CString. void ClearEvent (): This function will delete any data that is stored in any of the object member variables, with the exception of m_ThisDN. m_ThisDN is maintained because the destination number will remain the same while the agent connects to the server. The return value is empty. short DeleteUserData (long lParam, LPCTSTR dn, LPCTSTR szInKey): This function takes three parameters, however, it does not use the first two (lParam & dn). The function is designed to delete a portion of the m_UserData variable, which must be a delimited string ",". The szInKey parameter is the key to the data that the function will erase, and the function U iAx &i? M dsA), -A ». * -tt-tMfcfca te & s &&ii &tigiá *** »¡t? .. ^^ :? will erase the data in the string that resides between two commas after the key. short DeleteAllUserData (long lParam, LPCTSTR dn): The function does not use the last two parameters. The function will set the member variable m_UserData to an empty string (""). CContactClient Class: The CContactClient class is an API designed to facilitate communications between the agent application and the CServer via TCP / IP sockets by establishing / terminating the server connection and sending / receiving data. Additionally, the CContactClient class works as a wrapper for the CContactEvent class. Variables: Variable names followed by (.cpp) are declared inside the .cpp file instead of the file. h. This is so that the ReceiveThread function, a statistically declared function, can use these variables.

Functions: Constructor: The constructor micializes the pointers pEventHead, pEventSocket, and pLi stenerSocket to override; micializes the string messages for the ErrMsg array; and micializes the string descriptions for the TMessageStnng array. Destroyer: Call member function CContactEvent ClearEvent () to erase the data stored in CurrentEvent and OutboundEvent. Delete all the elements that may exist in the linked list of EVENT_OBJECT, including pEventHead. Close the receive string and set the pListenerSocket to void. Disconnect from CServer and set pEventSocket to void. short Open (LPCTSTR szServerName) short Open (LPCTSTR szServer ame, ClientType client): This overloaded function takes one or two parameters. szServerName refers to the Internet protocol address of the server to connect it and client refers to the type of client that is registered (ie, monitor client, agent client, or web client). The function checks pEventSocket to determine a null value. If null, assign and CContactSocket object with the new keyword. Next, the function checks ConnectionStatus to determine a connected status. If it is connected, it sets an error message warning that a server connection already exists and returns a false value, or 0. If there is no connection, the function sets the type of client for the CContactSocket with client, or a default of AGENTjCLIENT if the function does not receive a client parameter; fix m_ServerName of CContactClient with szServerName; and calls the connection function CContactSocket to make a connection to the server.

If the connection fails, the function sets an error message with the error received from the CContactSocket object, clears pEventSocket, and the function will exit with a false value. If a successful connection is presented, a second chain is initiated to receive CServer events. short CloseServer (): Calls the function of the CContactEvent ClearEvent () to erase data stored in CurrentEvent and OutboundEvent. Delete all the elements that may exist in the linked list EVENT_OBJECT, including pEventHead. Close the reception chain and set pListenerSocket to null. Disconnect from CServer and set pEventSocket to null. short isEventReady () short NextEvent (): These two functions have the same functionality. These functions will remove the first element in the linked list of EVENT_OBJECT and move the second link to the head. When they are called, if pEventHead is null, the function (s) delete any data that CurrentEvent has stored in its member variables and sets the return value to false, or 0. If the first element in the list is the only element, the function removes the element and sets pEventHead to null. Otherwise, the function removes the »JAi: fe.i-á_» te ^ j __- ^^ first element and the second link becomes the first. CString GetSocketString (): Est, the function calls the GetSocketString function of CContactEvent to format the CurrentEvent member variables in a single, delimited pipeline chain ("I"). The function returns the formatted string. void CreateEvent (CContactEvent NewEvent): This function will add a received event to the end of the linked list of EVENT_OBJECT. If there is an empty list, add NewEveint as the first link. Else, the function will add NewEvent to the end of the list. BOOL StartThread (LPCTSTR ServerName, ClientType Client): This function calls CreateThread (MFC) to start the reception chain. static DWORD INAPI Receive Thread (LPVOID Socket): This is the second string designed to receive incoming events from this CServer. The chain cycle will block on the socket until the event is received. When it is received, the function will pass the event to CreateEvent (CContactSocket NewEvent) for the addition to the linked list. If the event received is EventRegisterMachine, the function sets m__ThisDN OutboundEvent variable with the m_ThisDN variable of the received CContactEvent object. Additionally, the function will announce a message to the window if one of these is received.

Wrapper functions for CContactEvent: void SetVaria-leNa-Oe (type): The following functions act as a wrapper for the CContactEvent class. Each function is operated on the OutboundEvent object to set its member variables before sending the object to CServer. They are carried out by calling the member function (s) that correspond to establishing the desired member variable. Each function takes a single parameter of the same type as the member variable CContactEvent to establish and has a return value of empty. type GetVariabl eName (): Again, the following functions act as a wrapper for the CContactEvent class. Each function is operating in the CurrentEvent object to obtain the data stored in its member variables. This is done by calling the object member functions that correspond to removing the desired member variable. Each function does not take parameters and returns a value of the same type as the member variable CContactEvent to recover. short CallbackOn (LPCTSTR dn, short logType): This function requests the CServer to set the agent's ability to handle calls back. Set the m_Event of the OutboundEvent to EventCallbackOn, and set m_ThisDN and m_LoginType with the i »l¿¿¿i = s £ _______ 4 ___ i _______ ^^ past parameters. The function will check pEventSocket to determine a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Then, the function will try m_ThisDN of the OutboundEvent to determine an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the data stored in the member variables of the OutboundEvent. short AgentLogout (long lParam, LPCTSTR dn): This function requests the CServer to register the agent. Send m_Event of OutboundEvent with RequestAgentLogout and m_ThisDN with dn. The function will check pEventSocket. to determine a null value. If it is null, the function establishes an error message that warns that there is no server connection and will return a false value, or 0. Then, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the data stored in the member variables of the OutboundEvent. short MakeCall (long lParam, LPCTSTR dn, LPCTSTR szPhoneNumber): This function requests that CServer place a call. Fix m_Event of OutboundEvent with RequestMakeCall, m_Ani with szPhoneNumber, and m_ThisDN with dn. The function does not use lParam. The function will check pEventSocket to determine a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Next, the function will try m_ThisDN of the OutboundEvent to determine an empty string. If it is empty, it sets an error message that warns that no DN is registered and will return a false value.

Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, The function calls the ClearEvent function of the CContactEvent to delete the data stored in the member variables of the OutboundEvent: . short CallAnswer (long lParam, LPCTSTR dn): This function requests that CServer answer a call. Set m_Event of OutboundEvent with RequestAnswerCall and m_ThisDN with dn. The function does not use lParam. The function will check pEventSocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Then, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If you are tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent. to delete the data stored in the member variables of the OutboundEvent. short AgentReady (long lParam, LPCTSTR dn): This function requests that CServer set an agent status to ready. The function fi a m_Event in OutboundEvent in Request AgentReady and m_Th? SDN with dn. The function does not use lParam. The function will check pEventSocket to determine a null value. If it is null, the function establishes an error message that warns that there is no server connection and will return a false value, or 0. Next, the function will try m_Th? SDN of the OutboundEvent to determine an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to erase the data stored in the -_ * i «tt» .t_fe. ^^ l ^ tffa ^ ibri ^ ját. variable members of the OutboundEvent. short AgentNotReady (long lParam, LPCTSTR dn): This function requests that CServer fix an agent's state in not ready. The fixed function m_Event of the OutboundEvent in RequestAgentNotReady and m_ThisDN with dn. The function does not use lParam. The function will check pEvent? Ocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Then, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is set that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the data stored in the member variables of the OutboundEvent. short AgentBusy (long lParam, LPCTSTR dn): This function requests that CServer set an agent status to busy. The fixed function m_Event of ttte áito-i? ia «-fe'h [¡_________ to ____ j ______ l__áj ^ j ^^ a ¿« ii iaia.- .. > i-i_aiAi? OutboundEvent in Reque tAgentBusy and m_Th? SDN with dn. The function does not use lParam. The function will check pEventSocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Then, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the dstored in the member variables of the OutboundEvent. short AgentNotBusy (long lParam, LPCTSTR dn): This function requests that CServer set an agent status to not busy. The fixed function m_Event of the OutboundEvent in RequestAgentNotBusy and m_ThisDN with dn. The function does not use lParam. The function will check pEventSocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Next, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the dstored in the member variables of the OutboundEvent. short DeleteCallback (CString ANI, CString IP): This function requests that CServer delete a call back. Set m_Event of OutboundEvent on RequestDeleteCallback m_Ani with ANI, and m__IP with IP. The function will check pEventSocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Next, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the The function will verify the ConnectionStatus variable to determine a connected status. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the dstored in the member variables of the OutboundEvent. short Update Callback (CString appl_d CString origination, CS tring method, CString IP, CString ANI, CString NaspID, CString ContactTime, int ContactResult): This function requests that CServer update an existing return call. Fix m_Event of OutboundEvent on RequestUpda teCallback, m_IP, and m_Ani with ANI. The remaining parameters are formatted in a delimited string "?" and the variable m_UserDof OutboundEvent is set. The function will check pEventSocket for a null value. If it is null, the function sets an error message that warns that there is no server connection and will return a false value, or 0. Next, the function will try m_ThisDN of the OutboundEvent for an empty string. If it is empty, it sets an error message that warns that no DN registered and will return a false value. Finally, the function will verify the ConnectionStatus variable for k __. ¿A._a__ i¿Ji j &M¿ <tt, * determine a connected state. If it is not connected, an error message is generated that warns that there is no server connection and will return a false value. If these three tests pass, the function will send the OutboundEvent to the CServer on the socket and return a true value, or 1. Before leaving, the function calls the ClearEvent function of the CContactEvent to delete the data stored in the member variables of the OutboundEvent.

Claims (34)

1. CLAIMS 1. In a communications network, a system for establishing and maintaining communications between a client and a business that has a plurality of call centers over a plurality of communication means, including the system: (a) a first means for establish a first communication link between a client and a web server of the company; (b) a second means for tracking available resources in each of a plurality of call centers, including the resources a call center agent having a particular skill set and availability status, this second means also selects a call center. calls that a qualified agent has available to communicate with the lens; (c) a third means for establishing a second communication link between the selected call center and the customer; and (d) a local contact server located in each of a plurality of call centers that has means to handle and synchronize simultaneous Internet protocol communications between the web server and the selected call center, and between the web server and the client, mediafife which the agent in the call center selected the client can each see the first communication links while communicating with each other on the second communication link. 2. In a communication network, a system as claimed in claim 2, wherein the first communication link is an Internet protocol communication link. 3. In a communication network, a system as claimed in claim 1, wherein each premise contact server further includes means for communicating call center event messages including the status of resource availability to the second means. 4. In a communication network, a system as claimed in claim 1, wherein the third means includes a director of automatic telephony calls and a telephony server. 5. In a communications network, a system as claimed in claim 2, wherein the contact server of the premises communicates with the automatic call manager through the telephony server. 6. In a communication network, a system as claimed in claim 2, wherein the Internet protocol communications link includes a link that allows a client to request a call back if an agent is not available. 7. In a communications network, a system as claimed in claim 1, wherein the third means allows communication with the client with a communications protocol selected from the group of broadband telephony, TCP / IP, SMTP, conversation , Internet telephony or Internet video. 8. In a communication network, a system as claimed in claim 1, in donate the system includes a database server to authenticate the rights of a "customer and said call center." 9. In a communications network , a system as claimed in claim 6, wherein the second means includes a database server for matching the qualifications of a call center agent with a callback request from a client. of communications, a system as claimed in claim 1, wherein the system also includes a database server to provide access to data related to the services provided by the business to the client 11. In a communications network , a system as claimed in claim 2, wherein the system also includes first and second linked network servers separated by a security means, communicating the first -.iMtti ____________________________________ ^^ web server with the agent, and communicating the second web server with the bridge, providing the second web server at least one Java applet to said client over the Internet protocol communications link. - 12. In a communications network, a system as claimed in claim 1, wherein the second means also selects a qualified agent for communication with the client. 13. In a communication network, a system as claimed in claim 1, further including means for generating a status inquiry message to a selected call center to assess the availability of call center agents having a call center. desired skill set, the contact server of said call center generating a response to indicate the presence of a qualified call agent. 14. In a communication network, a system as claimed in claim 13, further including means for selecting another of the plurality of call centers if the qualified agent is not available in said selected call center. 15. In a communication network, a method for restoring and maintaining communications between a client and one of a plurality of call centers over a plurality of communication means, the method comprising steps of: (a) establishing a html communications link between a client and a company web server which allows the client to request a call back; (b) determining the availability of resources in each of the plurality of call centers for the customer, and selecting a call center that has a qualified agent available to communicate with the customer; (c) establishing a second communication link between the selected call center and the customer; and (d) simultaneously manage and synchronize the html communications between: (i) the web server and the selected call center, and; (ii) the web server and the client; whereby the agent can communicate with the client on the second communication link while each one sees the simultaneous html communication links. 16. In a communication network, a method as claimed in claim 15, wherein the step of establishing the second communication link includes establishing a telephony link with the client. 17. In a communication network, a method as claimed in claim 15, which further includes the step of enabling the client to request a call back from an agent if the agent is not available. 18. In a communication network, a method as claimed in claim 15, wherein the step of establishing a second communication link allows communication with the client with a communications protocol selected from the broadband telephony group, TCP / IP, SMTP, conversation, Internet telephony or Internet video. 19. In a communication network, a method as claimed in claim 15, which further includes the step of authenticating the rights of the clients in the selected call center. 20. In a communication network, a method as claimed in claim 15, wherein the step of selecting the call center that has qualified agent available also includes the step of matching the qualifications of a call center agent with a request for calls back from customers. . 21. In a communication network, a method as claimed in claim 15, further including the step of providing client and agent access to data related to services provided by the company to the client. 22. In a communications network, a method such as claims in claim 21, which also includes the step of providing access to data related to valuations of problems in the services provided by the company to the client. , 23. In a communications network, a method as claimed in claim 15, which further includes the step of synchronizing first and second web servers with fixed Internet protocol addresses to provide security for the company's data, communicating the first web server with the agent, and the second web server communicates with the client. 24. In a communication network, a method as claimed in claim 23, further comprising the step of communicating at least one Java applet from the second web server with the client over the Internet protocol communications link. 25. In a communication network, a system for distributing incoming telephone call events received as a telecommunications network switch over a public telephone switching network to one of a plurality of call centers belonging to a business enterprise, having each event a first set of. call data associated therewith, the system comprising: (a) a means for routing the call to a "??. voice response unit capable of obtaining information from the caller; (b) a means to track available resources in each of a plurality of training centers 5 calls, including resources one or more call center agents that have a particular skill set and availability status, also selecting the tracking means to one of a call center and a call center agent based on the information of which 10 calls, and communicating a second set of call data related to the call center selected to the voice response means; (c) an automatic call distribution means associated with each of a plurality of centers Calling 15 for routing calls for transmission over the public telephone switching network, the voice response unit routes the call to a first automatic call ribution means to send said call over the public telephone switching network to a second means 20 automatic call ributor associated with the selected call center, additionally the voice response unit routes the second set of call data to the second call center selected; (d) a contact server medium of 25 facilities located in the call center selected to receive the first call data set to p'artir from the second call ribution means - automatic and the second set of call data from the voice response unit and handle the ribution1 of the call to an agent in said selected call center at the same time that it sends the second data set to a workstation associated with the agent, whereby the agent in said selected call center and the client communicate with each other over the public switching network telephone, while the agent has updated data available to him on said workstation. 26. In a communication network, a system for ributing incoming telephone call events as claimed in claim 25, wherein the second set of call data is routed to the selected call center over one of a local area network and a wide area network. 27. In a communication network, a system for ributing incoming telephone call events as claimed in claim 25, wherein the routing means includes a data access point to determine a destination for the call based on the first data set . m 28. In a communication dc, a system for ributing incoming telephone call events as claimed in claim 27, wherein the first data set includes data related to an identifier 5 automatic numbers. 29. In a communication network, a system for ributing incoming telephone call events as claimed in claim 27, wherein the second data set includes data for routing the call to a destination 10 particular. 30. In a communication network, a system for ributing incoming telephone call events as claimed in claim 27, wherein the second data set includes data pertaining to a caller that 15 requests a particular service. 31. In a communications network, a system for ributing incoming telephone call events as claimed in claim 25, wherein each call center includes a telephony server medium for 20 facilitate routing of calls from the automatic call ributor to the facilities contact server medium. 32. In a communications network that has a plurality of call centers to receive service requests from customers, a system for communication 25 continues between the client and one of a plurality of centers # of calls based on return calls, said communication enabled on a plurality of communication means, including the system: (a) a first means to establish a link of 5 html communications between a client and a web server of the company and allow a request for calls back by the client; (b) a second means to determine the availability of resources in each of the centers of 10 calls for the customer and the request for calls back, and identify the agent in the call center available to communicate with the customer; (c) a third means to establish a call back communications link between the center of 15 calls selected and the client; and (d) a contact server in the call center selected to handle and synchronize simultaneous html communications between: (i) the web server and the selected call center, and; (ii) the web server and the Cluster Lens, whereby the agent establishes a call back communication link with the client while the contact server synchronizes the links of the client. 25 simultaneous html communications between the web server and the < * * client and web server and the agent. 33. In a communication network having a plurality of call centers for receiving service requests from customers, a method for communication 5 continues between a client and one of a plurality of service centers based on callbacks, return call communications enabled on a plurality of communication means, the method comprising the steps of: (a) establishing an html communications link between a client and a company web server which allows the client to request a call back. (b) determine the availability of resources in each of the plurality of call centers for the 15 client and select a call center that has a qualified agent available; (c) identify an agent in the call center available for call back communication with the client; 20 (d) establish a second communication link between the call center and the customer; (e) administer and synchronize simultaneous html communications between: (i) the web server and the 25 call center selected, and; ,. ***? LtiiáiÍß ** Ü & --- - • 'i &M. M ^ &t ^ # l íááh & * A¡ ?? £, "* -iPfc1j + (ii) the web server and the client; whereby the agent can communicate with the client on the second communication link while each one sees simultaneous html communications links. 34. In a communication network, a method as claimed in claim 33, further comprising the step of triggering the callback request from the client by running a Java applet in an html communication 10 received by the client. fifteen twenty 25 I * 1T * f.f * '' "" ft "f" tJ- < ** irt- > _u, - ^ Mfcaa »& j & Mt &jt; afea, j