Integrating an IVR application within a standards based application server

A method for providing Interactive Voice Response functionality within a multi-tiered telephony environment can identify an enterprise archive file that contains an Interactive Voice Response (IVR) application. The enterprise archive file can contain multiple interpreters for different markup languages. The enterprise archive file can also include a servlet that maps the interpreters to telephony sessions. The enterprise archive file can be deployed within a J2EE compliant application server having a SIP interface. The deployed IVR application can be utilized to provide IVR functions for SIP based telephony sessions.

BACKGROUND

1. Field of the Invention

The present invention relates to the field of speech processing and, more particularly, to a novel way to implement and deploy interactive voice response (IVR) functionality within a telephony environment.

2. Description of the Related Art

Interactive Voice Response (IVR) systems are systems that permit callers to interact with one or more computer systems using voice input and/or a telephone keypad. IVR systems translate the caller provided input into a form comprehensible by computer systems resulting in programmatic responses being generated. IVR systems can interpret output resulting from the programmatic responses and provide appropriate feedback to the callers. The feedback is generally audibly presented to callers as automatically generated speech output.

In a conventional telephony architecture, an IVR application is generally implemented within an IVR server, which is communicatively linked to the telephony network. In one common arrangement, the IVR server can be connected to a caller via a switched voice network and can be connected to one or more computer systems through a data network. The IVR system can receive caller input via the switched voice network, translate the input, and convey the translated input to the computer system via the data network.

In an Advanced Intelligent Network (AIN) environment, telephony services can be hosted in computer nodes or network elements of a data network. When deployed within an AIN environment, the IVR system can be implemented as a particular network element that provides IVR functionality. Under a conventional approach, logic for interacting with IVR network elements can be included within different application server specific components. Deployment of IVR components within an application server and parameter adjustment and/or optimizations for the same can be application server specific modifications requiring the attention of a skilled technician.

Conventionally implemented IVR systems are generally proprietary systems, which can be highly expensive to implement and maintain. These propriety IVR systems typically utilize a proprietary interface, unique to that particular IVR system. Accordingly, integrating a computer system to a conventionally implemented IVR system can require a substantial amount of time. Additionally, an administrator maintaining the IVR system must learn proprietary scripting languages, IVR specific interfaces, and other IVR specific features. Thus, the administrator must often attend IVR specific training and expend time becoming proficient with a particular IVR system. Should the owner of the computer system choose to utilize a different IVR system, the administrator must attend new training, new interface adjustments must be made, and additional time must be spent to for the administrator to become proficient with the new IVR system.

Further, when updating conventionally implemented IVR systems to incorporate new technologies, the underlying architecture of the IVR system may have to be fundamentally altered. Architecture changes can be costly and time intensive to implement.

SUMMARY OF THE INVENTION

A system and method for integrating an Interactive Voice Response (IVR) application component within a telephony application server at the application level in accordance with an embodiment of the inventive arrangements disclosed herein. The application server within which the IVR application is implemented can utilize modular components of a standardized runtime platform. The runtime platform can provide functionality for developing distributed, multi-tier, Web-based applications. The runtime platform can include a standard set of services, application programming interfaces, and protocols.

In one embodiment, the runtime platform can be a JAVA 2 ENTERPRISE EDITION (J2EE) based platform. The IVR application can be packaged as a JAVA enterprise archive file (EAR) and deployed upon any J2EE based application server using standardized EAR deployment mechanisms. The application server can be any of a variety of J2EE compliant application servers including, but not limited to, a WEBSPHERE application server from International Business Machines Corporation of Armonk, N.Y., a BEA WEBLOGIC application server from BEA Systems, Inc. of San Jose, Calif. and/or a JBOSS application server from JBoss, Inc. of Atlanta, Ga.

It should be appreciated that the above solution provides a means for integrating IVR functionality into an existing telecommunication infrastructure in a platform independent and extensible fashion. The solution adheres to established information technology standards and not to proprietary interfaces, allowing the solution to be implemented and maintained without retraining administrative personnel. The use of open standards in implementing IVR functionality can permit the same IVR functionality to be designed once and executed upon multiple platforms. Further, the use of open standards and leveraging an existing telecommunication infrastructure greatly reduces implementation and maintenance cost and makes it easy to update IVR functionally.

For example, the above solution contemplates that new markup interpreters can be designed and easily added to the IVR application by plugging a new or modified interpreter into the application server. The new or modified interpreter can be deployed using an appropriately modified EAR file via a web-based administration console.

The present invention can be implemented in accordance with numerous aspects consistent with material presented herein. For example, one aspect of the present invention can include an application server including an IVR application and a Session Initiation Protocol (SIP) interface. The IVR application can include a SIP servlet and a plurality of markup interpreters. Each markup interpreter can be based upon a common interpreter interface. The servlet can call methods of the interpreters in accordance with the common interpreter interface. The SIP interface can handle SIP operations for the application server. For SIP based telephony sessions involving IVR operations, the SIP interface can convey a SIP incoming request for a SIP telephony session to the SIP servlet. Upon receiving the SIP incoming request, the SIP servlet can determine at least one of the markup interpreters for interpreting markup during an associated SIP based telephony session.

Another aspect of the present invention can include an EAR file configured for deployment in a J2EE compliant application server. The EAR file can include one or more markup interpreters, each markup interpreter being based upon a common interpreter interface. The EAR file can also include a servlet configured to map incoming requests formatted in accordance with a SIP based protocol to one of the markup interpreters based upon a type of markup that is to be used during a telephony session as specified by the incoming request. The application server can utilize the mapped markup interpreter for the telephony session to handle markup associated with an IVR application executing upon the application server.

Still another aspect of the present invention can include a method for providing IVR functionality within a multi-tiered telephony environment. The method can identify an EAR file that contains an IVR application. The EAR file can be deployed within a J2EE compliant application server having a SIP interface. The deployed IVR application can be utilized to provide IVR functions for SIP based telephony sessions.

It should be noted that various aspects of the invention can be implemented as a program for controlling computing equipment to implement the functions described herein, or a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, any other recording medium, or can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space.

The method detailed herein can also be a method performed at least in part by a service agent and/or a machine manipulated by a service agent in response to a service request. For example, as part of deploying or maintaining IVR functionality for a customer, a service agent can use an EAR file to deploy the IVR application within an application server accessible by the customer in accordance with customer specific needs.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1is a schematic diagram of a telephony environment100for providing IVR functionality in accordance with an embodiment of inventive arrangements disclosed herein. Environment100can include an application server120that is communicatively linked to Session Initiated Protocol (SIP) phone102and/or PSTN phone104.

SIP phone102can be any communication device through with a caller can use a SIP based protocol to establish communications with application server120. SIP phone102can be a line based or a wireless communication device. For example, SIP phone102can include an internet protocol (IP) or Voice over Internet Protocol (VoIP) phone. SIP phone102can also include a desktop computer or other computing device having SIP communication software and suitable peripheral devices attached, such as a microphone and a speaker. A caller can utilize SIP phone102to directly establish a SIP communication session with application server120over data network114.

Public Switched Telephone Network (PSTN) phone104can be any communication device linking a telephone user to a PSTN network110. PSTN phone104can include mobile telephones, line-based phones, cordless phones, computers and fax machines having modems, and other such computing devices. PSTN network110can be communicatively linked to a VoIP gateway112.

VoIP gateway112can be a network node equipped for interfacing among two or more networks that use different protocols, such as PSTN network110and data network114. More specifically, the VoIP gateway112can convert circuit based signals originating from PSTN phone104to packet based signals conveyed to application server120and can convert packet based signals from application server120to circuit based signals conveyed to PSTN phone104. The protocol conversions can occur in real time. In one embodiment, the VoIP gateway112can be an IVR gateway configured to interface with IVR application124.

Application server120can be an application server that utilizes modular components of a standardized runtime platform. The application server120can represent a middleware server of a multi-tier environment. The runtime platform can provide functionality for developing distributed, multi-tier, Web-based applications. The runtime platform can also include a standard set of services, application programming interfaces, and protocols. That is, the runtime platform can permit a developer to create an enterprise application that is extensible and portable between multiple platforms. The runtime platform can include a collection of related technology specifications that describe required application program interfaces (APIs) and policies for compliance.

The modular nature of the runtime platforms upon which the application server120is based can provide comprehensive fault tolerance and security that does not require the addition of specialized hardware, such as new telephony cards that would generally be required when implementing fault tolerance measures. Consequently, by implementing the IVR application124within a standardized application server infrastructure, the infrastructure can be leveraged to provide a cost efficient, yet robust, IVR implementation.

In one embodiment, the runtime platform can be a JAVA 2 PLATFORM ENTERPRISE EDITION (J2EE) software platform. Accordingly, the application server120can be a J2EE compliant application server, such as a WEBSPHERE application server from International Business Machines Corporation of Armonk, N.Y., a BEA WEBLOGIC application server from BEA Systems, Inc. of San Jose, Calif., a JBOSS application server from JBoss, Inc. of Atlanta, Ga., a JOnAS application server from the ObjectWeb Consortium, and the like. The runtime platform is not to be construed as limited in this regard and other software platforms, such as the NET software platform, are contemplated herein. Accordingly, the application server120can be a .NET or other software platform compliant application server.

Application server120can include a SIP processor122that handles SIP related operations. SIP processor122can, for example, receive packet based telephony data over data network114and convert these packets in to a SIP compliant format. As used herein, the SIP protocol is utilized to generically represent any VoIP based protocol. SIP is a prevalent protocol being used in VoIP telephony networks today and referring to elements and specific examples based upon the SIP protocol has been done for purposes of clarity of description and is not intended to represent a limitation of the inventive concepts contained herein. It is contemplated and within the skills of an ordinary telecommunication engineer to adapt SIP protocol specific elements and examples to any other VoIP protocol including, but not limited to the H.323 protocol by the International Telecommunications Union (ITU), the media gateway control protocol (MGCP), the SIGTRAN protocol by the Internet Engineering Task Force (IETF), and/or the skinny protocol by Cisco Systems, Inc of San Jose, Calif. For example, in environment100, SIP processor122and SIP servlet126can be alternatively implemented as an H.323 processor (not shown) and a H.323 servlet (not shown).

The IVR application124can be an application that permits callers using SIP phone102and/or PSTN phone104to interact and receive information from a database using touch-tone signals and voice input. The IVR application124can provide information to the user in the form of automatically generated speech output. The IVR application124can present a series of voice prompts to a user and can receive and process prompt responses in accordance with previously established dialogue menus. Speech processing operations, such as text-to-speech operations, speech-to-text operations, caller identification operations, and voice authorization operations can be provided by a remotely located speech server130.

The IVR application124can interface with one or more remotely located computer systems, such as a management information system (MIS) or database system of a business associated with the IVR system. For example, an IVR application124that is customized to provide customers with banking information can be communicatively linked to a bank's customer account database. In one embodiment, the IVR application124can include voice browsing capabilities to permit callers to access Web content via phone102and/or phone104.

The Interactive voice response application124can include a SIP servlet126and one or more interpreters128. Interpreters128can include Call Control Extensible Markup Language (CCXML) interpreters, Voice Extensible Markup Language (VoiceXML) interpreters, Extensible Hypertext Markup Language (XML) plus voice profiles (X+V) interpreters, Speech Application Language Tags (SALT) interpreters, Media Resource Control Protocol (MCRP) interpreters, customized markup interpreters, and the like. Additionally, different versions of the interpreters, which may conform to different versions of a markup language, can exist. For example, a first interpreter128can be used to interpret VXML version 2.1 markup and a different interpreter128can be used to interpret VXML version 3.0 markup.

The SIP servlet126can map incoming SIP requests to the appropriate interpreters based upon a type of markup that is to be used during a telephony session as specified by the incoming request. The mapping and specification of the appropriate interpreter can occur by any of a variety of means. For example, the target interpreter128can be inferred from the Uniform Resource Identifier (URI) on an SIP INVITE command (e.g. “INVITE sip:IVR@0.22.74.34:5070?http://srv/app.c SIP/2.0”). In another example, an appropriate interpreter128can be specified in an extension of a markup (e.g. “application/voice+xml” for Voice XML). In still another example, i-lines in the Session Description Protocol (SDP) block can identify an appropriate interpreter128(e.g. i=ivr-interpreter ccxml”).

In one embodiment, the various interpreters128can be based upon a common interpreter interface. The SIP servlet126can call methods for the interpreters128based upon the common interpreter interface. Called methods called can include any of a variety of methods, such as methods to set a document to process, methods to set interpreter properties for a SIP session, methods to initialize primary interpreter processes, methods to set a listener, methods to receive and handle events, and the like.

In another embodiment, each interpreter128can be implemented as an object class. Each specific instance class can inherent methods and parameters from a base class, such as a generic interpreter class. Any number of interpreters can be implemented to handle any number of markup types and versions. In one illustrative embodiment, five different types of markup can each be associated with a particular interpreter128, as shown by the following illustrative configuration.

Because the IVR application124can conform to standards established for a particular runtime platform a common deployment mechanism can be used to facilitate deployment of the IVR application124within any of a variety of application servers120implemented in accordance with the runtime platform. For example, the IVR application124can be packaged within an enterprise archive file142, such as a JAVA EAR file. The enterprise archive file142can include SIP servlet126and interpreters128

Accordingly, an authorized administrator can use deploy the enterprise archive142in a variety of manners. For example, the administrator can use a Web based administration console140linked to the application server120via network114to deploy the enterprise archive file142. By bundling the various interpreters in the enterprise archive file142, additional interpreters can be easily added at need. For example, additional support files for the new interpreters can be added to the enterprise archive file142, which can be re-deployed in the application server120. Other updates to the IVR application124, such as adding new IVR features, can be implemented in a similar fashion.

FIG. 2is a schematic diagram of a system200that integrates an IVR application deployed via an IVR EAR file within a J2EE compliant application server in accordance with an embodiment of the illustrative arrangements disclosed herein. System200represents one contemplated embodiment for implementing arrangements detailed for telephony environment100. It should be understood that other embodiments and environments for implementing the IVR application within an application server exist and that the invention is not to be construed as limited in this regard.

InFIG. 2, system200illustrates a turn-based operational environment in which voice processing tasks occur, where the voice processing tasks include IVR tasks. More specifically, system200shows an architecture for an integrated IVR system capable of interfacing with users connected via a telephone network210. For example, the IVR application275included within J2EE application server250can be an IVR application for an automated call center that interfaces with users via voice-based telephone sessions. Components of IVR application275can be packaged in IVR enterprise archive file272, which can be deployed within the J2EE application server250.

The system200can include a telephone gateway215, one or more speech engines230, a resource connector220, and/or a media converter225in addition to J2EE application server250. The telephone gateway215can include hardware and/or software that translates protocols and/or routes calls between a telephone network210, such as a Public Switched Telephone Network (PSTN) and the J2EE application server250. The resource connector220can connect inbound and outbound calls to the J2EE application server250.

The speech engines230can include one or more automatic speech recognition engines234, one or more text-to-speech engines235, and other media resources. Particular ones of the speech engines230can include one or more application program interfaces (APIs) for interfacing with the J2EE application server250.

The media converter225can route input/output streams in one format to appropriate speech engines230as assigned by the J2EE application server250. Accordingly, the media converter225can assure that output generated by the J2EE application server250is converted into an outgoing audio stream with speech generated content and that speech input from an incoming audio stream is converted by an assigned speech engine230before being conveyed to the J2EE application server250.

The J2EE application server250can also include a multitude of component servers, such as telephone server260, dialogue server270, and voice server280, communicatively linked via one or more Web servers252. Each Web server252can include one or more plug-ins, where each plug-in can include routines for conveying data to particular component servers within the J2EE application server250. Each of the component servers of the application server250can be components implemented within a Viral Machine, such as virtual machines adhering to the J2EE specification or other similar and/or derivative specification.

In one embodiment, the IVR application275can be a stand alone component deployed within the J2EE application server250that handles IVR functions for a SIP telecommunication session. The IVR application275can receive markup from the dialogue server270and process the markup using an appropriate markup interpreter. When voice services are required, IVR application275can convey voice processing requests to the voice server280, which handles the requests using one or more speech engines230. In another embodiment, the IVR application275can be an application disposed within the dialogue server270or any other server or component of the J2EE application server250. Deployment parameters for the IVR application272can be specified within the IVR enterprise archive file272.

It should be appreciated that the J2EE application server250can include a SIP interface capable of treating any telephony session as a SIP based session. Accordingly, the IVR application275can provide IVR functionality for any type of telephony session, whether the session is initiated from a PSTN phone, a SIP enabled phone, or other telephony device conforming to any protocol capable of being handled by the J2EE application server250.

FIG. 3is a flow chart of a method300for providing IVR functionality for SIP telephony sessions by deploying an IVR application in a J2EE compliant server in accordance with an embodiment of the inventive arrangements disclosed herein. Method300can be performed in the context of environment100and/or system200. Method300is not limited in this regard and can be performed in the context of any telephony environment having a deployed IVR application within an application server. In one embodiment, the deployment of the IVR application can include the steps of packaging the application and associated components within an enterprise archive file, such as a JAVA EAR file, and deploying the enterprise archive file within the application server.

Method300can begin in step305, where a caller initializes a phone session. In step310, the method can determine if the phone session is a VoIP session that uses packets to convey telephony signals. A VoIP session can be initialized from an IP phone or from a computer having VoIP software. A circuit based voice session can be initialized from a standard PSTN network or mobile phone. If the initialized phone session is initialized from a PSTN phone, the method can proceed to step315, where the format of the telephone signals can be converted into a packetized format using a VoIP gateway. If the phone session is already in a packetized format, the method can proceed from step310to step320directly.

In step320, phone session initialization data can be conveyed to a J2EE compliant server, such as a WEBSPHERE application server. In step325, a determination can be made as to whether the VoIP phone session request is in SIP format or conforms to a different VoIP format. In step330, if a format other than SIP is used, the phone session request can be converted into a SIP compliant format. In step335, responsive to the phone session initialization data, a SIP INVITE message can be received by a SIP stack located within the J2EE server.

In step340, the SIP stack can convey a doInvite( ) request to a SIP servlet. The SIP servlet can be contained within an IVR application executing within the J2EE server. In step345, the servlet accepts the incoming request and identifies a type of markup and/or markup interpreter that is to be used for the session. For example, the incoming request can specify that a VoiceXML interpreter is to be utilized. In step350, the servlet can map the request to an appropriate interpreter.

In step355, during the phone session, markup associated with an IVR function in the specified format can be generated by J2EE server components. In step360, the markup can be interpreted using the designated interpreter of the IVR application. In step365, the interpreter can use a speech server to handle speech services. In one embodiment, a Media Resource Control Protocol (MRCP) compliant speech server can be used.

In step370, the phone session can be terminated. For example, the caller can hang up or the IVR application can disconnect from the caller. In step375, the SIP stack can receive a SIP BYE message. In step380, the SIP stack can call a doBye( ) method within the IVR SIP servlet. In step385, the IVR SIP servlet can release all resources for the SIP session including the interpreter.

FIG. 4is a flow chart of a method400showing a manner in which a service agent can configure an IVR application disposed within an application server in response to a service request in accordance with an embodiment of the illustrative arrangements disclosed herein. For example, the service agent can configure environment100and/or system200so that the system is capable of performing method300.

Method400can begin in step405, when a customer initiates a service request. The service request can be a request for a new IVR system as well as a request to service an existing IVR system with which the customer is experiencing problems or for which the customer wishes an upgrade. In step410, a human agent can be selected to respond to the service request. In step415, the human agent can analyze a customer's IVR needs. In step420, the human agent can use one or more computing devices to perform or to cause the computer device to perform the steps of method300.

Appreciably, the one or more computing devices used by the human agent can include the customer's computer, a mobile computing device used by the human agent, a networked computing device, and combinations thereof. The human agent may make adjustments to a middleware application server and/or to a client operated management information system that utilizes the middleware application server. For example, the human agent can load and configure an IVR application within a middleware application server and can adjust interface parameters of a customer's computer system to interact with the application server.

In optional step425, the human agent can configure the customer's computer in a manner that the customer or clients of the customer can perform one or more steps of method300in the future. For example, a client can be a banking institute that utilizes the agency which employs the human agent to deploy, maintain, and otherwise manage a bank IVR system. After the human agent configures the application server and/or the client's computer system, bank customers can call a telephone number associated with the IVR application, respond to IVR prompts, and receive audible information concerning their bank accounts. In step430, the human agent can complete the service activities having resolved the problem for which the service request was submitted.

It should be noted that while the human agent may physically travel to a location local to adjust the customer's computer or application server, physical travel may be unnecessary. For example, the human agent can use a remote agent to remotely manipulate the customer's computer system and/or an application server.