GB2362540A - Accessing databases via the internet - Google Patents

Abstract

A computer system provides telephone access to an e-mail server over the Internet via a web server. Voice recognition mean converts speech input at a telephone into a call to the web server; web server program means responds to such call to cause the web server to access the e-mail server and access e-mail messages thereon; the web server generates response messages incorporating the e-mail messages; and text-to-speech conversion of the response messages produces corresponding voice messages to the telephone. The telephone is coupled to the Internet via a gateway, and the web server, in response to the first call thereto, transmits a gateway web page to the gateway, the gateway including the voice recognition means and the text-to-speech conversion means. The gateway web page preferably remains in the gateway on termination of the telephone access to the e-mail server and the gateway can respond to a plurality of simultaneous independent callers. The web server program means is a Java servlet which generates the gateway web page as a VML message.

Description

2362540 1 Accessing Databases via the Internet

Field Of The Invention

This invention relates to a computer system for providing telephone access to databases such as Internet mail. It also relates to a corresponding method, and to computer software for use in the system and method.

Background Of The Invention

E-mail and the Internet are both long-established. The Internet is a world-wide data network which provides access between a large number of computers or data processors coupled to it. E-mail has largely been developed as an Internet-based service. The basic principle of e-mail is that a computer coupled to the Internet can receive e-mail messages from any other computer on the Internet (provided that the computers concerned all have the appropriate software, of course). In its simplest form, this requires that the receiving computer must be permanently coupled to the Internet.

To deal with systems which are liable to have limited Internet access, email servers have been developed. A system sending an e-mail can send it to the server rather than the recipient (i.e. the intended final recipient); the server then stores the e-mail and the recipient can retrieve it from the server at a later time. The e-mail server is in effect a database unit dedicated to storing e-mails However, these standard arrangements still require the recipient to have a computer system which can be coupled to the Internet in the standard way, and cannot be used by someone who does not have such facilities to use e-mail.

2 The main object of the invention is to provide an extended e-mail facility to such users, and in particular, to users who have only telephone communication facilities rather than full data communication facilities.

Summary Of The Invention

According to one aspect, the present invention provides a computer system for providing telephone access to an Internet database, including: first conversion means for converting user input into a call to a web server, means responsive to such call to cause the web server to access a database server and retrieve a database message, means for causing the web server to generate a page in a non-HTML format incorporating the database message, and second conversion means for interpreting the non-HTML page to produce a corresponding message to the user.

In a preferred form, the non-HTML format is a VIML format, the database server is an e-mail server, and the conversion means comprise means for interpreting the VML page as a voice message and a telephone to which the voice message is transmitted. However, the invention is also applicable to systems in which the user communicates with the web server by other means such as mobile telephones operating with a WMI, (Wireless Mark Up) language.

More specifically, the invention provides a computer system for providing telephone access to an e-mail server over the Internet via a web server. Voice recognition mean converts' speech input at a telephone into a call to the web server; web server program means responds to such call to cause the web server to access the e-mail server and access e-mail messages thereon; the web server generates response messages incorporating the e-mail messages; and text-to-speech 3 conversion of the response messages produces corresponding voice messages to the telephone.

Preferably, the telephone is coupled to the Internet via a gateway, and the web server, in response to the first call thereto, transmits a gateway web page to the gateway, the gateway including the voice recognition means and the text-tospeech conversion means.

Preferably, the web server program means is a Java servlet which generates the gateway web page as a VML message.

The invention also provides a method of accessing e-mail from an e-mail server via a web server over the Internet by telephone, and a web page computer program for a web server for providing such access.

The method of accessing Internet e-mail by telephone comprises converting speech input at the telephone into a call to a web server, causing the web server to access an e-mail server and retrieve an e-mail message in response to such call, causing the web server to generate a WL page incorporating the e-mail message, interpreting the WL page to produce a corresponding voice message, and transmitting the voice message to the telephone.

The program comprises a computer-readable medium bearing computer program code to cause a web server to access an e mail server and retrieve an email message in response to a call to the web server, and to cause the web server to generate a VML page incorporating the e-mail message.

As used herein, IIVML" is an abbreviation for Voice Markup Language, which is any computer language which can be used to create web content and services that can be accessed by voice. A particular example, used in the embodiment of the 4 present invention, is Motorola's VoxML voice mark-up language, but the invention is not limited thereto.

An advantage of the invention is that it enables the access to any e-mail system from any telephone using voice commands. This assists non-PC users by providing them with the advantages and facilities of e-mail without the necessity of acquiring a PC. It also benefits existing e-mail users by providing them with access to their e-mail accounts in situations where it is not always convenient to use a PC, such as during travel.

Detailed Description Of Preferred Embodiments

Brief List Of Drawings A computer system embodying the invention will now be described by way of example and with reference to the accompanying drawings, in which:

Fig. 1 is a general block diagram of the computer system; Fig. 1A is a more detailed block diagram of the voice gateway; Fig. 2 shows the sequence of events leading to the launch of the Application on the web server of Fig. 1; Fig. 3 shows the same sequence of events as a flow diagram; Fig. 4 shows the flow of information between the user, the Application, and the gateway in the user verification procedures; Figs. 5 and 6 show the procedures of Fig. 4 as a flow diagram; Fig. 7 shows the flow of information occurring when the Application interacts with a user's mail-server to enable the user to log-on; Fig. 8 shows the same processes as a flow diagram; Fig. 9 shows the flow of information occurring which allows the user to hear their e-mails in audio form; Fig. 10 shows the same process as a flow diagram; Fig. 11 shows the flow of information which occurs during the process of sending an e-mail; FiQ. 12 shows the same process as a flow diagram; Figs. 1317 are object interaction graphs showing method flows for various operations of the Application; and Fig. 1-8 shows the logical organization of the Application- The Internet and the Web The present system is an Internet and Webbased system. These may be summarized for present purposes as follows.

The Internet is a network which provides access between computers coupled to it. The Web (or World Wide Web) is a system supported by the Internet in which computers (termed Web servers) provide specific on-line services to client computers, typically running browser programs. Each service is known as a web site (large organisations may have their own web servers and web sites; smaller companies may hire space on web servers provided by Internet service providers.) A domain name, for example, www.yahoo.com locates an organization or other entity on the Internet. The domain name is mapped by a domain name server (DNS) (at an Internet Protocol (IP) address known to a browser program running on the client computer) to an IP address, usually represented as a dotted quad address in the form ddd.ddd.ddd.ddd, where ddd is between 0 and 255, representing a physical point on the Lnternet.

A web site is usually organized as a number of pages. The 6 initial access to a web site reaches what is known as the home page; this may provide access to further pages on the web site, other web sites, and further Internet services such as mail servers. (Such a mail server is a computer for receiving and forwarding e-mails and connected to the Internet.) Files, such as web pages or multi-media files, stored on the Internet are identified by Universal Resource Locators (URLs). A URL contains:

the name of the protocol required to access the resource, for example, http (Hyper Text Transfer Protocol) or ftp (File Transfer Protocol); 0 0 a domain name that identifies a specific computer on the Internet, for example, www.yahoo.com; and a hierarchical description of a file location on the computer, for example, /stock/index.html, indicating a file 'index.htm11 stored in a '/stock, sub-directory, so making the URL http://www.yahoo. com/stock/index.html.

Messages are typically sent over the Web using the HTTP protocol comprising a http request from a client computer at one IP address to a server at another IP address and a http response from the server to the client. The request typically contains a URL whereas the response contains a file stored at the URL. More recently, however, further protocols such as WAP (Wireless Application Protocol) have been developed to enable mobile devices, such as phones, personal digital assistants (PDA) to access the Internet more easily.

In addition to direct access to the Internet by computers directly coupled to it, access can also be gained from a variety of other communication systems and networks via gateways. Such a gateway is a computer which interfaces between the Internet and the other communication system, such as a PSTN (public service telephone network) telephone system, 7 GSM (Global System for Mobile communication), other private telephone system or even cable network. The gateway converts the signals bQtween the protocols of the two systems, and provides and performs any further processing required to achieve the desired communication between the telephone system and the Internet.

A standard document format used by web pages is HTML (Hyper Text Mark-up Language). Not all pages are static HTML files stored in directories awaiting retrieval. More and more pages are generated dynamically according to specific requests made by specific users, for example, to generate quotes for a portfolio of stocks held by a user.

In such cases, a gateway program is usually instantiated in response to a HTTP request from a client computer. This program executes to retrieve data and generate a HTML page which is then returned to the user as a HTTP response. One convention used for this purpose is CGI (Common Gateway Interface), which is supported by virtually all web servers. CGI programs can be developed in virtually any such language so that, when using this convention, a user selects a URL, which is usually of the form, http://domain namelcgibinIprogram name, the Web server typically passes the URL to the application program which processes the data and generates the response.

More recently, the Java language and system has been developed as an alternative to CGI systems. A feature of Java is that it uses what are termed applets and servlets, which are respectively small. application modules, which can be downloaded from a web site to run on a Java Virtual Machine (JVM) on a client computer, and server modules which run on the server. The proportion of web servers capable of supporting Java is rising and is already high.

8 The system (Figs. 1 and IA) Referring first to Fig. 1, the computer system for providing telephone access to Internet mail comprises a Javaenabled web server 10, a voice gateway 12, and a software program 14, herein called the "Application", resident on the web server 10 and having an associated database 16 of user profiles including User Ids and passwords and the necessary user email account details, contact details etc. The logical organization of the Application will be described later.

For convenience in describing the operation of the system, Fig. 1 also shows a telephone 18 connected (through a PSTN, not shown) to the gateway 12 and a mail server 20 coupled via the Internet to the.web server 10, although the telephone, PSTN, and mail server are not part of the system per se. The system will be described with reference to the use of the telephone 18 to access the mail server 20.

As shown in Fig. 1A, the voice gateway 12 contains a voice recognition unit 22, a text-to-speech unit 24 containing appropriate text-to-speech conversion software, and a control unit 26 containing VML interpretation software. The gateway used in the present system is the Motorola VoxML gateway.

The Application 14 is a web-server plug-in, accessible using HTTP calls, which generates Voice Mark-up Language (VML) and is based on Java Servlet technology. In the present system, which uses the Motorola gateway, the Application is based on the VoxML/VoiceXML specifications. (VML is broadly similar to HTML, but controls voice signals rather than text signals.)

The Application 14 operates by managing the interactions 9 and communications between the gateway 12, the web-server 10 and an e- mail server 20, to provide a user with voice-based control of their e- mail accounts. The interaction between these three subsystems and the user is based on the dynamic 5 generation of VoxML/VoiceXML pages.

The design and operation of the Application 14, as well as the function and design of the overall system, will now be described by following the sequence of events which occur during use of the system.

1. Logging On to the Application This involves two procedures: launching the Application (1A) and user verification (1B).

1A. Launching the Application (Fig. 2) Fig. 2 shows the sequence of events leading to the launch of the Application in terms of the information flows between the user, the gateway and the Application. Fig. 3 shows the same sequence of events as a flow diagram. The process steps are as follows:

Step 1-1: The user phones the gateway, from a land line or mobile phone.

Step 1-2: The gateway makes an H= call to a URL, which returns the entry/home WL page of the Application. This page welcomes the user to the system and consists of a static web page.

Step 1-3: The static WL web page is passed to the gateway by the webserver.

Step 1-4: The gateway interprets the WL web page and generates the corresponding voice-based welcome message, which is transmitted to the user through the telephone speaker.

Sr-ep 1-5: The gateway then makes a call to the URL for the 5 Application, in effect starting the Application.

1B. User Verification (Figs. 4 to 6) Prom this point on, all the VML web pages are generated dynamically, that is to say, on demand and according to circumstances.

This section describes the user verification procedures employed by the Application and how they are implemented. User verification involves two separate security screening procedures, the first of which requires the user to enter a user ID, and the second of which requires that the user to enter a password.

Fig, 4 shows the flow of information between the user, the Application and the gateway in the user verification procedures. Figs. 5 and 6 show these procedures as flow diagrams; Fig. 5 focuses on the user's entry of their ID and password, and Fig. 6 focuses on the verification of both entries. The process steps are as follows (the step numbering continues on directly from section 1A, since these steps described in this section reflect the normal progression of the software from the steps described in section la):

Step 16: The Application dynamically generates the VML log-on. page as the result of the previous call and returns it to the gateway.

Step 1-7: The gateway interprets the VML page and converts the appropriate prompts to a voice-based message.

11 Step 1-8: The message is transmitted to the user through the telephone speaker and requests the user to enter their user ID.

Step 1-9: The user enters their ID, either by voice or by a touch-tone sequence.

Step 1-10: The gateway interprets the ID and converts it to textual form, which is sent to the web-server as a parameter of the secure HTTP call to the URL of the Application.

Step 1-11: The Application generates as a response a WL page which prompts the user for a password, and passes the page to the gateway.

Step 1-12: The gateway interprets the WL page and converts it into a voice-based message.

Step 1-13: The!'Enter password" message is transmitted to the user through the telephone speaker.

Step 1-14: The user enters their password.

Step 1-15: The gateway converts the password to a textual form which is sent as a parameter of a secure HTTP call to the Application.

Step 1-16: The Application checks the records of the database 16 whether both the user ID and the password are correct (i.e.

whether the user ID exists and the password matches the ID).

Step 1-17A: If either the ID or the password is incorrect, the Application generates a WL page as its response; this page is sent to the gateway, which thereupon prompts the user to re enter the incorrect ID or password. The Application allows this error a total of three times before generating a "Sorry, 12 Log-on Faile& VML page.

Step 1-173: If the ID/Password combination is correct, the user is considered to be logged onto the Application.

2.

Logging onto an E-mail Server (Fig. 7) As a part of the registration, the user supplies the email accounts they wish to access using this system. They can also create an address book, which contains contacts which can be used by the user to send/forward new e-mails. Moreover, users can define options of the service like speed, volume, change password, etc.

Fig. 7 shows the flow of information occurring when the Application interacts with a user's mail-server to enable the user to log-on; Fig. 8 shows the same processes as a flow diagram. The process steps are as follows:

Steps 2-1 and 2-2: When the user has successfully logged on to the Application, information relating to the number of email accounts the user owns and their locations (i.e. addresses of corresponding mail- servers), along with the user's address books, is retrieved from the Application database.

Step 2-3A: If the user has more than one e-mail account, the Application generates a dynamic VML page as a response to the last call (see step 1-17A/B, Section 1B) requesting the user to indicate which e-mail account they wish to access. On. successful selection of an account, the Application works as described in step 2-3B. Alternatively, if the user has just one e-mail account, the Application proceeds directly to step 2-3B.

Step 2-3B: The Application goes to the mail-server on 13 which the e-mail account is resident and enquires from the mail-server whether or not the user has any e-mails. The Application generates a WL page indicating the number of emails the user has, with menu options such as Read Emails, Send New E-mail, etc. This page constitutes the response of the previous H= call to the Application (see step 1-17A/B, Section 1B).

Step 24: The gateway interprets the WL page and generates the corresponding voice-based message to the user through the telephone.

Step 2-5: The user chooses and enters their required activity option (spoken or touch tone).

Step 2-6: The gateway converts the voice based user entry into a textual form, evaluates the user's entry, and matches it to the list of available options (as contained in the VMI, page). If the entry corresponds to a valid option, it is sent to the web-server as a parameter of the H= call to the URL of the Application.

Step 2-7: The Application then performs the requested action/option and generates the appropriate VML page as a response and passes that page to the gateway.

Reading an E-mail (Figs. 9 and 10) Figs. 9 and 10 show the sequence of events that allow the user to hear their E-mails in audio form. Fig. 9 shows these processes from the perspective of the flow of information between the user, the gateway, the Application and the user's mail-server; Fig. 10 shows the same sequence of events as a flow diagram.

Step 3-1: If the user selects the "Read e-mails,' option, the 14 Application requests the first e-mail from the user's mail server. At this point the Application deals with the inquiry in different ways depending on the mail server type, such as POP3 (Post office Protocol, version 3) or IMAP4 (Internet Mail Access Protocol, version 4). All communication between the Application and mail server(s) is accomplished using a layer developed within the Application architecture using the Sun JavaMail APIs.

Step 3-2: The mail server returns the e-mail in a textual form to the Application, where it is cached.

Step 3-3: The Application wraps the e-mail in VML and returns the resulting VML page to the gateway. Preferably, the application uses a predefined Voice User Interface (VUI) template to generate the VML page with the appropriate email header details, such as subject, date, originator.

Step 3-4: The gateway interprets the VML page and converts the e-mail header (i.e. the originator/subject/date information) into an audio message transmitted to the user through the telephone.

Step 3-5: The user is then provided with options, such as "next" (for the next e-mail) and "read" to play the actual contents of the message.

Step 3-6: If the user selects the "read" option by voice, then it is sent to the web-server as a parameter of an HTTP call to the URL of the Application.

Step 37: In response, the Application generates a VIMI, page which contains the e-mail message contents.

Step 3-8: The gateway then interprets the VML page containing the e-mail message contents, using Text-To-Speech technology.

4. Sending an E-mail (Figs. 11 and 12) Figs. 11 and 12 show the sequence of events that allow the user to send their e-mails in audio form. Fig. 11 shows the flow of information between the user, the gateway, the Application and the user's mail-server which occurs during the process of sending an e-mail; Fig. 12 shows the same processes as a flow diagram. The process steps are as follows:

Step 4-1: If the user selects the "New,, option, the response generated by the Application is a WL page which contains the appropriate commands for requesting the recipient's address and the record message prompt; it also contains the nicknames/contacts in the user's address book.

Step 4-2: The gateway interprets the VML page as an audio message and transmits it to the user through the telephone.

Step 4-3: In response to the prompt, the user enters details of their desired address. Alternatively, the user says the nickname of one of their contacts in their address book; the gateway checks this for validity against those contained in the WL page.

Step 4-4: The gateway now prompts the user for the body of the e-mail message, which is spoken by the user through the phone and passed to the gateway.

Step 4-5: The gateway can either convert the message to a textual form or record the message as an audio file (file extension type WAV). In either case, the resulting information (the recipient's address and the message) is then sent to the Application as parameters of an H= call to the URL of the Application.

16 Step 4-6: If the information transmitted to the Application is in the form of an audio file.. the Application generates the email with the audio-fiie as an attachment which is then transmitted to the recipient's email address and therefore the recipients mail-server using the SMTP protocol.

The Application (Figs. 13-18) To launch the application, the VML home page is loaded; his page contains the URL and the command necessary to complete the launch, which involves requesting the HTTP Application ServIet to initiate the application. Table I is an exemplary VML home page with the name of top.vml; this is loaded by the Voice Browser instance by reading http://www.?.com/top.vml.

Table I <?xml version=111.011?> <DIALOG> <STEP NAME=11init11> <PROMPT> Welcome to Email </PROMPT> <INPUT TYPE = "NONE" NEXT=Ilhttp://www.?.com/servlet/VxsApplicationServlet?Action=In itiate" </INPUT> </STEP> </DIALOG> The Voice Browser instance, using Text to Speech, reads the text between the Prompt tag, so that the caller hears "Welcome to Email" in a synthesized voice. The Voice Browser then interprets the next command - an HTTP call to the URL of 1 the application servleti with a parameter called "Action,' that has a value of "Initiate".

When making HTTP requests to Web Servers, the most frequently used methods are GET and POST. In the Application, the VxsApplicationServlet Java class is a subclass of javax.servlet.http.HttpServlet and overrides both the doPosto to handle POST requests and doGeto to handle GET requests methods. (All Java classes designed/created for the Application are prefixed with Vxs for identification.) Figure 13 is an object interaction graph showing the method flow for this request. Step 13-1 shows the creation of the appropriate event from the value of the "Action" parameter. To start the application, this value is "Initiate". The Class VxsEvent is delegated the responsibility to read the "Action" value from HTTP request stream and instantiate the correct event type - in this case an initiate event. Step 13-2 shows the creation of an HttpSession, the unique session allocated between the Voice Browser and the application servlet by the Web Server, which is used for the duration of the call.

Step 13-3 involves the instantiation of a VxsCall object, which represents the physical call in the system. Within this step the VxsCall instance gets associated to the HttpSession, ensuring session tracking functionality. Fig. 14 shows this in more detail.

The application has so far instantiated a VxsCall object and HttpSession object for the caller. Step 13-4 shows the application servlet requesting the VxsCall object to process the "Initiate" event. Figure 15 expands on Step 13-4. By design, a VxsCall cannot process the event directly; instead, it delegates this responsibility to a VxsCallProcess type. However, the system has no current process activated, as we 18 are essentially launching the application. Uniquely in its life cycle, the VxsCall is responsible for creating the appropriate launch process and setting it to be the current process of the system.

Returning to Fig. 13, the first process to be launched in the application is a VxsCallProcessLogin. After instantiating a VxsCallProcessLogin object, the processEvento method determines how to proceed. In this case, the associated Voice User Interface (VUI) object is instantiated. A VxsVYILWILogin object is created, and effectively returned to the VxsApplicationServlet, because it is the last command executed within Step 13-4 of Figure 13. A WI object is essentially the template used in the Application for representing information in a Voice Mark Up page.

So far the application servlet has processed the HTTP request from the Voice Browser, to the point of determining the VUI necessary as its response. To complete the request, the application servlet requests the voice representation from the VUI object (Step 13-5). The voice representation is a string containing VML code, which constitutes the next VML page. The application servIet uses this string as its response. The final step in Figure 13 is step 13-6, where the application servlet writes its response to the httpServletResponse stream, and so returns the VML page shown in Table II to the Voice Browser.

Table II <?xml version=111.011?> <DIALOG> <STEP NAME="init"> <PROMPT> Please enter user ID </PROMPT> <INPUT TYPE = "DIGITS" NAME="ID" NEXT=Ilhttp://www.?.com/servlet/VxsApplicationServlet 11 19 </INPUT> </STEP> </DIALOG> Table II shows a typical Login page. The tags in this page allow the user to either enter an ID using spoken numbers (e.g. "one" followed by "two" for 111211) or using DTMF tones.

once the user has entered/spoken their ID, the next HTTP request made to the Application includes the ID value. The flow of this request andsubsequent requests is shown in Figure 16. No new HttpSession instance is created; the session is read from the HTTP request stream, and as a result of using HttpSession tracking capabilities (Fig. 14), the associated VxsCall instance can he retrieved (Step 16-3.1).

There are close similarities between the start up/launch procedures (Figure 13) and subsequent requests (Figure 16). The main differences between these two procedures are that in subsequent requests, no new HttpSession instance is created, no new VxsCall instance is created, and VxsCall does not create a VxsProcess.

The Application may be regarded to some extent as consisting of a Java application together with a Java servlet.

It will be noted that the servlet, as shown in Figs. 13 and 16, is extremely simple, and consists essentially only of means for interfacing between the Java application and the web server environment on which the Application runs. It therefore provides a means for the application to be HTTP enabled.

The current process, which determines the current status of the Application, is cached on the VxsCall instance (Step 16-4.1). This process determines what to do next by evaluating the VxsEvent type (Step 16-4.2). A VxsProcess can be responsible for selecting one or more VUIs or launch a new VxsProcess, depending on the event type. Fig. 17 shows in more detail the return of a VUI object by VxsProcessReviewMessage for a Read VxsEvent type.

Navigation of the system is therefore achieved by user voice/DTMF input. This input gets interpreted and sent as an HTTP request by the Voice Browser component, to the application. The application reads the HTTP request parameters and represents them as event types. These event types determine what action the application must perform the result of which must be an HTTP response containing a VML page. For example, a user can browse the next e- mail by saying "next". The application then instantiates the appropriate VxsEvent object. VxsCall then delegates the VxsEvent type to its current VxsCallProcess, which as a result also creates the appropriate Voice User Interface.

Fig. 18 shows the logical organization of the modules of -)0 the Application. The top module is the VxsApplicationServlet 30, which exists as a single object instance (indicated by the 1,111 against it) for all users. This is copied into the gateway when the Application is first called. This is coupled to a VxsCall instance module 32 in the VML page in the web server by an HTTPSession identifier. As the user becomes identified, the VxsCall module is coupled to a VxsUser object module 34 for the user which represents all user profile information such as e-mail account information and application-specific preferences; there is a separate VxsUser object for each user.

Each VxsUser module 34 is coupled to a VxsEmailMessage module 36 or, if the user has specific e-mail accounts, to the appropriate number of VxsEmailMessage modules 36 through a corresponding set of VxsEmailAccount modules 38.

Navigation through the Application is achieved by correlating user actions and options with application events.

21 For example, if a user wants to browse the next message by saying "Next", the VxsCall module will instantiate the appropriate VxsEvent object in the VxsEvent module 40. The VxsCall module 32 then delegates control to the current VxsCallProcess module 42. This module determines whether the event is a valid option, and if it is, launches a new VxsCallProcess type (which as a result also creates a new VUI (Voice User Interface) object VxsV= 44). A VUI is essentially a template for representing information for a VML page.

The result of the current VxsCallProcess processing an event is an appropriate VUI for the action or option choice of the user. To return the VUI to the gateway and therefore the user, the VxsCall module causes the VUI to represent itself in the appropriate VML language. The result is entered in the H= response stream, which the gateway then interprets as the next VML page.

When a VUI is requested to represent itself in the appropriate VML language, the translator used is a VxsVm1Translator module 46. The translators are used to make the VUIs language-independent, so that the Application can easily be converted to a different VML merely by providing the appropriate translator class.

Alternatively, Document Object Models (DOM) could be used to represent the static parts of the particular mark up language user interface (in this case VoxML and VoiceXML).

DOMs allow static pages to be created with markers for placing the dynamic content. Therefore when a VUI is created, the markers are replaced with the appropriate dynamic content.

General 22 The above description has focussed primarily on a single user using the system to gain access through a single gateway to a web server and thence to a single e-mail server. If another user initiates a voice-access e- mail session before the first user's session has been terminated, the second user will gain access to that same VML home page in the gateway. If several users want sessions at the same time, the single VML home page will handle all the users.

There may be several distinct telephone systems which have respective gateways to the Internet. In this situation, each gateway will of course operate independently, and each will store its own copy of the VML home page. The web server will be in communication with all the gateways.

The web server may of course be coupled to several different e-mail servers. Each caller, when calling the web server, will then identify the particular e-mail server which they want.

A user may want to return to an e-mail they have already read. It is therefore desirable to cache emails in the system once they have been retrieved from the e-mail server. This will allow faster access in such circumstances. It may also be desirable to cache the VML representation strings (VML pages) of the WIs, so that they do not need to be constructed repeatedly. This will reduce the processing required for initialization and improve performance. Such caching, of both e-mails and VML pages, can be done conventionally.

Although the invention has been described with reference to a particular embodiment thereof which uses the Motorola gateway and the VoxML specification of a voice Mark-up Language, any gateway that has a VML interpreter (VoiceXML,

VoxML or otherwise) can be used in the invention. Similarly, although the invention has been described with reference to a 23 particular embodiment thereof which uses an e-mail database server and provides access to e-mails, it can equally be applied to any similar database system.

The invention is not limited to the embodiments described herein, which may be modified or varied without departing from the scope of the invention.

24

Claims (18)

Claims

1 A computer system for providing telephone access to an internet database, including:

first conversion means for converting user input into a call to a web server, means responsive to such call to cause the web server to access a database server and retrieve a database message, means for causing the web server to generate a page in a nonHTML format incorporating the database message, and second conversion means for interpreting the non-HTML page to produce a corresponding message to the user.

is

2 A computer system according to claim 1 wherein the nonHTML format is a WL format, the database server is an e-mail server, the first conversion means comprise voice recognition means for converting speech input at a telephone into a call to the web server, and the second conversion means comprise textto-speech conversion means for interpreting nonHTML pages to produce corresponding voice messages and a telephone to which the voice message is transmitted.

3 A computer system according to claim 1 including a gateway through which the telephone is coupled to the Internet, and wherein the web server, in response to the first call thereto, transmits a gateway web page to the gateway, the gateway including the voice recognition means and the text-to30 speech conversion means.

4 A computer system according to claim 3 wherein the gateway web page remains in the gateway on termination of the telephone access to the email server.

A computer system according to claim 3 wherein the gateway can respond to a plurality of simultaneous independent callers.

6 A computer system according to claim 5 wherein the web server program means generates the gateway web page as a VML message.

7 A computer system according to claim 6 wherein the web server program means is a Java servlet.

8 A method of accessing e-mail from an e-mail server via a web server over the Internet by telephone, comprising: converting speech input at a telephone into a call to the web server; causing the web server to respond to such call to access the e- mail server and access e-mail messages thereon; causing the web server to generate response messages incorporating the e-mail messages; and converting the response messages to speech produce corresponding voice messages to the telephone.

9 A method according to claim 8 wherein the telephone is coupled to the Internet via a gateway, the method comprising causing the web server, in response to the first call thereto, to transmit a gateway web page to the gateway, the gateway including means for voice recognition and means for text-tospeech conversion.

10 A method according to claim 9 wherein. the gateway web page remains in the gateway on termination of the telephone access to the e-mail server.

11 A method according to claim 9 wherein the gateway can respond to a plurality of simultaneous independent callers.

26

12 A method according to claim 11 wherein the response message is a VML message.

13 A web page computer program for a web server, the program comprising means for causing a web server to access an e-mail server and access an e-mail messages thereon in response to a voice call from a telephone to the web server, and to convert messages into voice form and pass the messages in to the telephone.

the e-mail voice form

14 A program according to claim 13 including means for transmitting, in response to the first call thereto, a gateway web page to a gateway located intermediate between the web server and the telephone, the gateway including voice recognition means and text-to-speech conversion means.

is A program according to claim 14 wherein the gateway can respond to a plurality of simultaneous independent callers.

16 A program according to claim 15 including means for generating the response message as a VML message.

17 A program according to claim 16 wherein the program is a Java servlet.

18 A method of accessing data from a database server via a web server over the Internet by n6n-HTML format, comprising: converting a non-HTML request from a user into an HTML call to the web server; causing the web server to respond to such call to access the database server and access data thereon; causing the web server to generate response messages incorporating the data; and converting the response messages to non-HTML format to produce corresponding messages to the user.