US20100184409A1
2010-07-22
12/346,823
2008-12-30
A device and method for managing voice messages using a graphic user interface (GUI) to display text transcribed from the content of a voice message, to parse the transcribed text and to use the parsed data for an application running on a device. The present invention hence supplants the current approach of retrieving voice messages by phone using a voice prompt based system to a GUI based system. This GUI based system individually lists voice messages in a menu list, making it very simple for a user to not only read the transcribed text from the voice message but to run applications based on the parsed data from the transcribed text, as well as performing other more familiar functions as such retrieving the voice message for playing back.
Get notified when new applications in this technology area are published.
H04M3/53333 » CPC main
Automatic or semi-automatic exchanges; Systems providing special services or facilities to subscribers; Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers Centralised arrangements for recording messages; Centralised arrangements for recording incoming messages, i.e. mailbox systems; Voice mail systems Message receiving aspects
G10L15/26 » CPC further
Speech recognition Speech to text systems
H04L51/066 » CPC further
User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail; Message adaptation to terminal or network requirements Format adaptation, e.g. format conversion or compression
H04M1/7243 » CPC further
Substation equipment, e.g. for use by subscribers; Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection; User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
H04M3/42204 » CPC further
Automatic or semi-automatic exchanges; Systems providing special services or facilities to subscribers Arrangements at the exchange for service or number selection by voice
H04M3/4228 » CPC further
Automatic or semi-automatic exchanges; Systems providing special services or facilities to subscribers in networks
H04M3/53 » CPC further
Automatic or semi-automatic exchanges; Systems providing special services or facilities to subscribers; Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers Centralised arrangements for recording messages Centralised arrangements for recording incoming messages, i.e. mailbox systems
H04M3/537 » CPC further
Automatic or semi-automatic exchanges; Systems providing special services or facilities to subscribers; Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers Centralised arrangements for recording messages; Centralised arrangements for recording incoming messages, i.e. mailbox systems Arrangements for indicating the presence of a recorded message, whereby the presence information might include a preview or summary of the message
H04W4/12 » CPC further
Services specially adapted for wireless communication networks; Facilities therefor Messaging; Mailboxes; Announcements
H04W4/16 » CPC further
Services specially adapted for wireless communication networks; Facilities therefor Communication-related supplementary services, e.g. call-transfer or call-hold
H04M1/72436 » CPC further
Substation equipment, e.g. for use by subscribers; Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection; User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for text messaging, e.g. SMS or e-mail
H04M2201/60 » CPC further
Electronic components, circuits, software, systems or apparatus used in telephone systems Medium conversion
H04M2203/253 » CPC further
Aspects of automatic or semi-automatic exchanges related to user interface aspects of the telephonic communication service where a voice mode or a visual mode can be used interchangeably where a visual mode is used instead of a voice mode
H04M2203/4536 » CPC further
Aspects of automatic or semi-automatic exchanges related to voicemail messaging Voicemail combined with text-based messaging
H04M2250/74 » CPC further
Details of telephonic subscriber devices with voice recognition means
H04W4/14 » CPC further
Services specially adapted for wireless communication networks; Facilities therefor; Messaging; Mailboxes; Announcements Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
H04W4/18 » CPC further
Services specially adapted for wireless communication networks; Facilities therefor Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
H04W76/10 » CPC further
Connection management Connection setup
H04M11/00 IPC
Telephonic communication systems specially adapted for combination with other electrical systems
1. Field of the Invention
This invention relates to a method of managing voicemails from a mobile telephone.
2. Description of the Prior Art
Voicemail has the sole purpose of storing voice messages from someone trying to call a user's telephone when that user is otherwise unavailable and then relaying those messages to the user when convenient. But today's voicemail systems, particularly for mobile telephones, fail to do this intelligently. The primary reason is the nature of the interface from the user's mobile telephone to the remote voice mail server: typically, a mobile telephone user will call (or be called by) a voicemail server controlled by the network operator. The voicemail server will generate a synthetic voice announcing the number of messages to the user and then replaying the messages; various options are then spoken by the synthetic voice, such as âpress 1 to replyâ, âpress 2 to deleteâ, âpress 3 to repeatâ etc. This presents several challenges to the user: first, he may not have a pen and paper to hand to take down any important information; secondly, he may forget or not be able to hear the options and hence will be unable to operate the voicemail system effectively.
Because of this inadequate and opaque interface, voicemail is not used by at least 45% of mobile telephone users. Of those that do use voicemail, it typically accounts for 30% of a user's call time and spend. One of the reasons for this perhaps surprisingly high level is that, because of the difficult interface, users frequently dial in again just to listen to key voice messages they did not get the details of the first time round.
Some efforts have been made to make retrieving voicemails easier: reference may be made for example to U.S. Pat. No. 6,507,643 to Breveon Inc: in this patent, voice mail is automatically converted, using a voice recognition computer, to a text message suitable for sending as an e-mail message and for viewing on a text display device such as a PC or laptop computer. Reading a written message can be quicker than having to listen to a spoken voicemail; there is also no need to write down important information from the message since it has already been transcribed. However, automated voicemail systems have quite limited performance and accuracy; they also slavishly transcribe the normal hesitations in human speech (âerâ, âumâ, âahâ etc.). When one is listening to human speech, one can readily filter out these sounds and concentrate on the substantive communication. Seeing these hesitations slavishly transcribed to a text message or an e-mail can make the sender appear less then lucid.
In a first aspect, there is a method of managing voice messages using a mobile telephone, comprising the steps of:
The present invention hence supplants the current approach of retrieving voice messages (based on the user listening to various options spoken by a synthetic voice, such as âpress 1 to replyâ, âpress 2 to deleteâ, âpress 3 to repeatâ) with a GUI based system; this system individually lists voice messages in a menu list displayed on the mobile telephone, making it very simple for an end-user to select a message to initiate playback of the voice message.
In an implementation, the GUI is a hierarchical interface which at a first or second level lists the number of stored voice messages in an in-box. The interface may list at a first or second level whether the received voice messages are new or have been listened to. The interface could be an inbox view with folders for storage/retrieval of voice messages.
In addition, the GUI can list the name of a person leaving a voice message or their telephone number. This greatly aids operation: the end user can quickly scan the menu list of stored voice messages, looking at the caller name etc. to decide if there are any important messages to listen to immediately.
The GUI may display a menu list with one or more of the following selectable options: play all voice messages; delete all voice messages; mark all voice messages as heard; forward all voice messages; store all voice messages. Again, this GUI-based approach is far easier for most people to operate than the prior art âpress 1 to replyâ, âpress 2 to deleteâ, âpress 3 to repeatâ etc. approach.
The GUI may also be a hierarchical interface which displays a menu list of selectable items that enable the user to initiate further actions in respect of a selected voice message. For example, the further actions could be selected from the list: erase voice message; next voice message; fast forward through voice message; rewind through voice message; play previous voice message; call back to sender of voice message; open up text messaging application; store voice message in a specific folder; forward voice message; add caller's telephone number to contacts; configure greetings; configure call diversion behaviour. Again, presenting these options graphically on a display of the mobile telephone is far better than the current approach which give no visual cues as to how to initiate these functions.
Adding a caller's telephone number to a contacts application is an example of parsing the transcribed text message and using the parsed data in an application running on the mobile telephone. The GUI can display a menu list of other selectable items that enable the user to initiate further kinds of parsing and use of the parsed data. For example:
(a) extracting the phone number spoken allowing it to be used (to make a call), saved, edited or added to a phone book;
(b) extracting an email address and allowing it to be used, saved, edited or added to an address book;
(c) extracting a physical address and allowing it to be used, saved, edited or added to an address book;
(d) extracting a web address (hyperlink) and allow it to be used, edited, saved or added to an address book or browser favourites.
(e) extracting a time for a meeting and allow it to be used, saved, edited and added to an agenda as an entry
(f) extracting a number and saving it to one of the device applications
(g) extracting a real noun and providing options to search for it or, look it up on the web (WAP or full browser).
One or more items from the list could be displayed whilst the voice message is being played back on the device.
Speaking a command to initiate the further actions is also possible; then the telephone may display synchronised aural prompts (IVR) to facilitate a user speaking the command they want executed.
In another implementation, voice messages are succinctly transcribed to text format by remote, human transcribers and the transcribed messages are then sent to the mobile telephone. The GUI then lists any voice messages that have been converted to text format and the GUI further enables those voice messages converted to text format to be selected to cause the text format message to be displayed.
In a second aspect, there is a mobile telephone programmed to perform the above methods.
The present invention will be described with reference to the accompanying drawings, in which:
FIGS. 1-3 are schematics of an entire voicemail process, starting from voicemail origination, voicemail processing and voicemail delivery; in accordance with the present invention;
FIG. 4 depicts the format of a message notification (displayed in a messages in-box on a mobile telephone) for a voicemail transcribed using the method of the present invention;
FIG. 5 depicts a conventional text message notification;
FIG. 6 depicts how a voicemail transcribed using the method of the present invention appears as a text message displayed on a mobile telephone;
FIG. 7 depicts a mobile telephone displaying a list of text messages in a messages in-box. A transcribed voice mail is present in the list; the callout shows how it would be displayed if selected;
FIG. 8 depicts a menu list of three new functions available as options relevant to a transcribed voicemail;
FIGS. 9A to 9D depict a GUI based voicemail management application for managing conventional audio voicemails;
FIG. 10 depicts the operation of an application that enables a user to speak a message into his mobile telephone and have that remotely converted to a text message;
FIG. 11 shows the overall flow of actions at a voicemail server, indicating the actions initiated by user inputs;
FIG. 12 shows the overall flow of actions occurring at the voice message transcribers;
FIG. 13 shows a screen shot of the web-based interface used by voice message transcribers.
The present invention is implemented by SpinVox Limited, London, United Kingdom as part of a suite of mobile telephone products:
1. VoicemailViewâ˘: Voicemail to Text systemâThis gives subscribers the option to have voicemail delivered to their mobile telephone as text (SMS/MMS or equivalent messaging format) with the option to hear the original voicemail on the mobile telephone. The term âSMSâ means the short message service for sending plain text messages to mobile telephones; âMMSâ means the multimedia messaging service developed by 3GPP (Third Generation Partnership Project) for sending multimedia communications between mobile telephones and other forms of wireless information device. The terms also embrace any intermediary technology (such as EMS (Enhanced Message Service)) and variants, such as Premium SMS, and any future enhancements and developments of these services.
2. VoicemailManagerâ˘: A new Voicemail Management ApplicationâThis adds a GUI (graphical user interface) to the mobile telephone; it supplements (or replaces) the existing audio menu system (UI) provided by cellular phone voicemail systems and integrates the phone's call divert features, greetings controls and other related controls to provide a single environment (application) on the mobile telephone for voicemail management.
3. VoiceMessengerâ˘: Speech to Text systemâThis allows users to speak a text message into their mobile telephone, have it converted to text remotely and then sent without using the often tiring alphanumeric phone-pad entry system.
Key to the accurate transcription of voice messages to text format (as deployed in VoicemailView and VoiceMessenger) is the use of human operators to do the actual transcribing intelligently by extracting the message (not a verbose word-for-word transcription), and not automated voice recognition systems. Key to the efficient operation of this system is an IT architecture that rapidly sends voice files to the operators and allows them to rapidly hear these messages, efficiently generate a transcription and to them send the transcribed message as a text message.
A. VoicemailView⢠Voicemail to Text system
There are three solutions described which deliver the Voicemail to Text system:
Referring now to FIG. 1, the process deployed is as follows:
Referring now to FIG. 2, the process deployed is as follows:
Referring now to FIG. 3, the process deployed is as follows:
In any of the above variants, the mobile phone (or other wireless information device of some nature) will need to be upgraded OTA (Over the Air) or otherwise, in the following manner:
There are two options:
FIG. 4 shows a telephone handset icon that could be used next to a SMS message to indicate that it is a voicemail message in the messages inbox. A voicemail transcribed to text is present in the device's messages in-box; it has been sent from Homer Simpson. FIG. 5 shows what the current SMS text icon looks like. Another solution would be to precede each header with something logical such as âV:â for voicemailâhence âV: Homer Simpsonâ would indicate a SMS transcribed voice mail from Homer Simpson. In addition, inside the text file for the voicemail message, the time and date of the voicemail should be added (as not all gateways correctly timestamp sent messages), as shown in FIG. 6. FIG. 7 shows this in the context of a mobile telephone. The user has selected the âReadâ option for the highlighted transcribed voicemail (from Daniel Davies); the device displays the SMS in the normal manner, but with data and time added. It is also possible, just by pressing and holding a given key (in this illustration, key â1â) to activate the normal audio-based voicemail playback function.
When one opens a standard SMS message, one can generally readily access further functionality (via an Options menu in Nokia mobile telephones, for example), such as âEraseâ, âReplyâ, âEditâ etc. Under this standard âOptionsâ menu, or equivalent, the present implementation adds three new functions, as shown in FIG. 8:
We expand on these new functions below:
Hear Original: This allows the user to now hear the original voicemail and uses the unique i/d encoded into the SMS/MMS message to correctly connect to the original voice file.
There are three options:
(i) The user goes into the standard voicemail system and follows the existing audio prompts for hearing the message.
(ii) The user goes into the new Voicemail Management Application shown below at B.2.
In either case, upon ending the call to voicemail, the user is returned to the same point in the messaging application to decide what to do with the text/audio version.
(iii) The user embeds the original sound file in an MMS message (or equivalent, such as e-mail) to be played back locally on the terminal.
This uses the caller's number recorded with the message to call them back.
This takes the caller's number and automatically adds it to a new contact/address entry for the user to complete with name, etc.
This is a specific example of the mobile telephone software being able to parse the text that has been converted from voice and to use that intelligently. Other examples are:
(a) extracting the phone number spoken allowing it to be used (to make a call), saved, edited or added to a phone book;
(b) extracting an email address and allowing it to be used, saved, edited or added to an address book;
(c) extracting a physical address and allowing it to be used, saved, edited or added to an address book;
(d) extracting a web address (hyperlink) and allow it to be used, edited, saved or added to an address book or browser favourites.
(e) extracting a time for a meeting and allow it to be used, saved, edited and added to an agenda as an entry
(f) extracting a number and saving it to one of the device applications
(g) extracting a real noun and providing options to search for it or, look it up on the web (WAP or full browser).
The extent to which this can be done depends on the intelligence in your handset (in essence its parsing capacity and interoperability with other applications and common clipboard where this data is normally stored for use in other applications). Today, nearly all phones support extraction of phone numbers, email addresses and web addresses from a text message. This is normally made available when the user is reading the message by the content being underlined (as a hyperlink or equivalent); the user then simply selects âOptionsâ (as found on Nokia telephones, or its equivalent on a different make of handset) and âUseâ (as found on Nokia telephones, or its equivalent on a different handset) and then depending on the content type, further context sensitive options (e.g. with a street address it might offerâLook up, Navigate, Save in Address book, etc. . . . ).
This application can be used in either stand-alone or as integral part of the VoicemailView Voice to SMS/MMS system (or equivalent text delivery system) described above at B.1.
The Voicemail Management application gives a user a GUI (Graphical User Interface) in addition to the standard audio prompts they are used to receiving when accessing and managing normal audio voicemail. When a subscriber calls (FIG. 9a) into their audio voicemail using their mobile telephone, they are first taken into their âVoicemail Inboxâ and then presented with the controls shown in FIGS. 9B to D.
For programming purposes, these controls will nearly all relate to standard DTMF tones that the voicemail system uses as input to it when the user currently presses keys on their phone's keypad.
FIG. 9A shows the user calling Voicemail; FIG. 9B shows how a new management application has been invoked which first displays an Inbox's contents (here, 3 new audio calls and 2 stored audio calls) of all voicemails. The options menu operates as follows:
| Item listed in Options Menu | Action |
| Play All | Plays all messages in sequence |
| Delete All | Offers which to delete - all New or all |
| Stored - and deletes them all | |
| Mark all heard | Moves all New messages into Stored folder |
| Forward to | Forwards message to another subscribers |
| inbox | |
| Store | Store - only available in New messages or |
| during play back - moves message to Stored | |
| folder | |
Referring to FIG. 9C, if the user selects which category of audio voicemail he wishes to listen to (i.e. new or stored), he is then shown a menu list of the audio voicemails in that category, each identified with sender name if available, or failing that, the caller number. The transcribed text message ideally has added to it the caller name by the transcription service. This includes notifications when a user turns off the voice-to-text conversion in VoicemailView (i.e. they want plain voicemail) so that they will now be able to see the name of the person who has left them a voicemail before deciding whether to dial-in and listen to it/them. The user can readily navigate to and select the audio message he wishes to listen to. Once a message is selected, then, as shown in FIG. 9C, new Voicemail controls are displayed on screen. Their function is as follows:
| Voicemail control | Action |
| 1 Erase | Erases current message - returns to previous |
| screen, New or Stored folder view for user | |
| to select which message to now listen to, | |
| or goes straight to playing next message. | |
| 2 Next | Skips to next message. At end of messages, |
| goes back to previous screen, New or Stored | |
| folder view. | |
| 3 FFW | Fast forwards through message whilst button |
| held. At end of message, stops and shows next | |
| message to be heard (New or Stored folder | |
| view) or at end of all messages, goes back | |
| to top level view (New & Stored folder view) | |
| 4 REW | Rewinds back through message whilst button held. |
| At end of message, stops and shows previous | |
| message to be heard (New or Stored folder | |
| view) or at end of all messages, goes back | |
| to top level view (New & Stored folder view) | |
| 5 Previous | Skips to previous message. At beginning of |
| messages, goes back to previous screen, | |
| New or Stored folder view. | |
| 6 Call back | Calls user back and ends Voicemail call. |
| 7 Text message | Opens up Text (SMS or MMS) application with |
| callers number selected as default recipient | |
| for user to send them a text message. | |
| 8 Forward | Forwards message to another subscribers |
| Voicemail inbox. | |
| 9 Add to contacts | Adds number to contacts through phone's |
| standard contacts/address book application. | |
| 0 Configure | Configures voicemail - standard options for |
| Record New Greeting, Turn Greeting on/ off, | |
| etc . . . | |
| Integrates into existing phone software | |
| for configuring | |
| Divert behaviour - e.g. divert on busy/no | |
| answer/phone off to voicemail or specified | |
| number. | |
During this process, the user is always offered the aural navigation options which are synchronised with what is shown on-screen, so that they have the best of both worlds. With the use of simple command based Speech Recognition, the user may just speak the command they want to execute, so if the user wants to play new messages, they would just say âPlayâ and the VoicemailManager engine would recognise this command and do just thatâplay the message.
Note: The exact numbers (keypad numbers) and their related functions will be those of the existing voicemail system and so will vary by network operator/voicemail system.
It is often preferable for users to want to send a message in text format, rather than voiceâe.g. if they do not want to disturb the receiver, but want to get the message to them. But it is often difficult for people to thumb-type text on a small alpha-numeric keypad. They may also be mobile, such as walking, or in a car or have only one hand available, or be unable to type, such as whilst driving. The VoiceMessenger⢠speech to text service addresses this need.
The user goes into their Messaging/Text application running on their mobile telephone, simply selects the message recipient either from their phone's address book, or types their number in, then selects the new VoiceMessenger option, as shown in FIG. 10, by pressing and holding the â2â key. The user might also be connected to the service to start with and will then simply speak the number or the name to a local (on the mobile telephone) or a remote voice recognition engine which will take the user through the process.
When connected to the remote VoiceMessenger Engine, the user simply speaks his message and the remote VoiceMessenger Engine records it, and then sends the audio file for conversion to text using the human operator based voice transcription system. The text format message is then packaged as a SMS/MMS (email or other appropriate messaging system) and sent through the SMS/MMS etc. gateway. The user will be given aural prompts for controlling the input, hearing the conversion and sending the message.
A user with an MMS enabled phone will be able to send voice-notes via an MMS which the human operator based voice transcription service will then transcribe and send on to their desired destination. They can also have their Voicemail converted and sent to their phone in MMS format if preferred.
This is to speed up the processing of inbound voice files and reduce operating costs. The prime function will be to auto-detect spoken phone numbers, and detect language to route audio files to the correct human operator staffed transcription bureau. It will also be used for detecting names and spoken numbers and addresses from the users online phone-book (see below) and commands for VoicemailManager controls.
There will be two forms of online address book that a user will be able to use when connected to SpinVox services by simply saying the name of the person they want to say:
Using Presently Available Servers, users can define what mode they want to be in for receiving communications, e.g. âMeetingâ lets a user know before the communicate that the person they want to contact is in a meeting and will accept say SMS/MMS or a VoiceView text message. Once out of the meeting, the user can then change their contact status to âAvailableâ and be contacted by a phone call.
A standard voicemail server system with IVR is the foundation; the IVR is programmed as shown in the FIG. 11 flowchart.
The user's phone will (during technical provisioning shown below) have the â1â key (standard voicemail access key) re-programmed to automatically call the SpinVox voicemail server and have them automatically logged-in (unique phone-number+PIN) which takes them to the top level of the IVR tree.
If at any point the user hangs up, then the session is terminated with the relevant outcome. If this happens during a recording, including a dropped line from another mobile caller, then it is assumed to be the end of a recording, and the system proceeds to the transcription stage.
Each transcribed voicemail will contain a unique number starting with say a â4â (depends on final IVR tree configuration), so that when a user presses and holds â1â to connect to SpinVox's voicemail server, they simply press the unique message i/dâe.g. 403 which takes them to the 3rd message they have in the queue.
As shown in FIG. 11, the IVR tree will allow a user to dial in using their unique Divert No. (Voicemail No.) and will then be prompted to enter their PIN.
The IVR system will accept a user programming in a speed-dial that allows them to dial their unique SpinVox number+PIN. They are then able to access all features shown above.
The user's phone is configured to divert to SpinVox voicemail under conditions they define shown below, where the caller will either hear:
Then:
The above IVR diagram shows how a user accesses VoiceMessenger, whether directly from their mobile phone, or via another phone.
The IVR system will accept a user programming in a speed-dial that allows them to dial their unique SpinVox number+PIN+â3â.
If from their mobile phone, the technical provisioning below will have configured a speed-dial (by default key â2â) to dial and log them in (voicemail number+PIN+3) directly to the VoiceMessenger option.
They will then hear a standard prompt:
âWelcome to SpinVox's VoiceMessenger. At the tone, please either speak the destination number or type it in, then dictate the message you wish to send. Hang-up to send, or press # to send a new message.â [tone]
Then:
During Technical Provisioning, user data (handset, network, etc. . . . ) will be re-used to confirm to the user what they have selected.
Key will be the system sending the user SMS messages to part automate the configuration of the user's handset (diverts & V.Card for VoiceMessenger) and confirmation of successful setup. These messages are all sent as High Priority to ensure user/salesperson is not left âhangingâ whilst waiting for configuration SMS to arrive.
The steps are:
Step 1: handset selection, from a drop down list shown on the provisioning screen (usually at the point of sale)
Step 2: Voicemail View setup:
This is provided to a human operator transcriber when they log-on to their account. All they need is a web browser, sound card, media player capable of playing and controlling playback of the media files or streaming protocol, and high-speed internet access. FIG. 12 shows the process flowchart for transcription. Each Transcriber logs in and starts receiving VoicemailView (see FIG. 13 for the screen into which they type the transcribed message and from which they cause the message to be sent), or VoiceMessenger audio files to be transcribed (see FIG. 14), one at a time. While logged-in there are only 2 states: message currently in the process of being transcribed, and pause.
Note: For User Data Protection reasons, the Transcriber will never see auto-populated telephone fields (or other user data fields), so the system will not show these unless it requires the Transcriber to type the destination number in.
When the Transcriber hits âSendâ, the system will automatically spell check the message and if any errors occur, correct them and display the corrections to the Transcriber with a prompt âAccept & Sendâ, or allow them to manually correct (as there might be a particular spelling they want).
To do this properly, the spell checking process will include a real-noun dictionary relevant to the geographic area and culture of the user. So for example, in the UK the real-noun dictionary will contain not only English names, but place names, landmarks, road-names, chain establishment names (e.g. pubs, bars, restaurants, etc. . . . ), etc. . . . .
Where there isn't a match, the Transcriber just double clicks on the underlined word and is offered the closest matches. If need be, they can rewind and re-listen to that part of the message to make the appropriate selection.
They can view the statistics for all the Transcriber accounts they own below them. They will be able to view and analyse:
These are the requirements for the Transcription Services to be used for both VoicemailView and VoiceMessenger services.
The key requirement is to deliver the actual message, not all the redundant information which is often spoken and left in a message.
The Transcription service must minimally provide complete confidentiality of messages it, transcribes within the Data Protection Act 98 or other legislation in force at the time.
If the user receives a text message, it will be intelligibleâ99% accurate to original voice file message.
All numbers, phone numbers, email addresses, web addresses, street addresses will be correctly converted.
Character Set 100% Compatible with SMS/MMS Allowed Characters
Characters used during transcription are compatible with the SMS/MMS system resulting message will be sent through.
User will clearly know to continue to next message to continue reading transcription. If system doesn't automatically provide obvious prompt to do so, then insert â1 of 2â, â2 of 3â or the like.
Transcriptionists must be able to deal with the various regional accents and sayings that occur in a country. For instance, in the UK alone, there are over 12 regional accents ranging from the âposhâ South-Eastern accent to the thick Glaswegian accent of West Scotland to the lilted Irish accent. These should be translated correctly and in their form of saying things. Routing of a message to transcribers with the appropriate capabilities may be provided.
Typically speech contains much redundant ânoiseâ, e.g.: âummmsâ, âahhh'sâ, âerre, âehmmâ, pauses, breaths, coughs, sneezes and other typical speech artefacts. These clearly mustn't be included in the transcription.
Often a message will contain repeated phrases or names to clarify what is being said. These shouldn't be included.
Spoken message: âSee you outside Waxy O'Connors, that's Waxy as in candle wax and O'Connor as in Irish singer Sinead O'Connor.â
Transcription should read: âSee you outside Waxy O'Connors.â
Standard abbreviation of common terms should be used:
| Spoken | Abbreviation | |
| Apartment | Apt. | |
| Number | No. | |
| Telephone Number | Tel. | |
| Fax Number | Fax. | |
| Example | E.g. | |
| Okay | ok | |
| Electronic Mail | ||
| Internet Website | website | |
| (i.e. no http:// required) | ||
Whenever a number is spoken, the numeric format will be written down.
E.g. âSee you at seven forty five tonightâ=âSee you at 7:45 pmâ
E.g. âWe'd like to order eleven thousand, seven hundred and eighty eight nuts D4 size.â=âWe'd like to order 11,788 nuts D4 size.â
E.g. âJane lives on eleven seventy five Park View, apartment twenty three on the third floorâ=âJane lives on 1175 Park View, apt. 23 on the 3rd floor.â
To save character space, phone numbers are a single string of numbers with no spaces:
E.g.: 07798625155, not 07798 625 155 as two additional space characters are being used.
If phone number is given with 00 for international dialing, then convert this into a â+â.
e.g. 00442075864103 should be +442075864103.
Again this saves character spaces and correctly defines the number for international dialing prefix which is interpreted by the local Network for the correct international dial out code which isn't always 00 (e.g. in US it's 011).
Messages must be correctly spelt and it is suggested that the relevant spell checker is used for all messagesâe.g. UK English for the UK, US English for the US, etc. . . .
The dictionary/spell checker used must include Real Nouns (names) and Place Names to assist in getting the information in the message right 1st time.
There are several aspects of this:
In multi-cultural societies, it is important to know that on many days a certain community will be celebrating something. For example the Hindi new year (Divali) is not the same as the main UK new year, so on Divali, Transcribers must be prepared to hear greetings and wishes with this and other associated words in it and know how to spell them or what a message's context might mean.
(ii) Normal annual eventsâEaster, Christmas, New Year, etc. . . .
(iii) Sporting eventsânational leagues, world cups, F1 events, sailing events, etc. . . .
(iv) Media eventsâOscars, BAFTA, etc. . . . winners
(v) Unexpected eventsâlike the recent âTwin Towersâ attack, the bombing in Madrid, War in Iraq, etc. . . .
The local Transcription Bureau Manager must have a full calendar of all cultural, social and sporting events which they must plan for at least 2 days in advance. In addition, this will be critical to determining the likely load balancing required with staff. For instance, at the end of the recent England Rugby world cup win, the text messaging and voicemail loads in the 2-3 hours that followed the match probably exceeded 300% of their normal levels and there would have been lots of references to players names, technical words used in the game (try, conversion, ruck, mall, etc. . . . ), foreign cities and locations, and of course the following day all the traffic related to people getting back from the event, etc. . . . which will naturally skew the load balancing again.
After the best attempt has been made to figure out what the word might be (could be the name of a bar or place that is outside the normal vocabulary), a question mark in brackets will be placed after it.
Spoken message: Meet you at Jongleurs at 6 tonight.
Transcription: Meet you at Junglers(?) at 6 tonight.
The message may contain âdrop-outsâ, âgapsâ or other interference due to temporary Network coverage issues. In this case, insert a â_â where the word(s) are missing.
E.g. âJohn, it's Mike and I'm _ late _ so see you at 6 pm.â
This will likely prompt the user to dial-in to listen to the original and see if they can make sense of the message.
More than 3 Drop Outs:
In the case the message is unintelligible due to a high number of drop outs (3 or more), then use the âUndecipherableâ option to send the user a notice that they need to either listen to a voicemail or try speaking their text message again.
The user will be notified via a text message using a standard template that there are undecipherable voice messages for them to listen to:
The standard text will say, âYou have x new voicemail(s) to listen to that couldn't be converted. To hear them, please connect to VoicemailView by holding and pressing 1.â
Then the following fields will be automatically populated:
The standard text will say âWe're sorry we couldn't convert the message you just dictated. Please try again speaking slowly and clearly. Thank you!â
Then the following fields will be automatically populated:
When it is clear that the person leaving the message is also using mood as part of the message, then the transcriptionist will include the following at the beginning of the message:
When the mood is unclear (e.g. may be just the way that person talks or the context that they're in), then don't add this in.
VoiceMessenger Text'isms
It is becoming common to insert text symbols to represent emotions emoticons). The following will be published and will be supported. This is the set that we will support and publish on our website.
The official full listing of SMS-Speak is at: http://sites.ninemsn.com.au/minisite/web2sms/help/smsdict.asp
During dictation of the VoiceMessenger message, the user may say âInsert symbol-nameâ and the transcriber will insert the appropriate symbol.
E.g. âThanks for confirming our trip. Insert smiley. Bye!â=âThanks for confirming our trip :-) Bye!â
| Symbol | Symbol Name | |
| :-) | Smiley | |
| :-D | Laugher | |
| ;-) | Twinkle | |
| :-* | Kiss | |
| :-( | Sad | |
| :'-( | Crying | |
| :-c | Unhappy | |
| :-|| | Angry | |
| :-(0) | Shouting | |
| :-< | Cheated | |
| >:-( | Very angry | |
| :-O | Wow | |
| :-| | Determined | |
| :-* | Bitter | |
| O :-) | An angel | |
| :-9 | Salivating | |
| :-<> | Surprised | |
| %-6 | Not very clever | |
| :-() | Shocked | |
| :-o zz | Bored | |
| :-\ | Sceptical | |
| : @ | Shouting | |
| :-o | Appalled | |
| :-X | Not saying a word | |
| |-I | Sleeping | |
| %-} | Intoxicated | |
| :-v | Talking | |
Normal punctuation should be used such as capitals at the begging of sentence, full stops, question marks, exclamation marks, colons and semi-colons where it is clear that the intonation or the grammar requires it.
The Grammar checker used in the Transcribe Assistant ought to help eliminate mistypes.
Time taken for text message to arrive on receiver's phone from end of voicemail recording is on average 2 mins:
Queuing and load-balancing will be necessary to ensure optimal throughput of messages.
1. A device for managing voice messages left for a user comprising a graphical user interface that displays text transcribed from the content of a voice message, and a parser that parses data from the transcribed text, the parsed data being used for an application running on the device.
2. A device for managing voice messages as in claim 1 wherein the graphical user interface further displays a menu list that identifies more than one voice message.
3. A device for managing voice messages as in claim 2 wherein the transcribed text displayed on the graphical user interface is the transcribed text from the content of a voice message selected from the menu list.
4. A device for managing voice messages as in claim 3 wherein the graphical user interface is a hierarchical interface which, at a first or second level, displays the menu list.
5. A device for managing voice messages as in claim 3 wherein the menu list identifies the original devices that generated the more than one voice message.
6. A device for managing voice messages as in claim 5 wherein the original devices are identified by a person's name or a phone number.
7. A device for managing voice messages as in claim 3 wherein the device further plays the selected voice message.
8. A device for managing voice messages as in claim 7 wherein the voice message is remotely stored.
9. A device for managing voice messages as in claim 7 wherein the voice message is stored on the device.
10. A device for managing voice messages as in claim 7 wherein the graphical user interface further identifies the voice messages that have been played to the user.
11. A device for managing voice messages as in claim 1 wherein the parsed data is a phone number.
12. A device for managing voice messages as in claim 11 wherein the phone number is the phone number of the device that generated the voice message.
13. A device for managing voice messages as in claim 1 wherein the parsed data is an email address.
14. A device for managing voice messages as in claim 13 wherein the email address is an email address belonging to the person who generated the voice message.
15. A device for managing voice messages as in claim 1 wherein the parsed data is a noun.
16. A device for managing voice messages as in claim 15 wherein the application is a web search application.
17. A device for managing voice messages as in claim 1 wherein the parsed data is a physical address.
18. A device for managing voice messages as in claim 1 wherein the parsed data is a web address.
19. A device for managing voice messages as in claim 1 wherein the parsed data is a number.
20. A device for managing voice messages as in claim 1 wherein the parsed data is a time.
21. A device for managing voice messages as in claim 1 wherein the parsed data is a date.
22. A device for managing voice messages as in claim 1 wherein the device is a mobile phone.
23. A method for managing voice messages left for a user comprising the steps of: (a) displaying text transcribed from the content of a voice message and (b) a parsing the transcribed text, the parsed data being used for an application running on a device.
24. A method for managing voice messages as in claim 23 further comprising the step of displaying a menu list that identifies more than one voice message.
25. A method for managing voice messages as in claim 24 further comprising the step of selecting a voice message from the displayed menu list.
26. A method for managing voice messages as in claim 24 wherein the menu list is displayed in the first or second level of a hierarchical interface running on a graphical user interface.
27. A method for managing voice messages as in claim 24 wherein the menu list identifies the original devices that generated the more than one voice message.
28. A method for managing voice messages as in claim 27 wherein the original devices are identified by a person's name or a telephone number.
29. A method for managing voice messages as in claim 23 further comprising the step of playing the voice message to the user.
30. A method for managing voice messages as in claim 29 wherein the graphical user interface further identifies the voice messages that have been played to the user.
31. A method for managing voice messages as in claim 23 wherein the parsed data is a phone number.
32. A method for managing voice messages as in claim 33 wherein the phone number is the phone number of the device that generated the voice message.
33. A method for managing voice messages as in claim 23 wherein the parsed data is an email address.
34. A method for managing voice messages as in claim 35 wherein the email address is an email address belonging to the person who generated the voice message.
35. A method for managing voice messages as in claim 23 wherein the parsed data is a noun.
36. A method for managing voice messages as in claim 37 wherein the application is a web search application.
37. A method for managing voice messages as in claim 23 wherein the parsed data is a physical address.
38. A method for managing voice messages as in claim 23 wherein the parsed data is a web address.
39. A method for managing voice messages as in claim 23 wherein the parsed data is a number.
40. A method for managing voice messages as in claim 23 wherein the parsed data is a time.
41. A method for managing voice messages as in claim 23 wherein the parsed data is a date.