Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-05-09
2004-08-31
Vu, Viet D. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C719S311000, C719S318000, C379S070000
Reexamination Certificate
active
06785741
ABSTRACT:
CROSS REFERENCE TO RELATED APPLICATIONS
Not Applicable
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not Applicable
REFERENCE TO A MICROFICHE APPENDIX
Not Applicable
FIELD OF THE INVENTION
The present invention generally relates to public switched telephone networks (PSTN's)/voice-over-IP telephony and particularly to the application of the extension of scripts to interact with PSTN and IP telephones within the context of the same services. More specifically, the present invention relates generally to a Virtual Automatic Call Director environment with integrated Voice Response Unit (VRU) and Virtual Automatic Call Distributor (VACD) that permits a complete call flow to be executed in a single process.
BACKGROUND OF THE INVENTION
IP-based agent technology is evolving for IP call centers. The major problems with legacy call centers have been proprietary interfaces for service creation within switches that are complex to change. Most switch vendors control what information is accessible and makes development of new services very difficult. The invention enables a virtual Automatic Call Director (ACD) environment with integrated Voice Response Unit (VRU) and Virtual Automatic Call Distributor (VACD) to enable a programmable interface with a common script logic so that the complete call flow can be execute in a single process.
DESCRIPTION OF THE PRIOR ART
Referencing
FIG. 1
, the present state of the art includes telephone equipment (
101
), public switched telephone networks (
102
), and public branch exchanges (
103
). Remaining elements in this figure may be incorporated using the teachings of the present invention to provide features not present in the prior art.
OBJECTS OF THE INVENTION
Accordingly, the objects of the present invention are (among others) to circumvent the deficiencies in the prior art and affect the following objectives:
1. To provide a common script logic to enable complete call flow to be executed in a single process.
2. To permit extensions to existing call functions enabled at an API interface level that is available to application programmers.
While these objectives should not be understood to limit the teachings of the present invention, in general these objectives are achieved by the disclosed invention that is discussed in the following sections.
BRIEF SUMMARY OF THE INVENTION
Overview
IP based agent technology is evolving for IP call centers. The major problems with legacy call centers have been proprietary interfaces for service creation within switches that are complex to change. Most switch vendors control what information is accessible and makes development of new services very difficult.
Referencing
FIG. 2
, the present invention (
200
) enables a virtual ACD environment (
203
) with integrated Voice response unit (VRU) and Virtual Automatic Call Distributor (VACD) to have a programmable interface with a common script logic so that the complete call flow can be execute in a single process.
Generalized System Architecture
This section describes the work flow of the agent application using the Java Phone toolkit (
208
) and the work flow of the telephony application (i.e. the State Table (
201
,
400
)) using the Call Director (
202
). Together with the detailed API interface (
300
) it provides an insight on how the Gateway operates in a call center. The description includes all the messages between the application (the State Table (
201
,
400
), the Call Director Custom service, the VACD, the Java Phone toolkit (
208
) DACP interface and the Java Phone toolkit API. The goal of this discussion is to provide exemplary teaching and directions on how to use the APIs of each component from the ‘call point of view’.
Gateway Initiation
When DT starts both VOD (Voice over Data) CS and CD CS are initiated using the VOD_Init( ) and CD_Init functions. The VACD component is activated using the AIX Inittab and is assumed to be active at init time, the CD CS would establish a connection with the VACD at this stage.
Once the Call Director Custom Server has been started the call center is ready to start working.
Call Center Application Startup
The Java Phone toolkit (
208
) is activated by the Call Center application. The toolkit is activated with the socket interface option. The InitPhone message is sent at the Call Center application init stage and this action starts an H.323 (
206
) call to the Gateway (without a phone number). Once the call is established a short voice message would be played to the operator.
Agent Logon
Once the application is running the agent must logon to the call center system. The AgentLogon message propagates (with different formats) from the application through the toolkit through the CD CS to the VACD. The message includes userid, IP address, and password. A response is being sent back on the same route (an acknowledge is not implemented at this stage since we assume fast response). This information is also propagated by the VACD to the Call Router. A similar process is followed for AgentLogoff.
Agent Ready
Once logged on the application should send the AgentReady message. The AgentReady message propagates (with different formats) from the application through the toolkit through the CD CS to the VACD. A response is being sent back on the same route. At this stage the agent is ready to accept calls. This information is also propagated by the VACD to the Call Router.
From now on an AgentNotReady message can be sent on the same route with a similar response. This would direct the VACD to stop sending calls to the agent. A similar process is followed for AgentNotReady.
Application State Table
As generally illustrated in
FIG. 1
, the Network Call Center (NCC) with Call Director (
100
) system will now be described in detail. The overall operation of the Call Flow through the Call Director is illustrated in
FIG. 1
with exemplary data flow illustrated in FIG.
2
. The call flows will focus on the use of the Call Director and VOD (IP Telephony) CS. other components such as the Call Router (ICR) (
104
) CS and others are described elsewhere. The Application State Table is invoked ONLY when a call is accepted by the Call Director (
110
) and a caller (
101
) is connected to the PSTN (
102
) side. The PSTN interface can be to any switch or a PBX (
103
) that can provide ANI/DNIS information as well as call transfer capability relative to the calls.
The ICR is part of the IBM callpath product. It is intelligent call routing and the call is routed based on called and calling number information of a call. The agent selection and load balancing is done based on this and more information collected from caller. More information on ICR is available in the document entitled “Call Path programmers Users Guide Ver 6, Rel 2”, June 1999 which is available at online URL
(www-4.ibm.com/software/speech/enterprise/universalaccess
—
1
—
1.html.).
Each call that needs service from the Call Center opens a call_id using the CD_NewCallID (
321
) function. Information gathered from the user such as skills is passed to the CD CS using the CD_SaveCallInfo (
322
) function. The Call Director (
110
) passes this information to the Call Router (ICR) (
104
) to get the destination for Agent Pool or skill that needs to be used.
Using the destination information, the CD_GetAgent (
323
) function is invoked. This function will cause the CD to spawn a request to the VACD (
114
) to get an agent from the pool. The VACD (
114
) will be provided with all the call info saved prior to this call. Any information saved after this function has been called will not affect the pending request. If an agent is instantly ready for operation the VACD (
114
) will return with a valid IP address of the Agent and a return code of CD_OK (=0). If there is no agent ready immediately, the API will return CD_PENDING (=1) and a request ID that will be a handle to the pending request. When the ST will want to know when the agent is ready for this pending request, it should issue a CD_NotifyEvent (
324
) on the relevant call_id and will get an appropriate
Cohen Ran R.
Colson Vicki L.
Dahmus Edward J.
Hoher Ann-Marie W.
Mandalia Baiju D.
Fleit Kain Gibbons Gutman Bongini & Bianco P.L.
Gibbons Jon A.
Tomlin Richard A.
Vu Viet D.
LandOfFree
Call director system and method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Call director system and method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Call director system and method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3352563