EP1772001A1 - Method and system for downloading an ivr application to a device, executing it and uploading user's response - Google Patents

Abstract

A communication method comprises downloading to a device an interactive voice response application, receiving a user command to execute the interactive voice response application, executing the interactive voice response application in response to the command, creating a file that includes the user's response to the interactive voice response application, and uploading the file.

Description

DESCRIPTION

METHOD AND SYSTEM FOR DOWNLOADING AN IVR APPLICATION TO A DEVICE, EXECUTING IT AND UPLOADING USER'S RESPONSE

5 This invention relates to a communication method and system.

It is known to provide interactive voice response applications to the users of telephone systems. Such interactive voice response (IVR) applications are used by, for example, call centres, as a method of obtaining io information from the caller and/or for routing the call to the correct person.

Early voice response units (VRUs) provided dedicated IVR functionality (basic menu interaction and option selection by telephone pad key presses), but were detached from other systems of the operator. VRUs were phased out as integrated systems emerged. Mark-up languages for IVR were developed to

15 make the application development simpler and to enable distribution of functionality, for example, PML from Lucent for telephone interaction (AT&T PhoneWeb), VoxML, Motorola's voice-oriented markup language, and VoiceXML, which brought voice mark-up into line with world wide web developments.

20 VoiceXML describes IVR applications in a standardised mark-up language (XML) and leverages the advantages of web-oriented content and web-based architecture (distribution, content creation, tailorability, transcoding, scalability). VoiceXML shields the IVR programmer from telephone APIs, TTS (Text to Speech) and ASR (Automatic Speech Recognition) technologies. The

25 major components of a standard IVR Architecture VoiceXML IVR system are shown in Figure 1. The user connects through a phone 100 or PSTN terminal, via the public switched telephony network (PSTN) 102 to the VoiceXML Interpreter 104 through a telephony gateway 106. The VoiceXML Interpreter 104 conducts the call interaction with a caller based on the instructions of a

30 VoiceXML script supplied by the VoiceXML application server 108. The Interpreter 104 natively understands touchtone (DTMF) input and can manage pre-recorded audio prompts or files. The Interpreter 104 can also call upon voice technologies such as TTS (text-to-speech) 110 and ASR (automatic speech recognition) 112 for enhanced functionality. The VoiceXML Interpreter 104 communicates via web protocols (HTTP) 114 to either a local or remote VoiceXML application server 108. The VoiceXML application server 108 delivers the application, including VoiceXML text pages and binary audio files. The application server 108 receives spoken, touch-tone, and recorded input from the Interpreter 104. The VoiceXML application server 108 can query enterprise middleware and database systems 116 to dynamically drive VoiceXML to the user. The distribution of components such that backend applications reside

"elsewhere" on the Internet is commonplace for VoiceXML IVR architectures. These backend applications handle the knowledge and constraints of a particular application, such as a financial system for credit card payments, airline flight schedules and availability, theatre ticketing etc. The programming of the front-end user interface in VoiceXML is therefore shielded from the domain knowledge.

It is frequently the case that there is a front-end VoiceXML interpreter at the PSTN, which connects over the Internet (e.g. via secure http over IP, https) with back-end VoiceXML servers of the provider organisations. At any one time, the front-end interpreter will have enough 'pages' of IVR data (i.e. VoiceXML) to support the next set of interactions with a given caller (or callers). As needed, the interpreter can be programmed to call upon number checking routines, TTS modules, voice recognition modules, or even pass the caller over to a human operator. Furthermore, the interpreter can make requests of the VoiceXML server for further pages, which the server will generate in real-time, exchanging information with backend application servers if necessary.

There are a growing number of automatic services that are supported by IVR for the telephone user. These include, for example, talking yellow pages and other search services, voice messaging, weather reports, banking, travel news, train or transport timetables, flight information and booking, call centres (customer help-lines etc), football scores, chatlines, music download, ringtone downloads, games, setting up alerts/alarm calls, setting up call redirection. All of these applications are run in real time by a server accessing databases and calling data and messages as desired, on demand. In certain parts of the world, access to these services is denied to poorer people, by the fact that the charge for using the telephone is based upon the length of the call, which can be relatively long for the user of an IVR application. The cost of the call is beyond the reach of many people.

It is therefore an object of the invention to improve upon the known art. According to a first aspect of the present invention, there is provided a communication method comprising downloading to a device an interactive voice response application, receiving a user command to execute the interactive voice response application, executing the interactive voice response application in response to the command, creating a file that includes the user's response to the interactive voice response application, and uploading the file.

According to a second aspect of the present invention, there is provided a communication system comprising a gateway and a device for communicating with the gateway, the gateway for downloading to the device an interactive voice response application, and the device for receiving a user command to execute the interactive voice response application, for executing the interactive voice response application in response to the command, for creating a file that includes the user's response to the interactive voice response application, and for uploading the file to the gateway. Owing to the invention, it is possible to provide a communication method and system that allows a user to access an interactive voice response application, without incurring expensive call charges, but while having access to the advantages inherent within the interactive voice response application system. Versions of the IVR services would be very useful for populations that cannot afford the charges for on-line telephone usage. Off-network access to these services is also of interest to PSTN subscribers. The invention provides a method to enable use of IVR applications on low-level terminals. IVR applications can involve a lengthy and expensive phone call in order to acquire the correct information or undertake a desired transaction. By formatting such IVR applications in a suitable mark-up language, users can utilise and exploit such services offline at their leisure, opening up asynchronous access to a wide range of existing services provided for telephone users. Then, at the next docking opportunity, the completed sessions can be relayed to the original service provider in order to complete the transaction. The interactions with the services may be performed as a sequence of stages, with errors or final confirmation of successful transactions returned to the user.

Preferably, the device is either a datacard, or a portable handset. The interactive voice response application is downloaded to a user's handset, or to a datacard for use in handset, and the user can execute the interactive voice response application offline, without having to incur any call charges.

Advantageously, the interactive voice response application includes a database element. While the user is offline, the interactive voice response application will not have access to the usual backend services and databases, which would normally be available during the telephone access to an interactive voice response application. It is therefore advantageous to provide within the interactive voice response application, which is downloaded by the user, a database element that includes within it the functions and data that will be needed by the interactive voice response application when it is accessed offline. In a preferred embodiment, the step of executing the interactive voice response application includes error checking and correction. During telephone access to an interactive voice response application, there is a protocol for error checking the user's responses. For example, if the interactive voice response application asks for an input from 1 to 3, and the user presses the button 4 on the telephone, then an error message is produced and the flow of the interactive voice response application has to be changed to take account of the error. When the interactive voice response application is accessed by the user offline, after they have downloaded it to their device, the normal error protocol is not available. This could lead to an a situation where the user makes a mistake offline, and it is therefore desirable to provide some level of error checking and correction on the device, while the user is executing the interactive voice response application.

Advantageously, the communication method further comprises, following the uploading of the file, processing the file. The step of processing the file includes error checking and correction. Once the file containing the user's responses to the interactive voice response application has been uploaded, the gateway processes the file. This allows the gateway to check for errors in the uploaded file, and if possible to correct the errors. If the gateway detects an error that it cannot correct, then the error checking comprises creating a interactive voice response sub-application for downloading to the device. This has the advantage that rather than restarting the entire process again when an error is detected, the gateway will create a sub-application, that relates only to the error, for returning to the user.

Preferably, the communication method further comprises downloading to the device the interactive voice response sub-application, receiving a user command to execute the interactive voice response sub-application, executing the interactive voice response sub-application in response to the command, creating a second file that includes the user's response to the interactive voice response sub-application, and uploading the second file.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:- Figure 1 is a schematic diagram of a prior art system, Figure 2 is a schematic diagram of a first embodiment of a communication system,

Figure 3 is a schematic diagram of a second embodiment of the communication system,

Figure 4 is a schematic diagram of a third embodiment of the communication system, and Figure 5 is a schematic diagram of a fourth embodiment of the communication system,

Figure 1 , which is a prior art system is described in detail above. The proposed infrastructure for use in the communication system of this application is focused upon the store-and-forward provision of content and personal communications in an asynchronous manner for disadvantaged populations. Users have disconnected mobile handsets to interact with voice messages or interactive audio programs that are stored on data cards. These data cards can be periodically docked at a computer with Internet access to refresh the data content, download and upload new messages, interactive programs, or the stored responses to the programs.

The selection of content programs that are downloaded to the memory of a portable device for use by a given user (or group of users) is determined by the user profile of each user and is initially determined by user demographics, their interests and their opt-in/opt out exceptions. The content is distributed between content providers and distribution centres of the infrastructure using the Internet. Voice messages between users are delivered using Internet connections between distribution centres and regional content centres.

Interactive programs are described using a Voice Interactive Media Format (VIMF). VIMF is one of a family of XML mark-up languages, and has many constructs in common with VoiceXML and the earlier IVR languages (VoxML, PML). VIMF describes how objects are rendered on the client handset, visually as well as audibly. VIMF programs provide audio prompts, they capture key presses for controlling navigation branching as well as the user responses (key presses and speech recordings) in response to questions in the program.

These 'VIMF program responses' are also stored on the user's data card in the handset in a defined format, keyed to objects in the original interactive program. The user can replay the program to review their responses and make changes or corrections on the handset. These responses are subsequently returned on the next Internet docking of the data card, back to the content program provider or to their nominees, such as service call centres.

By using a markup language that has roots in VoiceXML (the pervasive markup language for IVR), VoiceXML applications can be readily emulated by, or transcoded into VIMF. Earlier IVR languages (e.g. VoxML) can also be similarly transcoded. Where the IVR architecture and markup language permit, there are a number of opportunities with different mechanisms to enable users to gain access to existing IVR applications and services. Different approaches are necessary, depending on the level of PSTN service and integration with gateways that interact with the low-level devices, and the degree of access agreed with the PSTN and service systems.

A first approach, which is shown in Figure 2, is to use an automated outcall mechanism from a gateway 200 that accesses the IVR applications through the PSTN 202. The gateway application must emulate a normal PSTN user; generating touch-tones and delivering stored speech fragments at the pace expected by the IVR application. (Essentially here there are two IVR applications talking to each other, with the gateway 200 taking the lead).

The system of Figure 2 includes a device 204 for communicating with the gateway 200, the gateway 200 downloading to the device 204 an interactive voice response application 206. The device 204, when offline, executes the interactive voice response application 206 in response to a user command, and creates a file 208 that includes the user's response to the interactive voice response application 206. When the user is next connected to the gateway 200 the file 208 is uploaded to the gateway 200. The gateway 200 communicates via the PSTN 202 with the IVR front end 210, which in turn is connected to the IVR server 212.

The advantages of this set-up are that there is no need for any changes to the IVR applications and the PSTN and IVR service providers deal with end users as if they were normal PSTN users. A disadvantage is that this solution is less robust for example, in relation to user errors and is potentially slower. Also, the more sophisticated IVR applications that enable a close dialogue between the PSTN user and the domain backend systems are more difficult to emulate.

A second approach, shown in Figure 3, is to enable a mechanism for the gateway 200 to connect into the PSTN 202 over IP directly into the underlying PSTN router that serves the IVR front-end application. One advantage of this is that the interaction between the gateway 200 and the front-end router 210 are data and therefore far faster than speech or DTMF (touch tones). Further, the dialogue is more robust, being packet exchange with no call-dropouts, and is therefore more suited to machine-to-machine interaction. It avoids PSTN call costs from the gateway 200 to the PSTN 202 and provides one point of access from the gateway 200 into the many IVR applications available to PSTN users.

A third approach, shown in Figure 4, is to use a gateway 200 that takes over the IVR front-end and deals with the various VoiceXML servers 212 that serve the IVR front-ends. In essence, here the service provider and their IVR application writers collaborate to produce a second 'batch-oriented' VIMF version of the application that can be run asynchronously by a user. This system has a number of advantages, including the fact that the organisation that is providing the gateway 200 deals directly with the provider companies, and the PSTN not involved. Service providers have privileged early access to a new, poorer market segment.

A fourth approach, shown in Figure 5, is to provide an IP gateway 200 directly interfacing the back-end applications 214 of provider companies. The advantages of this are that VoiceXML is bypassed altogether and the applications are rendered as VIMF for users, and data transactions are in the file formats required by each provider. A disadvantage of this approach is that deep access to complicated and sensitive or secure backend systems is needed.

Further advantages that apply to all four possible approaches are that the poorer users are included in the range of services available to PSTN users, with a vastly increased potential market for IVR service providers and asynchronous interaction with IVR services gives users a greater control to revisit and revise the options and their responses.

Further mechanisms are needed to bridge the divide between asynchronous VIMF applications and synchronous IVR applications, including reformulating IVR applications to operate effectively in a batch mode, support for session management in the infrastructure to enable a staged interaction that is transparent to PSTN-based providers and the capture of IVR responses and markup into VIMF in a structured fashion to support correction and resubmission of a failed transaction. As explained above, there is a spectrum of options to bring IVR applications to the world of offline users who cannot afford to incur the call charges inherent in accessing an IVR via the PSTN. The opportunities differ in the level of integration (commercial agreements) required with the stakeholders in the IVR application delivery chain. The lowest level of integration involves a "proxy" that can emulate a human PSTN user to undertake the synchronous exchange with PSTN-based IVR systems on behalf of poorer users. The second proposal involves a data connection direct into the PSTN at the "other side" that supports the IVR front-end, using VoiceXML to interact with the various IVR application providers through the PSTN routing mechanism. The third proposal involves setting up a customised data interaction between the gateway and each IVR service provider individually, utilising a connection directly to the VoiceXML server (or similar server) under the service provider's control. The fourth proposal requires a high degree of integration and co-working with the service providers. A gateway will deliver "native" transactions to the various transaction processing backend applications of the service provider (the service provider might alternatively decide to provide services in VIMF).

The spectrum of options to provide PSTN-based IVR applications to the poorer users includes the possible use of a proxy. This proxy could be a trusted person, employed to take users' requirements as defined in their VIMF program responses and perform the IVR phone calls, reporting any problems or successful completion back to the user. The human assistant acts in effect as an IVR scribe. Alternatively, the proxy could be an automatic outcall mechanism (for instance a "robot" caller) run by the gateway.

For a person to act as proxy, the process is as follows: The proxy must elicit knowledge of the IVR applications of interest to the users (this process is described later), build a VIMF program that can elicit the required input from a user offline (Progi), an agent distributes Progi to the poorer users, the agent collates the VIMF program responses to Progi , the proxy plays back the response, and transcribes them (Key presses for navigation and query response will be recorded by the VIMF application as keys pressed, i.e. "4" in the defined 'VIMF program response' format, tagged with the eliciting objects in the VIMF program Progi), the proxy calls up the IVR service and replicates the user's interactions with the application to the IVR and all feedback is recorded, and a VIMF formatted program response is prepared for the original user. The advantage of using a human proxy is the ease with which a person can deal with the eventualities of a phone call, and the possible prompts/responses during a phone call with an IVR. (For example, cinema times and films change weekly). The obvious disadvantage is the time and costs required transcribing user interactions, with each application, and repeating these over the phone to an IVR. It may be quite a monotonous job and people are prone to errors. On the other hand, this might provide new employment.

For an automated system to work as a proxy, a similar process has to be followed: Elicit knowledge of the IVR application paying close attention to the timing of the IVR prompts and response windows and exercising all possible options/paths (this process is described later), Build the VIMF program to offer the service asynchronously to the user (Progi), an agent distributes Progi as before, the agent collates responses to Progi, the 'robot' proxy extracts users responses from the VIMF program response file such that they are reconciled with the input data slots to be filled in during the IVR interaction, the proxy calls up the IVR service and at appropriate times, with appropriate delays, replays the user responses to navigate and respond to IVR queries (Appropriate DTMF tones are sent to replace the end-user's key¬ presses, original spoken utterances from users, captured by Prog1 ,are played into the IVR where required and knowledge of prompts and timings are used to synchronise rendering of responses.) and all IVR feedback is recorded, and a VIMF-formatted program response file is prepared to send back to the original user.

The advantages of using an automated proxy are principally reliability, accuracy, endurance and the automated proxy does not get bored, working overnight without error if required. The primary disadvantage is that the automated proxy cannot handle exceptions that are not pre-programmed in.

For an automated proxy to be able to handle outcalls to an IVR, it needs to have complete knowledge of the interaction sequence that will be required by the IVR in order to enter the options selected (the key presses/DTMF) and responses (key presses or speech) made by the user. Particularly, this means having information of the timings of the prompts from the IVR, and timing constraints with the regard to responses (key presses and speech) for the branches of the interaction that will be traversed in order to complete the user's transaction. It also means knowing the allowed ranges or sets of valid user input to the IVR application. Building a model of an IVR could be undertaken by trying out all the

IVR's options at all given junctures, identifying the subsequent impact of each option, and so on until all branches are exhausted. Similarly it would be possible to find out the maximum (and minimum) durations for speech to answer a prompt for spoken input. Such information would be used in the construction of a VIMF program that had built-in range and timing constraints, and would be essential to the later use of the IVR by the automatic proxy. In effect, the proxy had been 'trained' by exercising the IVR application.

If a data connection to individual application providers via PSTN is used, then as has been described earlier, use of VoiceXML hides from application developers and application providers the text to speech and any automatic speech recognition technology required to navigate an IVR. Only the data of concern to an application provider needs to be returned to them, for example, "What film does a customer wish to see of the four films showing tonight? How many tickets do they require and of which type? How will they pay?". A VIMF application can acquire the various responses from a user that are needed to build a response file suited for delivery as the user's data entry to the back-end VoiceXML server. Given knowledge of the necessary protocols at the PSTN, and knowledge of the VoiceXML-based data-formats and protocols required by the VoiceXML server, it is possible to route data transactions through the PSTN and directly to the chosen service provider.

For example, HTTP (or secure HTTPS) may be a suitable transport protocol. In effect, a collaboration is set up with each service provider to engineer a batch version of their IVR application. This may be simple to program, given that many service providers already offer an alternative entry point to their customers, namely via an online Internet web-page booking system which connects to their back-end domain systems, as well as IVR telephone access.

This level of integration requires knowledge of the internal protocols at the PSTN, and the protocols and data-formats used by the service providers (these data formats may be VoiceXML based, perhaps using HTTP as transport). This level of integration with the PSTN may be hard to achieve unless there is a commercial benefit (i.e. likely revenues). Acquiring data- formats (essentially VoiceXML source code) from service providers may not be a problem, as they stand to benefit if more users can access their services.

An alternative data connection to providers is via VoiceXML. A refinement of the above is the opportunity to work directly on an Internet connection with each IVR service provider independently, missing out the PSTN altogether. In this approach, the VoiceXML (source) description of the service is used in order to generate a corresponding VIMF program. The VIMF programs are used as usual (as defined above), and responses passed back to the appropriate gateway. This gateway then passes responses to the VoiceXML server, using suitable data formats (e.g. VoiceXML) and protocols (e.g. HTTP). Any responses from the VoiceXML server intended for the user will return to the gateway, and can readily be translated to a ¹VIMF program response' for forwarding to the user.

Alternatively, the data connection to providers could be using native data formats. Extending the proposal in the paragraph above further, is possible for the gateway to interoperate with IVR service providers at a high level of integration, with application developers from the gateway or from the IVR service provider creating a VIMF program that is optimal for the users. There is no intermediary IVR language. When the program is used, the resulting transaction is fed directly into the service provider's network for processing. Any responses for the customer are generated as VIMF program responses.

The disadvantage of the data sending approaches described above is that each new IVR service to be offered is a bespoke engineering task that will require programming resources from the gateway. The optimal solutions will require minimal re-engineering of IVR applications (e.g. automatic VIMF program generators, given the VoiceXML source code), and minimal engineering of new interfaces and gateways.

In all of the approaches outlined above, issues remain in the mapping between synchronous interaction and dialogue (described for example in VoiceXML) and asynchronous interaction (as captured in VIMF). One of the key issues is error handling and error recovery during an IVR session. A key advantage of synchronous interaction is the ability to rapidly detect errors and immediately correct them with the end-user or customer. This is not always possible in an asynchronous VIMF program, particularly for errors that are only identified once an application server has made a call-out to another back-end system (i.e. a credit card check.). However, some in out validity checks can be programmed in VIMF, for example, to check on valid keyed number input or that a user's entered number falls within a pre-defined range, or that the recording duration of a user's spoken reply to a question falls within a range of expected durations.

One of the ways that device-to-IVR gateways can support error correction is by recording error reports (for example "I'm sorry, the card number is incorrect") and providing the error reports back to the users in a form which enables them to understand and correct the error (these reports have to be verbal, so text to speech may be used by the VIMF program generator if speech is not provided by the IVR). Error correction by the user can also be aided by presenting the user with the responses they made, the gateway or proxy agent having added an extra mark-up of those user responses to the original VIMF Progi which were detected by the IVR to be erroneous, (the user can replay a VIMF interactive program on their handset, reviewing the responses they made previously to the program and changing them, up to the point at which their data card is presented for docking at an Internet access point). The subsequent corrected responses from the user to these VIMF "error" reports can then be inserted back into the sequence of responses. These user responses the gateway will use again in a second synchronous IVR interaction with the service provider. (Multiple staged error-report, error-correction, IVR-resubmission sessions may be necessary, and are supported by the system).

On completion of a successful IVR session, the confirmations from the IVR system can be added to the stored user's VIMF program response file. This can then be returned to the user by the gateway or proxy. The user will then receive a final record of their transaction that they can replay if wished, with the confirmations from the IVR service provider.

A further proposal (batch mode) that will aid use of IVR applications is that the providers of IVR services reformulate their interfaces such that they allow an interaction sequence to continue even if there are errors, rather than blocking any further progress. For example, if a complete transaction with a service requires unconstrained input (i.e. cannot be range-checked within VIMF and so will not be checked on the handset) on three occasions, and the user makes a mistake on the first field, the IVR system may supply an error remark and abort the transaction. The user won't know if the responses in the other 2nd and 3rd entry fields are correct until his/her responses are resubmitted (assuming the first field is correct on the second attempt). This scenario highlights that IVR systems are usually designed for synchronous interaction. This standard IVR approach can easily be remedied if IVR service providers allow errors (as far as possible) all the way to the end of the transaction. In this way, users will know most of their mistakes in the first transaction pass when they receive the first error response back from the service provider - hopefully when they submit their first retry they will get all the entries correct.

A further way that the divide between asynchronous and synchronous systems can be bridged is by use of a session-manager at the gateway (or as another element of the proxy). This session-manager can be used to help ease the users through a number of stages of interaction that are required to complete a transaction with a service provider. This session-manager may be responsible for maintaining correct user responses to prompts from an IVR until corrected responses are provided by the user for a retry, building a session of responses to make up a full transaction with an IVR in the case that the full session is too large to be stored on the user's handset, inserting prompts or help into VIMF programs delivered to the user if the user is having repeated problems with a particular service and escalation of error-recovery strategies, for example, progressive re-tracing of the IVR steps until the user supplies a valid input. There is a wide range of online IVR applications that could be rendered by the mechanisms proposed for staged handset access, or for batch-mode use, for example on PDA's for mobile users on airlines. Obviously, some IVR applications, such as a weather call line where only the region has to be selected are more predictable and require fewer back-end calls, so are easier to replicate in the batch/offline mode, than other more sophisticated IVR applications, like a airline's automatic ticket booking system. Whilst the main immediate aim is to provide a route for poor communities to access the growing range of telephone services, off-network use of services by richer user groups can also be attractive in some situations.

Claims

1. A communication method comprising downloading to a device (204) an interactive voice response application (206), receiving a user command to execute the interactive voice response application (206), executing the interactive voice response application (206) in response to the command, creating a file (208) that includes the user's response to the interactive voice response application (206), and uploading the file.

2. A method according to claim 1 , wherein the device is a datacard.

3. A method according to claim 1 , wherein the device is a portable handset.

4. A method according to claim 1, 2 or 3, wherein the interactive voice response application includes a database element.

5. A method according to any preceding claim, wherein the step of executing the interactive voice response application includes error checking and correction.

6. A method according to any preceding claim, and further comprising, following the uploading of the file, processing the file.

7. A method according to claim 6, wherein the step of processing the file includes error checking and correction.

8. A method according to claim 7, wherein the error checking comprises creating an interactive voice response sub-application for downloading to the device.

9. A method according to claim 8, and further comprising downloading to the device the interactive voice response sub-application, receiving a user command to execute the interactive voice response sub- application, executing the interactive voice response sub-application in response to the command, creating a second file that includes the user's response to the interactive voice response sub-application, and uploading the second file.

10. A communication system comprising a gateway (200) and a device (204) for communicating with the gateway (200), the gateway (200) for downloading to the device (204) an interactive voice response application (206), and the device (204) for receiving a user command to execute the interactive voice response application (206), for executing the interactive voice response application (206) in response to the command, for creating a file (208) that includes the user's response to the interactive voice response application (206), and for uploading the file (208) to the gateway (200).

11. A system according to claim 10, wherein the device is a datacard.

12. A system according to claim 10, wherein the device is a portable handset.

13. A system according to claim 10, 11 or 12, wherein the interactive voice response application includes a database element.

14. A system according to any one of claims 10 to 13, wherein the device, while executing the interactive voice response application, is further arranged to carry out error checking and correction.

15. A system according to any one of claims 10 to 14, wherein, the gateway is further arranged, following the uploading of the file, to process the file.

16. A system according to claim 15, wherein the gateway, while processing the file, is further arranged to carry out error checking and correction.

17. A system according to claim 16, wherein the gateway, while carrying out the error checking, creates an interactive voice response sub- application for downloading to the device.

18. A system according to claim 17, wherein the gateway is further arranged to download to the device the interactive voice response sub- application, and the device is further arranged to receive a user command to execute the interactive voice response sub-application, to execute the interactive voice response sub-application in response to the command, and to create a second file that includes the user's response to the interactive voice response sub-application, and to upload the second file.