 |
Description  |
|
|
FIELD OF THE INVENTION
The present invention pertains to the field of voice processing. More particularly, the present invention relates to a mechanism for integrating voice messaging with an electronic text messaging system.
BACKGROUND OF THE INVENTION
Since the advent of telephone communications, callers have frequently failed to make contact with the person they are calling either because that person is on another line, away from the phone, or otherwise preoccupied. Time and effort are
wasted by playing telephone tag. This problem is especially acute in the business environment as customers are faced with unanswered calls, extended waits on hold, unconveyed important information, etc. Communication within an organization between
employees is also a problem because of availability at the same time of the people who need to communicate. Time zone differences, especially in regards to international calls, particularly aggravate this issue.
Traditionally, a caller who cannot get hold of the person they are trying to contact could leave a message with a receptionist or secretary. However, written messages are notoriously prone to inaccuracies and are practically limited in length.
Furthermore, this approach only works during business hours when the receptionist or secretary is available to pick up the incoming call.
In response to the shortcomings of handwritten messaging, electronic voice and text messaging systems have been developed. A number of voice and text messaging systems are known in the art and are commercially available. A voice messaging
system is used to automate the answering of incoming calls from the outside telephone network and the taking of messages when the extensions are not answered by the called parties. Voice message systems are also used for people using any standard DTMF
(Dual Tone Multi-Frequency) phone to call the voice message system and create messages that are then addressed and sent to one or more select other users of the system. Such voice messaging systems incorporate features, such as the recording of voice
messages for users in what are known as "mailboxes". Commonly, voice messaging systems may also be accessed by users calling from PBX extensions or from the telephone network over incoming trunks to access their mailbox to listen to voice messages.
In most known voice messaging systems, answering of incoming trunk calls by the voice messaging system is accomplished by instructing the PBX to direct the incoming calls to a group of extensions. Voice ports of the voice messaging system are
coupled with this group of extensions and appear to the PBX simply as single line telephone sets in a hunt group. Typically, the voice messaging system will answer a call directed to it and provide a pre-recorded voice message allowing the caller to
"log-on" (i.e., enter a user identification number and security code) to access their mailbox in order to listen to or send voice messages. Internal users on the PBX can directly call the group of extensions in the hunt group to access the voice
messaging system.
In addition to handling calls received by the PBX from incoming telephone trunks and direct internal calls, an important function of known voice messaging systems is the handling of calls which do not successfully reach the originally intended
extension either because the extension was busy, did not answer, or had intentionally been placed in a mode in which it was not accepting calls. Such a function may be accomplished in known voice messaging systems by instructing the PBX to forward all
such unanswered calls to a group of extensions coupled with the voice ports of the voice messaging system. As is know in the prior art, for example U.S. Pat. No. 4,926,462, voice message systems are also connected to the PBX in such a way as to
receive information about the originally called extension number so that the voice message system can answer the call with the greeting of the called party and take a voice message that goes into the voice mailbox for that called person.
Another mechanism which has been used for the transmission and receipt of text messages involves computers. With the advent of personal computers and workstations, computing power was distributed to users at the desktop level. As is well know
in the prior art, these personal computers (PCs) and workstations can be connected using Local Area Network (LAN) and Wide Area Network (WAN) hardware and software technology.
The interconnection of PCs and workstations into networks is becoming increasingly popular and one of the most common applications is that of electronic mail (E-mail). E-mail allows users to compose, send, and receive messages on their PCs or
workstations over a LAN or WAN. Originally, E-mail systems only handled text-based messages. Increasingly, they are being enhanced to also support the transmission of other formats of information, such as graphics, spread sheets, facsimile, and voice.
Most of the E-mail systems available for PC network environments require a file server computer on the LAN. The most popular file server LAN software system is sold by Novell.TM. (Netware.TM.) or Microsoft.TM. (LAN Manager.TM.). These
software systems allow programs on individual PCs to access files on a computer running the file server software. These files can either be shared access or assigned to a particular individual. They also support what are called "peer-to-peer"
communications protocols, which allow PCs to send and receive data to and from other PCs on the LAN.
The E-mail software running on a particular user's PC uses a file server on a LAN as the "post office" for the mail messages. As an example, there is a shared file on the server that is the "user directory". It has information such as each
users' E-mail addresses and passwords. The file server is also where the messages are stored when they are waiting to be accessed by a user. The server also contains information for each user regarding how many messages they have, the date and time of
creation of each message, who it is from, who else was copied, etc. This information is sometimes called a message header or "envelope" information. Also supported in these E-mail systems is the ability to send E-mail messages to other E-mail systems
located on a different LAN (usually via a dedicated WAN connection or via dial-up modems). In these cases there is software running on one of the PCs on the LAN that handles the moving of messages and of all the message header information from one file
server via the WAN to another file server. There is also software that keeps the directories of these different LAN based E-mail systems automatically updated.
As indicated previously, the E-mail systems also support the ability to attach other files that are stored on the server as part of the E-mail message. In some E-mail systems, the names of these attached files might also be part of the message
header information. These E-mail systems typically have available Application Program Interfaces (APIs) which allow software programs to be written to use the E-mail directory, message handling, user access and security mechanisms of that particular
E-mail system for facilitating the development of other applications. The two most common LAN based E-mail systems are Microsoft Mail.TM. and Lotus cc:Mail.TM.. Microsoft.TM. supports a set of APIs called Messaging Application Program Interface
(MAPI) and Lotus.TM. supports, as do other software companies, APIs called Vendor Independent Messaging (VIM).
In prior art voice messaging systems, the methods for keeping track of user directories, message header information, and the messages themselves is unique to each manufacturer. Virtually all these methods are different from the methods the
E-mail software systems use to perform the same functions for E-mail. This means that a business organization that has both E-mail and voice messaging must maintain two user directories, two mailboxes per user, and two wide area networking and directory
update systems. This is both inconvenient for the users and more expensive to manage for the business.
Therefore, there exists a need in the prior art for an integrated voice and electronic messaging system. Such an integrated system would allow companies to maintain only one directory for all voice and E-mail users, maintain only one method of
wide area networking both kinds of messages, and give the users only one mailbox to check and use for all types of messages (e.g., voice, fax, text, graphic, etc.).
SUMMARY OF THE INVENTION
In the present invention, the APIs of a commercially available E-mail system and the ability to attach voice files as part of an E-mail message are used to implement a voice messaging system. The voice file is created by using a board in a PC
which connects to a phone system to accept incoming phone calls and to convert the analog voice signal into a digital format. For the purposes of this disclosure this will be called the voice gateway PC. Conversely, the digital format is converted back
to the analog voice signal for playback of a stored voice file. A voice message is recorded by storing the digital voice data on the file server using a uniquely created file name. To send a voice message, the voice file stored on the server is
attached to an E-mail message and "sent" using the appropriate API. For receiving a voice message, the voice file attached to an E-mail message is retrieved and transferred to the gateway PC. Thereupon, the board which is connected to a phone system
converts the voice file from a digital format to an analog voice signal for playback over the phone line.
There are three methods of creating and sending voice messages. In the first method, a user at his PC can elect to send an E-mail message by using the standard E-mail message software. But instead of just typing in the text of a message, he can
access another application running on his PC to send a peer-to-peer message to the voice gateway PC on the LAN. The voice gateway PC is connected to the phone system so that it can call the phone associated with the user's PC in order to record a voice
message. When he answers the phone, the gateway PC records his voice message using the voice board and writes the digitized voice data onto the file server with a unique file name and attaches that file name to the E-mall message that is waiting to be
sent.
In the second method, an unanswered call to a particular user's phone will be forwarded to a phone port of the voice gateway PC. The PBX informs the PC of that particular extension which did not answer. The voice gateway PC converts the
extension number to an E-mail address, plays a personal greeting file pre-recorded by the user, and records the caller's voice message onto the server. It will then select the appropriate E-mail APIs necessary for sending an E-mail with the attached
voice file to the user's E-mail address.
In the third method, a user directly calls the voice gateway PC. By using signals from his DTMF phone, which are translated by the phone interface board on the PC to digital signals, the user enters his extension number and E-mail password in
order to "log-on" to his mailbox. Note that the E-mail password must have been set to all numeric digits if it is to be the same as used directly by the voice message phone user. However, it would be possible for the voice message user to enter an
alphabetic password using multiple numeric digits to represent the selected alphabetic character. The user can then send commands from his DTMF phone to create the voice message which will be stored on the server and also to address voice messages using
the recipient's voice mailbox number. The voice gateway PC software uses the APIs to send the voice files to the appropriate E-mail user.
There are two methods for retrieving voice messages. In the first method, when a user views his E-mail "inbox" on his PC, some of the messages may contain voice files as a result of any of the three sending methods above. If the user opens such
a message and "selects" the voice file attached, the software running on his PC recognizes that the file name is of a particular type. Thereupon, it activates a software application on the PC which sends a command (using peer-to-peer communication) to
the voice gateway PC to ring the user's phone and to play the voice file selected.
In the second method, the user calls into the system from a DTMF phone directly to the voice gateway PC. As described above, the user logs-on to his mailbox via the phone. The voice gateway PC software selects the appropriate APIs to search the
user's E-mail message for attached voice files. The APIs also can be used to obtain information from the user's E-mail mailbox regarding the number of messages which have voice attachments. The voice gateway PC can speak this count to the telephone
user, and allows the user to play a voice file through the use of DTMF buttons on the telephone. Other standard voice messaging features such as save, erase, forward, reply, etc., are also supported.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 shows a client-server system architecture upon which the present invention may be practiced.
FIG. 2 shows a flowchart describing the steps for a caller logging into his or her mailbox using an E-mail system.
FIG. 3 shows a flowchart describing the steps for providing a caller with a message summary for review of his or her messages.
FIG. 4 is a flowchart showing the steps for scanning the mailbox of the caller for a voicemail system which is integrated with MAPI E-mail systems.
FIG. 5 is a flowchart describing the steps for message playback of new messages of a voicemail system integrated with MAPI E-mail systems.
FIG. 6 is a flowchart describing the steps for message playback of saved/old messages of a voicemail system integrated with MAPI E-mail systems.
FIG. 7 is a flowchart describing the steps for sending a message from one user to another over the telephone with MAPI E-mail systems.
FIG. 8 is a flowchart describing the steps for a call answering operation with MAPI E-mail systems.
FIG. 9 is a flowchart showing the steps for saving and deleting messages and marking messages as read with MAPI E-mail systems.
FIG. 10 is a flowchart showing the steps for replying to a message during message playback with MAPI E-mail systems.
FIG. 11 is a flowchart showing the steps for scanning the mailbox of the caller using the VIM (Vender Independent Messaging) APIs supported by Lotus cc:Mail.
FIG. 12 is a flowchart showing the steps for message playback of new messages with a VIM type E-mail system.
FIG. 13 is a flowchart showing the steps for sending a message from one user to another over the telephone with a VIM type E-mail system.
FIG. 14 is a flowchart showing the steps for a call answering operation with a VIM type E-mail system.
FIG. 15 is a flowchart showing the steps for marking as read and deleting messages for a VIM type E-mail system.
FIG. 16 is a flowchart showing the steps for replying to a message during message playback with a VIM type E-mail system.
FIG. 17 shows a computer display as may be implemented for an integrated voice and electronic mail system.
DETAILED DESCRIPTION
An integrated voice and electronic mail system is described. In the following description, numerous specific details are set forth such as specific APIs, prompts, menus, software code, subroutine calls, etc., in order to provide a thorough
understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram
form in order to avoid unnecessarily obscuring the present invention.
The present invention applies to a computer network-based voice processing system. A network of personal computers, workstations, servers, hubs, concentrators, routers, bridges, etc., is coupled to and interfaces with a standard telephone system
in order to create, send, and receive voice messages as well as electronic mail messages according to a single integrated message handling mechanism. The present invention also allows for access of messages from a remote phone. The present invention
also allows for the taking of a voice message as the result of an unanswered phone call and the putting of that voice message into a designated user's E-mail mailbox.
Referring to FIG. 1, a client-server system architecture upon which the present invention may be practiced is shown. A number of phones 101A-C are connected to a local PBX 102. PBX 102 has several trunks 110-112, which provide transmission of
analog voice signals to and from the local telephone network. Also coupled to PBX 102 is voice gateway 103. Voice gateway 103 is additionally coupled to a LAN 105 which in turn also connects a file server 106 and PC workstations 107-109. The file
server provides disk (or disks) 106B for storage use by the computers on the LAN. Voice gateway 103 is a computer with voice processing and network interface cards such as those available from Dialogic.TM. or Rhetorex.TM. Corporation. The voice
gateway 103 is connected via lines 104a to PBX 102. There may also be an additional connection between voice gateway 103 and PBX 102 that is the PBX Integration Link 104B for providing information when an unanswered call is forwarded to one of the lines
104A on the original called extension number.
An E-mail software package, such as Microsoft Mail.TM. or Lotus cc:Mail.TM., is installed on the PCs 107-109 and on the voice gateway PC 103. Thereby, E-mail capabilities are provided for each of the PCs on LAN 105. The file server 106 is used
as the "post office" for the E-mail system. In an alternative embodiment, the present invention is applicable to wide area networks (WANs) using the E-mail software packages available to provide messaging capabilities across different LANs. That is,
for workstations and PCs connected on a LAN with a file server, the two LANs are interconnected using commercially available routers, bridges, or gateways.
Software in the voice gateway 103 uses the voice processing cards connected to PBX 102 to convert analog voice signals to digital signals and sends the digital signals to file server 106 to be stored on its disk drive 106b. For playing voice
messages the voice files stored on the file server disk 106B are retrieved and sent to the voice gateway 103 to be converted by the voice processing cards from digital data to analog data. Furthermore, voice cards implemented in a PC, can also send DTMF
digits to dial a phone number, decode DTMF digits as commands, detect calls ringing in, answer calls (i.e., go off-hook), flash to indicate to the phone system a request for a PBX function (e.g., transfer), hang-up, etc.
The voice gateway 103 can be called directly by one of the phones 101A-C or can call one of the phones 101A-C to play or record voice messages. The voice gateway 103 can also be accessed directly by a call coming in on a trunk 110-112 being
connected via lines 104a to the voice processing cards in voice gateway 103. As indicated previously, calls to phones 101 that are not answered can be forwarded by the PBX 102 to one of lines 104A and information about the extension number of the phone
101A-C is transferred via link 104B to the voice gateway.
The integration of voice messaging with an E-mail system is accomplished in part through the use of Application Program Interfaces (APIs). An API defines the sets of standard function calls to interface to the messaging system that can be
invoked from an application program. Basically, an API is comprised of a group of subroutines that allows programmers to write code for using the E-mail directory, E-mail message handling mechanisms, E-mail security systems, etc., that already exist for
most E-mail systems. By taking advantage of the APIs, access is gained to an E-mail system's directory and message handling mechanisms so as to integrate voice messages with the E-mail system. In other words, a developer can write code for modifying
the interface for an E-mail system so as to include voice messages. In this way voice files may be managed equally as well as text files, or other attachment files.
Among the APIs are the "Messaging Application Program Interface" (MAPI) promoted by Microsoft used for interfacing to Microsoft Mail.TM. and other MAPI compliant e-mail products; and "Vendor Independent Messaging" (VIM) promoted by Lotus and
others for interfacing to Lotus cc:Mail.TM. and other VIM compliant e-mail products. Table 1 below lists the MAPI and VIM APIs used for implementing the voice messaging functions previously described. There are now and may be in the future other
E-mail API's that one of ordinary skill could use to produce the invention. These are given only as methods for two embodiments of the present invention. In the following description, digitized voice files are identified by the four character extension
.vox.
TABLE 1 __________________________________________________________________________ What's happening MAPI call VIM API call __________________________________________________________________________ PC/Workstation Software Operations Record a
message and MAPISendDocumen SMISendMail then press the mail button ts Listen to voice No special API No special API messages found in function required - function required - the user's mail autoloads special autoloads special folder/In Tray
Inbox application on the application on the K based on K based on association to .VOX association to .VOX extension extension General Housekeeping Administration Assign voicemail A template that Use the cc:Mail Admin box numbers has two
additional (DOS) program to create and passwords; fields aliases for existing also default `Voice mailbox users. These aliases telephone Number` and contain the mailbox extensions `Default Telephone number as the name, required for Extension` is the telephone extension `Connect to defined. In the comments field Sender`. The standard Mail and user name in the address book form address field. has two `Phone Number` fields. The `Phone number #2 is used as the Voice mailbox number, and
Phone number #1 is the extension number. Voice Gateway A text file VIMGetDefaultSessionl User Table containing the nfo Creation. The MAPI address book VIMOpenSession User Table is is created using the VIMOpenAddressBook created MS-Mail
VIMEnumerateAddress periodically and template.exe BookEntries is updated every utility, which is VIMCloseAddressBook time the Voice read into memory. VIMCloseSession Gateway is This contains the restarted. required information about the
users. General Session InitMAPI VIMInitialize Management MAPILogon VIMOpenSession MAPILogoff VIMCloseSession DelnitMAPI VIMTerminate PBX Integrated Call Answering Call forwards to Look up the Look up the extension Voice Gateway extension number
in the user table with called number in the created at start-up to get extension user table E-mail Mailbox number. number created at start- information up to get E-mail Mailbox number. External caller MAPILogon VIMGetDefaultSessionInfo records
message MAPISendMail VIMOpenSession for the called MAPILogoff VIMCreateMessage extension user. VIMSetMessageHeader Need to send VIMSetMessageRecipient voice file to the VIMSendMessage users E-mail VIMCloseSession address. User Calls In to Listen
to Messages User calls Voice Check name Check name from user Gateway to from user table. table. Check password check voice Check password using VIMOpenSession messages. User using enters Voice MAPILogon mailbox number and password. Count and
MAPIFindNext VIMOpenMessageContainer access voice MAPIReadMail VIMEnumerateMessages flles. (look for vox VIMOpenMessage files) VIMEnumerateMessagelte MAPIFreeBuffer ms (look for vox files) MAPILogoff VIMGetMessageItem VIMCloseMessage
VIMCloseMessageContainer VIMCloseSession Tell User how All.vox files All.vox files found above many voice found above have been extracted from messages. have been their messages and their extracted from filenames are sent to the their messages
Voice gateway PC for and their playing back. filenames are sent to the Voice gateway PC for playing back Listen to MAPIReadMail VIMOpenMessageContainer messages (without the VIMMarkMessageAsRead MAPI.sub.-- PEEK VIMCloseMessageContainer flag)
MAPIFreeBuffer Message Playback Options Options during Message Playback Connect to message The Voice Server The Voice Server has sender has received the received the telephone telephone extension extension of the of the sender with sender
with the the other information other information of the vox f e of the .vox file Reply to sender Combinations of Combinations of above above Forward to another Combinations of Combinations of user above above Save MAPI SaveMail is
VIMMarkMessageAs used to Save a mail Read message Record a new No special API No special API prompt functions required functions required Delete MAPIReadMail VIMOpenMessageCon MAPIDeleteMail tainer MAPIFreeBuffer VIMRemoveMessage
VIMCloseMessageCon tainer Cycle forwards and No Special No special functions backwards through functions required required messages __________________________________________________________________________
FIGS. 2-16 are flowcharts illustrating the steps for implementing the present invention. The following conventions are used in these flowcharts: a rectangular box indicates information entered by an outside caller; a diamond indicates a
conditional branching; an oval indicates internal voice message system operation or a function call; and a rectangle having rounded corners indicates a message being played to the caller. Phrases in quotation marks are typical of the system message
played to the caller at this point. In particular, the flowcharts of FIGS. 4-10 are directed towards the steps of implementing the present invention on MAPI E-mail systems, while the flowcharts depicted in FIGS. 11-15 are directed towards VIM E-mail
systems.
As indicated in Table 1, under "General Housekeeping," there are some functions performed for setting up the E-mail system user directory to handle voice messages and also by the voice gateway PC to create special tables to facilitate certain
feature implementations. In order to use the E-mail directory, the user voice mailbox and extension number need to be assigned and associated with their E-mail identification. In many cases, the extension number and voice mailbox may be the same, and
thus, only one entry is needed. In either case, the voice gateway PC scans the E-mail directory and builds a table (herein called the "User Table") which can be searched using the voice mailbox or extension number to determine an E-mail identification
called E-mail name. This User Table is referred to in the flow charts.
Referring now to FIG. 2, a flowchart describing the steps for a caller logging into his or her mailbox is shown. Initially, the computer prompts the caller to enter his or her mailbox number, step 201. Prompts are pre-named voice files that are
stored either on the file server or voice gateway and are read off disk storage and sent to the voice processing cards to be converted from digital data to analog data to be played. Thereupon, the caller enters his or her assigned voice mailbox number,
step 202. For this and other functions, the user "enters" numbers using a standard DTMF phone key pad. The tones received by the voice processing cards in the gateway PC are converted to their corresponding digit * or # representations and made
available to the voice gateway PC for processing. The voice gateway PC searches for the User's name from the User Table stored in memory, step 203. If there is no match, a voice message such as "Sorry, that is not a valid mailbox number," will be
played to the caller, step 208.
Otherwise, if the mailbox number is valid, the computer system prompts the user to enter his or her password, step 204. In response, the caller enters the password, step 205. The user name and password is sent to a subroutine (e.g., MAPILogon
or VIMOpenSession) to determine whether that password correctly matches with the user name, step 206. If the password is invalid, the computer sends a voice message such as "Sorry, that is not the correct password," to the caller, step 209. The
computer reprompts the caller to enter his password, step 204. If a valid password has been entered, the mailbox of the caller is scanned, step 207. The scanning step is described in detail below in reference to FIG. 4 for MAPI applications and to FIG.
11 for VIM applications.
FIG. 3 shows a flowchart describing the next steps for providing a caller with a message summary for review of his or her messages. The message count is used to determine the prompt about mailbox message information, step 302. Depending on the
message count, there can be three outcomes. If there are no messages, the caller is so informed, step 303. The computer system then prompts the user to press "*" to record a new message, step 306. A new message is recorded if the user proceeds to
press "*" and leaves a message, step 307. The steps for sending a message is described in detail below in reference to FIG. 6 for MAPI applications and to FIG. 10 for VIM applications. If there are new messages, the computer system will inform the user
of the number of new messages as well as the number of old messages, step 304. The messages are then played back, step 308. The steps for message playback of new messages is described in detail below in reference to FIG. 5 for MAPI applications and to
FIG. 12 for VIM applications. Once message playback is completed, the computer system indicates that there are no more new messages, step 309. At that point, the user can press "#" to listen to his or her old messages, step 311. If the user does press
the "#" symbol, the old messages are played back, step 312. The steps for message playback of old messages is described in detail below in reference to FIG. 6 for MAPI applications and FIG. 12 for VIM with step 1204 modified to reverse the path for
"yes" and "no".
If there are no old messages, the computer system so informs the caller, step 310. If there are no new messages, the computer system informs the caller of this status as well as the number of old messages, step 305. If there are no old messages
either, then the computer system indicates that the caller has no more messages, step 310. Otherwise, the user can press the "#" symbol to listen to his or her old messages, step 311. Pressing the "#" symbol causes the old messages to be played back,
step 312.
FIG. 4 is a flowchart showing the steps for scanning the mailbox of the caller for a voicemail system which is integrated with a MAPI E-mail system. In step 401, the MAPIFindNext subroutine is used to get the next mail message. Next, the
MAPIReadMail subroutine is used to get information about the message, step 402. A determination is made as to whether there are any voicemail attachments, step 403. If so, a count is incremented of the new and old messages, step 404. The algorithm
proceeds to step 405. If there are no voicemail attachments, a determination is made as to whether there are any more messages, step 405. If there are more messages, step 401 is repeated. Otherwise, the MAPILogoff subroutine is executed to end the
session, step 406.
FIG. 5 is a flowchart describing the steps for message playback of new messages of a voicemail system integrated with MAPI E-mail systems. In 501, the user name and password is provided to the MAPILogon subroutine. The MAPIFindNext subroutine
is used to get the next mail message, step 502. Next, the MAPIReadMail subroutine is used to get the information about that message, step 503. A determination is made as to whether this is a new message, step 504. If so, a determination is then made
as to whether there are any voicemail attachments, step 505. If it is determined that there are voicemail attachments, the .vox files are extracted from the message, step 506.
The extracted .vox file is played by using the message playback options, step 507. If it is determined in steps 504 and 505 that either this is not a new message or that there are no voicemail attachments, step 508 is performed immediately. If
it is determined in step 508 that there are no more messages, the MAPILogoff subroutine is used to end the session, step 509. Otherwise, step 502 is repeated to get the next mail message. Note that this flowchart shows message playback for new
messages.
FIG. 6 is a flowchart showing the steps for playback of saved or old messages. In step 601, the user name and password is provided to the MAPILogon subroutine. The MAPIFindNext subroutine is used to get the next mail message, step 602. Next,
the MAPIReadMail subroutine is used to get the information about that message, step 603. A determination is made as to whether this is a saved or old message, step 604. If so, a determination is then made as to whether there are any voicemail
attachments, step 605. If it is determined that there are voicemail attachments, the .vox files are extracted from the message, step 606.
The extracted .vox file is played by using the message playback options, step 607. If it is determined in steps 604 and 605 that either this is not a saved message or that there are no voicemail attachments, step 608 is performed immediately.
If it is determined in step 608 that there are no more messages, the MAPILogoff subroutine is used to end the session, step 609. Otherwise, step 512 is repeated to get the next mail message.
FIG. 7 is a flowchart describing the steps for voice message users to send a message to another user over the phone. In step 701, the user is prompted to enter the voice mailbox number of the recipient. The user then enters the voice mailbox
number of the recipient, step 702. The computer system locates the recipient E-mail name from the stored user table, step 703. If it is determined that the mailbox number is invalid, a voice message such as "Sorry, this is not a valid mailbox number.
Press * to try again or 0 to return to the start," is sent to the caller, step 711. If it is determined that the mailbox number is valid the system plays a prerecorded message such as "Record your message after the tone," step 704.
A new file is created on the file server with a file name that is uniquely created and has ".vox" as its last 4 characters and the system transfers the digitized voice signal to this file, step 705. The user indicates he is finished recording by
entering a #, step 706. In step 708, the call to MAPILogon is used with the sending user's E-mail name and password (so he will appear as the originator of the message). In step 709, the MAPISendMail subroutine is used to send the created voice file
with .vox in its file name attached to an E-mail message to the recipient using the E-mail name previously determined from the mailbox number. A MAPILogoff subroutine is used to end the session, step 710.
The flowchart of FIG. 8 shows the steps for a call answering voice message operation using MAPI. The called party's extension is forwarded to the voice message system ports, and the PBX provides integration information along with the call,
including giving the called party's extension number. In step 801, the extension number received from the PBX is used to find the called party's E-mail name from the User Table. In step 802, the system plays a personal greeting previously recorded by
the user of the called extension (or a default message if none is recorded--such as "Extension xxxx did not answer"). Step 803 shows the creation of a new file name with a .vox extension (to indicate it is a voice file) and the writing of digitized
voice data into the file. Recording is terminated when the user hangs-up or on the detection of silence, special tones, or a timeout and control proceeds to step 804.
If the forwarded call is from another extension on the same PBX, some PBX integrations also give the calling party's extension number as well as that of the called party. Step 804 checks to see if the caller extension has an entry in the User
Table. In Step 805, the decision is made to go to step 806 if there is an entry and it is a known user or to step 807 if it is not. In step 806, The FFAPI gtwput subroutine is used with the administrator password to create message from Caller or
equivalent MAPI functions. In step 807, a default name (for example, "External") and password is used as the originator of the message. Then MAPISendMail is used to send the .vox file, step 808, and MAPILogoff is used to end the session, step 809.
FIG. 9 is a flowchart showing the steps for marking as read, saving, and deleting messages. Initially, the caller instructs the computer system to either mark a message as read, save a message, or delete a message, step 901. A call is made to
the MAPILogon subroutine with the user name and password, step 902. A call is made to one of three different subroutines depending upon the caller's instruction, step 903. A call is made to the MAPIReadMail subroutine for marking the messages as read.
The MAPISaveMail subroutine is utilized for saving a message. The MAPIDeleteMail subroutine is used for deleting a message. MAPILogoff is used to end the session, step 904.
FIG. 10 is a flowchart showing the steps for replying to a message during message playback for MAPI applications. Initially, a determination is made as to whether the original sender is known, step 1001. If so, the process jumps to step 1006.
Otherwise, step 1002 prompts the user is prompted to "Please enter the Mailbox Number." In step 1003, the caller enters the voice mailbox number of the recipient. The user name is then located from the user table, step 10 | | |
