Testing voice message applications

Telephonic communications – Diagnostic testing – malfunction indication – or electrical... – Of centralized switching system

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C379S027040, C379S029020, C702S119000, C702S122000

Reexamination Certificate

active

06516051

ABSTRACT:

FIELD OF INVENTION
This invention relates to testing an interactive voice response system and in particular to bulk testing of voice messaging applications.
BACKGROUND OF INVENTION
A function of an interactive voice response (IVR) system is to provide an automated way of communicating information between a user and a business. Although it is unlikely that automated IVR systems will totally replace human operators in the near future they are becoming more pervasive throughout business for simple interactions. For instance while it is still the norm to deal with a human for directory enquiries for national and international calls, simple introductory functions such as acquiring a name are now performed by an IVR and a human interjects with the response or to make a further query. However a fully automatic company IVR directory application exists for company wide enquiries that can respond and query further when there is a problem. It can not be long before these fully automated directory enquiry applications become more pervasive for national and international use.
Voice mail is an IVR application whereby a caller can leave a message for a receiver by dialling directly for connection into a voice mail server. The caller can indirectly leave a message after being connected to a voice mail server after an engaged or timed out telephone call to a party. Once connected to the voice mail server an IVR voice mail application is initiated to service the call. A simple IVR voice mail application may begin by playing a voice prompt asking for the destination voice mail box number (if it does not already know it) and then ask the caller to leave a message which is recorded and stored in the voice mail box. A more complex IVR voice mail application will give the caller various options, for instance, to delete the message, to re-record the message or to forward the message to other voice mail box owners. If the called party who owns the voice mail box wants to listen to the voice mail, a connection to the voice mail server must be made whereby a different voice mail application is initiated. A simple application might allow the owner to listen and delete his messages but a more complex one might allow saving, replying, forwarding to another or other voice mail boxes, or even saving as an attachment and forwarding as an email to somewhere.
During development of a voice response system application, such as a voice mail application, it is necessary to simulate a plurality of calls so that the performance under strain can be monitored. Such a simulation can be performed by a bulk call generator which makes telephone calls to the IVR directly or through a private branch switch. Each simulated telephone call is programmed into the bulk call generator and associated with a particular application. Several types of telephone call may be designed and the bulk caller generator may simulate one or a combination of different calls at the same time using several channels connected to the IVR system.
However some problems still occur in the application which performance testing using programmed simulated calls does not find. This is because real callers behave in unpredictable ways which were not expected or assumed by the programmers of the simulated calls. Functional and/or performance tests are known to be artificial—and although the programmers of the tests may attempt to simulate various aspects of real-life use of voice response systems this is often done by the tester's inside knowledge of the code, which adds to the artificial nature of the testing. Customers sometimes report problems occurring which are so difficult to recreate in the laboratory that debugging the problems becomes almost impossible and occasionally the laboratory may even disbelieve the problem occurs at all. Therefore there is a need for a new type of voice application test system which does not rely on pre-programmed telephone calls to test an IVR system but is concerned more with realistic user interactions.
U.S. Pat. No. 5,222,083 discloses a method for use in developing, testing, debugging and trouble shooting a call progress monitoring (CPM) detection system which is utilised, for example, by a voice messaging system (VMS) One embodiment includes the steps of (a) monitoring at least one voice channel to obtain CPM tones and having a CPM detection system associated with the VMS perform an analysis of the CPM tones, the output of which analysis is referred to as CPM Trace Variables; (b) storing the CPM tones and the CPM Trace variables in a trace file; (c) obtaining a first voice channel; and (d) feeding the voice portion of the CPM trace file to a second channel for playing to the first voice channel. This system is for debugging problems with a call progress monitoring detection system and is primarily interested in recording call progress tones (e.g., ring tone, busy tone), in audio format, for outgoing calls and “trace variables” (analysed call progress tone details)—then “looping back” one voice channel to another so that the first channel can simulate the call progress tones originally detected by playing back the original audio recordings. It does not concern itself with recording user interactions, audio or otherwise.
SUMMARY OF INVENTION
According to one aspect of the invention there is provided a test system as described in claim
1
.
This solution provides actual customer data for recreating customer reported problems in the laboratory and for providing performance tests with realistic data. This solution provides an option to record the entire interaction of callers with the IVR system including incoming call data, DTMF keys pressed during the call, voice/silence detection data and hang-up (with exact timings) in a file (or database) for “playback” on voice response units in the laboratory.
In a preferred embodiment the amount of data recorded by the solution is less than the amount of information in the call as only certain events are logged. Some privacy issues (such as recording peoples' private messages) also do not complicate the implementation of this solution. If there is a requirement to not record DTMF data in certain circumstances (e.g., passwords, credit card numbers) then appropriate implementation of the solution (i.e., flagging that confidential data is about to occur on a channel, after which the system only records the timing of the DTMF presses, flagging that confidential data has finished, after which the system records all DTMF presses again) could ensure that such DTMF data is not recorded.
One difference between the prior art and the above solution is that the solution records details (not an audio recording) of user interactions such as DTMF input and voice input (i.e., the fact that voice input is occurring, not the audio of the voice input nor any details of what is actually being said) for incoming calls. The solution is not concerned about network interactions and the subsequent success or failure of outgoing calls, call progress tones, etc. as described in the US patent publication mentioned above.
Advantageously the user interaction data may be extracted directly from the voice input channels during a live user interaction. This might be used for instance during laboratory development whereby the testers are creating telephone calls to be simulated by making telephone calls and whereby the voice response test system records the interactions for later simulation. More advantageously it may be extracted from trace data recorded during real live user interactions. This might be used in the case where trace data is already available from a voice response application.
Preferably the user interaction data may comprise at least one event with at least one associated property, whereby the event may be an indication of a tone event such as when a DTMF key is pressed during the IVR dialogue. Such interaction data may further comprise properties of tone type (such as the specific DTMF key) produced during the call, timing of the tone, and possibly other details such as the duration of t

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Testing voice message applications does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Testing voice message applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Testing voice message applications will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3151349

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.