System and method for providing access to an interactive service offering

Abstract

A system and method are disclosed for providing access to an interactive service offering. A method incorporating teachings of the present disclosure may include receiving a first communication in a format that complies with a first protocol. The first communication may be associated with a desired interaction between a first device and a voice activated service (VAS) platform. The method may also include receiving a second communication in a different format that complies with a different protocol. The second communication may be associated with a desired interaction between a different device and the VAS platform. A system implementing the method may recognize that a platform does not support the first protocol, and translate the first communication to a platform-supported format to facilitate the desired interaction.

Description

CLAIM OF PRIORITY

The present application claims priority from and is a continuation of patent application Ser. No. 10/751,685 filed on Jan. 5, 2004 and entitled “System and Method for Providing Access to an Interactive Service Offering,” the contents of which are expressly incorporated herein by reference in their entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to the provisioning of interactive services, and more specifically to a system and method for providing access to an interactive service offering.

BACKGROUND

Voice activated service (VAS) offerings often employ some technique for providing requestors with interactive and voice-based access to information. One relatively common technique involves an interactive voice response (IVR) application. A typical IVR application includes software for accepting voice telephone inputs or touch-tone keypad selections from a requester. In response, the application may provide the requestor with responsive information and/or effectuate a requestor command.

The goal of many IVR and IVR-like solutions is often to reduce the number of low value-add calls handled by actual agents. In theory, automating common interactions may provide an enhanced level of requestor satisfaction while reducing the average cost per call. In practice, many organizations presenting VAS offerings find the available VAS platforms to be ineffectual.

While speech recognition technologies have assisted in making traditional IVR applications more requestor-friendly, these solutions often require proprietary software, hardware, and interfaces—increasing implementation costs and tightly coupling the organization deploying the technology with the organization supplying the technology. This combined with complex integration requirements and limited interoperability has helped make application development costly, slow, and rigid.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the Figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating teachings of the present disclosure are shown and described with respect to the drawings presented herein, in which:

FIG. 1 presents a flow diagram for providing flexible interconnection between disparate requesters and disparate VAS platforms in accordance with the teachings of the present disclosure;

FIG. 2 shows one embodiment of a network implemented system that incorporates teachings of the present disclosure to interconnect end users and VAS providers; and

FIG. 3 shows a block diagram of various components that may be employed in a system incorporating teachings of the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

Embodiments discussed below describe, in part, the provisioning of voice activated services (VAS) in a technology and protocol flexible manner. From a high level, a system incorporating teachings of the present disclosure may effectively create an abstraction layer between a requestor interface and a VAS or other interactive service offering. While the requestor interface may “understand” or be capable of communicating with a given requestor device, the service offering may employ a system or technology that does not “understand” the requestor device. In operation, the abstraction layer mentioned above may act as a translator - facilitating communication between the requestor device and the platform of the VAS offering.

A network-based VAS offering may be deployed on a vendor and/or technology specific platform. To interact with the deployed platform, a requestor may need to route communications through a tightly coupled requestor interface. The tight coupling may exist, for example, by virtue of some rigid and proprietary application interface requirements promulgated by the VAS platform. An abstraction layer that breaks this rigid platform/interface link may allow for lower cost, more flexible, and less rigid interactive service offerings.

An example technique incorporating teachings of the present disclosure may include receiving a first communication in a format that complies with a first protocol. The first communication may be associated with a desired interaction between a first device and a voice activated service (VAS) platform. The method may also include receiving a second communication in a different format that complies with a different protocol. The second communication may be associated with a desired interaction between a different device and the VAS platform. A system implementing the method may recognize that the VAS platform does not support the first protocol, and translate the first communication to a platform-supported format to facilitate the desired interaction.

As mentioned above, FIG. 1 presents a flow diagram for providing flexible interconnection between disparate requestors and disparate VAS platforms in accordance with the teachings of the present disclosure. As shown, technique 10 may begin and, at step 12, a VAS platform may be registered. Registering a platform may be an automated process and/or a more manual process. In some systems, an administrator may be able to remotely register a platform. For example, an administrator may be presented with a graphical user interface (GUI) at a remote location. The administrator may interact with the GUI to effectuate the creation or registration of one or more platforms. An administrator may effectively “tell” a system implementing technique 10 that a VAS platform being registered provides a specific interactive service and supports one or more communication protocols.

The interactive services may or may not be voice-enabled. The services may, for example, provide information like directory assistance, voice-based web browsing, regional information like weather and traffic alerts, some other types of information, and/or a combination thereof. The supported protocols may include, for example, Voice over Internet Protocol (VoIP) communications, TCP/IP, traditional telephony or Plain Old Telephony Service (POTS) communications, protocols associated with the Public Switched Telephone Network (PSTN), other communication-related protocols and formats, and/or combinations thereof. Through the supported protocols, the services can receive and process the request expressed in form of standards-based scripting languages such as HTML, extensible Markup Language (XML), VoiceXML, hybrids of eXtensible HTML (xHTML) and VoiceXML like (X+V), Speech Application Language Tag (SALT), and/or combinations thereof.

At step 14, a system implementing technique 10 may receive a call initiated by a requester. The requester may be remote or local. In some embodiments, the requestor may be a device making automated requests for information. The requestor may also be a remote end user employing an electronic communication device to interact with a network-based interactive service platform. The communication device may take several forms and may communicate information in formats that comply with one or more protocols. Communication devices may be implemented, for example, in wireless and cordless phones, personal digital assistants, cellular telephones, mobile telephones, laptop computers, desktop computers, mainframes, PSTN switches, Ethernet switches, routers, gateways, hardware, firmware, software, work stations, other options having some level of computing capability, and/or a combination thereof.

At step 16, a system implementing technique 10 may employ some methodology and/or engine for assessing what technology is supported by the requesting device. The system may, for example, recognize a supported protocol by considering the format of the incoming request. The system may also, at step 18, determine the information and/or the location of the information being requested. For example, a system implementing technique 10 may recognize that the requestor seeks directory information or some network-based data service information like stock quotes, account information, and/or help-line information. The system may recognize the type of information sought by actually considering the content of information received from the requester, considering dialed digits, considering an addressee of the request, some other technique, and/or a combination thereof.

In response to determining the type of information requested, a system implementing technique 10 may access a memory maintaining a list of available and/or registered interactive service platforms. The list may indicate the type of information available at each of the platforms, and at step 20, the location of requested information may be determined.

At step 22, a determination may be made as to whether or not additional information is implicated by the request. For example, a given request may indicate a desire or need for information maintained in a memory remote from the interactive service platform. If additional information is desired, technique 10 may progress to step 24, where the additional information is retrieved. The additional information may take several forms and may be communicated to the requestor and/or to the platform. The additional information may be communicated at step 26 and may include information about the requestor, information about the platform, information about a third party, authentication information, authorization information, other information, and/or a combination thereof. In some embodiments, the communication may be in-band and/or out of band from an interaction between the requestor and the appropriate platform.

Whether or not additional information was desired and/or needed, technique 10 may progress to step 28. At step 28, a system implementing technique 10 may determine a technology or communication protocol supported by the platform serving the requested information. At step 30, the system may determine whether or not the platform-supported protocol is supported by the requester device. If it is not, technique 10 may progress to step 32 and a connector may be employed to facilitate communication between the requestor device and the platform.

The connector may effectively form an abstraction layer between the requestor device and the platform. In some embodiments, this abstraction may be facilitated by an intermediary and/or generic protocol. For example, a request may come in having a format that complies with a first protocol, and the platform may communicate information in a format that complies with a different format. To effectuate communication between the requestor device and the platform, an intermediary protocol may be employed. The intermediary protocol may be one of the protocols natively supported by either the platform or the requestor device. It may also be a third protocol different than both the platform-supported protocol and the device protocol.

Technique 10 may eventually progress to step 34 and the request may be output to an appropriate platform. At step 36, information may be received from the platform and converted, if necessary, at step 38 into a format receivable by the requestor device. Various steps of technique 10 may be repeated in dialogues requiring additional interaction between a requestor device and a platform. Those skilled in the art will recognize that various steps of technique 10 could be implemented by a single server or computing platform, by a combination of devices, by hardware implementations, firmware implementations, software implementations, and/or combinations thereof.

For example, in one implementation, a computing platform may be able to read and execute computer-readable data to receive a voice communication having a first format, the communication associated with a desired interaction between a first device and a voice activated service (VAS) platform, to recognize that the VAS platform communicates voice information in a different format, and to effectuate the desired interaction by altering the voice communication to have the different format. A computer-readable medium storing the data may have additional computer-readable data to facilitate communication between a plurality of communication devices each communicating information in respective formats that comply with different protocols and a plurality of VAS platforms.

As mentioned above, FIG. 2 shows an embodiment of a network implemented system 40 that incorporates teachings of the present disclosure to interconnect end users and VAS providers. As shown, system 40 include a PSTN 42, Public Internet 44, and a wireless or cellular network 46. Other networks and network types may also be incorporated into system 40. In operation, a user may interact with one or more of the depicted system elements from a variety of locations and using a variety of device types. For example, a user may be at customer premises 48 and attempting to access an interactive service platform using POTS telephone station 50 or connected computer 52. A user may also be mobile and using wireless communication device 54 to interconnect with network 46 via network node 56.

Communication between device 54 and node 56 may take several forms. As shown, wireless communication 58 may be a Radio Frequency (RF) communication. As such, device 54 may be capable of Radio Frequency communication that employs a 2.5 G mobile technology like GPRS or EDGE. Device 54 may also employ higher bandwidth offerings like 3 G/UMTS. In some embodiments, device 54 may communicate with node 56 using a short-range or local wireless technology like 802.11, Wi-Fi, Bluetooth, and/or some other technique.

In operation, a device like device 54 may issue what amounts to a request to access a remote interactive service platform, like remote platform 60 or 62, each connected to Public Internet 44. Platforms 60 and 62 may support business logic and may provide Voice Activated Service functionality to an end user or requestor. The functionality may include, for example, traditional telephony features found in a conventional IVR, enhanced applications like text-to-speech, speech-to-text, speech recognition, speaker identity enrollment/verification, voice-based web browsing other functionality, and/or combinations thereof.

Platforms 60 and 62 may support a various protocols, and those protocols may not be supported by device 54, telephone 50, and/or computer 52. As such, to facilitate communication between various platforms and various devices, a network service provider may elect to employ an access center, like center 64. As depicted, center 64 may be operating as a service bureau and may support users from different networks and platforms associated with different networks.

Center 64 may present users with a network interface 66, which may be capable of forming at least a portion of a link communicatively coupling a remote communication device, like device 54, and an interactive service offering platform, like network platform 68. In some embodiments, network interface 66 may include a telephony interface, an Integrated Voice Response interface, a Voice over Internet Protocol interface, and/or a Voice over Extensible Markup Language interface. In operation, a requester device may engage one of these interfaces. The interface engaged may depend on the communication protocols supported by the requesting device. An interconnection engine 70 may recognize which interface of the network interface is engaged by the remote communication device. In response, the interconnection engine may output a signal indicating the communication protocol being used by the requestor device.

Center 64 may also include a platform interface 72, which may also be capable of forming at least a portion of a link communicatively coupling a remote communication device, like device 54, and an interactive service offering platform, like network platform 68. In some embodiments, platforms 60, 62, and 68 may communicate using different protocols. As such, like network interface 66, platform interface 72 may include various interface types to facilitate interconnection with the different platforms. The interface types may include, for example, a telephony interface, an Integrated Voice Response interface, a Voice over Internet Protocol interface, a Voice over Extensible Markup Language interface, and/or other interfaces.

As mentioned above, interconnection engine 70 may recognize which interface of network interface 66 is engaged by a communication device. A mapping engine 74 may recognize the type of service sought by the requestor and query a memory 76 to identify the platform or platforms providing such a service. Memory 76 may be maintaining information that indicates service types and/or supported protocols for the various interactive service offering platforms associated with center 64.

In some situations, the supported protocols of a given platform may not include the native protocol of a requesting device. In such a situation, an abstraction engine 78 may be capable of facilitating communication between the remote communication device and the interactive service offering platform. Abstraction engine 78 may “know” that the requester device understands a first protocol and the platform understands a different protocol. Abstraction engine 78 may employ a multi-protocol connector to bridge between the appropriate interface of network interface 66 and platform interface 72. For example, a requestor device may only understand POTS-based communication formats, and a desired platform may be accessible through a VoIP interface. To facilitate communication between the two, abstraction engine 78 may employ a connector that translates between VoIP and POTS.

In some embodiments, the abstraction engine may make use of an intermediary protocol or format that differs from both POTS and VoIP. This intermediary may effectively act as a universal connector. In such an embodiment, communications associated with various interfaces of network interface 66 and platform interface 72 may be translated into a generic format and then back up into the desired format before being communicated to either the requestor device or the platform in their respective natively-supported formats.

Center 64 may also include a retrieval engine 80 to gather information from a remote repository 82 in response to a recognition that additional information is desired in connection with the communication between a remote communication device and an interactive service offering platform. It should be understood that the telephones, computers, devices, engines, servers, and/or platforms, described herein, may take several different forms and may be stand alone and/or incorporated into several different pieces of equipment, like laptop computers, desktop computers, telephones, mainframes, PSTN switches, Ethernet switches, routers, gateways, hardware, firmware, software, work stations, other options having some level of computing capability, and/or a combination thereof. For example, engines 70, 74, 78, and 80 could be independent applications, could be independent servers, could be executing on different platforms, and/or could be executing on a single platform like platform 84.

As mentioned above, FIG. 3 shows a block diagram of various components that may be employed in a system 86 incorporating teachings of the present disclosure. As depicted, end user devices 88 may interact with appropriate interfaces 90. As shown, end user devices may include wireless-enabled device 92, computing device 94, and POTS telephone 96. Appropriate interfaces may include IVR interface 98, VoIP enabled interface or client 100, and VoiceXML or X+V driven application interface 102. Other devices and interfaces may be employed in a system incorporating teachings of the present disclosure. The depicted components are illustrative examples.

In practice, devices 88 and interfaces 90 may make up the front-end portion 104 of system 86. The back-end portion 106 of system 86 may include platform interfaces 108 and platforms 110. Each of platforms 112, 114, and 116 may be accessible using one or more different protocols or communication formats. Communications directed to one or more of the platforms may pass through an interface capable of forming at least a portion of a communication link with a given platform. Platform interfaces 108 may include, for example, protocol or technology specific interfaces like telephony interface 118, Voice Over IP interface 120, and XML interface 122.

As shown, system 86 includes an abstraction layer 124, which may effectively act as a multi-protocol connector. Abstraction layer 124 may allow system 86 to interconnect many different types of devices communicating in many different formats with platforms supporting many different formats.

In an operational embodiment, device 94 may lack an audio interface capability (neither built-in microphone nor speaker) and may want to access some services. As such, device 94 may use interface 102 to submit the request. Through an abstraction layer 124, XML interface 120 may determine that the only interface available on the back-end portion 106 of system 86 is telephony interface 118 at the time of the request. Therefore, interface 120 should relay the request to interface 98 by forwarding necessary information such as digital files containing the previously recorded utterances necessary for the services. Upon receiving this information, interface 98 may make a telephony connection to the telephony connector 118 on the backend system on behalf of device 94. The audio output information from the services will be first received by the IVR interface 98 and then converted into text information. The text information may then be sent back to the XML interface 102 which may in turn send the textual information to device 94 for display.

The methods and systems described herein provide for an adaptable implementation. Although certain embodiments have been described using specific examples, it will be apparent to those skilled in the art that the invention is not limited to these few examples. Note also, that although certain illustrative embodiments have been shown and described in detail herein, along with certain variants thereof, many other varied embodiments may be constructed by those skilled in the art.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of the present invention. Accordingly, the present invention is not intended to be limited to the specific. form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as provided by the claims below.

Claims

1. A method comprising:

receiving a first communication in a format that complies with a first protocol, the first communication associated with a desired interaction between a first device and a voice activated service (VAS) platform;

receiving a second communication in a different format that complies with a different protocol;

recognizing that the VAS platform does not support the first protocol; and

translating the first communication, but not the second communication, to a platform-supported format to facilitate the desired interaction in response to the recognition that the VAS platform does not support the first protocol.

2. The method of claim 1, further comprising:

receiving a third communication, the third communication associated with an additional interaction between a third device and a second voice activated service (VAS) platform; and

facilitating the additional interaction.

3. The method of claim 2, further comprising maintaining a list of formats supported by the VAS platform and the second VAS platform.

4. The method of claim 3, further comprising maintaining an information store comprising mapping information that identifies a first service offering associated with the VAS platform and a second service offering associated with the second VAS platform.

5. The method of claim 1, wherein the platform-supported format comprises a packetized call format that complies with a Voice Extensible Markup Language (VoiceXML) format.

6. The method of claim 5, wherein the first communication comprises analog voice signals.

7. The method of claim 6, further comprising routing the first communication to the voice activated service (VAS) platform via a connector operable to facilitate information exchange between a VoiceXML device and an analog telephony device.

8. The method of claim 7, further comprising:

receiving a third communication, the third communication associated with a device interaction between a third device and a second voice activated service (VAS) platform; and

routing the third collection of communication information to the second voice activated service (VAS) platform via a second connector to facilitate information exchange between a VoIP device and an analog telephony device.

9. The method of claim 1, wherein before receiving the first communication, the method further comprises registering VAS platforms as capable of supporting at least one protocol and at least one interactive service, and wherein recognizing that the VAS platform does not support the first protocol comprises identifying a VAS platform to perform the desired interaction via the first protocol based on the registration of VAS platforms.

10. A method comprising:

receiving a first request for access to a first network-based interactive service, the first request having a format for a circuit-switched communication;

receiving a second request for access to a second network-based interactive service, the second request having a second format for communication via an Internet Protocol (IP) network;

identifying a platform capable of offering the first network-based interactive service;

routing the first request to the platform;

identifying a second platform capable of offering the second network-based interactive service; and

routing the second request to the second platform.

11. The method of claim 10, further comprising:

recognizing that the platform does not support the first format; and

initiating translation from the first format into a platform-supported format.

12. The method of claim 11 further comprising accessing a multi-protocol connector to interconnect an initiator of the first request and the platform.

13. The method of claim 12, wherein the multi-protocol connector is operable to facilitate communication between a plurality of different request formats and a plurality of different platform-supported formats.

14. A system for providing access to an interactive service, the system comprising:

a network interface operable to form at least a portion of a link communicatively coupling a remote communication device to an interactive service offering platform;

a memory maintaining information that indicates a supported protocol for the interactive service offering platform; and

an abstraction engine operable to translate a first communication, but not a second received communication, to facilitate communication between the remote communication device and the interactive service offering platform in response to a determination that a communication of the remote communication device does not comply with the supported protocol.

15. The system of claim 14, further comprising:

a second interactive service offering platform having a second supported protocol and operable to receive communications via the network interface protocol wherein the abstraction engine is further operable to facilitate communication between a second remote communication device and the second interactive service offering platform.

16. The system of claim 14, further comprising a retrieval engine operable to gather information from a repository in response to a recognition that additional information is desired in connection with the communication between the remote communication device and the interactive service offering platform.

17. The system of claim 14, further comprising a multi-protocol connector having a telephony connector engine, a voice over Internet Protocol connector engine, and an Extensible Markup Language connector engine.

18. The system of claim 17, wherein the abstraction engine employs at least one engine of the multi-protocol connector to facilitate communication between the remote communication device and the interactive service offering platform.

19. The system of claim 17, wherein the network interface comprises an Integrated Voice Response interface, a Voice over Internet Protocol interface, and a Voice over Extensible Markup Language interface.

20. The system of claim 19, further comprising an interconnection engine operable to recognize which interface of the network interface is receiving communication information from the remote communication device, the interconnection engine further operable to initiate employing at least one engine of the multi-protocol connector to facilitate communication between the remote communication device and the interactive service offering platform.