U.S. patent application number 11/890996 was filed with the patent office on 2008-01-31 for system and method for providing access to an interactive service offering.
This patent application is currently assigned to SBC Knowledge Ventures, L.P.. Invention is credited to Hisao M. Chang, Brian M. Novack.
Application Number | 20080027730 11/890996 |
Document ID | / |
Family ID | 34711480 |
Filed Date | 2008-01-31 |
United States Patent
Application |
20080027730 |
Kind Code |
A1 |
Novack; Brian M. ; et
al. |
January 31, 2008 |
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.
Inventors: |
Novack; Brian M.; (St.
Louis, MO) ; Chang; Hisao M.; (Austin, TX) |
Correspondence
Address: |
TOLER LAW GROUP
8500 BLUFFSTONE COVE
SUITE A201
AUSTIN
TX
78759
US
|
Assignee: |
SBC Knowledge Ventures,
L.P.
Reno
NV
89502
|
Family ID: |
34711480 |
Appl. No.: |
11/890996 |
Filed: |
August 7, 2007 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10751685 |
Jan 5, 2004 |
|
|
|
11890996 |
Aug 7, 2007 |
|
|
|
Current U.S.
Class: |
704/275 |
Current CPC
Class: |
H04M 11/062 20130101;
H04M 3/304 20130101; H04M 3/306 20130101; H04L 12/66 20130101 |
Class at
Publication: |
704/275 |
International
Class: |
G10L 21/00 20060101
G10L021/00 |
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.
Description
CLAIM OF PRIORITY
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.
[0005] 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
[0006] 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:
[0007] 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;
[0008] 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
[0009] 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
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
* * * * *