WO2006008713A1

WO2006008713A1 - System and method for offline listening and creation of voicemails

Info

Publication number: WO2006008713A1
Application number: PCT/IB2005/052362
Authority: WO
Inventors: Paul J. Rankin; David A. Bell
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2004-07-16
Filing date: 2005-07-15
Publication date: 2006-01-26
Also published as: GB0415925D0

Abstract

A communication system comprises a gateway (20) and a plurality of docking stations (14,16). Each docking station is for receiving a device (10), and is connected to the gateway. When a device is received at a docking station, thú station identifies the received device, and downloads voicemails from the gateway (20) to the device (10), and at the same time uploads voicemails from that device to the gateway.

Description

DESCRIPTION

SYSTEM AND METHOD FOR OFFLINE LISTENING AND CREATION OF VOICEMAILS

5 This invention relates to a communication system and method.

It is known to access voicemails from a remote location. Typically, a user of such a system will dial a known telephone number, enter a dedicated security code, and have their voicemails played back to them. There are a io number of disadvantages with this system, in that it does not allow the user to store the messages that are played to them, nor to send messages back via this system.

It is therefore an object of the invention, to improve upon the known art.

15 According to a first aspect of the present invention, there is provided a communication system comprising a gateway and a plurality of docking stations, each for receiving a device, and each connected to the gateway, each docking station arranged to identify a received device, to download voicemails from the gateway to the received device, and to upload voicemails

20 from the received device to the gateway.

According to a second aspect of the present invention, there is provided a communication method comprising receiving a device, identifying the received device, downloading voicemails from a gateway to the received device, and uploading voicemails from the received device to the gateway.

25 Owing to the invention, it is possible for a user to access their voicemails from a remote location, allowing the user to receive and store their new voicemails, and upload stored voicemails at the same time. The user has a device that stores voicemails that they wish to upload, and this accesses the central gateway via the docking station.

30 Advantageously, the device is a handset, or a data card. Preferably, each docking station is further arranged to download programs to a device and to receive responses to those programs from the device.

In an advantageous embodiment, the gateway is arranged to receive messages in a format other than voicemail, and to convert those messages into voicemails. The gateway is also arranged to receive a voicemail from a device, and to convert that message into a format other than voicemail.

Ideally, the gateway is further arranged to resolve the destination of the received voicemail, and to communicate with a public switched telephone network (PSTN) server to deliver the voicemail.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:-

Figure 1 shows a schematic view of a communication system, Figure 2 shows a flowchart of voicemail processing at a gateway, and

Figure 3 shows a flowchart showing forwarding of a voicemail to a PSTN user.

Figure 1 shows a communication system for providing content and personal communications in an asynchronous manner. The programme of content downloaded to a portable device 10 is determined by a user profile that is initially determined by user demographics. This user profile can be modified using an Interactive Voice Response (IVR) application from any telephone on the public switched telephone network (PSTN). In addition, subscribers can access and playback their interactive content through a standard telephone. Refreshing the content of a device (upload of voicemails to be delivered and programme responses, as well as download of new voicemails received and new programming) can also be performed over the

PSTN. The billing system of the PSTN operator used to collect micro- payments can be used to bill users for use of these services.

In the system, a portable device 10 has the facility to receive and store structured audio programs in memory for later playback. This offline playback is interactive, the user's responses are stored on the device and subsequently uploaded to content or service providers. Content is exchanged between the network and the handset 10 in a periodic wired docking process. The public telephone networks are used as a means to configure programmes and downloaded content.

As various content providers (governmental organisations, job centres, health centres, NGOs, Radio stations) make new content available, it is marked up (in a markup language Voice Interactive Media Format - VIMF) and the Regional Content Centres (RCC) 12 take editorial control and make initial proposals for distribution to the various interest groups.

The RCC 12 then has responsibility to get the new content out to the distribution centres - Internet Tele-Centres (ITCs) 14 and Data Card Refresh Services (DCRSs) 16 with the DCRS optionally also being responsible for Data Card production. The ITC is an internet access point and may be in the form of a tele-centre, a kiosk, a suitably configured ATM, a postal office or a dedicated DCRS. By caching the content at these centres, the burden of distributing a great deal of content over limited bandwidth is much reduced. The proposed synchronisation process for handsets 10 can take two routes, either docking of the handset (or card alone) at an ITC 14 or refreshing a data card 18 (that would be used in a hand set 10) on its own at a DCRS 16.

If docking at an ITC 14, the user ID will be checked, and there will be an opportunity for the user to refine his/her configuration online and modify sensitive information such as their security code. At the same time, the usual information exchange can take place. This information exchange typically takes the following form:

1. Voice Messages ("Vmails") from the user, awaiting delivery, are uploaded,

2. Responses that the user has previously made to programmes are uploaded,

3. Unnecessary programming and data on the card is deleted,

4. New vmails for the user are downloaded, 5. New programmes are downloaded.

If a user is docking at a DCRS₁ the data card owners will probably not be present, and the cards 18 will simply be "docked" and refreshed, before being dispatched for return to their owners. The refresh process will be the same as above, except of course that the users will not be present to authorise the refresh, or to interact with any services (e.g. to modify profile etc.).

The handsets 10 have a USB 2.0 data connection, giving up to

480Mbit/s data rate. A data card 18 used in the handset 10 may have between 32MB and 256MB of on-board flash memory, which will require a few minutes at most to refresh, assuming the ITC 14 or DCRS 16 has the capacity for upload, and pre-cached content ready for download.

Communication to and from the devices 10 via the ITCs 14 travels through a gateway 20. The ITCs 14 connect to the gateway 20 via the telephone network (PSTN) in most instances.

The communication system comprises the gateway 20 and the plurality of docking stations (the ITCs or DCRS) 14,16. Each docking station 14 or 16 is connected to the gateway 20 and is for receiving a device, which is either a handset 10 or a data card 18. Each station 14 or 16 is arranged to identify the handset 10 or data card 18, and downloads voicemails from the gateway 20 to the handset 10 or data card 18, and uploads voicemails to the gateway 20.

Each docking station 14 or 16 is also arranged to download programs to the handset 10 or data card 18 and receives back responses to those programs from the handset 10 or data card 18. The gateway 20 can receive messages in a format other than voicemail, and can convert those messages into voicemails. Likewise, the gateway 20 can receive a voicemail from a handset 10 or data card 18, and can convert that message into a format other than voicemail. The gateway 20 is also arranged to resolve the destination of the received voicemail, and to communicate with a server to deliver the voicemail.

The system provides a simple "phone-number" oriented addressing system for voicemail, which makes addressing as simple as a phone call. Users select a recipient (or reply to a voicemail) and then speaks the message into the handset 10. The message will be routed to the recipient at the next docking opportunity. This is illustrated in the flowchart shown in Figure 2.

The infrastructure can accommodate routing of voice messages between the gateway 20 and the PSTN (wired or wireless). To do this, the gateway 20 is used to resolve addresses between handset address space and the address space used by the PSTN. Furthermore, this gateway 20 has access to facilities that maintain message integrity as the message is transferred between message systems. Complementary mechanisms of the gateway 20 are implemented that enable replies from users outside the network. This is illustrated in the flowchart shown in Figure 3.

Programmed content such as entertainment and education can be made available for many segments of a poor community. The primary medium used will be spoken audio, to enable participation by those with low literacy. The programming for an individual is determined by demographics, personal circumstances and preferences (user profile).

An infrastructure is to be provided to deliver such programming to portable devices, such that the user can listen to the program later. This approach enables fast, efficient use of precious resources such as PCs and network bandwidth. The primary means for users to acquire content is by connecting the portable device to the network at a telecentre (ITC) or by uploading content directly to the memory card (at a data card centre, or via suitable internet kiosk) - this is called docking. Docking may be over a wired connection, although wireless docking is also possible. Alternatively, a users data card carries enough information about its owner to enable the data card to be refreshed without his/her presence, whether over remote link or otherwise.

The programmed content is marked up in a proprietary language (VIMF - Voice Interactive Media Format) that contains mechanisms to acquire responses from the user; these responses are then returned to appropriate agencies at the next docking. The unique ID and security code for each user enables peer-to-peer voicemail between users and relevant agencies (for example, NGOs, clinics).

The basic system provides communication and a two-way information channel at an affordable price for the poorer segments of the population. The system is packet switched, and exploits secure connections over the Internet as a means of transport. PSTN provides the advantage of real-time connection at a high price over a circuit switched network. Users of PSTN are also provided with store and forward services such as voice-message boxes or automated telephone ordering systems. Asynchronous and synchronous communication systems offer different levels of integrity with regard to message exchange. When making a phone call, the caller knows immediately the status of the recipient, and knows how to deal with each eventuality, such as:

^■ wrong number ■ recipient takes the call

■ recipient's line is busy, or

■ call is unanswered.

The caller knows exactly how successful a call is once the call takes place because there is ongoing spoken interaction during the call. All manner of eventualities can be accommodated, and the outcome maybe a result of a negotiation, for example:

■ the recipient cannot speak now, please call back,

■ the recipient understood the message, or

■ the recipient did not understand (or didn't even listen). From the recipient's side, the call may be missed (the recipient is out or busy on the phone), an answer message may deliver a message and details of a missed call (for example UK telephone service dial number 1571), some PSTN-based notification (for example UK telephone service dial number 1471) may indicate a missed call and the number of the caller, the phone call may interrupt an important activity (maybe the recipient offers to call back, or asks for the caller to call back later), or the call may be welcomed (or indeed, unwelcome and cut short). This knowledge is not readily available for those delivering voice-messages.

Users of asynchronous systems expect the usual protocols of message sending and reception to operate as follows, there will be some time delay to delivery of the message (a day or more), wrongly addressed messages will be notified, the recipient will receive the message when they next access the message system, and the recipient will respond appropriately (if necessary) when they get the opportunity.

If asynchronous messages could be passed between the worlds of PSTN and handset based interaction, respecting the protocols of each system, then there can be a much greater degree of social inclusion and economic benefit for all involved. The challenges are not just due to the transformation of voice-messages between formats, but are also due to the need to maintain integrity of communication. Integrity implies that the sender knows the message has been conveyed successfully to the right person, faults in delivery are reported and the recipient can reply.

It is necessary to create a successful mapping between these systems, and to overcome the differences between the protocols inherent to each. The driver to providing a gateway to the PSTN is that it greatly increases the "digital inclusion" of the handset users, bringing them in touch with the wider community and those they may able to work with to improve their lives.

Pertinent to all the opportunities is the need to map between address spaces of different communication systems. Methods are proposed to map between address space of the handset environment and the PSTN without compromising the simplified addressing mechanism available to handset users.

When delivering voicemail to the PSTN it is necessary to ensure that an addressing translation mechanism is in place to resolve PSTN numbers from handset address space, and that mechanisms are in place to ensure successful delivery of the message taking into account all the possible call eventualities. Furthermore, to maintain integrity, mechanisms are proposed which will provide delivery reports to the sender. Mechanisms are also proposed which will enable the PSTN user to call back and leave a response to the original handset sender.

The PSTN networks offer users a wide range of services. The PSTN networks are an important channel for many businesses and services. Mechanisms are provided that will enable handset users to make use of simple PSTN-based services (such as PSTN voicemail answer-phone systems). This further enhances the value as a means of social inclusion, but also provides a PSTN service provider with a much greater market for their services.

It is also possible to send voicemail from the PSTN to handset users. Once the new network is in operation, further "digital inclusion" and community cohesion will result if PSTN users are able to take the initiative and send voice messages to handset users.

The handset system is deliberately designed with short (8-digit) numbers for addressing services and users, i.e. xxxx-xxxx. This convention parallels the local phone numbers used in at least one known region. Addresses are readily memorised and recalled by the target users. The handset address space is configured such that certain 4-digit prefixes are reserved for medical advice, others are for legal advice and job finding and so on. Area codes are also possible. The handset numbering space is community-oriented, but can enable inclusion of agencies that are geographically remote.

If a voicemail ("vmail") submitted for delivery by a handset on the system is addressed to another handset user, it will be delivered to the inbox of that user immediately by a mail-server at the Regional Content Centre (RCC) as long as the address is valid.

If the vmail address is identified for eventual resolution as a PSTN telephone number, the vmail can be forwarded from the mail-server to a gateway that can interface with the PSTN and pass the message onto a telephone number or service (possibly terminating at an answer phone). The interfacing to the PSTN can be at various levels, depending on the access to the PSTN network that is permitted. Handset users can indicate to the system that a message is intended for a PSTN subscriber in a number of ways, for example by prefixing the recipient's number with a "*". When the address is parsed, the "*" prefix will trigger a database lookup to find the PSTN number of the addressee. It may well be that the handset address forms part of the PSTN number, or they may be entirely different (i.e. the address database has been populated with 8-digit codes which are resolved to PSTN numbers).

One solution is to use a direct mapping from local 8-digit telephone numbers into handset unique addresses. In general, a directory mapping system is used for resolving the vmail addresses and auxiliary information into PSTN numbers. One way of addressing PSTN numbers is to send all vmails to a special handset address, with the handset sender adding the required PSTN number in special fields in the message.

The directory mapping not only delivers the equivalent PSTN address, but can include the look up of specific protocols for accessing that PSTN number and associated services on that number. These may include a PSTN answer-phone's protocol and signals that will be required to deliver the message successfully. The advantage of extending the handset address space in this way is so that the main handset user group uses the simplest possible addressing for the majority of the time.

Enabling address resolution via standardised 8 digit handset addresses may be useful for communication between handset users and the external PSTN users, while the short-form of internal handset address space could be maintained internally to enable ease of use. As described above, there is a great deal of difference between asynchronous and synchronous communication, not least being the stages of interaction that enable the course of the communication to proceed in a fashion which is negotiated and agreed by each party.

Because handset users are remote from the communication when the message is passed on, the message gateway has to take the information that is available and prepare for a synchronous telephone call that will provide the PSTN recipient with some of the affordances that telephone calls offer (i.e. the option to repeat the message, to request a later call, to offer to call back etc). The message gateway also needs to be able to recognise and handle all of the problems of completing a successful call connection in the PSTN world.

The essential features of the gateway to forward vmails to the PSTN (wired or wire-free) are:

• Resolving the target PSTN number (as described above)

• composing a call from the vmail elements

• direct delivery to voicemail (if possible)

• ...or automated dialout • dealing with call eventualities: o user busy o call unanswered o call answered o call cut off o answer machine

• message delivery, possibly using Interactive Voice Response (IVR)

• enabling the PSTN recipient to return a message to the handset sender. The audio message content that needs to be delivered to the recipient suitably includes an introductory identification of the sender, the spoken message itself, and details of how the PSTN recipient can respond (mechanisms to support callback are described below).

There are a number of ways the gateway might deliver the message to the recipient, depending on its level of access to the PSTN system. In the highest degree of integration, the gateway will deliver the message directly to a PSTN voicemail database. This is possible if there is a suitable connection to the target network, or a gateway at the target network. Such a mechanism is provided within some GSM-based networks. At the lowest level of integration, the gateway can use an automatic dialler to call the recipient's PSTN number. In this approach, an agent acts on the handset user's behalf to deliver the pre- recorded message in a synchronous fashion. The mechanisms used are much like the computer-calls that are used for cold-call sales, marketing campaigns, or even games. The sequence and protocols of delivery to the voice box can be looked up from a database directory that is maintained by the gateway.

Other schemes are possible between these two extremes. For instance it is possible to automatically deal with call connection eventualities. In all cases, the gateway needs to catch any errors and return these to the handset sender. For example, if an incorrect telephone number is detected during the gateway's dialling process, the gateway can automatically generate a spoken vmail to send back to the handset user to inform them.

Other events in a call may also be handled automatically by the gateway, and may use features that are standard in PSTN dialling systems such as PC telephone-modem software. For example, if the recipient line is busy or unanswered, the auto-dialler may simply schedule a later call, and repeat such rescheduled calls up to a maximum number before returning an error report to the sender. Likewise, upon making a connection, the automatic dialler can provide identification of the sender and pass control to an IVR to enable the PSTN recipient to have some control over the message-delivery call, which can then proceed in two ways; either the auto-dialler leaves instructions for picking up the voice message from the handset network, or the auto-dialler delivers the full message. If there are any errors in this process, the user can be notified

Alternatively, to pickup a voice message from the handset network, PSTN users may have to call an access code to interact with the gateway that is part of the network and then work with a standard IVR system, entering a given code or authorisation in order to retrieve the message. In a normal PSTN-to-PSTN telephone call, the recipient is readily able to return a call due to inclusion of Caller Line Identification (CLI, caller ID) in the system, or from details left on an answer machine. In the case of a handset-initiated message to a PSTN number, the CLI may be set to the telephone number of the handset to PSTN gateway. This may be useful in the first instance, but the sender's unique address will also need to be encoded in the message to enable the recipient to return a message to the handset user. One implementation of the handset system takes the unique handset address of the sender, convert it automatically to a spoken address and extend the spoken message with this extra information. The PSTN recipient can then listen to the sender's address and use it in their reply. For example, they could call a special PSTN access number and be invited to key in the required 8-digit handset address. In another implementation, the user might have to interact with an IVR system for the return call, to key in the 8-digit handset address.

A further implementation converts the sender's unique address into DTMF tones for delivery with the message to a known PSTN recipient IVR system. The reply can then be made automatically by exploiting the 8-digit handset address captured by the PSTN IVR system. In such an arrangement the interaction with a standard IVR system on the handset network involves entering the 8-digit number of the handset user they seek when prompted, and recording the message when prompted. This message will be delivered to the handset user as a standard vmail.

Delivering voice messages to mobile phone users is suitably the same as delivery to any PSTN, and should prove simpler due to the increased functionality and flexibility that has been designed into these more recent networks.

The widely used mechanism for text messaging between mobile phones (SMS), is also a possible medium for communication between handset users and mobile phone subscribers. The handsets have a numeric keypad, which supports multi-tap text entry, or can be connected to a full-text-entry keypad in principle. The handset also has a small display for showing short text messages.

The voice message gateway described above is extendable to allow text message exchange with SMS users on the PLMN (Public Land Mobile Networks), fax machines, or telegram services. In the latter case, spoken voicemail messages are automatically or manually transcribed before delivery as a telegram. In the reverse path, incoming text messages to the gateway from PLMN/PSTN users can be delivered to the handset screen. Extensions to the bridge between the gateway and the PSTN to allow handset users to receive and send text emails can also be achieved.

Like voicemail and email, messages to mobile phone (SMS) addresses could be prefixed with a special character such as "*" or an "!". This would prompt forwarding to the SMS gateway, and address resolving. Once the address lookup has successfully resolved the "yyyy-zzzz" number to a mobile number, the gateway undertakes the following:

• compose an SMS header consisting of: o addressee mobile number o sender name o return SMS number o date / time

• compose the SMS body

• deliver the SMS message • catch and report any errors.

The addressee mobile number is resolved from a database. The sender's name can be easily picked up from the handset users' database, and will be added at the end of the SMS message. The return SMS number will be the number of the SMS gateway, which provides access to the handset network.

To construct the SMS text, the gateway could use a speech to text converter, but the recorded text is preferably very short (-120 characters to allow space for instructional reply text at the end). Once this is completed, the gateway can deliver the message to the handset-SMS gateway (or it can be delivered to an SMS gateway hosted by an external telecommunications company).

The SMS message received by the mobile user will arrive as any other SMS. However, like the voice message sent to the PSTN, the SMS response to a handset user is preferably addressed to an SMS gateway into the handset environment. The SMS may suitably be constructed to start with a code followed by the handset user's 8-digit number. Following this addressing, the message can be entered as normal. The SMS-to-handset gateway should be able to strip out the addressing information and deliver the message (via Text- to-speech converter if necessary) to the user's vmail inbox. Being able to exchange SMS brings the handset community into contact with those who have access to mobile phones. It is also possible to use PSTN services from the handset network. By extending the gateway mechanisms that enable the handset users to deliver voicemails to PSTN/PLMN users, it is possible for the handset users to utilise some of the many services that are available on the PSTN/PLMN networks. As described above, an automated dialling facility may dial a number on the PSTN and interact with a basic answer machine / voice message recording facility in order to leave a message.

For specific services on the PSTN, an "agent" is provided as a proxy for handset users, that is able to handle the synchronous interaction with a PSTN based service in order to provide the desired service to the handset user. One example of such a PSTN-based service is a network-based voicemail service that stores voice messages for an account holder who may be registered with the service but who does not necessarily have a telephone number (or phone) of their own, only an access number. The features available in such a service may be presented to the PSTN user via an IVR (Interactive Voice Response) system, with a well-defined menu hierarchy and stages of key input and spoken response. The PSTN service interface can be mapped to one or more VIMF programmes, which are available for the handset user to download. Offline playback and interaction with these programmes enables the handset user to complete a transaction. This is then processed automatically on the user's behalf with the real PSTN service, at a later time, after the user's responses have been uploaded to the system.

To build an agent that can undertake interactions with PSTN services on behalf of a handset user requires that the agent be customised and equipped with full knowledge of the IVR interactions to be presented by the service, the timings, and the range of valid responses. The validation of user responses to the eliciting VIMF program can be done at the time the user inputs are uploaded and checked by the system, but they might even be checked at the handset at the time of user-interaction (the VIMF language supports input range checking). When the gateway then dials out and interacts with the PSTN service, it only needs to ensure that the rendition of user responses are delivered at the appropriate point in the interaction (these might be DTMF tones to simulate key-presses, or spoken responses as captured from the user).

The series of transactions which enable the handset user to use a PSTN based service (such as "virtual voicemail") are as follows:

• PSTN service "virtual voicemail" access protocols are mapped to VIMF programme(s).

• Handset user registers a request to use a given PSTN service (e.g. "virtual voicemail").

• The system sends the handset user the VIMF programme for "virtual voicemail" (this contains prompts and "fields" to securely capture information from the user in order use their "virtual voicemail" service, e.g. PSTN account number and security code).

• The user plays back, and interacts with the VIMF programme, entering details as requested.

• VIMF programme will verbally present the available options that the user can select from as if he/she were using the "virtual voicemail" system on the PSTN directly.

• If the user completes the session successfully, when he next uploads his responses to the programme into the system, the agent will dialout and interact with the PSTN "virtual voicemail" service and perform the desired tasks. These tasks might include playback of PSTN voice messages, recording them for transfer as vmails to the handset user, deletion of old messages etc.

• The interactions with the VIMF programme may have to complete with the transaction partially completed, for instance if further interactions are needed with the user. In such a case, the agent will undertake the necessary exchanges with the PSTN-based "virtual voicemail" and get the next series of interactions for the handset user such that he may continue and complete his session.

An alternative approach for interoperating with PSTN voice boxes is via service actuation and authorisation profiles that the handset users have securely stored in the gateway database. For example, one user profile might activate the agent to regularly, at a frequency specified by the user, connect to their PSTN service, playback new stored messages, create vmails for the user for each message, and then delete all the stored PSTN messages from the PSTN mailbox. This simpler approach may be sufficient for many users. Users of the PSTN (or PLMN) may reply, with voice messages, to handset users by using a PSTN call back number to a gateway to the handset network, and then, using an IVR at that gateway to enter the 8-digit handset user address, the message may be left. PSTN-initiated voice-messages for handset users will follow a very similar process. The primary differences are that the PSTN user needs to know the handset user's unique address from the outset (unless there is a speech-recognition system at the gateway to derive the address in response to user names).

One advantage of having a single entry-point in the form of a special PSTN access number for PSTN-users to leave voice messages for handset users is that it is "transparent" to the other networks, having no special status or special behaviours.

A local PSTN-to-handset gateway for subscribers of that PSTN may provide the same function as the gateway for receiving voice-messages, in that it will offer an IVR to take a handset user's unique address, and take the message for them. However, it may be possible for the PSTN to provide a dial- code for the handset network that can be suffixed with the 8-digit address. This gives the handset network the same status as other (tandem) networks as far as the PSTN users are concerned. This will make it easy for PSTN users to dial and store frequent handset "numbers" for messaging. The most straightforward way in which to implement the gateway is to have it as a component of the handset infrastructure. In this way, the gateway is completely embedded in the system, and can exploit all the features and functions therein. However, being a node within the system means that such a gateway is remote from other networks such as the PSTN networks, and is simply a termination point as far as connections between these networks are concerned. As such, there is no privileged access to features or nodes that these other networks have to offer (i.e. interfaces to PSTN-based voicemail, or access to SMS Centre).

A second solution is to have a gateway counterpart located with each of the other networks, such that handset network is in some way a peer of these networks, and may be classed as a "Tandem" network, as has been done when other systems (such as GSM networks) have been interfaced to the PSTN. Moreover, with tandem network status, appropriate access may be possible for the handset system (with native protocols, e.g. SS7 to SMSC) to nodes of other networks as well as making the communication exchanges far more usable, probably far faster and more robust. Furthermore, conveying voice messages to networks that are inherently

IP based (i.e. 3G networks) will mean that less adaptation of the message is required. The MMS multimedia message structure (SMIL - Synchronized Media Integration Language) can be used to enable ready passage of voice messages to from the handset network to MMS enabled phones and networks, and this structure would enable voice messages to be combined with text and graphics.

For messages that will entail a PSTN phone call, the sender may be charged some premium for such a call out, as opposed to the normal charge for a vmail. Billing for messages sent to/from poor handset users may be adjusted, by negotiation, with the operator and government subsidy. As in most systems commonly used, the caller or message-sender is responsible for paying for the outgoing call or message. The handset user may be able to determine whether their message is delivered immediately (i.e. for an urgent message) or is delivered using a default schedule (possibly overnight, when PSTN charging is lower). Immediate delivery may incur a higher cost. Users of the PSTN network will be billed by their own operators for messages that are delivered to handset users. The infrastructure provides a mechanism for asynchronous exchange of spoken messages, vmails, using the Internet as a backbone between the various ITCs and RCCs. Like email and other message systems using the Internet, there is no difference in cost to the users whether they are local or on different continents. Given that it is possible to provide gateways to the handset network from other networks (i.e. PSTN) the infrastructure can be a mechanism to provide cheap long-distance asynchronous voice messaging to the general public.

Users (subscribers) can submit messages from their PSTN via a gateway to the network to the voice message handling system, which then passes the message to another remote gateway node of the network for transmission to a second PSTN network, delivering the message to the addressee. Furthermore, delivery of the voice-message could be scheduled at both ends to utilise local cheap-rate PSTN tariffs (i.e. evening/overnight) in the different time zones.

The system is focused upon enabling communication between users of a system that is inherently asynchronous and users of systems that are synchronous. Enabling users of the infrastructure to undertake exchanges outside the handset environment is the primary aim, but there is application for the many millions of PDA users who dock devices in order to synchronise programmed content, schedules and emails. The innovations described here may have application to PDA users who would prefer to answer phone messages in bulk, away from a phone. It is also suitable for those users who wish to respond to emails and SMS messages using voice - which is much faster than typing on a keyboard, a phone keypad, or touch-screen. Furthermore accessing phone messages, SMS texts and emails for action and response off-line enables more efficient use of time, and may be possible in situations where a phone cannot be used (for example on a plane).

Claims

1. A communication system comprising a gateway (20) and a plurality of docking stations (14, 16), each for receiving a device (10, 18), and each connected to the gateway (20), each docking station (14, 16) arranged to identify a received device (10, 18), to download voicemails from the gateway (20) to the received device (10, 18), and to upload voicemails from the received device (10, 18) to the gateway (20).

2. A system according to claim 1 , wherein the device (10) is a handset (10).

3. A system according to claim 1, wherein the device (18) is a data card (18).

4. A system according to claim 1, 2 or 3, wherein each docking station (14, 16) is further arranged to download programs to a device (10, 18) and to receive responses to those programs from the device (10, 18).

5. A system according to any preceding claim, wherein the gateway

(20) is arranged to receive messages in a format other than voicemail, and to convert those messages into voicemails.

6. A system according to any preceding claim, wherein the gateway (20) is further arranged to receive a voicemail from a device (10, 18), and to convert that message into a format other than voicemail.

7. A system according to any preceding claim, wherein the gateway (20) is further arranged to resolve the destination of the received voicemail, and to communicate with a server to deliver the voicemail.

8. A communication method comprising receiving a device (10, 18), identifying the received device (10, 18), downloading voicemails from a gateway (20) to the received device (10, 18) , and uploading voicemails from the received device (10, 18) to the gateway (20).

9. A method according to claim 8, wherein the device (10) is a handset (10).

10. A method according to claim 9, wherein the device (18) is a data card (18).

11. A method according to claim 8, 9 or 10, and further comprising downloading programs to a device (10, 18) and receiving responses to those programs from the device (10, 18).

12. A method according to any one of claims 8 to 11 , and further comprising receiving messages at the gateway (20) in a format other than voicemail, and converting those messages into voicemails.

13. A method according to any one of claims 8 to 12, and further comprising receiving a voicemail at the gateway (20) from a device (10, 18), and converting that message into a format other than voicemail.

14. A method according to any one of claims 8 to 13, and further comprising resolving the destination of the received voicemail at the gateway (20), and communicating with a server to deliver the voicemail.