 |
Description  |
|
|
TECHNICAL FIELD
This invention relates generally to voice-mail systems, and relates
particularly to user interfaces to such systems.
BACKGROUND OF THE INVENTION
Voice-mail service systems are well known in the art. They principally
provide to a calling party the ability to send a voice message to a called
party without contacting another human being e.g., answering service
operator, in the process, and enable the called party to retrieve those
messages at will via his or her telephone, also without intervention of
another human being. These systems also typically formulate a header for
each message that identifies, e.g., when the message was received and the
telephone number and/or identity of the calling party. The called party
can retrieve and review the header information--for example, to determine
what new messages have been received--without retrieving and listening to
the messages themselves. An example of such a system, is the AT&T
Audix.RTM. voice-mail service system.
SUMMARY OF THE INVENTION
Conventional voice-mail service systems provide only an audio--i.e.,
telephone set--access to the voice messages and message headers stored
therein. We have realized that this is unfortunate, because it is
inconvenient and time-consuming for a called party to scroll through his
or her message headers in voice mode, i.e., by listening to the header
information.
The invention is directed to solving this and other disadvantages of the
prior art. According to the invention, a combined voice and data access to
the voice-mail service system is provided to users. The user-access
interface to the voice-mail service system includes a voice channel or
connection--the conventional voice connection, for example--plus a
concurrent data channel or connection, thereby providing the user both
visual and audio access to the voice mail system in a single communication
session. The data connection enables the user to interact with the
voice-mail service system visually via a display terminal or a
display-equipped computer (such as a personal computer), supplying data
control signals to the system to effect operation of the system, and
receiving responses to the control signals. In particular, the user can
receive and print message headers on the terminal or display, so that he
or she can then visually scan the headers. The visual scanning of message
headers is substantially faster for most users than voice-mode scanning.
And, by means of the data connection, the user is able to access message
headers (as well as the corresponding messages) in random order.
Additionally, the user can then play or record messages via the voice
connection under control of data control signals supplied to the system
over the data connection. In contrast to a data-only interface that would
require the user to retrieve or store messages in digital form, and hence
would require that each user's terminal or computer be equipped with a
digital-to-audio and an audio-to-digital converter, the combined
voice-and-data interface allows all users to share use of the converter
which is included in the voice-mail service system.
As a further advantage, the digital connection enables the provisioning of
a myriad of different user-access interfaces, each customized for a given
application, merely by modifying the functionality of that portion of the
interface which interacts with the user(e.g., a personal-computer-resident
interactive application program).
These and other advantages and features of the invention will become more
apparent from the following description of an illustrative embodiment of
the invention considered together with the drawing.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of a voice-mail service system including an
illustrative embodiment of the invention;
FIGS. 2 and 4-14 are a state diagram of the operation of function 30 of
FIG. 1;
FIGS. 3-14 are a state diagram of the operation of function 31 of FIG. 1;
The odd-numbered ones of FIGS. 15-110 are flow diagrams of the operation of
function 30 in the transitions and states of FIGS. 2 and 4-14;
The even-numbered ones of FIGS. 15-110 are flow diagrams of the operation
of function 31 in the transitions and states of FIGS. 3-14 and
FIGS. 111-113 show illustrative screen displays of a terminal 11 of FIG. 1.
DETAILED DESCRIPTION
FIG. 1 shows the configuration of a communication system that provides
voice-mail services to users. At their premises, users are equipped with
terminal equipment. The terminal equipment includes voice terminals 10,
such as standard or digital telephone sets, and data terminals 11, such as
personal computers (PCs) or the AT&T 510D video terminals. Alternatively,
a voice terminal may even take the form of a handset 10 and a touch pad 10
incorporated into a data terminal 11. (For ease of reference, voice
terminals in all forms will hereinafter be designated by the numeral 10,
and data terminals in all forms will hereinafter be designated by the
numeral 11.) Users, i.e., their equipment, are interconnected for
communication through a switching system 12. Switching system 12 is
illustratively a private branch exchange (PBX) such as the AT&T System 75
or System 85 PBX. Voice terminals 10 are connected to switching system 12
via voice channels 13, while data terminals 11 are connected to switching
system 12 via data channels 14. A voice channel 13 and a data channel 14
may be carried by either separate physical links 29 or a common link 29.
For example, where voice terminal 10 is a standard telephone set and data
terminal 11 is a stand-alone PC or terminal, voice channel 13 may be
carried by a conventional telephone loop while data channel 14 is carried
by a separate data link that supports the ISDN xB+D or the AT&T DCP
protocol. Alternatively, where voice terminal 10 is a digital telephone
set and data terminal is a PC or a terminal coupled to that set, or where
voice terminal 10 is incorporated into data terminal 11, both voice and
data channels 13 and 14 are commonly carried by a single link that
supports the ISDN protocol, in a conventional manner.
Data terminals 11 are coupled to links 29 either through digital telephones
or through interfaces 15. An illustrative interface to a DCP link 29 is
the AT&T PC/PBX interface. The PC/PBX interface and the DCP protocol are
described in U.S. Pat. No. 4,748,656.
Also connected to switching system 12 is a voice-mail service system 16,
illustratively the AT&T Audix voice-mail service system. The connection to
system 16 is made up of voice links 17 and a control link 18 such as an
AT&T DCIU protocol link--as is conventional and described in U.S. Pat.
Nos. 4,646,346 and 4,612,416--plus data links 19. Voice links 17 carry
voice channels 13. Data links 19 are illustratively links that support the
ISDN or DCP protocol. Data links carry data channels 14. Voice links 17
are coupled to voice ports 22 of system 16 directly, whereas data links 19
are coupled to data ports 21 of system 16 by an interface 20. Interface 20
merely translates between the protocol used on data links 19 and the
protocol or format that is understood or used internally by system 16.
Translators of this nature are well-known in the art. If system 16
understands the protocol of links 19 directly, no interface 20 is needed.
Operation of an illustrative voice-mail service system and its interface
to a PBX are described in U.S. Pat. No. 4,790,003.
According to the invention, to permit communication by data terminal 11
with system 16 over data channels 14, terminal 11 includes a voice message
system interface function 30. Function 30 is illustratively implemented in
software. Similarly, to permit communication by system 16 with terminal 11
over data channels 14, system 16 includes a data terminal interface
function 31. Function 31 is likewise illustratively implemented in
software. The operation of function 30 is shown by the state diagram of
FIGS. 2 and 4-14; the steps involved in those states and state transitions
are shown by the flow diagrams of odd-numbered ones of FIGS. 15-110.
Similarly, the operation of function 31 is shown by the state diagram of
FIGS. 3-14, while the steps involved in those steps are shown by the flow
diagrams of even-numbered ones of FIGS. 15-110. FIGS. 2-110 are referred
to jointly in the following description of the operation of functions 30
and 31.
Illustratively, the communication protocol used between system 16 and
terminal 11 has two layers above the physical layer. Layer 2 guarantees
delivery of messages between system 16 and terminal 11, and notifies them
if a failure occurs while trying to deliver a layer 3 message. Most
acknowledgments are at layer 2 of the protocol, and command and response
messages are at level 3. For purposes of simplifying the description,
however, no distinction is made hereinbelow between the two layers.
Initially, function 30 is stopped, i.e., not invoked or executing, in
"stop" state 2000 of FIG. 2. Upon being invoked, i.e., upon being started,
function 30 makes transition 2001 to "login" state 2002. The operation of
function 30 in state 2002 is shown in FIG. 15. Upon starting to execute,
on data terminal 11, at step 200, function 30 presents a menu of possible
login-related activities to a user of terminal 11, by displaying a login
menu on the screen of terminal 11, at step 201. Function 30 then a awaits
the user's selection of one of the options from the login menu, at step
202. Further activities of function 30 depend upon which login menu option
is selected, as indicated at step 202.
A user selects the LOGIN or AUTO-LOGIN option to establish a connection to
system 16. If the user selects the LOGIN option, the user must provide the
system with login information, such as the user's own phone number, the
user's password to system 16, the data-link telephone number of system 16,
and the voice-link telephone number of system 16. If the user selects the
AUTO-LOGIN option, the login information is assumed to be stored in memory
of terminal 11. Accordingly, if the LOGIN option was selected, function 30
receives the selection at step 295, and causes the user to be prompted for
the requisite login information via messages displayed on the screen of
terminal 11 and causes the login information to be collected from keyboard
of terminal 11, at step 203. Conversely, if the AUTO-LOGIN option was
selected, function 30 receives the selection at step 296 and causes the
requisite login information to be retrieved from memory, at step 204. From
this point on, the LOGIN and AUTO-LOGIN procedures are identical.
To originally store the requisite login information for AUTO-LOGIN
purposes, the user selects at step 202 the ADMINISTER-LOGIN option. This
selection causes function 30 to make a transition 2003 that does not
result in a state change, as shown in FIG. 2. In response to receiving the
user's selection, at step 297 of FIG. 15, function 30 causes the user to
be prompted for login information and causes that information to be
collected, in the same manner as at step 203, at step 298. Function 30
then stores this information in memory of terminal 11, at step 299, and
returns to step 201 to re-present the login menu to the user.
Returning to the discussion of the LOGIN and AUTO-LOGIN procedures, when
function 30 is in possession of the requisite login information, it
initiates a data call to system 16, using the data-link telephone number
of system 16 to dial a data port 21 of system 16 over data channel 14, at
step 205, in a conventional manner. It then waits for the call to be
answered by system 16, at step 206.
The data call that is initiated by terminal 11 over a data channel 14 is
received and processed by system 12 in a conventional manner. System 12
responds to the dialed number by connecting the data call and channel 14
to system 16 via a link 19.
Initially, function 31 is in "idle" state 3000 of FIG. 3 and not actively
executing. When function 31 of system 16 detects that a call is coming in
over a link 19, it makes a transition to 3001 to begin state 3002. The
operation of function 31 in state 3002 is shown in FIG. 16. Upon detecting
the incoming data call in a conventional manner, at step 300, function 31
answers the call, at step 301, again conventionally. A data communication
path is thus established between system 16 and terminal 11 over a channel
14 and a link 19 through system 12. Function 31 then waits for a response
from the caller, at step 302.
When it receives indication that system 16 has answered the call, at step
210 of FIG. 15, and that a communication path to system 16 has thus been
established, function 30 responds by sending a login command over the data
path to system 16, at step 211. The command includes the calling, i.e.,
the user's, telephone number. Function 30 then awaits a response from
system 16, at step 212.
Function 31 receives the login command at step 310 of FIG. 16. In response,
it saves the calling telephone number that was included in the command, at
step 311. Function 31 then selects and associates with this data call a
unique I.D., at step 312. Any I.D. and any method of selection may be
used, as long as the selected I.D. is unique to this call. Function 31
then sends the selected I.D. to terminal 11 over the data call, at step
313, and proceeds to await establishment of a voice call from voice
terminal 10, at step 314.
Function 30 receives the I.D. associated with the data call, at step 215 of
FIG. 15, and stores it, at step 216. Function 30 then signals the user to
dial a voice port 22 of system 16 from voice terminal 10, at step 217,
illustratively by displaying a message to that effect on the screen of
terminal 11. Alternatively at step 217, if data terminal 11 has access to
voice link 13 of voice terminal 10, function 30 of terminal 11 may perform
the dialing of voice port 22 for the user automatically. Function 30 then
awaits receipt via the data call of an acknowledgment from system 16 that
the requisite voice call has been established, at step 218.
The user establishes a voice call to system 16 from terminal 10 in a
conventional manner. As part of, or following, the call establishment, the
calling telephone number is conveyed to system 16, and is transferred to
function 31. This conveyance is accomplished in a conventional manner,
either by means of an automatic number identification (ANI) feature of
switch 12, or by means of a user response to a prompt from system 16.
When function 31 receives the calling telephone number of a voice call, at
step 320 of FIG. 16, it compares this number against the stored calling
telephone numbers of all presently-existing data calls (which it stored
during execution of step 311 for each of those calls), at step 321. If no
match is detected, at step 322, function 31 treats the voice call as a
conventional attempt to access system 16. Function 31 therefore invokes
the conventional voice call processing function of system 16, at step 323,
and then returns to step 314.
If function 31 detects at step 322 a match between the calling numbers of a
voice and a data call, it recognizes that those two calls originated with
the same user. Function 31 therefore sends an acknowledgment of the
establishment of the voice call to terminal 11 via the data call, at step
324, and waits for the user to log in over the voice call, at step 325.
Upon receiving the acknowledgment of the establishment of a voice call, at
step 220 of FIG. 15, function 30 signals the user to log in over the voice
call, and provides the user with the I.D. associated with the data call,
at step 221, illustratively by displaying the information on the screen of
terminal 11. Alternatively at step 221, if data terminal 11 has access to
voice link 13 of voice terminal 10, function 30 of terminal 11 may perform
the logging into system 16 for the user automatically. Function 30 then
awaits an acknowledgment from system 16 that the user has been logged in
properly, at step 222.
The user logs in to system 16 over the voice call in the conventional
manner, with the exception that he or she provides the I.D. identifying
the data call as part of the login procedure. System 16 responds to the
conventional portion of the login information conventionally. The data
call I.D. that was provided to system 16 as part of the login is given to
function 31.
In response to being given the data call I.D. from the voice call, at step
330 of FIG. 16, function 31 compares this I.D. with the I.D.s of
presently-existing data calls, at step 331. If no match is detected, at
step 332, function 31 treats the voice call as being erroneous, and it
causes the voice call to be terminated, at step 333. Function then returns
to step 325.
If function 31 detects a match between the I.D. provided by the voice call
and a data call's I.D., at step 334, it recognizes the two calls as being
related, i.e., as being part of the same communication session between the
user and system 16. Function 31 therefore creates an association between
the two calls, at step 334, illustratively by storing in memory of system
16 information that relates the two calls together. Function 31 then sends
an acknowledgment over the data call to terminal 11, at step 335, to
advise it that the voice call login succeeded in establishing a voice and
data call association.
The success of the login leads both functions 30 and 31 to make a
transition to a new state. Function 31 therefore sends a command to
terminal 11 to advise function 30 to prepare for a new state, at step 350.
Function 31 then waits for an acknowledgment from terminal 11, at step
351. When it receives the acknowledgment at step 352, function 31 makes a
transition 3003 to activity menu state 2006.
The activities of function 31 in state 2006 are shown in FIG. 18. Function
31 sends a message to terminal 11 advising function 30 that the new state
is the activity menu state, at step 353. Function 31 again waits for an
acknowledgment, at step 353, and upon receipt thereof, at step 355,
function 31 waits, at step 336, to be informed by terminal 11 of what
activity the user has selected to engage in.
Returning to step 222 of FIG. 15, function 30 awaits acknowledgment of
success of the voice call login for only a predetermined period of time.
Function 30 is thus prevented from awaiting indefinitely the arrival of an
acknowledgment of a voice call that was terminated at step 333 and for
which no acknowledgment has been or will be given. If the allotted time
period times out before the acknowledgment is received, function 30 makes
a transition 2003 back to stop state 2000. Function 30 notifies the user
of the timeout at step 226, illustratively by displaying a message on the
screen of terminal 11. Function 30 then conventionally terminates the data
call to system 16, at step 227, and quits, at step 228.
If, however, function 30 receives the login acknowledgement, at step 229,
before the allotted time period times out at step 225, it proceeds to wait
for receipt of a command from system 16, at step 250.
Function 30 receives the "prepare for a new state" command from system 16,
at step 251. It acknowledges the command, at step 253, and then waits for
receipt of the new state, at step 253. When it receives the message from
system 16, at step 254, that the new state is the activity menu state,
function 30 acknowledges it, at step 255, and makes a transition 2004 or
2005--depending on whether the successful login was a LOGIN or an
AUTO-LOGIN, respectively--to "activity menu" state 2006 (see FIG. 2).
The activities of function 30 in state 2006 are shown in FIG. 17. First,
function 30 requests of system 16 the counts of the various kinds of
messages that system 16 may be storing. Function 30 sends the request to
system 16 over the data call, at step 230. Function 30 then awaits receipt
from system 16 of an acknowledgment of the request, at step 231.
Function 31 receives the message count request, at step 337 of FIG. 18, and
sends an acknowledgment thereof to terminal 11 over the data call, at step
330. Function 31 then retrieves the counts of the various types of
incoming and outgoing messages that are associated in system 16 with the
user of terminal 11, at step 339, and reports these counts to terminal 11,
at step 340. Function 31 then awaits receipt from terminal 11 of an
acknowledgment of the counts, at step 341.
Function 30 receives the acknowledgment of its request, at step 235 of FIG.
17, and then waits for receipt of the requested counts, at step 236. When
it receives the counts, at step 237, function 30 sends an acknowledgment
to system 16 over the data call, at step 238. Function 30 then presents
the count to the user, along with a menu of activities that the user may
opt to undertake, at step 239. Function 30 then awaits selection by the
user of one of the menu items, at step 240.
Function 31 responds to receipt of the acknowledgment from terminal 11, at
step 345 of FIG. 18, by returning to step 336 to await receipt of a new
command from terminal 11.
The options presented to the user by the activity menu at step 239 are to
scan the headers of one of the types of incoming messages--new, old, and
unopened--to scan the headers of one of the types of outgoing
messages--undelivered, delivered, accessed, undeliverable, and file
cabinet--to record a new outgoing message, and to administer the user's
greeting. These are the conventional choices presented by system 16 to
users. An illustrative activity menu screen displayed by terminal 11 is
shown in FIG. 111.
Any one of the selections causes a transition of functions 30 and 31 from
activity menu state 2006 to a new state representative of the selection,
as shown in FIGS. 2 and 3. For example (considering first the incoming
message options), as shown in FIG. 4, selection of the "scan new message
headers" option causes functions 30 and 31 to make transition 2007 to
"scan new" state 2030; selection of the "scan old message heade | | |
