CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
1
VIRTUAL INTELLIGENT NETWORK FOR USER INTERACTION SERVICES
RELATED APPLICATION
The present application is related to and is a continuation-in-part of co-
pending
Application No. 09/249,395, entitled "Point-of-Presence Call Center Management
System", filed
on February 12, 1999, by Prem Uppaluru and Mukesh Sundaram, and assigned to
the Assignee of
the present invention.
FIELD OF THE INVENTION
The present invention relates to the field of telecommunications, and more
particularly to
the management of telephone calls to and from call centers.
BACKGROUND
Figure 1 is a functional diagram of a business call center connecting an end
user 116 to a
business call center 108 via an originating Local Public Switched
Telecommunications Network
(PSTN) 106, a Long Distance Network 114 and a terminating Local PSTN 106.
Business call
centers are typically put together by integrating multiple system components
into a complete
business solution to answer, service, queue and route inbound customer calls
within the call
center. These system components can include a Private Branch Exchange (PBX)
102, an
Automatic Call Distributor (ACD) 112 and an Interactive Voice Response (IVR)
System 110 in
addition to customer service or help desk applications for the call center
agents 104. Many call
centers also deploy a Computer Telephone Integration (CTI) server 118 for
providing intelligent
call routing.
Traditionally, multiple vendors supplied the system components and system
integrators
pulled the components together into a solution and programmed them to
implement business-
dependent logic in servicing a call. However, to service the calls this
traditional solution requires
bringing the calls to the call center over long distance networks 114,
provided by such companies
as American Telephone & Telegraph (AT&T), Microwave Communications
Incorporated (MCI)
WorIdCom and Sprint. This method added to the cost of operation of the call
center 108, because
as soon as a call was brought to the call center, an accumulation of long
distance charges started.
Furthermore, businesses with multiple physical locations were required to
maintain
programmable intelligence and develop multiple applications to implement the
logic of servicing
calls at every physical location, because of the insufficient flexibility of
the long distance network
that connects the locations.
Figure 2 is a functional diagram of a network-based call center connecting an
end user
116 to a business call center 108 via an originating Local PSTN 106, a Long
Distance Network
114 and a terminating Local PSTN 106. Network call centers may include a
Switch 122, an ACD
112 and an IVR 110 within the Long Distance Network 114 to provide call
answering, servicing
and queuing services. Network call centers usually integrate carrier-provided
voice
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
telecommunications with premises-based switching, call distribution,
interactive voice response
and computer telephony technologies to perform such services. Traditionally,
network-based call
centers relied on vender-specific proprietary systems and software to develop
and deploy call
management applications to perform answering, servicing and queuing services.
Recently,
telecom carriers have started offering value-added call management
applications as managed
network services. However, such managed network services are usually
proprietary to the
providing carrier, often insufficient in their flexibility and typically
incomplete in functionality.
SUMMARY OF THE INVENTION
In accordance with one embodiment of the present invention, a telephone call
to a first
call center is directed to a second call center on the command of user
specified applications.
Under the direction of the user specified applications the call is serviced at
the second call center
while the user specified applications direct the first call center to
establish a connection therein.
When the connection in the first call center is established, the user
specified applications direct
the second call center to transfer or bridge the call with a telephone
connection in the first call
center via a telecommunications network.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in
the figures of
the accompanying drawings in which like references indicate similar elements
and in which:
Figure 1 is a schematic diagram illustrating a conventional call center
configuration with
PBX, ACD and IVR systems located at the call center;
Figure 2 is a schematic diagram illustrating a conventional network-based call
center
configuration with Switch, ACD and IVR systems located within a long distance
network;
Figure 3 is a flow diagram illustrating one example of an operational method
of a Virtual
Intelligent Network in accordance with an embodiment of the present invention;
Figure 4 is a flow diagram illustrating one process for selection of a
premises call center
in accordance with an embodiment of the present invention;
Figure 5 is a call flow diagram illustrating various aspects of the use of XML
commands
within a virtual intelligent network (VIN) in accordance with a n embodiment
of the present
invention;
Figure 6 illustrates examples of XML tags that may be included in an XML Page
for
transmission within a VIN in accordance with an embodiment of the present
invention;
Figure 7 is a call diagram illustrating various aspects of the case of XML
commands
within a VIN for making outbound calls from a call center in accordance with
an embodiment of
the present invention;
Figure 8 is a schematic diagram illustrating components of a Virtual
Intelligent Network
according to an embodiment of the present invention that includes a point-of-
presence (POP) Call
Center Gateway, a Premises Call Center Gateway, a Call Center Network, a
Network Operations
Center and a Web Application Server;
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
Figure 9 is a schematic diagram illustrating a Virtual Intelligent Network
configuration
according to an embodiment of the present invention that includes a POP Call
Center Gateway
connected to a Premises Call Center Gateway over a Call Center Network
controlled by user
specified applications deployed on a Web Applications Server;
Figure 10 is a schematic diagram illustrating components of a Virtual
Intelligent
Network according to an embodiment of the present invention that supports a
single business with
multiple call center sites connected with multiple POP Call Center Gateways;
Figure 11 is a schematic diagram illustrating components of a Virtual
Intelligent
Network according to an embodiment of the present invention that supports
multiple business call
centers connected to multiple POP Call Center Gateways.
Figure 12 illustrates an exemplary network togology according to an embodiment
of
the present invention.
DETAILED DESCRIPTION
Although the present invention is described below by way of various
embodiments that
include specific structures and methods, embodiments that include alternative
structures and
methods may be employed without departing from the principles of the invention
described
herein. In general, the embodiments described below feature a Virtual
Intelligent Network (VIN)
that provides a distributed call center system controlled by a call center
service provider,
henceforth a user, and is capable of answering, servicing, queuing and/or
routing calls at local
points of presence to reduce communications costs and enhance operational
efficiency for call
centers. A call center is a single point of contact where telephone calls, may
it be enquiries,
order-placing, after-sales support or other call center activities, are
handled and processed by a
team of call center agents. These call center agents or operators can be based
at a single site or at
multiple sites, depending on the configuration of the call center and the
organization that it
belongs to. The industries and organizations where the use of call centers
have become most
widespread are those where there is a focus on customer service and a high
volume of dispersed
customer contact. These include banking and finance institutions, insurance
companies, airline,
hotels, and car rental organizations, and travel services.
Before describing embodiments of the present invention in detail, it is
helpful to discuss
some of the components of the VIN and other general concepts on which the
present invention is
based. The present invention utilizes point-of-presence (POP) call center
gateways. POP call
center gateways were described in detail in the above-cited related
application (which is hereby
incorporated by reference) and their applicability in efforts to minimize
telephone charges for call
center service providers was highlighted therein. A POP call center gateway is
configured to
answer, service, queue and/or route calls at a local point-of-presence, close
to the point of call
origination. POP call center gateways may thus provide initial processing of
incoming calls;
holding and queuing the calls until live operators at the called business call
center are available.
Once live operators become available, the POP call center gateways route the
locally queued calls
to the operators at the business call center. Thus, one benefit of using such
POP call center
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
gateways is that the business call center service provider will only incur
long distance charges for
the time that a caller is actually connected to a business call center
operator. Time spent on hold,
in a queue or answering automated menu questions, etc., will not add to the
long distance charges,
because that portion of the call is treated as a local call, terminating at
the POP call center
gateway.
Another integral component of the present invention is a computer server.
Servers are
computer programs, which may be configured to execute on any one or more of a
variety of
computer hardware platforms to provide some service to other programs, called
clients (which
may also operate on a variety of computer platforms). A client and server
communicate by means
of message passing often over a network, and use some protocol, a set of
formal rules describing
how to communicate (i.e., transmit and receive) data, to encode the client's
requests and/or
responses and the server's responses and/or requests. A server may run
continually, waiting for a
client's requests and/or responses to arrive, or it may be invoked by some
higher level software
application, such as a continually running server, which controls a number of
specific servers.
Client-server communication is analogous to a customer (client) sending an
order (request) on an
order form to a supplier (server), who in turn dispatches the requested goods
and an invoice
(response). The order form and invoice (e.g., the terms and conditions
specified therein) are part
of the protocol used to communicate the request and response.
As further explained below, the present VIN employs a so-called eXtensible
Markup
Language (XML), a computer-based language designed to enable the use of the
Standard
Generalized Markup Language (SGML) on the World Wide Web (sometimes know as
the
"Web"). SGML is the international standard for defining descriptions of the
structure and content
of different types of electronic documents. Furthermore, the VIN utilizes the
well-known
Hypertext Transfer Protocol (HTTP), designed for distribution of hypertext
documents over the
Internet, to facilitate communication between network components (e.g.,
clients and servers) via
XML messages over virtual private networks (VPN), which provide a tunnel
within an otherwise
public network for secure and private data communications.
In at least one embodiment of the present invention, the VIN includes a set of
POP call center
gateways, distributed at points-of presence close to the point of call
origination, interconnected by a user-
controlled virtual private network to premises call center gateways,
distributed at locations where the call
centers exist. The POP and premises gateways, according to embodiments of the
invention, are
programmable telephony applications gateways that are dynamically controlled
by call flow management
(CFM) and interactive voice response (IVR) web applications. A CFM application
uses information such
as time of day, day of month, holidays, overflow, percentage allocation across
multiple sites and agent
group sets to select an answering resource to which to route a call. An IVR
application may be regarded as
a software application that uses a prerecorded database of voice (or
synthesized voice) messages to present
and/or collect user entered digits, interact with office databases and provide
results the user. An IVR
application may also optionally use speech recognition to secure input options
from a user. These
applications, CFM and IVR, can reside on web application servers, such as
Netscape Application Server 2.1
and NetDymanics 4.0, potentially hosted at external Internet data centers
and/or the call center premises and
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
connected to the same VPN as the POP and premises gateways. The CFM and IVR
applications control the
call flow and voice response behavior of these gateways through XML messages
using HTTP and virtual
private networks for distributed call resources (hardware and/or software)
management.
The process of operating the VIN may be generally described with reference to
the
simplified flow diagram shown in Figure 3. In response to an inbound call
being placed, at step
200 the user specified CFM and IVR applications direct a POP gateway, at or
near the point of
call origination, to intercept the inbound call. Thus, the POP gateway answers
and terminates the
inbound call locally, taking advantage of the economics of local
interconnection, which generally
provide for minimal access charges. In addition, the CFM, at step 204, issues
a command (e.g.,
using an XML Page as described further below) to the POP call center gateway
to provide a
service, such as an interactive voice response-based automated service to hold
and queue the call
until operators are available to service the call, and/or to play music or
customized
announcements to the caller while the call is being held.
In parallel, the CFM, at step 208, may issue a command (again via an XMI.
Page) to a
premises call center gateway to originate a proxy call to a call center
operator in its automatic call
distributor (ACD). In response, the premises call center gateway generates and
presents the proxy
call to the ACD. The CFM command may also direct the premises call center
gateway to monitor
the progress of the proxy call within the ACD for operator availability and
communicate the
same to the CFM, at step 210. When the proxy call reaches the head of the
premises call center
queue and is about to be answered by a live call center agent, the premises
call center gateway
alerts the CFM. Based on this real-time information regarding the availability
of the selected
operator, the CFM application, at step 212, issues a command to the POP call
center gateway to
transfer the on-hold call to the premises call center gateway and also
instructs the premises call
center gateway to bridge the incoming call from the POP gateway to the proxy
call (now about to
be answered by the operator) in the premises ACD. Such local queuing and just-
in-time call
delivery saves on long distance communications charges that would otherwise be
incurred if the
call were to be earlier connected to the premises call center for queuing.
The process of selecting of a premises call center is generally described with
reference to
the flow diagram shown in Figure 4. At step 216, an incoming call is directed
to an IVR
application that is preferably developed as a web application and deployed on
a web server. Such
an application can be used to gather caller specific information (e.g., an
account number, which
the CFM application can use to intelligently route the call to the best
matching answering
resource. At step 218, the CFM directs a POP call center local to the incoming
call to intercept
the call and to provide interactive voice response-based automated services as
described above.
The CFM; at step 220, instructs the premises call center gateway selected as
the best answering
resource to insert a proxy call in its ACD. If the best answering resource is
not available to service
the call and the call needs to be transferred to a second best location, the
CFM, at step 224, issues
a command to the best answering resource to drop the proxy call from its ACD
and directs, at step
228, the call center at the second best answering location to place a proxy
call in its ACD. (This
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
process can be repeated as necessary (and as resources permit) until an
answering resource
capable of handling the call is located.) The second location, in response to
the CFM command,
monitors the progress of the proxy call, at step 230, and communicates
operator availability to the
CFM. Upon receiving a message from the second location that a live operator is
available to
service the call, the CFM, at step 232, instructs the POP call center gateway
to transfer the call to
the second location. Such local queuing at the POP call center gateway saves
on long distance
communications charges that would otherwise be incurred if the call were to be
earlier connected
to the best answering resource and then transferred to the second location.
When the call is ultimately connected to an agent at a premises call center,
the VIN may
take advantages of conventional Internet technologies such as IP telephony,
Media Gateway
Control Protocol (MGCP), Gatekeeper protocols, and virtual private networks
with guaranteed
quality of service for long distance voice communications to ensure a quality
user experience is
provided. A selected call center agent at the premises call center then
answers the transferred call
and provides customer service to/for the caller. Finally, when the caller or
the call center agent
hangs up the call, the CFM instructs the POP and Premises gateways to
terminate the call.
Preferably, the POP and Premises gateways as well as the controlling CFM and
IVR
application servers, according to embodiments of the invention, are managed
from a central
Network Operations Center (NOC) 156 (see Figure 9) connected to the same VPN
as the
gateways and servers. Using the Simple Network Management Protocol (SNMP) and
network
management web tools, the NOC is capable of discovering, configuring,
monitoring and
managing all the components in the VIN. In addition, the NOC hosts other
operations support
systems including service provisioning, user billing, user support and other
service management
systems enabling the VIN to offer a suite of end-to-end managed user
interaction services.
The present VIN not only gives a user (i.e., a call center provider) control
over the
inbound operations of the call center, but also over outbound call center
operations. Under the
guidance of the CFM application, the VIN can be used to dial specified long
distance numbers as
local numbers, filter out unanswered or machine-answered calls, play specified
announcements or
messages when calls are answered, and allow the called party to conduct
interactive transactions
with live operators and/or sotred interactive software applications. The CFM
web application can
specify a set of alternative long distance numbers and instruct elements of
the VIN, via XML
messages, to contact a called party and deliver prescribed voice messages. The
VIN dispatches
the request to attempt such contact to the appropriate POP gateway where the
dialed number
would be a local call. If the call is unanswered or answered by a machine,
other specified numbers
may be tried in a sequence until a call can be completed to a live person.
When a call is
answered, an IVR application can authenticate the called party and deliver the
CFM-specified
voice message or announcement and receive an acknowledgement from the called
party. The
IVR can also provide the called party with an option to be connected to a
servicing agent. Upon
the called party's selection of this option, the CFM directs the remote call
center to establish a
connection with the servicing agent, by requesting a proxy call in the remote
call center's ACD
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
7
and monitoring the progress of the proxy call. When the connection with the
servicing agent is
established, the CFM instructs the remote call center to bridge the proxy call
to the local call
center, thus eliminating unnecessary long distance charges that would
otherwise be accumulated
transferring and queuing the call.
A more general view may thus regard the programmable VIN as a collection of
intelligent, telephony ports, capable of originating or terminating calls,
bridging call pairs and
attaching callers to IVR applications. The programmability of the telephony
ports is
accomplished through the use of XML Pages, where each of the "tags" of the
Pages instructs the
telephony ports to perform designated call management functions. Such XML tags
may be part
of a general Voice Response Control Language (VCRL) for remotely controlling
the behavior of
POP call-center gateways. Thus, the set of point-of-presence call center
gateways distributed at
points of presence close to the point of call origination are interconnected
by the programmable
VIN to premises voice response servers at business locations where the call
centers reside. The
Call Flow Manager (CFM) orchestrates the creation and management of telephone
calls in the
VIN, under the control of the call center IVR applications.
As indicated above, the VRCL provides the syntax for the XML Page objects,
which are
generated at the CFM and used by a POP gateway to execute actions on behalf of
the call center.
The XML Page objects may be simple pages of ASCII text that are stored in a
Web server's
directory or generated by scripts at the server hosting the CFM. The XML Pages
are transmitted
by the CFM in response to H'TTP requests made by a client application running
on a POP
gateway.
To more fully appreciate how the VRCL may be used by an IVR application
running at a
call center to control the actions of a POP gateway on behalf of the call
center consider the
following example with respect to the call flow diagram shown in Figure 5.
When an inbound
call arrives at a POP gateway, a data communication path is established
between the POP
gateway and the CFM. Soon after the call is accepted, the CFM transfers
control to the IVR
application for providing voice prompts and menu selection choices to the
caller. The POP
gateway fetches an initial XML Page from the IVR application, parses and
executes the
commands in the XML Page, and then requests the next XML Page from a location
defined by a
Universal Resource Locator (URL) specified in the first XML Page. This process
then repeats,
with the POP gateway continuing to get new sets of commands (represented by
the tags in the
XML Pages) from the IVR application. An important thing to note about VRCL is
that unlike
HTML a VRCL page represents a linear sequence of instructions. An I-iTML page
is generally
presented to a user all at once, but a VRCL page is audibly rendered and acted
upon in a top to
bottom sequence.
An IVR application may lead a POP gateway through a series of XML Pages
depending
upon the complexity of the application. For example, a series of inter-linked
menus may need to
be navigated by a caller before the callei s intentions and/or choices are
fully defined. Ultimately,
the IVR application may either terminate the call or transfer the call to a
live operator. In either
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
case, the IVR application transfers control back to the CFM, which then
directs the POP gateway
to either setup a call over the PSTN or to terminate the call. The set of XML
tags specified in the
call flow shown in Figure 5 may be understood with reference to the following
discussion
regarding examples of the type of tags which may be used in the VIN.
The VRCL further provides the ability to queue calls before being transferred
to a live
operator, and to integrate other Web-enhanced telephony applications, such as
Click-to-Talk
application. This is made possible by the use of dedicated XML tags, which can
be interpreted by
POP gateway to implement the desired commands specified therein. Thus, the
VRCL defines a
number of tags or elements (analogous to commands) to control the behavior of
the POP servers.
Figure 6 shows pictorially examples of the types of tags that can be included
in an XML Page that
is generated by an IVR application.
In the description below, the term "conversation controller" refers to the end
point within
the POP server that manages interaction with the IVR application or a CFM. As
shown, the XML
Page element is the root element for every XML Page used by the CFM and/or IVR
for
communication with the POP gateway. The Page element can have the following
attributes
(among others):
TYPE An IVR application should use the value "IVR" while
other applications may use different values (e.g. a Call
Flow Manager may use the value "CC") to identify the
source of the page.
CUSTID A unique identifier for the call center.
PAGEID (optional) A character string (can be numerals) to identify
each page.
SESSIONID An identifier for the particular session with the caller.
This may be part of a query-string that is sent by a POP
gateway in the HTTP request for each page.
HREF The URL of the next XML Page to fetch if the end of the
page is reached (a child element may transfer control to
another URL from somewhere within the page).
Each XML Page represents a unit of work (i.e., a work order) to be performed
by the POP
gateway. The unit of work may consist of a single action or it may consist of
a linear list of
several actions. At the top-level, basic elements (e.g., PLAY, TONEMAP,
VOICEMAP and
EXCEPTIONMAP), complex elements (e.g., MENU, FORM), and/or anchor elements for
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
labeling (e.g., A) may be included in a Page. In addition a RECFILE element
for handling voice
recordings and/or a SET element for setting user-defined variables may be
provided (not shown in
the diagram). The sub-elements of an XML Page root are oriented towards call
flow, interaction
with a caller or call control.
Some possible children (sub-elements) of an XML Page root element that are
oriented
towards call flow and interaction management are: PLAY, TONEMAP, VOICEMAP,
EXCEPTIONMAP, MENU, FORM, A, RECFILE, and SET. Sub-elements oriented towards
call
control are: CREATE LEG_AND DIAL, HANGUP_AND DESTROY LEG, QUEUE_CALL,
QUEUE_DROP, BRIDGE CALL, UNBRIDGE_CALL, LEG WAIT, ALERT LEG, and
END SESSION. These sub-elements can occur in any order and multiple times. The
CFM is
able to utilize a larger set of more primitive call control tags which cannot
be issued by an IVR
application. This is because the CFM is a VIN supervisory process.
The PLAY element allows an IVR application to direct a POP gateway server to
play a voice file, pause for a specified amount of time, play out a number or
set of digits,
and so on. It can have the following attributes:
INTERRUPTIBLE (optional) YES or NO. By default a message being
played is interruptible by a tone input. However, it can
be made non-interruptible by using a value of NO
(except in a MENU - see below).
PLAY has several possible children elements, which can be used in any order,
any number of
times: VOICE, PAUSE, STRING, DATE, TIME, NUMBER, CURRENCY, ORDINAL,
INDEXFILE, and DTMF.
The VOICE element specifies the voice file to be played. The voice file can be
any
computer-readable audio file, such as a .vox file or a .wav file. In one
embodiment the VOICE
element has two attributes, one of which (SRC) is required and the other of
which (TEXT) is
optional.
SRC The fully specified URL of the file to be played.
TEXT (optional) A textual rendering of what is in the
SRC file.
VOICE has no children and is an empty element (i.e., the closing tag can be a
simple"/>" at the
end of the attributes).
The PAUSE element specifies a period of silence. It may, for example, follow a
VOICE
tag within a PLAY element. If its parent PLAY tag is not part of a MENU or a
FIELD, the
PAUSE merely introduces silence for the specified TIME. On the other hand, if
its parent PLAY
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
tag is part of a MENU or FIELD, the PAUSE works as a timeout period, during
which time the
caller is expected to enter at least one digit (see also the description of
MAX_IDD -- max inter-
digit-delay -- in the INPUT tag description below).
PAUSE has two attributes: TIME and UNIT:
TIME The value of the time-period for which silence is
desired, and during which caller input is desired
(if part of a MENU or FIELD).
UNIT (optional) The units (SEC or TENTHS) in which
the TIME is specified. TENTHS means unit = 0.1
SEC.
PAUSE has no children.
The STRING element, which has no children, is used to indicate that the IVR
application
wants the POP server to play out a string of letters, digits and/or special
characters, one at a time.
It has two attributes, both of which are required.
SRC The URL of the index file (see below) to be used by the
voice subsystem for speaking out the characters.
VALUE The string of letters/digits/characters to be played out.
The string can contain any combination of the following
symbols:
A,B,C,D,E,F,G,H,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,
2,0,1,2,3,4,5,6,7,8,9, +,<,_,%,-,>,&,.,#,*,@, etc. (i.e.,
any ASCII character). Note, because of the special
meaning that conventional XML parsing code attaches
to "<", ">", and "&" symbols, these may need to be
actually written as "<", ">" and "&"
respectively.
As an example of how the STRING tag may be used, consider VALUE = "IBM". When
played out, this will be rendered as "Aiyee Bee Emm". If VALUE = "3+4", the
phrase played out
will be "Three Plus Four", and so on. A special index file to be used when
playing out STRING,
DATE, TIME, NUMBER, CURRENCY, and ORDINAL data may store sounds for all the
common prompts used in playing out these types of data. It may also include a
header section in
the beginning of the file that is an array of offsets pointing, in a well
defined order, to the starting
points of the prompts therein. The format of the index file is not critical to
the present invention.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
11
The DATE element is used to indicate that the IVR application wants the POP
server to
play out a date to the caller. It has three attributes, all of which are
required.
SRC The URL of the index file to be used by the
voice subsystem for speaking out the date
(see the above description of the STRING
tag).
VALUE The value of the date to be spoken out. The
value may be specified as yyyymmdd (8
digits) ,mmdd (4 digits), w:yymmdd(10
characters), w:mmdd (6 characters), or
another user-defined format. w refers to the
day of the week with 0 corresponding to
Sunday, 1 to Monday and so on. yy, mm and
dd refer to the year, month and day of the
month, respectively.
FORMAT This indicates how the date should be played
out. Possible values of this attribute are
DDMM, MMDD, DDMMYYYY
,MMDDYYYY, W:DDMM, W:MMDD,
W:DDMMYYYYY and W:MMDDYYYY.
For example, DDMMYYYY means that the
date should be spoken out as "day - month -
year". W:MMDD means that the date should
be spoken out as (say) day of the week -
month - day of the month.
DATE has no children.
The TIME element may be used to indicate that the IVR application wants the
POP server
to play out a time to the caller. It has three attributes, all of which are
required.
SRC The URL of the index file to be used by the voice
subsystem for playing out the time (see the above
description of the STRING tag).
VALUE The value of the time to be played out. It may be
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
12
specified either as hhmm (4 digits) or as hhmmss (6
digits), or another user-specified format (e.g., in 24 hr
time fashion).
FORMAT Describes how the time should be played out.
Possible values are 12 HOUR or 24 HOUR.
TIME has no children
The NUMBER element may indicate that the IVR application wants the POP server
to
play out a number to the caller. It has two attributes, both of which are
required.
SRC The URL of the index file to be used by the voice
subsystem for speaking out the number (see the
above description of the STRING tag).
VALUE The value of the number to be played out.
NUMBER has no children
The CURRENCY element may be used to indicate that the IVR application wants
the
POP server to play out a money value to the caller. It has three attributes,
all of which are
required.
SRC The URL of the index file to be used by the voice
subsystem for speaking out the currency (see the
above description of the STRING tag).
VALUE The value of the currency to be spoken out. It may
or may not have a decimal point.
COUNTRY 3 character (e.g., ISO-4217 compliant) currency
code.
CURRENCY has no children
The ORDINAL element may be used to indicate that the IVR application wants the
POP
server to play out an ordinal (e.g. "First", "Third" etc) to the caller. It
has two attributes:
SRC The URL of the index file to be used by the voice
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
13
subsystem for speaking out the ordinal.
VALUE The value of the ordinal to be spoken out. The
allowed values may be:
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
20,21,22,23,24,25,26,27,28,29,30,31,40,50,60,7
0,80,90,100,1000,1000000,1000000000, etc.
ORDINAL has no children
The INDEXFILE element may be used by an IVR application for playing date,
currency,
digits etc., if the above-mentioned index file format is unsuitable for
playing the desired prompts
(e.g., the call center may use some additional prompts or the call centei s
index file may not
conform to the above-described file type). In such a case the IVR application
should not use the
DATE, CURRENCY, etc., tags described above, but rather use the INDEXFILE tag
and specify
the offset and length within the file to ensure that the desired prompts are
played out.
INDEXFILE may have up to four attributes:
SRC The URL of the call center's index file to be used by
the voice subsystem for playing out the prompts.
OFFSETS A list of comma-separated offsets, indicating the byte
offsets for the starting points of the prompts to be
played in the file. For example OFFSETS may have a
value of: "0031545,0038040,0022060,0041122" for
the phrase "MSFT, assuming that the offsets for the
beginning of M, S, F and T prompts are 0031545,
0038040, 0022060 and 0041122, respectively.
LENGTHS A list of comma-separated lengths, indicating the
lengths of the prompts to be played in the file. There
should be one-to-one correspondence between the
OFFSETS and the LENGTHS.
TEXT An optional textual rendering of what is in the
prompts.
INDEXFILE has no children.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
14
The DTMF tag should only be used as a child tag under PLAY. The purpose of
this tag is
to allow the IVR application to send an in-band DTMF tone on an already
established call to an
ACD/PBX. This allows the IVR application to send account numbers, etc., and
take the ACD/CTI
application to a stage where the caller will not have to re-enter/repeat
information before talking
to a live operator. The DTMF tag has only one attribute:
VALUE The tones that are to be sent (e.g.
"2690",*#,3396"). A comma in the value may
be used to indicate a pause
A PLAY DTMF combination should not be used within a MENU so that no
interference
between tones within a MENU will result. DTMF has no children.
The TONEMAP element allows an IVR application to specify a mapping between
tone
keys entered by the caller and URLs of XML Pages to go to in response to the
user input. A
TONEMAP can exist either at the top level within a XML Page or it can be used
as a sub-element
of a MENU. In the first case (when specified outside a MENU), the TONEMAP has
global effect
in the sense that it is remembered across pages. In the second case (when
specified as part of a
MENU) its scope is local.. Within a MENU the local TONEMAP takes precedence
over the global
TONEMAP for TONEs (see below) which are in conflict between the two maps. For
TONEs in
the global TONEMAP that do not have any conflict with a local TONEMAP, such
TONES will
have the same effect as for the global case, even within the MENU. After a
MENU is exited, the
applicable TONEMAP reverts to the applicable global TONEMAP.
TONEMAP may have a TONE child element, which may be used to specify the
mapping
between one tone key and the URL from which to fetch the next page. TONE has
the following
attributes. The first (TONEID) is required. One out of the second or third
attributes must also be
entered.
TONEID One of 0,1,2,3,4,5,6,7,8,9,*, #,OTHER.
OTHER includes all the remaining keys left
unspecified in the TONEMAP. (required)
HREF The URL from which to fetch the next page.
This can also point to a label within the
current Page (see description of the A
element, below). (optional in place of
REPEAT)
REPEAT Value must be MENU. This allows control to
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
go back to the PLAY at the beginning of the
MENU in case the associated tone key is
entered. (optional in place of HREF)
TONE has no children
The VOICEMAP element allows an IVR application to specify a mapping between
certain voice inputs received from a caller and URLs of XML Pages to go to in
response thereto.
A VOICEMAP can exist either at the top level within an XML Page or it can
occur as a sub-
element of a MENU. In the first case (when specified outside a MENU), the
VOICEMAP has
global effect in the sense that it is remembered across pages (e.g., any time
a caller says
"operator", a certain URL's XML Page may be accessed to transfer control to an
operator). In the
second case (when specified as part of a MENU) its scope is local. Within a
MENU the local
VOICEMAP takes precedence over the global VOICEMAP for PHRASES (see below)
which are
in conflict between the two maps. For PHRASES in the global VOICEMAP that do
not have any
conflict with the local VOICEMAP, they have the same effect as for the global
casse, even within
the MENU. After the MENU is exited, the applicable VOICEMAP reverts to the
global
VOICEMAP.
VOICEMAP may have a PHRASE child element, which specifies the mapping between
one voice command (phrase) and the URL from which to fetch the next XML Page
in response
thereto. It has two attributes, both of which are required.
SRC A voice recognition file or a voice grammar
file.
HREF The URL from which to fetch the next page.
This can also point to a label within a page
(see description of the A element, below).
PHRASE has no children
The EXCEPTIONMAP element may be used to specify a mapping between certain
exceptions (for example a timeout) and the URLs of the XML Pages to fetch in
the case of such
an event. Like a TONEMAP, an EXCEPTIONMAP can be either global (when it occurs
at the
top level as a sub-element of an XML Page) or local (as a sub-element of FIELD
or MENU) in
scope. Within a FIELD or MENU the local EXCEPTIONMAP takes precedence over the
global
EXCEPTIONMAP for EXCEPTIONS (see below) which are in conflict between the two
maps.
For EXCEPTIONS in the global EXCEPTIONMAP that do not have any conflict with
the local
EXCEPTIONMAP, they still have the same effect as for the global case, even
within the FIELD
or MENU. After the FIELD or MENU is exited, the applicable EXCEPTIONMAP
reverts to the
global EXCEPTIONMAP.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
16
The EXCEPTIONMAP may have EXCEPTION children elements, which specify the
mappings between exceptions and the URL from which to fetch the corresponding
pages, if such
exceptions are encountered. EXCEPTION has three possible attributes: EVENT,
which is
required; HREF, which is required for a global EXCEPTIONMAP; and REPEAT, which
may be
used in place of HREF for an EXCEPTIONMAP within a MENU or FIELD.
EVENT Possible values:
TOOFEWDIGITS - applicable in
FIELDs. The number of digits entered by
the caller is less than expected.
TIMEOUT - caller entered no input
within a period specified by previous
PAUSE tag
CALLERHUP - caller unexpectedly
hangs up
OTHER - catch-all for unanticipated
exceptions
HREF The URL from which to fetch the next
page in case of the exception specified by
EVENT being encountered. This can also
point to a label within the current page
(see description of the A element below)
REPEAT Value can be "MENU" or "FIELD" for an
EXCEPTIONMAP specified within a
MENU or FIELD. This allows control to
go back to the PLAY at the beginning of
the MENU/FIELD in case the
EXCEPTION occurred.
An EXCEPTION can be raised at any time and it may be a completely asynchronous
event (e.g., where the caller hangs up suddenly). Therefore it is useful to
specify a default global
CA 02389075 2002-04-25
WO 01/35617 PCT/US00141354
17
EXCEPTIONMAP in one of the very first XML Pages sent by the IVR application.
EXCEPTION has no children.
The MENU element offers an IVR application the ability to have a POP server
play a
message and then collect a caller's selection (from a menu of choices) and
fetch a new XML Page
based on such selection. The caller can make his/her selection by either
entering a tone key or
speaking a word or phrase (if voice recognition is supported). MENU has one
attribute:
MAXREPEATS (optional) The maximum number of times
control can return to the beginning of the
MENU. To prevent infinite loops, control
goes to the HREF specified in the XML
Page tag specified at the top of the page if
a REPEAT exception is encountered more
than MAXREPEATS times in succession.
Note, MAXREPEATS also applies to the
case where control goes back to a FIELD
tag by virtue of using an A (anchor) label.
MENU can have the following children: PLAY, TONEMAP, VOICEMAP, and
EXCEPTIONMAP. One or both of TONEMAP and VOICEMAP should be present. When used
in a MENU, PLAY should include a PAUSE sub-element to specify a timeout within
which it
expects the caller to enter a tone or provide a voice input. If the caller
enters no tone/voice input
within the timeout period, control may go to the HItEF specified in the
TIMEOUT EXCEPTION.
If no TIMEOUT EXCEPTION is specified in the local EXCEPTIONMAP, the global
EXCEPTIONMAP is consulted. If no TIMEOUT EXCEPTION exists even at the global
level,
then the next page as specified in the HREF attribute of the current XML Page
is fetched. This
same hierarchy of exception handling may be used for all exceptions. It is
also possible to
transfer control to an anchor/label on the current XML Page by using the A sub-
element (see
below) and specifying #label in the XML Page's HREF attribute.
A FORM element may be used to instruct the POP server to collect information
(e.g.,
multi-key inputs or voice recordings) about a number of FIELDS and then send
the information
back as NAME, VALUE pairs to the HREF specified in the FORM.
A FORM can have the following attributes (only HREF is required):
HREF The URL to send the information collected from
the caller to. This URL will typically be a binary
program or a pert, java or ASP script.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
18
METHOD (optional) GET or POST. Specifies whether the
data is sent to the URL as a query-string or as
standard input.
SRC (optional) The URL of a file (e.g., a .vox file) to
play while the data submitted in the FORM is
being processed by the IVR application. The file
will typically contain a message like "please wait
while we process your input". If the SRC attribute
is not included, the caller will hear silence while
the POP server is waiting for the IVR application
to send the next XML Page after processing the
FORM data.
SUBMIT PARTIAL (optional) This specifies whether the FORM should
be submitted to the IVR application if the caller
hangs up after filling out some or all of the fields
and does not remain on-line to interact with the
IVR application. Possible values are:
PARTIAL OK: send values for whatever
fields have been filled up
COMPLETE ONLY: send values only if
all fields have been filled
LAST FIELD HUP: send values if all the
fields have been filled in and the caller is
still interacting with IVR or the caller
hangs up while entering data (or recording
voice) for the last field
POSTHREF (optional - for voice fields only). This is the URL
of an application that will receive the voice
recording files. The voice file that contains a
message recorded by the caller is POSTed by the
POP server at a later time, determined by a
network manager. The manager (which may be a
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
19
software application) ensures that not too much of
the available network bandwidth is consumed in
transporting the voice recording files. The
POSTHREF URL should contain within the query
string the following:
?SESSIONID=$sessionid$ &
FIELDNAME=$fieldname$ & RESULT=$status$
A FORM may have one or more FIELD children, which allow the POP server to
collect
information (e.g., mufti-key input or voice recordings) for a single named
field according to
certain rules specified in the INPUT sub-element. A FIELD has the following
attributes:
HREF (For VOICE only). The URL where the
contents of the voice file are to be POSTED
after the recording of the voice file is
complete
If no HREF is specified then the network
manager will POST the files to the
POSTHREF specified in the FORM.
MAXREPEATS (optional) The maximum number of times
control can go back to the beginning of the
FIELD. To prevent infinite loops, control
goes to the HREF specified in the XML
Page tag specified at the top of the page, if a
REPEAT exception is encountered more
than MAXREPEATS times in succession.
Note that MAXREPEATS also applies to
the case where control goes back to the
FIELD tag by virtue of using the A (anchor)
label.
A FIELD should always be composed of a triplet consisting of the following sub-
elements:
PLAY, INPUT, and EXCEPTIONMAP
The INPUT element specifies the rules for the telephony interface at the POP
server for
collecting input for a FIELD. It can have the following attributes:
NAME The name of the variable in which to collect the
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
caller's input. For VOICE input, the value of
NAME (in the NAME,VALIJE pairs sent back by
the FORM) is either the FILENAME returned in
the RECFILE tag by the application, or is the
URL of the recording file that has been stored
locally on the POP server (see also HREF
attribute description for FIELD tag). If
POSTHREF is specified in the FORM the value
of NAME (in the NAME,VALUE pairs sent back
by the FORM) is the name of the recording file
that has been stored locally on the POP server.
TYPE (optional) TONES or VOICE or EITHER to
indicate the type of expected input.
MINDIGITS (Optional) Minimum number of digits required for
the field (not valid for voice).
MAXDIGITS (optional) Maximum number of digits that can be
entered for this field (not valid for voice). Add I
for the ACCEPT key if so specified.
ACCEPT (optional) The tone key which signals the end of a
user's input (e.g. "#" ).
MAX_IDD (optional) The maximum interdigit delay in
seconds, after which the end of a user's input is
implied.
MAXSILENCE (optional) During recording of voice input, the
maximum silence (in seconds) before the end of a
user's input is implied.
MAXRECLEN (optional) During recording of voice input, the
maximum length of the message in seconds, that
can be recorded.
VOICEFILE_FORMAT (optional) Desired format and sampling rate for
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
21
the recording file.
INPUT has no children.
If POSTHREF is specified in the FORM tag, then the IVR application will first
receive
an HTTP GET request with the NAME, VALUE pairs for the different fields as
specified in the
INPUT NAME attributes. The values will be the names of the recording file that
has been stored
locally on the POP server. If necessary, the IVR application may playback the
contents of the
recording file to the caller. Later, the IVR application will receive multiple
HTTP POST requests
with the binary data of the recorded files in the contents.
A RECFILE tag may be used by an IVR application in response to a POST request
containing data for a VOICE field input. It has the following attribute:
FILENAME Name of the file in which the POSTed voice
data has been stored by the IVR application
server.
RECFILE has no children.
The "A" (anchor) element may be provided as a labeling mechanism in an XML
Page. A
URL can specify a target within a current or different XML Page by using #name
(as in HTML).
This provides the ability to direct a POP server to start parsing and
executing an XML Page not at
the beginning of the page but at a labeled point within the page. It can also
be used as a
mechanism to jump to a certain point within a current XML Page. A has one
required attribute
and has no children.
NAME The label name by which this anchor will be
referred to by URLs.
The SET element allows an IVR application to set the value of a user-definable
variable
for later substitution by a POP server. It is a convenient mechanism to allow
an IVR application
to specify an association between a particular value and a particular variable
name such that the
POP server should substitute the variable name with the value when the IVR
application uses the
variable name later in the same or another XML Page. SET has two required
attributes and no
children.
VARNAME The name of the variable.
VALUE The value to assign to the variable.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
22
SET thus offers a stateless IVR application a powerful mechanism to maintain
state and
use session variables for any Web server environment. The IVR application may
define and set
the value of a session variable (a variable that lasts during the life-time of
a current session/call)
by using the SET tag. The value of the session variable can then be later
retrieved by the
application by putting the variable in the query string of the application URL
that needs to use the
value of the variable.
Described below are the call control oriented tags that an IVR application may
issue to
the POP server. The CREATE LEG AND DIAL element may be sent by an IVR
application in
order to make an outbound call. The attributes of CREATE LEG AND DIAL are:
TELNUM The telephone number that the telephony
server needs to call.
IVRURL URL from where the conversation controller of
the new leg should fetch its first XML Page
after the outbound call is made and the call is
answered. This can be used by the IVR
application to play an audio message or to
carry out other VRCL commands. This
attribute can also carry a value of LEG WAIT,
in which case the new conversation controller
just goes into an interruptible wait state and the
person answering the phone at the called
number hears silence until an interrupt causes
the conversation controller to bridge the call.
The IVRURL is not used when the BRIDGE
attribute is set to YES.
ANI (optional) The ANI that the telephony manager
should send in the outgoing call.
BRIDGE (optional) YES or NO. If YES, the new call is
bridged with a call on a current LEG as soon as
the new call is dialed and answered.
The TELNUM attribute can contain commas in its value. A comma has two meanings
inside TELNUM. The first comma (from the left) signifies that the digits to
the left of the first
comma will be used for dialing out and establishing the call, while the digits
to the right of the
first comma will be sent out as in-band DTMF tones on the established call.
The commas) within
WO 01/35617 CA 02389075 2002-04-25 pCT/US00/41354
23
the digits to the right of the first comma signify that a pause should be
inserted for each comma in
the DTMF tone sequence. For example TELNUM='12159090",**,90061234#" instructs
the
telephony server to dial 12159090 for establishing the call, pause, send **
tones, pause and send
90061234# tones. If better control is needed in order to make sure that the
call is answered
before any tones are sent, PLAY DTMF tags should be used by sending the
created leg to
IVRURL and using these tags in the XML Page sent back by IVRURL. In that case,
the
BRIDGE=NO option should be used. Using commas in the TELNUM field provides a
convenient
mechanism for combining dialing out with fixed pauses and sending some in-band
DTMF tones,
but it does not provide as much control as the DTMF tag.
CREATE LEG AND DIAL does not have any children. Normally a
CREATE LEG AND_ DIAL tag will be followed by a LEG WAIT tag (or a PLAY
followed by
a LEG WAIT) in order to wait for the other leg to synchronize with this leg.
Upon receiving this tag, the telephony server sends a CREATE_LEG AND_DIAL_REQ
NextAction request to the CFM. The CFM reserves an outbound port on an
appropriate
telephony server (based on TELNUM), creates a new conversation controller on
the telephony
server and then sends a DIAL_CALL XML tag and (optionally) a BRIDGE CALL tag
to the new
conversation controller to make an outbound call and bridge it to the current
call. In the case of
errors, the global EXCEPTIONMAP is consulted and the URL corresponding to
CREATE LEG ERROR, DIAL ERROR or BRIDGE ERROR is contacted, depending upon the
type of error.
The HANG UP_AND DESTROY LEG element may be used by an IVR application to
inform the POP server that the call on the designated leg should be terminated
and the
conversation controller (LEG) receiving this tag should be destroyed. The
attributes of this
element are:
REASON (optional) NORMAL or ERROR or
CALLERHUP.
This element does not have any sub-elements.
A QUEUE_CALL tag may transmitted by the IVR application to put a call on hold.
The
attributes of this tag are:
AGENTGRP Identifies the agent group where call should
be queued (e.g. SALES).
STATUS INT_TIME (optional) This is the interval at which the
IVR application should be informed about
the status of the queued call.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
24
STATUS INT_URL (optional) This is the URL where the IVR
should be informed about the status of the
call on hold after receiving the CFC
interrupt to give ICR/ACD status.
(The QUEUE_ERROR exception in the
global EXCEPTIONMAP will be
consulted).
ACD_TELNUM (optional) This is the outbound telephone
number that needs to be dialed by the
telephony server to queue the call with the
ACD
ANI (optional) This is the ANI that the IVR
application wants the POP server to insert
into the outbound call that will be placed to
the ACD or ICR. This can be either a
telephone number or the string $ANI$
USR_PARAMS (optional) Information that the caller
entered into the IVR system before
requesting transfer to an operator. This field
would contain sub-parameters and values
separated by colons (": ") with the different
parameter-value pairs separated by commas
e.g., PARAM1:25, PARAM2:busy,
PARAM3:411. The names and values of the
sub-parameters are translated by the ACD
adapter for interpretation by the ACD.
AGENT URL (optional) This the URL from where the
LEG of the telephony server with the
outbound call to the ACD should get its
XML Page after the AGENT is connected.
This can be used for playing some caller-
related information into the agent's
telephone, before the call is bridged with
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
that of the caller.
QUEUE_CALL can optionally have an EXCEPTIONMAP as a child.
The QUEUE_DROP tag is sent by the IVR application when the caller and/or
application
decides that it is not worth continuing to hold the call and that the call
should be dropped from the
ACD _queue. This tag has no attributes, but QUEUE DROP can optionally have an
EXCEPTIONMAP as a child.
The identification of the QUEUE to be dropped is implicit because there can be
only one
queue for a conversation. The telephony server sends a QUEUE DROP REQ to the
CFM upon
receiving this tag.
The BRIDGE CALL tag is sent by the IVR application to bridge a current call
(call on a
current leg) with another call on the same POP server or a call on a different
gateway on a
different POP gateway. BRIDGE CALL has one required attribute:
LEG ID The identification of the other leg to be bridged
with the call on the current leg. A value of
ALL will bridge the call on the current leg with
all other calls associated with various legs of
this session.
BRIDGE CALL can optionally have an EXCEPTIONMAP as a child.
After the two calls are bridged, all bridged calls go into a LEG WAIT state.
If there is an
error in bridging the calls, the BRIDGE ERROR exception is raised and the next
XML Page is
fetched from the HREF specified in the exception.
An XML Page with the UNBRIDGE_CALL tag is sent by the IVR application in to
break the bridge between various legs of a call. The attributes of UNBRIDGE
CALL are
LEG_ID (required) Used to identify the other leg
which is to be unbridged. A value of ALL
will break the bridge between the current
leg's call and all other calls bridged with the
current call.
OTHER LEG_URL (optional) The URL from where the other
legs) should fetch their next XML Page
after being unbridged. If this attribute is
omitted, the other legs) will continue in
LEG WAIT state and an ALERT LEG tag
will be needed to wake them up.
It is assumed that one of the legs is implicitly the one receiving this
UNBRIDGE_CALL tag.
CA 02389075 2002-04-25
WO 01/35617 PCT/ITS00/41354
26
UNBRIDGE_CALL can optionally have an EXCEPTIONMAP as a child. After the calls
are unbridged, the POP server executes the next tag following the
UNBRIDGE_CALL tag or (if
there is none) fetches the next XML Page from the HREF specified in the XML
Page root
element tag at the top of the page. If there is an error in unbridging the
calls, the
UNBRIDLE ERROR exception is raised and the next XML page is fetched from the
HREF
specified in the exception.
An XMLPage with the LEG WAIT tag is sent by the IVR application to put the
conversation controller receiving this tag into a wait state. The conversation
controller is then
expected to do nothing except wait for an event from the telephony manager
(e.g., caller hangup)
or an interrupt from the CFM or an ALERT LEG tag from the IVR application.
LEG_WAIT has
no attributes and no children.
The ALERT LEG tag is used by the IVR to interrupt a conversation controller
thread in a
LEG WAIT state and to instruct it to send an HTTP GET request to the URL
specified as an
attribute. The attributes of ALERT LEG are:
LEG ID The identifier of the other legs) that
is/are to be alerted. The legs to be
alerted would normally be sitting in a
LEG WAIT state.
If a value of ALL is used, all other legs
of this session will be alerted.
IVRURL URL from where to fetch the next XML
Page for the other legs after they have
been alerted.
ALERT LEG has no children. This tag may be used, for example, after unbridging
a call to alert
the other leg and direct it to a specified URL.
An END_SESSION may be used by the IVR application to destroy all LEGS of a
current
session and hang up all the associated calls. This gets translated into a
END_SESSION REQ
NextAction request which is sent by the telephony server to the CFM. Upon
receiving such a
request, the CFM then sends HANGUP_CALL and DESTROY LEG tags to all the
conversation
controller threads associated with the session.
Some examples of the uses of the above tags may be helpful at this point. In
the first
example, Example 1, an XML Page for playing out a welcome message and setting
a global
TONEMAP and EXCEPTIONMAP is presented. First, the page type and customer
identifiers are
specified. Note that a call center server URL of "customer.com" is used as an
address where the
various pages are stored.
<!-- Example # 1 -->
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
27
<?xml version--'1.0" ?>
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID--'"0001"
VERSION=" 1.7"
SESSIONID-=' 3"
HREF="www.customer.coin/tele/initial.asp?SESSIONID=3" >
Now, a global TONEMAP is defined. The TONEMAP allows a caller to press a 0 at
any
time and get through to an operator, or to press the * key and go straight to
a login menu. Also, if
the caller presses an invalid key, control transfers to another XML Page,
located at the specified
HREF, that handles such a case. This will apply to all subsequent pages unless
over-ridden by a
new TONEMAP.
<TONEMAP >
<TONE TONEID="0"
HREF="www.customer.coin/tele/operator.asp?SESSIONID=3" />
<TONE TONEID--'"*"
HREF="www.customer.com/tele/login.asp?SESSIONID=3" />
<TONE TONEID="OTHER"
HREF="www.customer.coin/tele/problem.asp?SESSIONID=3" />
</TONEMAP>
Now a global EXCEPTIONMAP can be defined. The EXCEPTION MAP causes an
exception to be raised any time the caller fails to press a key within a
specified timeout period
when asked to enter a FIELD value or make a choice from a MENU. Control then
transfers to the
specified timeout exception handler (timeout.asp?SESSIONID=3). An exception is
also raised if
the caller hangs up suddenly. The HREF attribute in each EXCEPTION specifies
which XML
Page to fetch next in case such an exception happens. The global EXCEPTIONMAP
applies to all
subsequent pages unless over-ridden.
<EXCEPTIONMAP >
<EXCEPTION EVENT--"TIMEOUT"
HREF="www.customer.coin/tele/timeout.asp?SESSIONID=3" />
<EXCEPTION EVENT--"CALLERHUP"
HREF="www.customer.coin/tele/terminate.asp?SESSIONID=3" />
<EXCEPTION EVENT="OTHER"
HREF="www.customer.coin/tele/error.asp?SESSIONID=3&ERROR=$last-error$
& DESCRIPTION=$last-error-
string$&URL=$error-url$ />
</EXCEPTIONMAP>
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
28
Now commands can be issued to play a greeting message. The message should not
be
interrupted by the caller and so there is an instruction to ignore any keys
that he/she may press
while the message is playing.
<PLAY INTERRUPTIBLE="NO" >
<VOICE SRC="www.customer.com/tele/greeting.vox" TEXT--"Welcome to
Customei s Call Center" />
<PAUSE TIME--"1" UNIT-='SEC" />
</PLAY>
</XMLPage>
On reaching this end of the page, the next XML Page specified at the start of
the initial Page will
be fetched (initial.asp).
A second example, Example 2, provides an XML Page for announcing a set of
choices and accepting a single tone input from a caller.
<!-- Example # 2 -->
<?xml version="1.0" ?>
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID="v101"
VERSION=" 1.7"
SESSIONID=" 3"
HREF="www.customer.com/tele/custsvc.asp?SESSIONID=3" >
<A NAME="labell" />
<1VIENU>
<PLAY>
<VOICE SRC="www.customer.com/tele/initial.vox" TEXT="Press 1 if you have
an account, Press 2 to open an account" />
<PAUSE TIME="5" />
</PLAY>
<TONEMAP >
<TONE TONEID="1"
HREF="www.customer.com/tele/login.asp?SESSIONID=3" />
<TONE TONEID="2"
HREF="www.customer.com/tele/newacc.asp?SESSIONID=3" />
<TONE TONEID="OTHER" HREF="#label l" />
</TONEMAP>
<EXCEPTIONMAP >
<EXCEPTION EVENT="TIMEOUT" HREF="#labell" />
</EXCEPTIONMAP>
</MENU> -
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
29
</XMLPage>
With the global TONEMAP as specified on the previous Page (from Example 1),
this
Page's local TONEMAP will cause "0", "*", "1" and "2" to be all valid
responses. After the
MENU is exited, the TONEMAP specified within the MENU is no longer applicable
and only
"0" and "*" will be accepted as valid tones. Recall that any global map
(EXCEPTIONMAP as
well as TONEMAP) that needs to be acted upon in a FORM or MENU in an XML Page
must be
placed above the FORM or MENU. The execution of the tags in an XML Page is
sequential in
nature. One should not expect a map defined at the end of the Page to have an
effect on the tags
executed in that Page. If no tone is entered by the caller within the timeout
period specified in the
PAUSE sub-element of PLAY in the above MENU, a TIMEOUT exception is raised and
control
goes to the corresponding HREF (in this example to the A label with
NAME="labell"). If an
invalid key is entered, TONEID=OTHER applies and control again goes to labell.
REPEAT--"MENU" could have been used instead of HREF=#label l to achieve the
same effect in
the TIMEOUT EXCEPTION.
In the following Example 3, an XML Page for accepting a set of input fields (a
Social
Security Number and Password) is presented. A FORM element allows a caller to
enter multiple
FIELDS before the data is sent over to the call center. For example in the
following FORM data
for both the ssnum and passw FIELDS is collected before it is sent (when the
end tag </FORM> is
encountered).
<-- Example # 3-->
<?xml version--" 1.0" ?>
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID="v102"
VERSION-= ' 1.7"
SESSIONID--'" 3"
HREF="www.customer.com/tele/operator.asp?SESSIONID=3" >
<FORM METHOD--"GET" HREF="www.customer.tele/cgi-
bin/validate.asp?SESSIONID=3" >
<FIELD HREF="www.customer.com/tele/ss.asp?SESSIONID=3"
MAXREPEATS--''3">
<PLAY>
<VOICE SRC="www.customer.com/tele/ss.vox" TEXT--"Please enter your 9 digit
social security number"/>
<PAUSE TIME=" 10" />
</PLAY>
<INPUT NAME="ssnum" MINDIGITS-='9" MAXDIGITS--"9"
MAX IDD="2/>
<EXCEPTIONMAP >
<EXCEPTION EVENT--"TIMEOUT" REPEAT--"FIELD" />
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
<EXCEPTION EVENT--"TOOFEWDIGITS"
HREF="www.customer.com/tele/invalid.asp?SESSIONID=3" />
</EXCEPTIONMAP>
</FIELD>
<FIELD HREF="www.customer.com/tele/passw.asp?SESSIONID=3"
MAXREPEATS="3">
<PLAY>
<VOICE SRC="www.customer.com/tele/passw.vox" TEXT--"Please enter your 3-
7 digit password followed by the pound sign"/>
<PAUSE TIME="5" />
</PLAY>
<INPUT _NAME="passw" MINDIGITS="3" MAXDIGITS--''8" MAX_IDD="2"
ACCEPT="#" />
<EXCEPTIONMAP >
<EXCEPTION EVENT="TIMEOUT" REPEAT--"FIELD" />
<EXCEPTION EVENT="TOOFEWDIGITS" REPEAT="FIELD" />
</EXCEPTIONMAP>
</FIELD>
</FORM>
</XMLPage>
Any values input by the caller for the various fields in the FORM are sent as
a query-
string (URL followed by ? and NAME, VALUE pairs) to the URL specified by the
HREF
attribute in the FORM. This query-string is sent when the end tag </FORM> is
encountered. The
MAX_IDD--"2" attribute in INPUT specifies that if no key is entered for 2
seconds since the last
key was entered, it is considered that the caller has finished entering the
input value as if an
ACCEPT key was entered. (IDD is short for Inter-digit-delay). The distinction
between a
TIMEOUT event and MAX_IDD is rather subtle. The EXCEPTION with EVENT= TIMEOUT
is encountered if not even the first digit is entered within the period
specified by PAUSE's TIME
attribute, after the voice file has stopped playing. However, if one or more
digits are entered
within TIME seconds and then no digit is entered for MAX_IDD seconds, the
field input is
considered to be complete. MAXDIGITS for the password field is specified as 8
even though the
max password length is 7. This is to accommodate the # key which is the ACCEPT
character.
In the following Example 4, an XML Page for playing back a caller's account
record
(e.g., an account balance) is provided.
<!--Example # 4-->
<?xml version-= ' 1.0" ?>
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID="0004"
VERSION--" 1.7"
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
SESSIONID=" 3"
31
HREF="www.customer.com/tele/next.asp?SESSIONID=3" >
<PLAY INTERRUPTIBLE--''NO" >
<VOICE SRC="www.customer.com/tele/balance.vox" TEXT="Your account
balance is" />
<PAUSE TIME=" 1" /> <!-- default value of UNIT is "SEC". You need not
include it if time is in seconds >
<CURRENCY SRC=" www.customer.com/tele/currency.indexfile" VALUE="7568.29"
COUNTRY="USD" />
<PAUSE TIME=" 1" />
</PLAY>
<!-- Now ask the caller to make a choice from a MENU for going back to the
main menu
or ending this call>
<MENU>
<PLAY>
<VOICE SRC="www.customer.com/tele/end.vox" TEXT--"Press I to go back to
the main menu, 2 to end this call" />
<PAUSE TIME="5" !>
</PLAY>
<TONEMAP >
<TONE TONEID="1"
HREF="www.customer.com/tele/main.asp?SESSIONID=3" />
<TONE TONEID="2"
HREF="www.customer.com/tele/end.asp?SESSIONID=3" />
<TONE TONEID="OTHER" REPEAT="MENU" /> <!-- repeats the prompt
if any other key is entered -->
</TONEMAP>
</MENU> <!-- no EXCEPTIONMAP specified here because the global
EXCEPTIONMAP is
adequate >
</XMLPage>
In the following Example 5, an XML Page for playing a goodbye message and
transferring
control back to the CFM for ending this call is provided.
<!-- Example # 5 -->
<?xml version--'1.0" ?>
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
32
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID="0004"
VERSION=" I .7"
SESSIONID=" 3
HREF="www.customer.com/tele/CFC.asp?SESSIONID=3&
CC.NEXTACTION=END CALL" >
<!--above query-string tells the Call Flow Manager to end this call -->
<PLAY INTERRUPTIBLE="NO" >
<VOICE SRC="www.customer.com/tele/goodbye.vox" TEXT="Goodbye and
have a nice day" />
</PLAY>
</XMLPage>
Example 6, below, provides an XML page for directing the CFM to transfer a
call to an
operator.
<!-- Example # 6 -->
<?xml version="I.0" ?>
<XMLPage TYPE= "IVR" CUSTID="customer" PAGEID="0004"
VERSION--" 1.7"
SESSIONID--'" 3"
HREF="www.customer.com/tele/CFC.asp?SESSIONID=3$&
CC.NEXTACTION=MADE-OUTCALL&TELNUM= (408)730-
8647" >
<!--above query-string tells the Call Flow Manager to make an outbound
call -->
<PLAY INTERRUPTIBLE="NO" >
<VOICE SRC-='www.customer.com/tele/transferring.vox" TEXT--"You are
being transferred to an operator" />
</PLAY>
</XMI,Page>
In addition to interaction between the IVR application and the POP gateway,
there is also
interaction between the CFM and the IVR application. As mentioned above, the
CFM is a
software component which executes on a server in the VIN and facilitates
communication
between the call center IVR application and the POP gateway server. There need
not be any
direct interaction between the CFM and the IVR application (and whether they
reside on the same
computer platform or different platforms is not important). Instead, these
applications may
communicate directly with the POP server. When control needs to be transferred
from the CFM
to the IVR application, the CFM sends an XML Page to the POP server with the
next HREF
pointing to the IVR application's URL. Similarly when the IVR application
needs to send control
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
33
back to the CFM, it directs the POP server to request the next XML Page from a
URL associated
with the CFM. Any parameters that need to be passed are sent as name/value
pairs in query-
strings after the URL name in the HTTP request. This is explained in more
detail with the help of
specific examples below:
Consider a situation where an incoming call has just been received at a POP
server. With
the help of a central lookup database the POP server learns the customer's
(i.e., the call center
provider's) CFM URL corresponding to the called number. The POP server now
sends a HTTP
request to the following URL:
http://<call-mgr-
url>?DID=<did>&ANI=<ani>&CC.NEXTACTION=PROCESS INCALL
In this example, <call-mgr-url> is the Call Flow Manager URL obtained from the
lookup server
(and does not include the query string); <did> is the called number for the
incoming call; <ani> is
the caller's number for the incoming call; and CC.NEXTACTION=PROCESS INCALL
indicates that the next action required of the CFM is to process a new
incoming call.
In response to the above, the CFM may return an XML Page to the POP server
indicating
whether the call should be accepted or rejected (depending upon the
availability of certain
resources). If the call is to be accepted, the URL of the customer's IVR
application is included in
the (ACCEPT CALL) XML Page, together with a SESSION ID to be included in all
future
communications between the POP server and the customer's IVR application. The
POP server's
first HTTP request to the customer's IVR application would then have the
following form:
http://<ivr-url>?DID=<did>&ANI=<ani>&SESSIONID=<sessionid>
In this example, <ivr-url> is the IVR application's URL sent to the POP server
by the CFM in the
ACCEPT_CALL page; <sessionid> is the SESSIONID sent to the POP server by the
CFM in the
ACCEPT CALL page; <did> is the called number for the incoming call; and <ani>
is the caller's
number in the incoming call
From this point forward, the IVR application is in control and directs what
prompts and
choices the POP server must present to the caller with the help of XML Pages
(such as those
provided in Examples I - 6 above) with the appropriate tags. The SESSIONID is
included as part
of the query-string for each HTTP request from the POP server and as an
attribute in the XML
Page tag in each XML Page sent by the IVR application. DID and ANI need not be
included in
the query-string of any HTTP request from the POP server except the first.
When the IVR application is ready to turn control back to the CFM for ending
the call or
for making an outbound call, the IVR application may send the POP server an
HREF with the
following value:
http://$call-mgr-url$?SESSIONID=$sessionid$&CC.NEXTACTION=END CALL
The only NextAction requests that need to be transmitted to a CFM are
NEW SESSION REQ and END_CALL. NEW SESSION REQ is an interrupt is sent by a Web
application (e.g., Click-to-talk) to a CFM to prompt the CFM to start a new
session. The
parameters for this request are:
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
34
IVRURL: The URL that should be part of a subsequent CREATE LEG REQ interrupt
to
a POP server. This tells the POP server from where it should fetch its next
XML Page
after a new conversation has been started.
TELNUM is used to help the CFM identify the POP server (and gateway) on which
the
new conversation should be started.
NUM LINES specifies the number of outbound telephone lines that need to be
reserved
for this session. For click-to-talk applications, this number will always be
2. The second
phone number needed in a click-to-talk application should be carried inside
the customer
application's IVRURL.
APP NAME identifies the application for which this action is desired. This
helps the
CFM front-end identify the CFM process to which this request should be
presented.
FAILURE_URL specifies the URL that should be used to inform components of the
VIN
that a failure occurred in executing the NEW SESSION REQ.
The response to the NEW SESSION REQ interrupt should be an XML Page containing
a single RESPONSE tag with a RESULT attribute indicating success or failure.
The HREF
attribute in the XML Page header should be null ("").
An END CALL query string may be sent by a POP server to a CFM in response to
either
a normal hang-up by the IVR application/caller or an error situation that
cannot be otherwise
handled (e.g., such as when the IVR server goes down) and there is no option
except to end the
call. If the IVR application wants to end the call, the last XML Page will
have an HIZEF pointing
to the CFM and it will have the following query string: CC.NEXTACTION=END_CALL
&SESSION)D=$sessionid$ &REASON=NORMAL If the caller hangs up in the
middle of the IVR session, the POP server will first send an HTTP request to
the CFM with the
following query string: CC.NEXTACTION=END_CALL plus other name/value pairs.
The POP
server will also send an HTTP request to the IVR application at a URL
specified as part of
CALLERHUP global EXCEPTION. If the IVR server goes down for some reason, the
POP
server may send the following query string to the CFC, depending upon the
value set in the
IVR ERROR exception of the CC EXCEPTIONMAP (the POP server should already have
set
the values of $last-error, $error-url$ and $last-error-string$ by then):
CC.NEXTACTION=END_CALL&REASON=IVR ERROR&SESSIONID=$sessionid
$&ERROR=$last-error$& URL=$last-error-url$&DESCRIPTION=$last-error-
string$.
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
As was the case for communications between the POP server and the IVR
application, the
basic method of communication between the POP server and the CFM is through
the use of XML
Pages. This communication starts as soon as an incoming call is presented at
the POP server, and,
through a DID-to-CalIMgrURL translation using a central lookup server at a
Network Operations
Center (NOC) (see Figure 9), the POP server learns the URL of the CFM. The POP
server sends
information about the request in the form of NAME, VALUE pairs in the query-
string of the
XML Page request. The CFM returns responses in the form of XML Pages with
appropriate
elements. The following elements/tags are available to the CFM for such call
control responses.
In addition, the LEG WAIT tag introduced above may also be used for
communications between
the POP server and the CFM. So too are the BRIDGE CALL and UNBRIDGE_CALL tags
used.
The only difference for the CFM is that it cannot use a LEG ID of ALL. It must
specify one and
only one LEG ID explicitly to bridge and/or unbridge the call.
An "XMLPage" element is the root element for every XML Page used by the CFM
for
communication with the POP server. It can have the following attributes:
TYPE can take on a value of CC or IVR. The CFM uses
value CC (call control).
CUSTID identifies the customer
PAGEID (optional) identifies the page itself
VERSION used by the customer for identifying the version
number of his application
SESSIONID an identifier for identifying the particular session
with the caller
Each XMLPage represents a response to a call control request by the POP
server. The possible children
(sub-elements) of XMLPage are: ACCEPT CALL; LEG WAIT; RESPONSE; DIAL CALL;
BRIDGE CALL; UNBRIDGE_CALL; HANGLJP_CALL; DESTROY LEG; REJECT CALL;
END_CALL; MAKE_OUTCALL; SET; CC EXCEPTIONMAP; EXCEPTION; and
IMMEDIATE TRANSFER.
The ACCEPT CALL element is used by the CFM to alert the POP server that the
resources are available for an incoming telephone call and that the POP server
should accept the
call. The attributes of this element are:
RINGS (optional) An attribute to control the number of
rings in the ringback before answering the call. As
rings as necessary are played until the first XML
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
36
Page from the IVR application is received.
UNIT (optional) value can be SEC or NUMBER to
indicate the units of RINGS.
HREF URL of the IVR application from which the next
XML Page should be fetched by the POP server
after it has answered the call.
This XML Page tag is sent in response to a request from the POP server when an
incoming call comes in. The request to the URL of this page should contain the
DID and, if
available, the ANI of the incoming call as part of the query-string. The
ACCEPT_CALL
response page returns a SESSIONID, which is the unique identifier for the
session created by the
CFM. All future requests from the POP server to the CFM (as well as the IVR
application)
should carry the SESSIONID instead of the DID and ANI. ACCEPT CALL does not
have any
sub-elements as children.
The XML Page containing the ACCEPT element (the very first page from the CFM)
should also include a CC EXCEPTIONMAP containing an IVR ERROR EXCEPTION to
handle non-recoverable IVR errors. The CC EXCEPTIONMAP is a global map and
should be
placed before any ACCEPT tag.
The RESPONSE tag is sent by the CFM or a POP server in response to an
interrupt.
request (see above). It indicates whether the action requested by the
interrupt was successful or
not, and if a failure the reason for the failure. RESPONSE has two required
attributes and no
children.
RESULT SUCCESS or FAILURE.
REASON (optional) - in case of FAILURE, the possible
values are UNKNOWN REQ,
INVALID PARAMETERS, NO_RESOURCES
An XML Page with a DIAL_CALL tag may be transmitted by the CFM in response to
a
request by the IVR and other applications to make an outbound call. The
attributes of
DIAL CALL are:
TELNUM telephone number that the POP server needs to
call
ANI (optional) the ANI that telephony manager
should send in the outgoing call. This value is
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
37
specified by the application in QUE~ CALL
tag
If the outbound call fails, the POP server immediately informs the CFM by
sending a request to
the HREF specified in the EVENT=DIAL ERROR exception. If the outbound call
succeeds,
the POP server falls through to the next tag (if there is one) or to the HREF
in the XML Page tag
at the top of the Page (if DIAL-CALL is the last tag on the Page. DIAL- CALL
has one child
element - CC EXCEPTIONMAP. Also a global CC EXCEPTIONMAP should be specified
with CALLERHUP event. $end-call-url$ should also be set for the conversation
controller by
this time.
A HANG>JP-CALL element is used by the CFM to inform the POP server that the
call
on the leg receiving this tag should be terminated. The attributes of this
element are:
REASON (optional) NORMAL or ERROR or
CALLERHUP.
The HANG>JP-CALL tag differs from the END CALL tag in that it does not destroy
the
conversation controller associated with the dropped call. The HANGUP CALL tag
may be
followed by a DESTROY LEG tag if no more calls are to be made on the
associated conversation
controller or it may be followed by another DIAL-CALL to make another outbound
call.
HANGl~_CALL does not have any sub-elements.
The DESTROY LEG element is used by the CFM to inform the POP server that a
conversation controller should be terminated. The attributes of this element
are:
REASON (optional) NORMAL or ERROR or
CALLERHUP.
DESTROY LEG does not have any sub-elements. Even though it is expected that
DESTROY LEG would be preceded by a HANGS CALL tag if there is an active call
on the
leg, in case the conversation controller does receive a DESTROY LEG without a
preceding
HANG>JP-CALL then it should do the necessary cleanup needed to destroy this
leg.
A REJECT CALL element is used by the CFM to inform the POP server that the
resources for the call have not been allocated and that the POP server should
reject the incoming
call by presenting a busy signal. The attributes of this element are:
REASON (optional). NOPORTS or OTHER.
REJECT CALL does not have any sub-elements.
An END CALL element may be used by the CFM to inform the POP server that the
call
should be terminated. An XML Page with this tag is sent in response to a
request to the CFM
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
38
from the POP server to end the call. The POP server uses CC.NEXTACTION=END
CALL in
the query string of such a request to so advise the CFM. The attributes of
this element are:
REASON (optional) NORMAL or IVR_ERROR or
CALLER REQ.
This tag is also sent back by the CFM to the POP server when an inbound or
outbound call has
already terminated (see MAI~E_OUTCALL below). The CFM cleans up and decrements
its
resource usage count after sending this tag to the POP server. END CALL does
not have any sub-
elements.
An XML Page with a MAI~E_OUTCALL tag is sent by the CFM in response to a
request
by an IVR application to make an outbound call and bridge the caller's
incoming call to this
outbound call. This request is made by the POP server on behalf of the IVR
application by
following the HREF on an XML Page sent by the IVR application. For example, if
the IVR
application wants to connect the caller to an operator when he/she presses the
key "0", the last
XML Page sent by the IVR application should have an HREF corresponding to
TONEID=0 with
the following value:
http://$call-
mgrurl$?SESSIONID=$sessionid$&CC.NEXTACTION=MAKE OUTCALL&
TELNUM=<tel-num>,
where <telnum> is replaced by the telephone number that the IVR application
wants the POP
server to call and $sessionid$ is replaced by the session ID that was created
when the inbound call
first came in.
The attributes of MAKE OUTCALL are:
TELNUM telephone number that the POP server needs to call
HREF call flow conductor URL to notify (when the outbound
finally ends) if the call is successful
If the outbound call fails, the POP server immediately so informs the CFM by
sending a
request to the HREF specified in the EVENT=OUTCALL_ERROR exception (see
example 9
below). If the outbound call succeeds, the POP server does not send any
notification to the CFM
immediately. Rather, it waits for the outbound call to be finished (either by
the caller or the
called party), before sending a request to the HREF attribute of MAKE_OUTCALL.
The CFM
sends back an XML Page with an END_CALL tag in response to both the success
and failure
notifications.
MAKE_OUTCALL has one child element: CC EXCEPTIONMAP, which specifies a
mapping between certain call control exceptions and the URLs of the XML Pages
to fetch if such
an exception happens. A CC_EXCEPTIONMAP with the IVR_ERROR EXCEPTION should be
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
39
included before any ACCEPT tag in the first XML Page from the CFM. A
CC EXCEPTIONMAP with the OUTCALL_ERROR EXCEPTION should be included within
the MAI~E_OUTCALL and IMMEDIATE TRANSFER tags.
The EXCEPTIONMAP may use the child element EXCEPTION to specify the mapping
between an exception and the URL from which to fetch the next Page, in case
such an exception
is encountered. EXCEPTION has two required attributes:
EVENT Possible values are BRIDGE_ERROR,
UNBRIDGE_ERROR, IVR ERROR and
OUTCALL ERROR.
HItEF The URL from which to fetch the next page
in case the exception specified by EVENT is
encountered.
EXCEPTION has no children.
IVR_ERROR indicates an unrecoverable IVR application error. The first XML Page
from the CFM (that includes an ACCEPT tag) should include a CC_EXCEPTIONMAP
with the
IVR _ERROR event and this should be placed before the ACCEPT tag.
OUTCALL_ERROR
indicates that the attempt to dial a call failed. An XML Page with the MADE-
OUTCALL or
IMMEDIATE_TRANSFER tag should include a CC EXCEPTIONMAP with the
OUTCALL ERROR event.
A SET tag allows the CFM to set the value of a variable for later substitution
by the POP.
It is a convenient mechanism to allow the CFM to indicate to the POP server
that the POP server
should associate a particular value with a particular variable name and that
the POP server should
substitute the variable name with the value when the CFM uses the variable
name later in the
same or another XML Page. SET has two required attributes and no children.
VARNAME The name of the variable.
VALUE The value to be assigned to the variable.
The IMMEDIATE_TRANSFER element is used by the CFM to redirect an incoming call
to an operator by making an outbound call and bridging it to the incoming
call. This comes in
handy if the IVR application server is down for some reason. The attributes of
IMMEDIATE TRANSFER are:
TELNUM telephone number that the POP server needs to call
HREF CFM URL to notify (when the outbound call finally
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
ends) if the call is successful
If the outbound call fails, the POP server immediately so informs the CFM by
sending a request
to the HItEF specified in the EVENT=OUTCALL-ERROR exception. If the outbound
call
succeeds, the POP server does not send any notification to the call flow
conductor.
IMMEDIATE_TRANSFER has one child element - CC EXCEPTIONMAP.
As before, some examples will help to explain the use of the above tags. In
Example 7,
an XML Page for directing a POP server to accept an incoming call is
presented. This Page is
sent in response to a new-call indication from the POP server. This indication
is usually the first
request sent by the POP server to the CFM for a newly arrived call. After
allocating resources for
a proxy call to the ACD, the CFM returns this Page to the POP server. Note
that the Page
contains, in the SESSIONID attribute, the address of the call structure
reserved by the CFM. If
the CFM fords that it is close to exhausting the available ports on the ACD or
IVR, it can increase
the number of RINGS that are given in the RINGBACK before the call is answered
by the POP
server.
<--Example 7-->
<?xml version--" 1.0" ?>
<XMLPage TYPE= "CC" CUSTID="customer" PAGEID="v 101" VERSION--" 1.7"
SESSIONiD=" OxFFOD2040">
<SET VARNAME="$sessionid$ VALUE="OxFFOD2040" />
<SET VARNAME="$ivr-root-dir$" VALUE="http://customer/teleb"
<SET VARNAME="$ivr-url$" VALUE=" $ivr-root-dir$/ivr.asp" />
<SET VARNAME="$voicefile-format" VALUE="MFF_VOX_M 8MHZ" />
<CC EXCEPTIONMAP >
<EXCEPTION EVENT="IVR ERROR" HREF="$call-mgr-
url$?SESSIONID=$sessionid$&
ERROR=$last-error$&URL=$error-
url$&DESCRIPTION=$last-error-string" />
dCC EXCEPTIONMAP>
<ACCEPT CALL RINGS--" 10" UNIT="SEC"
HREF=" $ivr-
url$?SESSIONID=$sessionid$&DID=$did$&ANI=$ani$"/>
</XMI,Page>
Such a Page may be used as the <ACCEPT_CALL> page returned by the CFM in
response to the
incoming call alert from the POP gateway as shown in Figure 5.
In the following Example 8, a call termination example is provided. In this
case, an IVR
application has decided that the caller is done and the call should be
terminated. In such a case
the last XML Page sent by the IVR application will have an HREF which looks
like the
following:
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
41
$call-mgr-url$?SESSIONID=$sessionid$&CC.NEXTACTION=END CALL
When the POP server sends the request to the CFM, it will send back the
following XMLPage:
<--Example 8-->
<?xml version='1.0" ?>
<XMLPage TYPE= "CC" CUSTID="customer" PAGEID="v 102" VERSION=" 1.7"
SESSIONID=" OxFFOD2040" >
<END CALL REASON="NORMAL" />
</XMLPage>
In the following Example 9, an IVR application has decided that the caller
needs to make
an outbound call. In such a case the last XML Page sent by the IVR application
will have an
HREF which looks like the following:
$call-mgr-
url$?SESSIONID=$sessionid$&CC.NEXTACTION=MAC OUTCALL
&TELNUM= (xxx)xxx-xxxx
When the POP server sends the request to the CFM, it will send back the
following XMLPage
<--Example 9-->
<?xml version--" 1.0" ?>
<XMLPage TYPE= "CC" CUSTID="customer" PAGEID="v 102" VERSION=" 1.7"
SESSIONID=" OxFFOD2040" >
<MA~ OUTCALL TELNUM=" (xxx)xxx-xxxx"
HREF= "call-mgr-url$?RESULT=SUCCESS
&SESSIONID=$sessionid$" >
<CC EXCEPTIONMAP >
<EXCEPTION EVENT-"OUTCALL ERROR"
HREF=" call-mgr-url$?RESULT=FAILURE & SESSIONID=$sessionid$"
/>
dCC EXCEPTIONMAP>
</MAKE OUTCALL>
</XMLPage>
In the following Example 10, an XML Page for informing a POP server that the
call has
been placed in the ACD's queue, awaiting an agent with the appropriate skill
set to become
available, is presented. Such a Page may be sent by the CFM in response to a
REDIRECT HTTP
request (originally from the IVR server) with a query string containing
information about the
agent group with the right skill set. Through this XML Page, the CFM instructs
the POP server to
play a music/infomercial file to the caller while the call is on hold. The
CALL_QUEUED element
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
42
can optionally contain an indication about how long the queue is and what is
likely to be the hold
time.
<--Example 10-->
<?xml version--'1.0" ?>
<XMLPage TYPE= "CC" CUSTID--'"customer" PAGEID="v101" VERSION="1.7"
SESSIONID=" OxFFOD2043" >
<CALL_QUEUED SRC="www.customer.com/teleb/musicl.vox" QLEN="5" TIME="10"
UNIT="MIN" />
</XMLPage>
With the above tags, call flow management operations such as those illustrated
in Figures
and 7 can be easily implemented. For example, as shown in Figure 5, inbound
calls may be
intercepted at a local POP gateway close to the point of call origin, so as to
reduce long distance
charges that might otherwise be incurred. In response, the local POP gateway
notifies the CFM
of the call , seeking instructions for managing the call. This portion of the
call is referred to in the
diagram as LEG ID = 1.
In response to the notification from the POP gateway, the CFM returns an
<ACCEPT_CALL> page, directing the POP gateway to the appropriate URL to fetch
instructions
form the IVR. Following this direction, the POP gateway begins an exchange
with the IVR
application, which provides instructions for handling the inbound call. For
example, the IVR may
provide instructions regarding data collection from the user that can be
prompted using specified
menus, as discussed above.
As the dialog between the IVR and the local POP gateway is in progress, the
IVR may
instruct the POP gateway to request that a proxy call be placed in the call
center's ACD, with the
point being to ultimately connect the caller to an operator at the call
center. As shown in the
diagram this may be done using the CREATE LEG AND DIAL command described
above.
The specified TELNUM is the number to be dialed to reach the call center. In
other cases, this
instruction may go to a premises gateway server at the call center.
In either case, the gateway server passes a request to the CFM to initiate the
proxy call
and, in response, the CFM opens a dialog with the requesting gateway to do so.
Once the proxy
call has been set up (identified as LEG_ID = 2 in the diagram), and the proxy
call is about to be
answered the two calls (LEG_ID = 1 and LEG_ID =2) are bridged (in response to
a
BRIDGE CALL command from the CFM) as shown.
In addition to allowing for the management of inbound calls, the XML command
may
also be used to manage outbound calls from a call center, as illustrated in
Figure 7. This time, the
IVR initiates the process by asking the CFM to establish a new call session
for a call to an
identified telephone number (npa) nxx-xxxx. In response, the CFM determines an
appropriate
local POP gateway and begins a call set-up dialog, the POP gateway is
instructed too place an
outbound call to the specified telephone number, using the DIAL_CALL command.
Once this
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
43
call is established, the CFM hands over control to the IVR (by passing the POP
gateway an
appropriate URL from which to fetch a Page) and the IVR can then provide the
POP gateway
with appropriate called-party interaction instructions.
SYSTEM DESCRIPTION
Having thus reviewed the process flow aspects of the present invention, a
system
overview may be useful. Figure 8 is a functional diagram of a virtual
intelligent network system
in accordance with at least one embodiment of the present invention wherein
the end user 116 is
connected to the business call center 150 via an originating Local PSTN 106, a
Long Distance
Network 114 and a terminating Local PSTN 106.
The VIN includes of one or more POP call center gateway servers 146
distributed at one
or more points of presence 152 close to the points of call origination. These
POP call center
gateway servers 146 are connected by one or more call center networks 148 to
the Premises call
center gateway servers 142 at one or more business call centers 150. The call
center networks 148
are connected to one or more applications web application servers 154 which
host user specified
applications, such as the CFM and IVR applications, on behalf of the multiple
business call
centers 150. The POP call center gateway server 146 is further connected to a
switched or
dedicated access public telecommunications network 114 enabling long distance
voice
communications with connected premises call center gateway servers 142.
A business call center 150 may belong to a plurality of business call centers,
distributed
over a wide area, and may include of one or more premises call center gateway
servers 142, one
of which would be dynamically selected by the CFM application at the time of
handling of an
incoming call at a POP call center gateway.
Referring now to Figure 9, POP gateway 166, under the direction of the CFM,
intercepts
and answers inbound calls at or near the point of call origination. In
addition, POP gateway 166
provides automated services with the CFM-specified interactive voice response
applications,
holds and queues a call until instructed to transfer the call to the premises
call center gateway 164
at the call center 150 when appropriate operators are available to service the
call, and/or plays
music or customized announcements to the caller, while the call is on hold. If
the call is queued,
the CFM application may issue a command to a premises call center gateway 164
to originate a
proxy call at the call center 150 and to monitor the progress of the queued
call. The premises call
center gateway 164 is selected by the CFM using call specific information such
as ANI and DNIS
or caller account information that is provided by the IVR application deployed
on Web server
154, to intelligently choose the best matching answering resource. Then, when
the premises call
center gateway 164 so alerts the CFM, the CFM directs the POP call center
gateway 166 to route
the locally queued call to the premises call center gateway 166 just-in-time
before an operator
answers the call.
The premises call center gateway 164 responds to the CFM command and generates
proxy calls to the premises call center ACD. The premises call center gateway
164 then monitors
WO 01/35617 CA 02389075 2002-04-25
PCT/US00/41354
44
the progress of proxy calls within the ACD for operator availability,
communicates with the CFM
for just-in-time call delivery to the selected operator and bridges the call
between the POP call
center gateway 166 and the premises ACD.
The network operations center (NOC) 156 may host a database that can be
accessed by
the CFM and/or other resources of the VIN to lookup called numbers. In this
way, intelligent
called routing may be provided.
Referring to Figure 10, a virtual intelligent network, according to one
embodiment, is a
virtual private network connecting multiple POP call center gateways 166, one
or more premises
call center gateways 164, all of which may belong to a single business call
center 150, and one or
more web application servers 154 that host user-specified applications, such
as CFM and IVR
application for that business call center, through a call center network 148.
A virtual private
network offers connection and transport protocols such as Asynchronous
Transfer Mode (ATM),
Frame Relay or Internet Protocol (IP) for secure and private data
communications between
connected entities with optional quality of service guarantees.
Referring to Figure 11, each POP call center gateway 166 can be part of
multiple such
call center networks 148, one for each business call center 150 served, all
connected to one or
more web application servers 154 for the business call centers 150. POP call
center gateways 166
use a call center network 148 to connect to corresponding premises call center
gateways 164 and
to access appropriate interactive voice response applications under the
direction of the CFM for a
respective business call center.
In the foregoing specification the present invention has been described with
reference to
specific exemplary embodiments thereof. It will, however, be evident that
various modifications
and changes may be made to the specific exemplary embodiments without
departing from the
broader spirit and scope of the invention as set forth in the appended claims.
For example, the
XML commands described above may be stored on any computer-readable media
(e.g., CD-
ROM, floppy disk, etc.) and/or may be transported as electrical or other
(e.g., light, microwave,
etc.) signals on a media interconnecting elements of the VIN.
In addition, one should not lose sight of the overall goals of the present
VIN. In essence,
the VIN extends an enterprise network (e.g., the business call center
discussed above) to the edge
of an access network in a manner that is transparent to the enterprise network
and independent of
the underlying media transport mechanisms. Consider, for example, the network
topology
depicted in Figure 12. Network 200 includes a number (N) of access networks
202, at the edges
of which are provided gateways 204. The gateways 204 may be similar to the POP
call center
gateways discussed above.
Each access network 202 may serve as a local access network to a number of
users 206.
For example one or more of the access networks 202 may be local loop network
(wireless or
wireline), cellular telephone networks (analog or digital), digital networks
(e.g., IP, ATM, frame
relay, etc:), or other access networks. Through the gateways 204, the access
networks 202, may
be communicatively coupled to one or more enterprise networks (e.g., business
call centers, office
CA 02389075 2002-04-25
WO 01/35617 PCT/US00/41354
computer networks, intra-nets, etc.) 208, via an interexchange network (INX)
210 and/or an IP
network 212. IXN 210 may be a long distance or other telecommunications
network operated by
an interexchange carrier and may use conventional time division multiplied
(TDM) transport
mechanisms, analog or digital switched communication transport mechanisms,
voice-over-IP,
voice-over-ATM, voice-over-frame relay, or any other circuit switched or other
underlying
transport and/or communication mechanisms to carry voice calls and/or data
communications.
The IP network 212 may include the CFM server described above.
Through the control of local applications executed at the gateways 204, for
example
under the control of IVR and/or CFM servers as discussed above, the
functionality of the
gateways 208 is delivered to the edges of the access networks 202. Thus, users
206 may be
provided with services without having to incur expenses associated with
transport and/or
connection access IXN 210. In addition, multiple gateways 208 (which need not
be associated
with the same business entity) can share the gateways 204, with each having
control over
applications to be executed at the gateways 204 through the XML control
processes discussed
above, because such control processes make use of the IP network 212, these
control processes
also avoid fees associated with the use of IXN 210. Only when a true
connection to the enterprise
network is needed (e.g., when an operator becomes available) does a call need
to be bridged
across the IXN 210 (in any manner; e.g., circuit switched PSTN, voice-over-IP,
voice-over-ATM,
voice-over-frame relay, etc.).
The present VIN also allows for easy end-to-end call routing. For example,
using the
XML control processes described above, an enterprise network may provide
destination address
information to a gateway 204 to allow for transport of an incoming call over
an IP or other digital
network. Consider that an incoming call will be associated with an POTS dialed
number.
Although a conventional circuit switched PSTN may make use of this dialed
number to route the
call, a network based on IP, ATM, frame relay, etc., must have an associated
address (e.g., an IP
address, VP/VCI, DLCI, etc., as the case may be) in order to route the call.
Using the XML
control procedures described above, the gateway 204 can be provided with such
an address to
provide call routing over such a network, perhaps even directly to an IP end-
point (e.g., an IP
phone). Thus, the present VIN separates call management from media management
to efficiently
use VOIP (VOATM, VOFR, etc.) as a voice (or other data) transport mechanisms.
Accordingly,
because of the general nature of present VIN and the multiple applications
afforded thereby, the
specification and drawings are to be regarded in an illustrative rather than a
restrictive sense.
