Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
7092370
Jiang , ; et al.
August 15, 2006
Title
Method and system for wireless voice channel/data channel integration
Abstract
A system and method for wireless communication is disclosed. In one embodiment of a method, a user of a wireless device initiates a communication session during which a wireless data session can be triggered from a voice session and a voice session can be triggered from a wireless data session. During the communication session, data is shared between the wireless data channel and the voice channel.
Inventors:
Jiang; Yuen Jun
(Danville,
CA
)
, Chang; Hisao M.
(Austin,
TX
)
Assignee:
Roamware, Inc.
(San Jose,
CA
)
Appl. No.:
09/932,439
Filed:
August 16, 2001
Current U.S. Class:
370/329
370/352
455/450
455/464
Current International Class:
H04Q 7/00 (20060101) H04L 12/66 (20060101) H04Q 7/20 (20060101)
Field of Search:
370/329,352 455/450,451,464 709/219
U.S. Patent Documents
20010034225
October 2001
Gupte et al.
20020019246
February 2002
Forte
20020055350
May 2002
Gupte et al.
20020099799
July 2002
Kolsky
20040213207
October 2004
Silver et al.
3701851
October 1972
Starrett
5428608
June 1995
Freeman et al.
5450472
September 1995
Brax
6009325
December 1999
Retzer et al.
6055441
April 2000
Wieand et al.
6424945
July 2002
Sorsa
6725031
April 2004
Watler et al.
6801832
October 2004
Park et al.
6947738
September 2005
Skog et al.
6959182
October 2005
Lingafeldt et al.
Foreign Patent Documents
19804563
Jan., 1999
DE
2345613
Jul., 2000
GB
WO 9421077
Sep., 1994
WO
WO 9810596
Mar., 1998
WO
Primary Examiner:
Kizou; Hassan
Assistant Examiner:
Cho; Hong Sol
Attorney, Agent or Firm:
Courtney Staniford & Gregory LLP
Parent Case Text
CROSS-REFERENCE TO RELATED APPLICATION(S)
This application claims priority from the following U.S. Provisional Patent Applications: Ser. No. 60/226,255, entitled Method and Apparatus for Integrated Data Management, filed Aug. 17, 2000; Ser. No. 60/226,363, entitled Method and Apparatus for Integrated Data Management, filed Aug. 18, 2000; Ser. No. 60/226,855, entitled Method and Apparatus for Integrated Data Management, filed Aug. 22, 2000; Ser. No. 60/242,730, entitled Wireless Location Proxy, filed Oct. 23, 2000; Ser. No. 60/253,978, entitled Wireless Device Registration, filed Nov. 29, 2000; and Ser. No. 60/261,572 entitled Smart Wireless Applications, filed Jan. 12, 2001, all of which are incorporated herein by reference.
Claims
We claim:
1. A method for conducting a communication session, comprising: during the communication session, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; wherein triggering the wireless data communication includes transmitting one or more of automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device; during the communication session, triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, and wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data; and a call service that facilitates the communication session, including, communicating with a customer application to receive a specification of data to be pushed or pulled during the communication session; performing data formatting as required on data to be pushed or pulled during the communication session; communicating with an interactive voice response (IVR) application, including transferring formatted data to the IVR application for delivery to a wireless device and receiving data from the wireless device via the IVR application; and an incall service that that handles voice channel content to be sent to a wireless device in response to a request from the wireless device, the incall service including, receiving content from the customer application, wherein the content is selected using a wireless device; transferring the content to the IVR application; notifying the customer application that the IVR application is ready to communicate with the wireless device; and sending an identifier of the wireless device and a status message to the customer application, wherein the status message indicates a status of communication between the wireless device and the IVR application.
2. The method of claim 1, wherein the content is selected during the communication session.
3. The method of claim 1, wherein the content is selected before the communication session, and wherein the content is associated with an identifier of the wireless device.
4. The method of claim 1, further comprising a home page provisioning service, including: after the initiation of a voice communication from a wireless device, receiving an identifier for the wireless device; leaving the voice communication; locating a homepage uniform resource locator (URL) using the identifier; sending the homepage URL to a messaging service, wherein the messaging service sends an actionable alert to the wireless device, wherein the homepage URL is embedded in the actionable alert such that responding to the actionable alert using the wireless device initiates a data communication with the homepage URL.
5. The method of claim 1, further comprising a fax service, including: receiving previously scheduled fax data from a customer application; sending the fax data to one or more previously designated recipient fax machines; receiving a request for specific fax data from a wireless device during a data session; receiving a destination fax number from the wireless device; and sending the fax data to the destination fax number.
6. The method of claim 5, wherein the data communication is a wireless application protocol (WAP) communication.
7. A method for conducting a communication session comprising: during the communication session, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; wherein triggering the wireless data communication includes transmitting one or more of automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device; during the communication session, triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, and wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data; and a call service that facilitates the communication session, including, communicating with a customer application to receive a specification of data to be pushed or pulled during the communication session; performing data formatting as required on data to be pushed or pulled during the communication session; communicating with an interactive voice response (IVR) application, including transferring formatted data to the IVR application for delivery to a wireless device and receiving data from the wireless device via the IVR application; and an outcall service that that handles voice channel content to be sent to a wireless device at a predetermined time, the outcall service including: receiving content from the customer application; transferring the content to the IVR application; notifying the customer application that the IVR application is ready to communicate with the wireless device; and sending a status message to the customer application that indicates a status of communication between the wireless device and the IVR application, including any response from the wireless device.
8. A method for conducting a communication session, comprising: during the communication session, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; wherein triggering the wireless data session includes transmitting one or more of automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device; and during the communication session, triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, and wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data; and a directory service, including, maintaining a directory of information items including entries formatted for a wireless device display, wherein maintaining includes receiving entries and configuration preferences; retrieving entries in response to a request during a communication session via the wireless device, wherein the request includes a voice request and a data request; and displaying a requested information item on the wireless device display.
9. A method for conducting a communication session, comprising: during the communication session, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; wherein triggering the wireless data session includes transmitting one or more of automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device; and during the communication session, triggering a voice communication via a voice channel front the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is shared between the wireless data channel and the voice channel, and wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data; and a device registration service, comprising, capturing a device identification (ID) during a data communication initiated by a device user for registering the device; querying the user for a telephone number of the device; presenting the user with a personal identification number (PIN) that is unique to the user; automatically leaving the data communication and initiating a voice communication to the device; and during the voice communication, prompting the user to enter the PIN; and receiving the PIN and relating the telephone number to the device ID.
10. A wireless communication method, comprising: during a communication session, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; during the communication session, triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, the data comprising historical data and user selection data; capturing a device identification (ID) during a data communication initiated by a device user for registering the device; querying the user for a telephone number of the device; presenting the user with a personal identification number (PIN) that is unique to the user; when the device does not support a simultaneous voice channel and data channel communication session, automatically leaving the data communication and initiating a voice communication to the device; during the voice communication, prompting the user to enter the PIN; and receiving the PIN and relating the telephone number to the device ID.
11. The wireless communication method of claim 10, wherein triggering a wireless data communication includes transmitting automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device.
12. The wireless communication method of claim 10, wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data.
13. The wireless communication method of claim 10, further comprising toggling between a data channel and a voice channel in one communication session.
14. The wireless communication method of claim 10, wherein the data pushed and pulled includes actionable data that initiates an action in a channel receiving the actionable data.
15. The wireless communication method of claim 10, further comprising navigating data that was pushed or pulled from the voice channel or the data channel, wherein navigation functions include fast forward, rewind, pause, and delete.
16. A system for wireless network communication, comprising: at least one network coupled among two or more wireless communication devices and at least one customer application; and two or more components coupled to the at least one network, including, a computer telephony integration/interactive voice response (CTI/IVR) service, a fax service, a call service, and a directory service, wherein the wireless communication devices access the components during a communication session, and wherein the communication session includes, triggering a wireless data communication with a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; and triggering a voice communication with a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, wherein the call service component includes, an incall service; an outcall service; and a call service interactive voice response (IVR) application, wherein the incall service, receives content from the at least one customer application, wherein the content is selected using a wireless communication device; transfers the content to the IVR application; notifies the customer application that the IVR application is ready to communicate with the wireless communication device; and sends an identifier of the wireless communication device and a status message to the customer application, wherein the status message indicates a status of communication between the wireless communication device and the IVR application.
17. The system of claim 16, wherein triggering a wireless data communication includes transmitting automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless communication device.
18. The system of claim 16, wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data.
19. The system of claim 16, wherein the outcall service handles voice channel content to be sent to a wireless communication device at a predetermined time, wherein handling includes: receiving content from the customer application; transferring the content to the IVR application; notifying the customer application that the IVR application is ready to communicate with the wireless communication device; and sending a status message to the customer application that indicates a status of communication between the wireless communication device and the IVR application, including any response from the wireless communication device.
20. The system of claim 16, wherein the homepage provisioning service component includes: after the initiation of a voice communication from a wireless communication device, receiving an identifier for the wireless communication device; leaving the voice communication; locating a homepage uniform resource locator (URL) using the identifier; sending the homepage URL to a messaging service, wherein the messaging service sends an actionable alert to the wireless communication device, wherein the homepage URL is embedded in the actionable alert such that responding to the actionable alert using the wireless communication device initiates a data communication with the homepage URL.
21. A system for wireless network communication, comprising: at least one network coupled among two or more wireless communication devices and at least one customer application; and two or more components coupled to the at least one network, including, a computer telephony integration/interactive voice response (CTI/IVR) service, a fax service, a call service, and a directory service, wherein the wireless communication devices access the components during a communication session, and wherein the communication session includes, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; and triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel, wherein the fax service component includes, an application specific wireless markup language (WML) dialog module coupled to a wireless communication device; a fax server coupled to the WML dialog module; and a messaging service, wherein the fax service, executes a request to send a fax, including receiving the request during a wireless application protocol (WAP) session, wherein the request includes format and addressing information, and sending a status message to a wireless device regarding a status of the request; and executes a scheduled request to send a fax to one or more previously identified recipients, including sending a message to the one or more recipients asking whether the recipient wants to receive the fax, and sending a message to a sender of the scheduled request indicating a status of the scheduled request.
22. A system for wireless network communication, comprising: at least one network coupled among two or more wireless communication devices and at least one customer application; and two or more components coupled to the at least one network, including, a computer telephony integration/interactive voice response (CTI/IVR) service, a fax service, a call service, and a directory service, wherein the wireless communication devices access the components during a communication session, and wherein the communication session includes, triggering a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; triggering a voice communication via a voice channel from the wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across the wireless data channel and the voice channel and; a device registration service, comprising, capturing a device identification (ID) during a data communication initiated by a device user for registering the device; querying the user for a telephone number of the device; presenting the user with a personal identification (PIN) number that is unique to the user; when the device does not support a simultaneous voice channel and data channel communication session, automatically leaving the data communication and initiating a voice communication to the device; and during the voice communication, prompting the user to enter the PIN; and receiving the PIN and relating the telephone number to the device ID.
23. An electromagnetic medium having instructions stored on it, that when executed by a processor, cause the processor to: during a communication session between two or more devices, trigger a wireless data communication via a wireless data channel from a voice communication, including pushing data to the wireless data channel and pulling data from the wireless data channel; during the communication session, trigger a voice communication via a voice channel from a wireless data communication, including pushing data to the voice channel and pulling data from the voice channel, wherein during the communication session, data is maintained across, the wireless data channel and the voice channel; capturing a device identification (ID) during a data session initiated by a device user for registering the device; querying the user for a telephone number of the device; presenting the user with a personal identification number that is unique to the user; when the device does not support simultaneous voice channel and data channel communication sessions, automatically leaving the data communication and initiating a voice communication to the device; during the voice communication, prompting the user to enter the PIN; and receiving the PIN and relating the telephone number to the device ID.
24. The electromagnetic medium of claim 23, wherein triggering a wireless data communication includes transmitting automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data via a wireless device.
25. The electromagnetic medium of claim 23, wherein the data pushed and pulled includes VoiceXML data, hypertext transfer protocol (HTTP) data, wireless application protocol (WAP) data, short message service (SMS) data, and wireless markup language (WML) data.
26. The electromagnetic medium of claim 23, further comprising toggling between a data channel and a voice channel in one communication session.
27. The electromagnetic medium of claim 23, wherein the data pushed and pulled includes actionable data that initiates an action in a channel receiving the actionable data.
28. The electromagnetic medium of claim 23, further comprising navigating data that was pushed or pulled from the voice channel or the data channel, wherein navigation functions include fast forward, rewind, pause, and delete.
29. A wireless communication apparatus, comprising: means for triggering a wireless data communication via a wireless data channel from a voice communication, and for triggering a voice communication via a voice channel from the wireless data communication, wherein during the communication session, data is maintained across the wireless data channel and the voice channel; and call service means for facilitating the communication session, including, means for communicating with a customer application to receive a specification of data to be pushed or pulled during the communication session; means for performing data formatting as required on data to be pushed or pulled during the communication session; means for communicating with an interactive voice response (IVR) application, including transferring formatted data to the IVR application for delivery to a wireless device and receiving data from the wireless device via the IVR application; and incall service means that that handles voice channel content to be sent to a wireless device in response to a request from the wireless device, the incall service including: means for receiving content from the customer application, wherein the content is selected using a wireless device; means for transferring the content to an interactive voice response (IVR) application; means for notifying the customer application that the IVR application is ready to communicate with the wireless device; and means for sending an identifier of the wireless device and a status message to the customer application, wherein the status message indicates a status of communication between the wireless device and the IVR application.
30. The apparatus of claim 29, wherein the call service means further includes an outcall service that that handles voice channel content to be sent to a wireless device at a predetermined time, the outcall service, including: means for receiving content from the customer application; means for transferring the content to the IVR application; means for notifying the customer application that the IVR application is ready to communicate with the wireless device; and means for sending a status message to the customer application that indicates a status of communication between the wireless device and the IVR application, including any response from the wireless device.
Description
TECHNICAL FIELD
Disclosed embodiments of the invention are in the field of wireless communication devices and associated software applications.
BACKGROUND
Access to data and services through electronic networks has become a necessary part of everyday personal and business life. Especially since the Internet became widely accessible, many people increasingly rely on accessing Internet data and services through a variety of devices. Businesses, or enterprises, also use networks to make specific data and services available to employees, partners, and customers. Traditionally, the devices used to access networks were wired to the network. Examples include wired computers and wired telephones. Increasingly, however, people want to be able to access network data and services anywhere using portable, wireless devices such as wireless telephones and hand-held personal data assistants (PDAs). Enterprises now seek the ability to provide wireless access to data and services that is just as complete and easy as wired access. The arrival of wireless Internet telephone devices makes it possible to integrate voice and data services that combine the advantages of either access method. Integration of multiple communication channels such as voice and wireless data has, however, proven challenging.
Traditional multi-channel integration approaches to, for example, customer relations management (CRM), only involve computer telephone integration/interactive voice response (CTI/IVR), web, email, chat, and voice over Internet protocol (IP). Existing integration approaches have the disadvantage of sharing multiple data sources that at best facilitate one channel process (e.g., voice channel with screen pops for a call agent). The lack of channel integration in traditional approaches hinders a satisfactory solution to wireless access to enterprise data and applications, or services.
Without effective integration, accessing a wireless applications protocol (WAP) site for the first time is difficult for several reasons. A standard web browser with a keyboard makes it relatively easy to locate a new web site or directly enter a uniform resource locator (URL). Mobile wireless devices have limited input and user interface capability, however, compared to a computer with a standard web browser. A WAP telephone, for example, doesn't easily allow the typical hyperlinking, searching, bookmarking, or URL entry required to effectively navigate. This creates a significant barrier to the use of a WAP site.
Another disadvantage of traditional techniques for accessing WAP sites is that access to homepages is complicated and inefficient. Typically, homepages in the WAP/HDTP world are controlled by the carrier or must to be manually entered by the user on a wireless device. In the former case, which is characteristic in the United States, to go to a URL for an enterprise site not on carrier's homepage, the user must go through the inconvenience of finding the "goto place" and entering the URL. To avoid this, a large enterprise (e.g. America Online.TM.) might have to pay to be on the carrier's homepage. In the latter case, the user has to enter the URL using the awkward wireless device configuration. In either case, a new URL change results in an awkward data entry process.
Another disadvantage of traditional techniques for accessing WAP sites is inferior device location technology. For many applications, the current location of the wireless device is important. For example, map services or yellow page services may be keyed to the location of the wireless user in order to provide only pertinent information. While multiple location technologies exist, not all are expected to be available and operational in every network, for every device, and at each location within the network. Furthermore, the position measurements retrieved from the location networks may require further processing to obtain the desired data format or related information (e.g., directions to a site). Besides location processing, there is also a need to obtain proper authorization for locating a mobile device. Current approaches lack the ability to mediate among network entities, preferences, authorizations, and related functions.
Another disadvantage of traditional techniques for accessing WAP sites is a cumbersome method for handling sign-on processes for multiple, disparate applications. Some "single sign-on" services exist for providing a more uniform user experience when signing on to different applications. Existing single-sign-on services, however, typically impose a single authentication scheme to which all participating applications must conform.
Another disadvantage of traditional techniques for accessing WAP sites is the difficulty of moving between sites and managing the wireless sessions on each site. Existing systems may not allow a wireless user to maintain multiple sessions, including leaving one site for another, and returning to the original location at the original site.
Traditional techniques for accessing WAP sites rely on desktop-based or client-based cookie management. Some network-based cookie systems provide only cookie store and deliver mechanisms, but do not provide privacy management and security management. Current network-based cookie systems do not support multiple devices of the same user.
Current methods for registering a wireless device with a web site have several disadvantages. For example, to verify the phone number of the device entered by a user at registration, current methods send a short message service (SMS) message containing a code to the device. The user must enter the code in the registration process to continue. This verification process requires the user to switch between wireless device modes of WAP browsing and the wireless device's internal SMS message application. This increases the number of steps involved in completing the registration. On many wireless devices, the WAP browser will not maintain its state while the SMS message is being accessed. Therefore, the user must re-enter the WAP registration application to supply the code. Because use of the registration application in most cases will require the manual entry of a URL into a wireless device, re-entry involves repeating that manual entry, thus imposing a major barrier to use of the application.
Many wireless device users choose to receive messages and alerts of many different kinds on their devices. Existing wireless alert systems usually integrate the delivery of alerts with the generation of alerts. The delivery mechanism is normally one-way based and does not deal with two-way based actionable alerts. Furthermore, existing wireless alert systems do not handle escalation, which may be desirable when a message is not responded to within some time period.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a system including an embodiment of a wireless network communication architecture platform.
FIG. 2 is a block diagram of an embodiment of a wireless network communication architecture platform.
FIG. 3 is a block diagram of an embodiment of a communication system.
FIG. 4 is a block diagram showing the interaction between wireless devices and customer systems.
FIG. 5 is a block diagram of an embodiment of a computer telephony integration/interactive voice response (CTI/IVR) service.
FIG. 6 is a block diagram of an embodiment of a communication system including a DVT-VoiceXML engine.
FIG. 7 is a block diagram of components of a call service.
FIG. 8A is a block diagram of components of an incall service.
FIG. 8B is a block diagram of components of an incall service.
FIG. 8C is a block diagram of components of an incall service.
FIG. 8D is a block diagram of components of an incall service.
FIG. 8E is a block diagram of components of an incall service.
FIG. 8F is a block diagram of components of an incall service.
FIG. 8G is a block diagram of components of an incall service.
FIG. 8H is a flow diagram illustrating an incall service flow.
FIG. 9A is a list of XML tags in one embodiment.
FIG. 9B is a list of XML tags in one embodiment.
FIG. 9C is a list of XML tags in one embodiment.
FIG. 9D is a list of XML tags in one embodiment.
FIG. 10A is an XML file of one embodiment.
FIG. 10B is an XML file of one embodiment.
FIG. 11A is a block diagram of components of an outcall service.
FIG. 11B is a block diagram of components of an outcall service.
FIG. 11C is a flow diagram illustrating an outcall service flow.
FIG. 12A is a list of XML tags in one embodiment.
FIG. 12B is a list of XML tags in one embodiment.
FIG. 12C is a list of XML tags in one embodiment.
FIG. 12D is a list of XML tags in one embodiment.
FIG. 13A is an XML file of one embodiment.
FIG. 13B is an XML file of one embodiment with a generic dialog sample.
FIG. 14 is a block diagram of an embodiment of a home provisioning service.
FIG. 15 is a block diagram of an embodiment of a location service.
FIG. 16 is a block diagram illustrating the interaction of the location service with other services/entities.
FIG. 17 is a block diagram of an embodiment of a single sign-on service.
FIG. 18 is a block diagram of an embodiment of a single sign-on service.
FIG. 19 is a block diagram of an embodiment of a single sign-on service.
FIG. 20 is a block diagram of an embodiment of a session management service.
FIG. 21 is a block diagram of an embodiment of navigation and presentation services.
FIG. 22 is a block diagram of an embodiment of a cookie management service.
FIG. 23 is a block diagram of an embodiment of a cookie transporter.
FIG. 24 is a block diagram of an embodiment of a device management service.
FIG. 25 is a block diagram of an embodiment of a messaging service.
FIG. 26 is a block diagram of an embodiment of an XSL style-sheet generator.
FIG. 27 is a block diagram of an embodiment of a "prefill" application.
FIG. 28 is a block diagram of an embodiment of a password management service.
FIG. 29A is a block diagram of an embodiment of a wireless data and fax apparatus.
FIG. 29B is a diagram illustrating an IVR/FAX server.
FIG. 29C is a diagram of components of one embodiment of a fax service.
FIG. 29D is a diagram of components of one embodiment of a fax service.
FIG. 30 is a block diagram of an embodiment of a mobile wallet service.
FIG. 31 is a block diagram of an embodiment of WAP-based directory service.
FIG. 32A is an example of a user interface element created with an embodiment of an enhanced service.
FIG. 32B is an example of a user interface element created with an embodiment of an enhanced service.
FIG. 32C is an example of a user interface element created with an embodiment of an enhanced service.
FIG. 32D is an example of a user interface element created with an embodiment of an enhanced service.
DETAILED DESCRIPTION
The present invention overcomes the limitations of the prior art and provides additional benefits. A brief summary of some embodiments and aspects of the invention are first presented. Some simplifications and omissions may be made in the following summary; the summary is intended to highlight and introduce some aspects of the disclosed embodiments, but not to limit the scope of the invention. Thereafter, a detailed description of illustrated embodiments is presented, which will permit one skilled in the relevant art to make and use aspects of the invention. One skilled in the relevant art can obtain a full appreciation of aspects of the invention from the subsequent detailed description, read together with the Figures, and from the claims.
A system and method for integrating wireless data and voice calls that explores the advantages of both access methods are described. Embodiments include computer telephony integration/interactive voice response (CTI/IVR) integration including a wireless data and wireless voice channel that is wireless protocol independent. The CTI/IVR integration includes protocols with which voice calls can be triggered in a wireless data session and with which data sessions can be triggered by a voice call or by an actionable alert. Actionable data from the actionable alert allows the control of navigation from a wireless channel to a voice channel and vice versa during a communication session. Significantly, session data is shared between the voice channel and the data channel during a communication session. Voice data can trigger a data session in a push action or a pull action. Similarly, data can trigger a voice session in a push action or a pull action. One embodiment includes initiating a wireless applications protocol (WAP) session from a voice call, thus removing the problems that a traditional wireless user would have in navigating to a WAP site. A WAP session is presented to the user as a result of placing a normal telephone call. In one embodiment, initiating the wireless data WAP session comprises sending a message to a device, and receiving from the device a selection of a uniform resource locator (URL) within the message. In response to receiving the selection of the URL, a data session is initiated to a web server. In one embodiment, the message is a short message service (SMS) message.
One embodiment includes a central gateway through which wireless device users access multiple applications. These accessible applications could be hosted locally (in the same physical location or the same administration domain as the gateway), in the same Intranet behind the firewall, or anywhere on the Internet. In one embodiment, an apparatus architecture includes a tiered topology that supports large-scale, high performance, mission-critical wireless applications on a variety of devices. The method and system integrate various wireless applications with existing wireless network infrastructure, including wireless Internet infrastructure. The method and system further integrate multiple wired and wireless devices with the network, including providing a consistent user interface across multiple wireless devices. The method and system include numerous wireless applications that facilitate the wireless devices user's access to network services. One embodiment includes computer telephony integration/interactive voice response (CTI/IVR) integration. The CTI/IVR integration adds a wireless protocol independent wireless channel. The CTI/IVR integration presents actionable data that allows the control of navigation from a wireless channel to a voice channel and vice versa.
FIG. 1 is a high level block diagram of one embodiment 100 of a system for wireless network communication that includes an embodiment 104 of a wireless network communication architecture, or platform. In general, the architecture 104 components include tools and administration, integration with the customer system 102, wireless applications available to users of wireless devices 106, enhanced services available to users of wireless devices 106, and network integration with the wireless devices
106. The architecture 104 performs two-way communication with wireless devices 106 and also with customer system 102. Customer system 102 is any system that communicates internally and externally via networks, including wireless networks. For example, customer system 102 can be the communication and data system of a large or small enterprise. The architecture 104 provides a seamless, scalable interface between the customer system 102 and users who access the customer system 102 through wireless devices 106.
FIG. 2 is a block diagram showing more detail of the architecture 104. A network integration layer 202 components includes a wireless application protocol (WAP) gateway, homepage provisioning, a CTI/IVR service, a wireless telephony applications service, a WAP push gateway, a voice extensible markup language (voice XML) gateway, a location gateway, and a short message service (SMS)/email gateway. Various components of the network integration layer will be described in more detail herein. An enhanced services layer 204 includes a messaging service, a navigation service, a cookie management service, a two-way wallet service, a device management service, a session management service, a single sign-on service, a voice portal, a presentation service, and a personalization service, some of which are described in more detail below. A wireless application layer 206 includes enterprise applications, portals, exchanges, existing wireless applications, etc., as shown. The integration layer 208
includes an XML engine and an infrastructure engine interface.
FIG. 3 is a block diagram of an embodiment of a communication system 300 showing a relative position of an architecture 304. Wireless devices 306 communicate with customer systems 302 through various gateways 310 and the architecture 304, which includes the various integration and application layers as described with reference to architecture 104. For example, a wireless telephone 306A communicates using a short messaging protocol with the SMS gateway. The architecture 304 includes a hypertext transfer protocol server and an application server. The architecture 304 further includes extensible style-sheet language templates (XSLTs), which are explained more fully below. The architecture 304 includes the enhanced services as shown in FIG. 2. The enhanced services facilitate the wireless device user's access to data 308 and customer systems 302. Examples of customer systems 302 are the systems provided by SAP.TM., Siebel.TM., TIBCO.TM., and others.
FIG. 4 is another view of the interaction between the wireless devices and the customer systems. The dotted line indicates that the items excluding the wireless devices 406 and the customer applications 420 are included in the architecture. The wireless devices 406 communicate with a navigation service 408, which routes data in two directions. The navigation service 408 communicates with a device management service 410 and a session management service 412, which are each enhanced services of one embodiment. The device management service 410 verifies the identity of the wireless device and its type. The session management service 412, which will described in more detail below, returns a menu to the wireless device 406. The menu is part of a configurable, consistent user interface that facilitates the wireless device user's network access. A single sign-on service 416 and the cookie management service 418 are further enhanced services that will each be described in more detail. In general, however, the single sign-on service 416 allows the wireless device user to sign on once, with minimum actions on the user's part, to access a wireless network session that may include communication with many sites and applications. The cookie management system facilitates the maintenance, storage, and control of consistent user information, which normally cannot be stored on the wireless device 406. The navigation service 408 transmits a device type to the extensible style-sheet language template (XSLT) repository 414, and a specially formatted presentation appropriate for the particular wireless device 406 is returned. XSL templates will be discussed in more detail below. The menu and the specially formatted presentation facilitate the user's data request to the customer application 420.
FIG. 5 is a block diagram of an embodiment of a CTI/IVR service 500, which includes a wireless protocol independent wireless channel. IVR applications use the telephone as the primary input/output device to communicate with the end user where the user input may be provided either using a dual tone multi frequency (DTMF) based touch-tone keypad (or soft keys on a PDA with telephone interface) or by speaking a voice command. DTMF is the signal to the phone company that is generated when the key on an ordinary telephone touch pad is pressed. This is commonly known as touchtone dialing on a "Touchtone" phone (formerly a registered trademark of AT&T). DTMF has generally replaced loop disconnect ("pulse") dialing. With DTMF, each key pressed on the telephone generates two tones of specific frequencies.
IVR applications typically run on an IVR system with appropriate hardware components that interface with wireline or wireless telephone networks.
The CTI/IVR service 500 controls navigation from a wireless data channel to a voice channel and vice versa. In one embodiment, the CTI/IVR service 500 operates where telephone calls can be triggered in a wireless data session. Automatic number identification (ANI) data, dialed number identification service (DNIS) data, and unique identifier (UID) data is sent to a workflow-based decision system 522 and a work agent 524, and is processed by a history and action aggregator 514. A session management service 510 publishes data to an XML-based messaging bus 512, which subscribes to the history and action aggregator 514. The history and action aggregator uses the subscription information to access a customer layer 536. The customer layer
536 includes ecommerce transactions 526, chat history/data 528, email history/data 530, voice over Internet protocol (IP) history/data 532, and legacy and other data 534.
The CTI/IVR service 500 coordinates the wireless data transactions with voice channel-based transactions and vice versa. It allows wireless data sessions to control, guide and trigger voice channel sessions and vice versa.
Wireless data transactions are published and stored on the messaging platform to guide voice channels. These transactions can in particular be actions to control the interactions with the caller in the voice channel. Similarly, voice channel transactions are published and stored on the messaging platform to guide wireless data channels. These transactions can in particular be actions to control the interactions with the wireless device user. In both cases, the actionable data can be pushed or pulled by a channel.
In the case of pulling actionable data using the CTI/IVR service 500, a user can click a link (e.g. "Listen to Movie Review") on a wireless data session to trigger a call to the IVR system 518 that is to be controlled by the actionable data. By examining the voice channel data, such as the DNIS and ANI, the wireless session data, the voice call can be guided to execute the requested action, such as playing the Dinosaur movie review.
As a push example, suppose that a user clicks a link (e.g. "Fax the Document") on a wireless data session to register actionable data with the messaging platform. This actionable data is picked up by a fax listener 538, which is registered with the messaging platform to listen for fax actions. The session data (e.g. telephone number, or document) will guide the fax listener 538 to deliver the document as a fax.
Similarly, the CTI/IVR service 500 can be used to request to send a uniform resource locator (URL) to a wireless data wireless device to trigger a wireless session. In this case, the actionable data from the voice session is being used to control the wireless data action. Here, the actionable data is registered with the messaging platform to be picked up by a WAP alert listener registered with the messaging platform to listen for the WAP alert actions.
These examples illustrate that the CTI/IVR service 500 allows the actionable data to be executed by the destination channel at the current point of the menu structure instead of having to start from the top of the menu structure to reach the intended target of the actionable data.
The CTI/IVR service 500 does not require that the wireless device 506 support simultaneous voice channel and wireless data channel as long as it supports concurrent voice channel and wireless data channel. It allows a user to toggle between a voice session and a data session. The CTI/IVR service 500 can involve two different devices for voice and wireless data, for example, providing a speech recognition interface to a telephone so as to send a URL or other data to a WAP wireless device in response to a spoken request. A user can use a telephone to do a transaction and have the receipt sent via a WAP alert to a WAP device or emailed to another device, such as a RIM.TM. device.
In one embodiment, the actionable data is represented as XML data on the messaging platform. The action type can either be a push action (e.g., WAP alert or outfax call) or a pull action (e.g., the voice channel queries the messaging platform whether there is a registered action such as "play the movie review of Dinosaur").
FIG. 6 is a high level block diagram illustrating the initiation of a wireless data session by a voice call. In one embodiment, a wireless data WAP session is initiated from within a voice call by sending an SMS message, email or other text message to the wireless device. During a voice call, a wireless data message (e.g., SMS or email) is sent to the wireless device that initiated the voice call. When the message is accessed on the device and the user selects a URL within that message, a data session is initiated to a web server. The embedded URL, and thus the data session, is set up based on the context of the voice call. For example, the voice call can be to an IVR or a service representative. This is significantly easier than the traditional method of manual keying to initiate a wireless data session.
A VoiceXML gateway 608 receives calls from wireless devices 606 or from wired device 607. VoiceXML gateways are Internet based telephony platforms over which a user can submit a VoiceXML document and initiate an audio dialog with the document over standard telephony channels. VoiceXML is a standard designed by the World Wide Web Consortium (W3C) to create audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations.
Internet protocol (IP) data is sent to software 610. In one embodiment, the software 610 is a data voice telephony (DVT)-VoiceXML application engine, which includes automatic speech recognition and a text-to-speech (TTS) interface. For example, Nuance.TM., Speechworks.TM., and Fonix.TM. can be used. The software 610 also includes a hypertext transfer protocol (HTTP) directory client, dynamic grammar generation, a domain/personalization manager, an audio content manager, and an instant messaging and notification hierarchy. The software 610 is in communication with a web server 612. Referring to FIG. 2, the location gateway 616 is part of the network integration layer between the enhanced service layer and the devices 606 and 607. The session management service 614 and the mail or messaging service 618 are enhanced services between the network integration layer and the wireless application layer. An integration interface 620 is part of the integration layer between the wireless application layer and the customer system layer. Referring again to FIG. 6, the customer applications 602 include customer relations management software, enterprise relationship software, ecommerce software, etc.
Customer applications 602 initiate XML-based content trigger via the integration interface 620 to a DVT-VoiceXML application engine 610. The DVT-VoiceXML application engine 610 uses the audio content manager and transcoder to parse the XML content dialog file. Based on the parsing, a voice menu is constructed using the dynamic grammar generation module. The DVT-VoiceXML application engine 610 then generates a VoiceXML document and stores it in a local storage for expected callers. When an expected caller dials into the system (from a manual dial or from a data session), the domain personalization/manager recognizes the DNIS/ANI associated with the call and retrieves an appropriate VoiceXML document waiting for the caller. The DVT-VoiceXML application engine 610 sends the VoiceXML document to the VoiceXML gateway 608 that executes the document controlling the voice session dialog. When the caller enters a response via voice or DTMF, the DVT-VoiceXML application engine 610
activates the instant messaging and notification hierarchy module and sends the user response to a back-end application. During the voice session, the DVT-VoiceXML application engine 610 can activate the HTTP directory client to provide directory service if needed.
As an example of a wireless data session initiated by a voice call, consider a telephone company customer calling her wireless provider's "wireless web customer service" number to check the remaining minutes on her account. When the call is received the ANI, or calling telephone number, is used to generate an email/SMS message that is sent to the caller, and the voice session terminates. When the subscriber accesses the URL within the message, a session is started connecting the provider's customer care WAP site, and the customer accesses her account information.
As another example, a wireless web customer of a wireless telephone service provider wants to reserve tickets for an upcoming concert and purchase the tickets from a ticketing company. The ticketing company is not on the service provider's portal. The customer calls an appropriate toll free telephone number, and navigates a menu to "concerts". The customer then chooses the IVR option "wireless ticketing". An email is sent to the customer's wireless device with the initial page being "upcoming concerts". The email is already tuned to the location of the caller. The customer can navigate the page to find information, price, and times, and purchase via the WAP application. The significant advantage to the ticketing company is that it easier to move the customer to a lower cost channel, and the cost of being on the service provider's portal is avoided.
In both of the examples a significant benefit is the ability of an end user to easily gain access to the relevant wireless data site without having to navigate multiple menus or enter a string of characters on the wireless device. This is a benefit to both the user and the company that wishes to have customers access company information over a wireless channel. Many applications benefit from initiation of a wireless data session by a voice call. They include customer service, direction finding, package tracking, movies, banking, gambling, and virtually any other interactive voice response (IVR) application.
This functionality does not require the wireless device to support simultaneous voice channel and wireless data channel. The voice channel can be terminated and the data channel can be opened later by the message that was sent to the wireless device.
One embodiment includes a call service that enables a customer application 602 to manage the sending of audio messages to a user and receive the user's touch tone response. The call service includes various components and software agents, including a call agent. The call service includes an incall service and an outcall service which include an incall agent and an outcall agent. A call service IVR receives a call from an end user and is ready with the appropriate sound files to play to the caller. After the audio files are played, the caller may hear a menu with choices or a transfer option, or a prompt asking for a multidigit string.
Before the call comes in, the customer application must send an XML file specifying which audio to play to which expected callers. Once the call is done, the call service will send the status of the call and the choice that the user selected from the menu to the response URL or the customer application so that the appropriate action can be taken.
FIG. 7 is a simplified block diagram of the call agent 701, showing its communication with a customer applications 702 and IVR service 718. The customer application 702 dictates the content that is to be played to end users through their telephones as well as any available content choices. The content and/or choices may be sound files, or they may be text that is rendered to audio by a text-to-speech object. The call agent includes an incall agent that receives calls from a caller, and an outcall agent that initiates calls to users.
The call agent 701 allows the customer application 702 to present information to mobile users that is not suited for the small screens typical of WAP-enabled mobile devices such as wireless device 706. This information is presented to the user via audio over the user's wireless device 706. Playing the audio includes checking to ensure that all audio is in an acceptable format, playing the content, playing the choices, and collecting a touch tone response from the caller.
The IVR service 718 handles the call with the end user. The call agent 701 sits between the IVR service 718 and the customer application 702 and manages the communication between the two. The customer application 702 provides an XML file that specifies, among other things, the audio file that the caller hears as well as any menu choices or transfer information for the call. This XML file also specifies any authentication necessary for the caller to receive the information.
A conversion component of the call agent 701 verifies that the audio requested by the customer application 702 is correctly formatted, and converts the audio content to a .wav file if necessary. The customer application 702 may specify audio in one of three ways: by specifying the URL of a valid .wav file; by specifying the URL of a text files; or by using text.
If the URL points to a .wav file, the conversion component checks the header to verify that the file type is supported. If the file has the RIFF header, it is accepted. RIFF is a Microsoft.TM. file format used for .wav, or WAV files. WAV is a sound format developed by Microsoft.TM.. If the file has a national institute of standards and technology (NIST) header, it is re-written with a RIFF header. If the .wav file does not have a RIFF or NIST header, it is rejected. It is also rejected if it is empty or does not exist.
If the audio input is provided as a .txt file, the text is given to a text-to-speech (TTS) module for conversion to a .wav file.
A content player plays the content to the end user. Through a user interface, it provides the user with functions similar to those of a cassette player, including play, pause, fast forward, fast backward. These functions allow the user to repeat or skip portions of the message. The content player also has additional help functions built in.
The call agent further includes a menu selector. The menu selector is a self-contained object that handles the presentation of choices and their selection by the caller. The menu selector provides a single level of choices based on input from the customer application. All prompts pertinent to the menu, such as user input, caller selection, flow, and error handling are handled by the menu selector.
The menu selector receives prompts and choices from the customer application 702 via an XML file. The menu selector plays the prompts in the order in which they were provided. In one embodiment, each prompt is preceded by a prerecorded .wav file containing a phrase such as "If you would like . . . ", and is followed by the phrase ". . . press <number>", where <number> is the corresponding value for that choice as specified in the XML file. For each choice, the value is the DTMF code expected when the caller makes the given choice.
The menu selector returns the value of a choice ID corresponding to the choice value selected by the user. If the call was dropped, it returns the status, "dropped call" to the call agent 701.
If the interaction contains a transfer, "0" is reserved for the transfer choice value. If the interaction does not contain a transfer, "0" may be one of the menu choice values.
In one embodiment, the call agent interfaces with the Dialogic.TM. board and software via the Dialogic.TM. applications programming interface (API).
The call agent 701 accepts the XML file from the customer application 702 via an HTTP request. The XML file is different for the incall agent and the outcall agent. The incall agent and the outcall agent will be described more fully below. The incall agent and the outcall agent communicate with the customer application 702 via HTTP. In one embodiment, the format for the request from the customer application 702 is as follows:
TABLE-US-00001 http://<hostname>/servlet/Incall/?ID=nnn&xml=aaa.xml where hostname is the name of the server where the XML file exists nnn (ID) is the customer specified ID for the call aaa.xml (xml) is the XML file name
The incall agent and the outcall agent each perform the following functions:
1. Get the request ID and XML file with the standard format from the customer application's HTTP request. The request from the customer application should be of the format: http://<hostname>/servlet/Incall/?ID=nnn&xml=aaa.xml
2. The agent replies immediately to the customer application by transmitting a text file containing a numeric code and an explanation of the code. The standard HTTP status code of 200 should be present in the header, regardless of the contents of the text file returned.
If the request was well formed, the agent returns "0 accepted". If the request was ill-formed, the agent returns "<nnn> <plain-text explanation>".
If the reply was anything other than "0 accepted", there will be no further reply from the agent regarding the failed request.
3. Check the XML file format (using the standard XML parser). If the XML file was ill-formed, send the ill-formed status to the customer application.
4. Check user license and appropriate permissions.
5. Check for the existence of .wav and text files specified in the XML file. Also check extensions and file size. The audio for the interaction can be specified in any of several ways, including: text is inside of content tag; wave file in the URL; and text file in the URL.
6. If the audio is not an acceptable file type, the agent will send a message to the customer application indicating so: http://www.customer.com/servlet/CallinService?id=nnn&status=unaccept
7. Pass the XML file to the IVR with request ID.
The menu selector provides a single level of choices for the user. It receives a set of prompt contents in text or wav format, and plays them in the order in which they were provided. Each prompt is preceded by a prerecorded wav file containing the phrase "If you would like . . . ", and is followed by the phrase ". . . press <number>", where <number> corresponds to the position of the current choice in the list. The value returned by the menu selector is a number between -1 and
9, where -1 indicates that the call was dropped, and the values 0 through 9 indicate that the user entered a valid choice. If the user enters a number that was not assigned to any choice, the menu selector will play an error message, and play the choices again from the beginning. This process is repeated until the user either hangs up or enters a valid choice, but the customer software may provide a "timeout" value that indicates the maximum number of cycles.
The incall service and incall agent will now be discussed in more detail with examples. The incall agent, in one embodiment, is a user-initiated voice channel content delivery and actionable response system. Users can reach the system either through direct dialing or from a WAP data session using the wireless telephony application (WTA) "make call" capability. The in-bound call can be user and/or session specific (but need not be), with built-in optional authentication capabilities. The content can be recorded audio or text presented using built-in text-to-speech. A single layer menu may be presented to the caller after the content has been played. The incall agent responds to an XML document or URL link request from a customer application, and provides status and response information to that application through HTTP.
An incoming call may be initiated from a data session to deliver information that is not conducive to the small screen on a web-enabled telephone. The incall agent can be used when context persistence when switching modes (from data to voice) is important. In this case, a call is triggered by a data session and the context of the data session is transferred to the voice call. On the other hand, the incall agent can be used for context-independent or user-independent audio content. In this case, any person who calls from any telephone device can hear a message.
In one embodiment, a standards-based VoiceXML gateway installation is supported in addition to a Dialogic D41/ESC based analog telephony platform. For the VoiceXML gateway configuration, the IVR component is served by a qualified VoiceXML gateway platform.
Two system configurations for an incall service including the incall agent will be described. Many more configurations are possible. The two configurations are referred to as option A (a Dialogic.TM. D41/ESC based IVR platform), and option B (a VoiceXML gateway based IVR). Suitable components for both configurations are listed below:
TABLE-US-00002 Option A: Dialogic .TM. D41/ESC based call service .quadrature. incall agent (the main incall service servlet) .quadrature. XML Parser (C++) .quadrature. IVR/DTMF: Content Player (C++/Dialogic) .quadrature. Product Admin Web Page (JSP/Bean) Option B: VoiceXML version of call service .quadrature. Agent (the main incall service servlet) .quadrature. Content Manager (Java) .quadrature. IVR Dialog Manager (VoiceXML) .quadrature. Product Admin Web Page (JSP/Bean)
Option B includes a content manager software module. In the Dialogic.TM. D41/ESC based configuration (Option A), most functions performed by this software module are a part of the C++ based IVR component. The VoiceXML configuration does not have any C++ based platform to serve this module, and a set of Java classes take over this function. These Java classes reside on an application server of the architecture platform and perform various functions for both the incall agent (the main servlet) and the dialog manager (written in VoiceXML codes and Java server pages (JSP)).
System requirements for one embodiment of the incall agent of option A are:
Windows 2000, Service pack 2;
128 MB of RAM required, 256 MB recommended for T1 card;
Pentium III 733 MHz required, 1 GHz recommended for better Text-to-Speech performance;
Disk space for audio content caching: about 30 MB per hour of audio;
One or two Dialogic D/41-ESC cards (4 channels each) or single Dialogic D/240 (T-1); and
Adequate network bandwidth for downloading audio content (LAN, DSL or T1).
The T1 (or T1) carrier is the most commonly used digital line in the United States, Canada, and Japan. In these countries, it carries 24 pulse code modulation (PCM) signals using time-division multiplexing (TDM) at an overall rate of 1.544
million bits per second (Mbps).
Option B is a VoiceXML configuration. For option B, the system should include a Nuance.TM. voice web server and a VoiceXML gateway, such as VoiceGenie.TM.. The VoiceXML gateway should be configured to associate one or more incoming voice ports with a DNIS (which is the number the user calls to access desired content) and URL. The URL is the root VoiceXML document for the incall agent. As an alternative to installing the VoiceXML gateway, the VoiceXML gateway can be hosted.
Performance of the incall agent on a T1 line is acceptable with separate machines handling the databases and servers. The central processing unit (CPU) overhead is relatively small. Dialogic.TM. supports this setup with an architecture designed to span multiple boards in multiple chassis. In this case the entire array appears as a single node with a large number of channels and resources.
Performance approximations for a T1 line are as follows: the incall agent can support 691 one-minute incoming calls per busy hour with a blocking factor of 0.001; 868 calls with a blocking factor of 0.010; 1000 calls with a blocking factor of
0.030; or 1244 calls with a blocking factor of 0.1. Where blocking factor is a measure of switch efficiency.
For failover handling in option A, the incall agent stores the XML files as they are given to it. In this case they do not need to be queued. Multiple IVRs are available to handle failover.
For failover handling in option B, failover is handled differently depending on the particular customer setup. If the customer is using a remote hosted VoiceXML gateway, failover management is built into the architecture of the hosting party. In this case, an incoming call is routed to one of several working machines. If the customer chooses to host their own VoiceXML gateway, failover is not provided, and the recovery process is reduced to manually restarting the VoiceXML gateway service on the platform after an incall agent failure, power outage, or other fatal system error. During this period, the system cannot accept a call. Such a recovery process takes approximately 15 minutes.
The incall agent can be scaled to a T3 line. A single T3 circuit has 28 DS-1 circuits for a total of 672 voice, or bearer channels. If primary rate ISDN (PRI) signaling is used, a few of the bearer channels are used to carry the signaling on a D-channel. PRI service is provided over a channelized T-1 facility. Twenty-three bearer channels (B-channels) are used to carry voice or customer data circuits. The twenty-fourth channel (D-channel) is used for out of band signaling to control the twenty-three bearer channels. Each B-channel has 64 k bits per second of throughput. At most one D-channel per T1 is used, but if the telephone company supports it, the customer can use non facility associated signaling (NFAS), where a single D-channel on one T1 span carries the signaling of several other T1 spans. The minimum voice channels in a T3 would be approximately 644 in the case of PRI with no NFAS, and the maximum would be approximately 672 (in the case of robbed bit signaling). With T3, the incall agent supports approximately 35,000 one-minute incoming calls per hour, with one percent of the callers getting a busy signal.
For NFAS, multiple PRI circuits to the same customer premises are bonded together so that the D-channel of one PRI can control multiple PRIs. This frees up the D-channels on the bonded trunks to be used as additional B-channels. Normally a second D-channel is assigned to be a backup to the primary D-channel for redundancy.
FIG. 8A is a high-level diagram of one embodiment that applies to both option A and option B. The incall agent 801 communicates with the customer application 802 using HTTP. The wireless device 806 communicates with the incall agent 801 using a voice connection, and with the customer application 802 using an optional data connection. The response URL 813 communicates with the incall agent 801 using an optional HTTP connection. A caller can dial in to the incall agent 801 directly or from a data session, such as a data session talking to the customer application 802. Once the caller has connected to incall agent, the caller can listen to a message and respond to requests for input. The result of the call, including any input given by the caller, is then passed back to the customer application 802 or to the response URL 813.
FIG. 8B is a diagram of an option A configuration in one embodiment. The incall agent 801 is between the customer application 802, the wireless network communication architecture platform 804, and the telephony system 830. The actual software modules (written in C++) reside on the Dialogic.TM.-based telephony system (D41/ESC-PCI interface) 831.
FIG. 8C is a diagram of an option B configuration in one embodiment. The configuration for option B supports VoiceXML based implementation where the IVR component (written in VoiceXML and related Java server pages (JSP) documents) of the incall agent 801 can reside on either the architecture platform 801, or on the actual VoiceXML gateway 832. If the incall agent 801 is on the architecture platform 804, the VoiceXML documents are delivered at run time to the VoiceXML gateway 832 via an HTTP interface.
For Option B, the run-time environment of the VoiceXML based IVR component is provided by the VoiceXML gateway 832 which can be either co-located on the same LAN with the architecture platform 804, or located in a remote hosting environment managed by a VoiceXML gateway operator such as VoiceGenie.TM., BeVocal.TM., Tellme.TM., HeyAnita.TM.. The incall agent is thus independent from the telephony component of the VoiceXML 832.
Typically, the incall agent resides on the architecture platform and supports one of the two configuration options described above. For both option A and option B, the incall agent 801 sits on the architecture platform 804, as shown in FIG. 8D. In option A, the IVR 833, or the part of the incall agent 801 that handles the telephony and the dialog with the caller, is on a separate platform.
FIGS. 8E and 8F show two alternate call flows for option A. In FIG. 8E, the call is initiated from a data session. (1) The user is on a data session with the customer application 802. (2) When the user selects the content, the customer application 802 passes an XML file to the incall agent 801. (3) The XML file is then passed to the IVR 833. (4) The IVR 833 alerts the incall agent 801 that the IVR 833 is ready. (5) The incall agent 801 alerts the customer application 802 that the IVR 833 is ready. (6) The customer application 802 gives the user the option to call in. (7) The user calls in to the IVR 833. (8) The IVR 833 carries on a dialog with the user. (9) The IVR sends the call status to the incall agent 801. (10) The incall agent 801 sends the call status and telephone number to the customer application or to the response URL (not shown).
In the alternate call flow, shown in FIG. 8F, the call is initiated from a voice connection. The user is on a data session with the customer application 802. (0) At some point before the user calls, the customer application 802 must give the incall agent 801 the XML file for the caller. (1) The user initiates the call and the IVR 833 answers. (2) The IVR 833 collects the user's telephone number, either via mobile identification number (MIN), by asking the caller for it, etc. (3) The IVR
833 passes the telephone number to the incall agent 801. (4) The incall agent 801 passes the correct XML file to the IVR 833. (5) The IVR 833 authenticates (if necessary) and plays the content message. (6) The IVR 833 passes a status message back to the incall agent 801. (7) The incall agent 801 responds to the customer application 802 with the status and the telephone number.
FIG. 8G is a high-level diagram of an option B embodiment. The architecture platform 804 includes the incall agent 801, the content manager 842, the audio, content, and prompt files 844, and the IVR/DTMF dialog manager 840. The architecture platform 804 communicates with the customer applications 802 and the VoiceXML gateway 832. The VoiceXML gateway 832 communicates with the audio cache 848 and the wireless devices 806. The VoiceXML gateway 832, in one embodiment, communicates with the wireless devices 806 through an ACD 850.
In one embodiment, the incall agent 801 is a Java class. The content manager 842 is an XML parser that is a Java class module that supports VoiceXML configuration. Configuration 846 is part of an administrative web site, and defines installation and configuration parameters, such as prompt language and file directories. The IVR/DTNF dialog manager 840 is a VoiceXML document that defines the DTMF-based IVR dialog (without voice recognition). This document is managed by the web server of the architecture platform 804 with a pre-defined URL for the VoiceXML gateway 832 to fetch.
In this VoiceXML based system configuration, option B essentially runs on two computers or groups of computers: the architecture platform 804, and a VoiceXML gateway 832 which could be hosted through a third party VoiceXML gateway 832 operator. An advantage of option B is that it could require only the installation of the architecture platform 804 without any other telephony infrastructure at the customer premise. The following describes how the data flows through the system shown in FIG. 8G.
The customer application 802 sends an HTTP request to the incall agent 801. One of the arguments to the HTTP request is a URL for the XML document defining the request details. The incall agent 801 checks the access permision for the requesting host and the arguments to the HTTP request, and then passes the XML file to content manager 842. The content manager 842 parses the XML file, processes related audio files, and stores the relates audio files at a proper location for one or more expected callers (ANI) calling into one or more specified numbers (DNIS).
When a call arrives at a particular voice port (DNIS) on the VoiceXML gateway 832, the VoiceXML gateway 832 sends an HTTP request to the architecture platform 804 asking for a pre-defined VoiceXML root document associated with that DNIS. If the caller's ANI is also delivered to the gateway 832, the gateway 832 will store the ANI at a location for the VoiceXML root document to use if desired.
The VoiceXML root document, after arriving at the VoiceXML gateway, will initate the IVR/DTMF dialog manager with DNIS and ANI if it is available.
IVR dialog manager 840 (written in JSP and VoiceXML) will contact the content manager for the initial opening prompts associated with that DNIS such as branding or service name defined in the XML document from the customer application 802.
If ANI is not available, the IVR dialog manager 840 will ask the caller to enter their ANI in DTMF. With DNIS and ANI, the IVR dialog manager 840 will retrieve relevant information about this call from the content manager 842 and carry on the dialog with the caller.
After obtaining a user response (if required) in DTMF, the IVR dialog manager 840 will send the user response to the incall agent 801 along with various status codes in the form of an HTTP request.
The incall agent 801 will then contact the content manager 842 to determine if there is a response URL defined in the XML document from the customer application 802. If there is, the incall agent 801 will send the user response to that response URL. If there is no response URL, or if the call is not successful, the incall agent 801 will send the user response to the customer application 802 if requested (via an argument to the orignial HTTP request from the customer application).
The user interface for the incall service includes prompts that can be constructed from pre-recorded prompts, customer supplied audio files, or text-to-speech. The user interfaces for both option A and option B can be identical. However, limitations of VoiceXML may dictate some differences in the interfaces.
The basic user flow for the incall agent 801 is illustrated in FIG. 8H. The user calls the incall agent IVR 862. In cases where the content is user and/or session-specific, if the customer application does not get the caller's telephone number via MIN, it asks the caller to input their telephone number by DTMF 864. Once it has the telephone number, it authenticates the caller 866, if directed to do so by the presence of authentication parameters in the XML file. Once the caller is authenticated, the incall agent IVR plays the content for the user to listen to 868. The incall agent IVR also offers any appropriate content player commands with any menu choices, or prompts the user for a multidigit input. The user may enter a menu selection or a multidigit input 870. Hanging up 872 ends the session.
The customer must supply the XML file that drives incall agent. The customer may build this XML file in any way, but for the purposes of this document, we assume that the XML file is built through some sort of automated application (e.g., a customer application). This customer application then sends the XML file to the incall agent via an HTTP request. The formats for the XML file and for the request are detailed below.
For a VoiceXML-based configuration, the VoiceXML gateway chosen to provide the run-time environment for the IVR/DTMF dialog manager (written in VoiceXML and JSP) is considered to be an external component even if such a VoiceXML gateway platform is on the same LAN as the architecture platform. The interface between such a VoiceXML gateway and the incall agent is an HTTP request. For each inbound voice port on the VoiceXML gateway there is a corresponding URL that points to a VoiceXML root document stored on the web server of the architecture platform. This URL must be reachable from the VoiceXML gateway, for instance: http://<mobHost>/vxml/IncallService_start.vxml.
This root document URL is typically provisioned via an administrative interface on the VoiceXML gateway using standard web browsers or some type of graphical user interface (GUI) or text file entries. Table 1 shows the logic entries in such a provisioning table.
TABLE-US-00003 TABLE 1 Channel IDs DNIS Default url 14 5124939850 http://<mobhost>/vxm1/SCI.vxml
The database provisioning for incall services specifies which hosts may illustrated in Table 2, a table in a services database contains the following data for each host provisioned:
TABLE-US-00004 TABLE 2 Column Name Contents id Unique id (primary record key) host IPaddress purpose R for requesting host, A for answering host, V for a VoiceXML gateway permission Yes/No for current availability/authorization
Only those hosts with R purpose and Yes permission can submit requests for incall agent services. Only those hosts with D or V purpose and Yes permission will be assigned requests for answering an incoming call to the incall agent IVR host (Dialogic D41/ESC based or VoiceXML gateway based). The host for the response URL and the host for the machine storing the XML must be provisioned in addition to the IVR host and the requesting host. For option B, the following additions are made to the incall agent provisioning table. These items are specified per DNIS:
Document Root directory;
Install type--either US/Canada or Europe (default is US/Canada);
Language for the prompts;
Voice talent;
Input mode--voice or DTMF; and
Audio Playback Skip Interval (go back or forward by N seconds).
For each item, a default is predetermined.
In one embodiment, the incall agent is a Java servlet based software module that acts as a link between the customer application and the IVR component. The incall agent uses the standard Internet HTTP protocol to communicate with the IVR, as well as to return status codes to the customer application. The incall agent also verifies that incall requests emanate from known authorized hosts, and manages assignment of requests to available hosts.
In one embodiment, the IVR is the component responsible for interacting with the end user. It interacts with the incall agent to receive the XML that feeds the dialog with the end user. After the voice channel based dialog with the end user, the IVR sends back a report in XML to the incall agent. The report contains the status of the call (e.g., success or failure) and the user response in DTMF, if required. The incall agent assembles a response message in XML and sends it to the response URL specified in the original XML file from the customer application. If no response URL is specified, the incall agent will discard the status report from the IVR. If the response URL returns a VoiceXML document in the case of VoiceXML configuration for this service, the VoiceXML document will be sent to the VoiceXML gateway. This will allow the user to conduct further interactions via the voice channel.
In one embodiment, for options A and B, the incall agent sends a post-call response either to the customer application or to the response URL. If the call is not successful, for example user input was desired but none was obtained, or the user disconnected before the end of the content message, the incall agent returns a status code indicating the nature of the call to the customer application. If the call was successful, for example user input was obtained, or no user input was desired and the listener heard the entire content message, the incall agent sends the call status along with the user input (if it exists) to the response URL.
Any file or text to be played to the end user is specified as a .wav file, a .txt file, or text in double quotes. FIGS. 9A 9D provide more detail regarding the incall XML tags. FIGS. 10A and 10B list example XML files that illustrate the use of the tags in the XML sent by a customer application to the incall agent.
The incall agent uses the standard Internet HTTP protocol to communicate with either the incall service IVR running on a Dialogic.TM. D41/ESC based telephony platform or the incall service IVR/DTMF dialog manager implemented as a set of VoiceXML documents which reside on the web server of the architecture platform. In addition, the incall agent sends the appropriate response messages to the response URL (if specified) that may or may not be a part of the customer application requesting the incall service. Specifically, the incall agent performs the following tasks: for each HTTP request from the customer application, normal Internet status codes are returned, i.e., 200 for valid request and 400 for failing to parse the arguments to the HTTP request; handle an optional parameter to the HTTP request from the customer application, such as acknowledge=<true|false>; default is true; upon receiving the HTTP request, the incall agent sends back a status code to the customer application in XML format (such as "the XML file does not parse") if acknowledge=true; after successfully completing the call as specified in the XML document, the incall agent sends the status report and the user response in XML format, if required, to the response URL; if no response URL is specified, the incall agent sends the XML data back to the customer application if acknowledge=true; after failing to complete the call or failing to obtain a user response as required, the incall agent sends proper status codes and related error messages to the customer application if acknowledge=true; delegate appropriate tasks to other components such as the C++ based IVR component or the VoiceXML based IVR/DTMF dialog manager to handle the incoming calls; and receive the final call status and the user response, if specified, from the IVR component via an HTTP request with embedded XML body as follows: http://<mob-host>/servlet/Incall?ANI=<ANI>&DNIS=<DNIS>.
The incall agent acts as a link between the customer application and the IVR component in both option A and option B. The format for the request from the customer application is http://<hostname>/servlet/Incall?ID=abc&xml=aaa.xml&acknowledge=<- ;true|false> where:
hostname is the name of the server where the incall agent resides;
ID (abc) is the customer specified ID for the call;
xml (aaa.xml) is the XML file name; and
acknowledge is true or false for returning acknowledgement to the customer application.
The incall agent responds to the customer application with HTTP requests, first to indicate the immediate feedback from receiving a request, and then with the result from the call. The immediate response consists of XML containing status and message in the following format: <status>nnn</status> <message>message text</message>
where the status is 200 for a success and 400 for HTTP request not valid.
Once a call comes in and is completed, the incall agent responds either to the customer application or the response URL, depending upon the status of the call. If the call is successful, the incall agent responds to the customer application. If the call was not successful and the acknowledge parameter is set to true in the original HTTP request from the customer application, the incall agent sends the status code back to the customer application. If the acknowledge parameter is set to false, the incall agent does not send a status code back to the customer application.
Table 3 lists 2-digit status codes returned from the incall service IVR to the incall agent under various conditions.
TABLE-US-00005 TABLE 3 Message Status Code SUCCESS 10 NO_ANSWER/BUSY 20 AUTHENTICATION_FAILED 21 HANGUP_AFTER_AUTH 22 HANGUP_DURING_CONTENT_PLAY 23 HANGUP_AFTER_CONTENT_PLAY 24 HANGUP_DURING_MENU 25 HANGUP_AFTER_MENU 26
MISSING_ARGUMENTS_FOR_RESPONSE 27 NO_ENTRY_FOR_CALLER 28 Input MENU_CHOICE_0 0 MENU_CHOICE_1 1 MENU_CHOICE_2 2 MENU_CHOICE_3 3 MENU_CHOICE_4 4 MENU_CHOICE_5 5 MENU_CHOICE_6 6 MENU_CHOICE_7 7 MENU_CHOICE_8 8 MENU_CHOICE_9 9 MENU_CHOICE_TRANSFER 10
MULTIDIGIT_INPUT [xx. . .xx]
The incall service IVR sends this status code to the incall agent using a standard HTTP POST request as follows: http://<hostname>/servlet/Incall?call_ID=<call_id>&url=<re- sp_URL>
where the <resp_URL>(optional) came from the XML data received earlier from the incall agent. The XML specifying the response is as follows: <status>NNN</status>; <input>X</input>; <message>message text</message>.
If there is no input (e.g., in the case of a hang-up, or when no choices are specified in the XML), the input tag is absent.
Based upon a "Purpose" configuration for the answering hosts provisioned at an administrative screen of a user interface, the incall agent knows if an answering host is a Dialogic D41/ESC-based IVR platform (Option A) or a VoiceXML gateway (Option B). In case of option A (Purpose=A), the incall agent communicates with the IVR component via an HTTP POST, with an attached XML body, as follows: http://<IVR-host>/SmartIncall.html?id=<id>
where the attached XML body is strictly copied from the original XML file submitted by the customer application.
In case of option B, the incall agent will pass this XML file to a Java-based content manager, which parses the XML file and processes individual XML elements accordingly. For either configuration option, if the XML file fails to parse (e.g., because it is missing the <Service>element), the incall agent sends proper status codes and related error messages to the customer application if acknowledge=true. Because both the incall agent and the content manager are implemented in Java classes and reside on the same architecture platform, they can communicate with each other using either http requests or Java class based services.
The incall agent keeps a list of requests that have been submitted. An HTTP request of the form http://<hostname>/servlet/Incall?pending will return a list of request IDs not yet reported as completed, along with their time of submission.
This Java based software module resides on an application server of the architecture platform. Its primary function is to parse the XML received from the incall agent, process audio content, and store it as various URLs for the IVR/DTMF dialog manager (VoiceXML document) to use. In one embodiment of option A, this set of functions are performed by a C++ based module residing on the Dialogic.TM. D41/ESC based telephony platform.
One of the variables the content manager must know is the location of the root directory for all the audio content files and system prompt files. Like the initial login page for the web administration of the architecture platform (e.g., http://<hostname>/html/Welcome.jsp), the underlying JSP document is stored in a pre-defined system folder. Similarly, the content manager must obtain this root directory location information from a data source. In one embodiment, this interface is implemented by introducing a new field on an incall service administrative page to associate the default web document folder for the web server with the actual reachable local folder name.
In one embodiment of option A, the installation will copy the system prompts for the incall service into a location that is not designed for constructing a URL path. For example, the actual system prompt files are copied from the release compact disc (CD) into a typical local folder.
In one embodiment of option B (VoiceXML version), all system prompt files are also copied into an appropriate webclient folder. For example, if these system prompt files are copied into the webclient folder, they are reachable later by a VoiceXML document.
For example, a Welcome.wav audio file stored there can be referenced by the following URL:
http://<hostname>/com/mobileum/incall/sounds/US_English/prompt/mobil- eum/Welcome.wav
The directory structure for managing audio content is designed to handle both broadcasting mode, in which the same audio message could be accessed by millions of different end users, and personal mode, in which one audio message is only for one particular end user. The overall audio content directory tree is structured to support four mutually related branches under the root directory: DNIS, Service, ANI, and Audio. The following example directory tree is constructed by the content manager based on an XML file describing one DNIS entry, two ANI entries, one audio content file with a URL path, and a three-choice menu with each menu choice represented by a URL path pointing to an audio file of proper file format (.wav). To support fast-forward or fast-rewind while playing a long audio file, the content manager constructs five overlapping audio files from the original audio file. In the example of Table 4, it is assumed that the audio content is presented by a text file divided into three text files for support of playback options.
TABLE-US-00006 TABLE 4 $root_directory/<DNIS>/<Service_ID>/<Service_ID>.service- _name .../5122901234 .../5122904567 .../audio/moive_sales.wav .../<time-stamp>_1.wav .../<time-stamp>_2.wav .../<time-stamp>_3.wav .../<time-stamp>_4.wav .../<time-stamp>_5.wav .../audio_text/<audio_file_name>.txt .../audio_text/1.txt .../audio_text/2.txt .../audio_text/3.txt $root_directory/sounds/<language>/prompts/<voice-talent>/ Thank_you.wav .../Goodbye.wav
Every XML file requires a service name element, such as <Service name="some text">. Because the name attribute does not have any limit on text strings, the content manager maps each name string into a unique service ID using some algorithm. For example, a name string "movie sales online store" may be mapped into "moviesale1404", which is the first two words plus a 4-digit sequence number.
The content manager provides an API as illustrated in Table 5 for the IVR dialog manager or the incall agent to retrieve context information about a specific call.
TABLE-US-00007 TABLE 5 API Argument Data Available Explanation/Example DNIS $root_directory cm().root <language> cm() language <service_ID> acm().serviceID DNIS, ANI Auth_description cm().authDescription (could be null) Auth_code cm().authCode (could be null) NumAudioSeg cm().NaudioSeg (1 to N) Prefix_audio_file cm().prefix (e.g., <time-stamp> like YYYYMMDDHHMMSS) Suffix_audio_file cm().suffix (e.g., ".wav") NumMenuChoices cm().NmenuChoices (1 to 9), acm() .menu [i] cm().menu[I].type = "txt","wav","url" ANI <response_URL> Acm().responseURL (could be null)
For option A, the telephone number collection component uses the telephone number class as previously defined. In one embodiment, the DTMFTelephoneNumberClass is used. For option B, the telephone number collection component is implemented in VoiceXML. In one embodiment, telephone number collection is always turned on, because MIN may not be reliable across a VoiceXML gateway.
The behavior of the authentication component is the same for option A and option B. If the XML contains non-empty strings for the authentication description and authentication code, this component plays a phrase such as, "If you are $expected_caller, please enter your <authentication_description>followed by the pound sign". The authentication component accepts a string of DTMF tones. If the string matches the expected authentication code, the authentication component returns "true", otherwise it repeats the above procedure up to a configurable number of times. If the user has not entered the correct code the authentication component plays a final error message, drops the call, and returns "false".
If the XML contains no authentication codes, the component returns "true". An empty authentication description or an empty authentication code indicates that authentication is not necessary for this interaction and therefore should be skipped in the dialog.
The following use cases are examples that describe the user experience with the incall service, including the interaction on a data session with the application, the call initiated from the data session, the interaction with the IVR, and subsequent actions. The incall service handles the portion of this experience that dictates the interaction between the user and the IVR.
In a first case, Jane follows Company WX and other wireless infrastructure companies closely. She subscribes to a service from Epoch Partners.TM. that provides her with an analyst's comments every Tuesday morning. When she turns on her cellular telephone on Tuesday morning, typically there is already an alert message from Epoch Partners.TM. waiting for her. Once she has gotten her daily 30-minute commute to work underway, she views the alert message. The message offers Jane the option to listen to the report. Jane presses the "CallIn" softkey, puts the handset to her ear, and waits to hear the analyst report.
The content in the report is specific to Jane, and therefore requires her telephone number as well as an authorization code. If Jane's telephone number does not come through on CallerID, the IVR will ask her for it. Jane uses the "fast forward", "rewind", and "pause" functions to facilitate reviewing the material. When Jane gets to the end of the message, she can choose an action such as faxing or emailing the document.
If Jane's call drops, she uses her telephone's "redial" function to get back in. She uses the "fast forward" function to get back to the portion she was last listening to.
In a second case, John wants to see a movie at a theatre tonight, but doesn't know what is playing. He accesses the Fandango.TM. site from his cellular telephone. John has previously allowed that site to categorize the zip code he lives in as well as his movie preferences. John loves action films and never wants to hear about romances. Today, he can see that there are two interesting looking films playing nearby. John selects one of the films and presses a softkey that invites him to listen to a movie review. He then puts the handset to his ear. When the call connects, he hears the movie review. After the review is completed, he is offered the option to purchase a ticket. Instead, John just hangs up and browses to the next film, to hear that review.
The movie review must be queued up for John when he requests it. While it is a public piece of material, it is one of many available. Therefore, if John's CallerID had not come through, he would have been asked to key in his telephone number. However, because this is not secure material, John will never be asked for an authorization code of any kind. John can take advantage of the "fast forward", "rewind", and "pause" functions to navigate through the material.
Because the "actions" on this material are optional, hanging up is an option for John. John just goes back to where his browser left off. Many telephones cache the last page. For telephones that do not cache the last page, and "action" can allow the user to return to a previous location in a data session. If John elects to purchase a ticket, a browser alert is sent to allow him to navigate easily to the appropriate point in the data site.
The outcall service and outcall agent will now be discussed in more detail. In one embodiment, the outcall service enables a customer application to send a voice alert to an end user by making an outgoing call and playing audio messages to the person called. The outcall service then either plays a single-tier menu or plays a prompt asking for multidigit input, and accept a response.
The outcall service initiates a call to an end user which may or may not be an actionable call. The customer application specifies that the IVR send a voice alert by calling an end user. Once the end user answers and authenticates (if necessary), the specified voice files are played, choices are presented, or an input string is asked for, and a response is accepted. The XML file sent by the customer application can specify the phone number to call and the audio file(s) to be played. as well as the authentication information, menu choices or value input prompt, and transfer information.
In one embodiment, the outcall service requires the following system setup: Windows 2000, Service pack 2; 128 MB of RAM required, 256 MB recommended for D/41 setup, 256 MB required for T-1 card; Pentium III or better, 733 MHz or faster required,
1 GHz recommended for better Text-to-Speech performance; Disk space for audio content caching: about 30 MB per hour of audio; Dialogic telephony system release 5.0.1; A single Dialogic D/41-ESC card (4 channels) or a single Dialogic D/240 (T-1); Fonix FAAST TTS 5.0 software; and Adequate network bandwidth for downloading audio content (LAN, DSL, or T-1).
Digital trunks require different call control signaling than the analog lines. The two most common signaling schemes for T1 lines in North America are Robbed Bit Signaling (RBS) and Primary Rate ISDN (PRI). For RBS, a non-ISDN digital trunk is provided over a channelized T-1 facility. 24 channels are available for voice or customer data circuits. Signaling is in-band in that a few bits from each T-1 super-frame are "robbed" to serve as status bits for the 24 channels. Each channel ends up with only 56 k bits per second of real throughput. Digits are sent as DTMF or MF tones in-band during call setup.
In various embodiments, different protocols may or may not be supported for RBS and PRI. For example, for one embodiment using PRI, only National ISDN 2 (NI2) protocol is supported.
One embodiment of the outcall service supports a T-1 line based Dialogic.TM. digital telephony platform with a single T-1 interface card (D240). With a T-1 line, the outcall service can support 1380 outgoing one-minute calls per busy hour, at
100% capacity. To handle failover, the outcall service keeps the XML files sent by the customer application. In a worst-case scenario, the end user could receive more calls than the ensure completion value indicates. However, this case is expected to be extremely rare and the consequences acceptable. The outcall service allows multiple active IVR hosts to be provisioned, therefore, if one IVR host is down, another can complete the calls. A switch to a new IVR can be manual or automatic.
FIG. 11A is an overview diagram of one embodiment of the outcall service. The outcall agent 1101 communicates with the customer application 1102 and the IVR 1133. The IVR 1133 communicates with the wireless device 1106. The following items explain a data flow for the outcall service: (1) the customer application sends an XML file to the outcall agent; (2) application telling it whether the request was accepted; (3) the outcall agent passes the XML file on to the IVR, and the IVR passes the XML and checks the headers of the audio files to ensure they are acceptable; (4) the IVR calls the specified number; (5) the IVR asks for authentication to ensure that the correct person was reached (this is optional); (6) the IVR plays the content message and any menu choices or a prompt for multidigit input; (7) the IVR sends the recipient's response to the outcall agent; and (8) the outcall agent returns a status message to the customer application including the recipient's response.
Typically, the outcall agent 1101 resides on the architecture platform 1104 as shown in FIG. 11B.
FIG. 11C illustrates an example of a user flow for the outcall service. The user receives a telephone call, just like any normal telephone call. When the user answers 1140, they authenticate 1142 if necessary. If it is not necessary to authenticate, the user can press any key to indicate that the system has reached a person and not an answering machine or voice mail. The user can then listen to the content message 1144 (with the appropriate content player commands) and choose from the menu choices 1146, if offered. If the menu choices permit, the user may choose to be transferred to a different number. Hanging up 1148 terminates the session.
Various implementation details for embodiments of the outcall service will now be discussed. The implementation details refer to two of the software components that work together to provide the functionality of the outcall service. The first component is a Java-based outcall agent. The second component is a C++ based software component, the outcall IVR, which interfaces directly to a Dialogic.TM. telephony platform.
The customer must supply the XML file that drives outcall service. The customer may build this XML file in any way, but for the purposes of this document, we assume that the XML file is built through some sort of automated application (e.g., a customer application). This application then sends the XML file to the outcall service via an HTTP request. The tags for the XML file are detailed in FIGS. 12A 12D. FIGS. 13A and 13B list example XML files that illustrate the use of the tags in an XML file sent by a customer application to the outcall agent.
The outcall agent makes standard requests of the product provisioning and configuration tables that are stored in a database of the architecture platform. This set of tables can be organized as a single web page for all voice products. The outcall agent has its own web page to provision various run-time parameters. In addition, the outcall agent is integrated with other services to deliver "voice" alerts in addition to other types of alerts such as WAP, SMS, etc.
The database provisioning for the outcall services specifies which hosts may make requests, and which hosts are available to serve those requests. A MOBHOSTPERMISSION table in a services database contains the data shown in Table 6 for each host provisioned.
TABLE-US-00008 TABLE 6 Column Name Contents Host IP address or domain name such as www.ml.com Reference App Outcall Host Type Request or IVR Permission Yes/No for current availability/authorization
Only those hosts with host type Request and permission Yes can submit requests for outcall services. Only those hosts with host type IVR and permission Yes will be assigned requests for dialing. In the case of a WAP browser making the request of the outcall service, the host on which the attached XML file can be found must be provisioned.
The outcall agent checks licensing issues and interacts with the customer application and the IVRs. One task of the outcall agent is determining which provisioned IVR to send an XML file to. The outcall agent uses a load balancing algorithm to determine the IVR that has been contacted least. However, the outcall agent must send all HTTP requests with the same ID to the same IVR so that M-files and their corresponding P-files go to the same IVR. The outcall agent also determines if/where to send a response based on the outcome of a call.
The outcall agent accepts an XML file from the customer application via an HTTP request. The request may be either a POST or GET request. If the customer chooses to utilize a GET request, the format for the request from the customer application is as follows: http://<hostname>/servlet/Outcall?ID=<abc>&xml=<xml=file url>&acknowledge=<true|false>
The format for a POST request is as follows: http://<hostname>/servlet/Outcall?ID=<abc>&acknowledge=<tr- ue|false>
where
TABLE-US-00009 hostname is the name of the server where the outcall agent resides ID abc is the customer specified alphanumeric ID for the XML request xml xml-file is a UIRL pointing to the XML file that specifies the dialog acknowledge specifies whether the sending application will receive error messages or not, since only information about successful calls will be sent to the response URL specified in the XML
In order for the outcall agent to support multiple customer applications and multiple IVRs, the ID for an M-file and all corresponding P-files must match. An M-file is one that contains a MULTICALL tag and possibly a PERCALL tag. A P-file is one that contains only a PERCALL tag and no MULTICALL tag. The calls specified in a P-file use tag values specified in a previous M-file.
The outcall agent responds immediately to the customer application with an HTTP request to indicate the immediate feedback from receiving a request. This immediate response consists of XML containing the status and a message in the following format: <status>NNN</status> <message>message text</message>
where the status is 200 for success, or 400 for HTTP request not valid.
After the outcall IVR completes a call, either successfully (e.g., by reaching the number specified in the XML file), or unsuccessfully (e.g., by reaching a point at which it cannot fulfill the request for any reason), it sends a final status code to the outcall agent.
The 2-digit status codes shown in Table 7 are returned from the outcall IVR to the outcall agent under various conditions.
TABLE-US-00010 TABLE 7 Message Status Code SUCCESS 10 NO_ANSWER/BUSY 20 AUTHENTICATION_FAILED 21 HANGUP_AFTER_AUTH 22 HANGUP_DURING_CONTENT_PLAY 23 HANGUP_AFTER_CONTENT_PLAY 24 HANGUP_DURING_MENU 25 HANGUP_AFTER_MENU 26
MISSING_ARGUMENTS_FOR_RESPONSE 27
The outcall IVR sends this status code to the outcall agent using a standard HTTP POST request as follows: http://<hostname>/servlet/Outcall?call_ID=<call_id>&url=<r- esp_URL> where the <resp_URL>(optional) came from the XML data received earlier from the Agent. The XML specifying the response is as follows: <status>NNN</status> <input>X</input> <message>message text</message>
If there is no input (e.g., in the case of a hang-up or if no choices are specified in the XML), the INPUT tag is absent.
After the outcall agent receives a final response from the outcall IVR, the outcall agent will reply to the response URL of the customer application, or not at all, depending on the status of the call and the value of the acknowledge parameter in the original HTTP request. If the call is successful (status code 0) the outcall agent will form an HTTP request to be sent to the response URL with the following format. <resp_URL>?call_ID=<call_id>&status=NN&input=value&message=me- ssage
where "NN" is the 2-digit status code from outcall IVR, "input" is the user's input, and "message" is the corresponding message. For example, if the status code is 0, the input 1, the message will be "Menu Selection 1".
If the status code is not 0, the outcall agent will determine where to send the result based on the acknowledge parameter sent with the original HTTP request from the customer application. If the acknowledge parameter is set to True, the outcall agent will send the result of an unsuccessful call back to the customer application. If the acknowledge parameter is False, the outcall agent will not respond to the customer application with the result of the call. The default for the acknowledge parameter is True.
The outcall IVR keeps a list of requests that have been submitted, but have not yet been