A DATA ACCESS SYSTEM AND METHOD

Abstract: A data access system, including an interface for connecting to a caller using a voice call path, a call flow module for receiving a request for data from the caller on the call path, and a page translator for sending the request to a location in a communications network determined by the request, the location including the data in a prompt navigation language. The page translator receives and translates the data in the prompt navigation language into voice data, and the call flow module, with a text to speech converter, converts the voice data to voice for the caller on the call path. The system provides a voice browser for standard telephone users to access data on communications networks, such as the Internet.

Description: A DATA ACCESS SYSTEM AND METHOD The present invention relates to a data access system and method, and a voice browser. The Internet provides access to information and data resources on a scale which is unprecedented. The resources however are primarily limited to individuals who have access to a computer system with appropriate communications equipment and software that enables the system to connect to the Internet. For this reason the media continually refers to a current divide between the information rich and the information poor, being those who have access to the Internet and those do not. One way of addressing this divide and facilitate wider access to individuals is to move away from requiring the access system to comprise the traditional computer system. One line of development has focused on providing an access system which includes a telephone interface and voice browser software on a server connected to the Internet. The telephone interface allows any person with a telephone to call the server and respond to voice prompts issued by the server by pressing keys of the telephone to forward the corresponding dual tone multifrequency (DTMF) signals for the server. The DTMF responses received by the server are used to instruct the voice browser to access World Wide Web pages from the Internet. The voice browser on receiving web pages encoded in hypertext markup language (HTML) includes translation software to deconstruct the pages into voice data which is used to provide voice signals for the caller. There are however significant difficulties and problems associated with the translation of HTML pages into appropriate voice data for a caller. Whilst the text of a HTML page can be directly translated into voice data considerable difficulties are associated with the other data elements of a HTML page. HTML is a language which is designed to provide a visual display on a computer screen, and accordingly the various display elements cannot be correctly dealt with, if at all, by the translation software of the voice browser. The various video and image formats, such as MPEG and JPEG, cannot be translated. Also a number of web sites utilise frames and tables in their HTML code which also gives rise to significant difficulties and complexity for the voice browser. The tendency for HTML pages is to include more and more visual elements, such as video and images, to attract users and this gives rise to significant difficulties for a voice browser. A separate, independent, line of development is based on the work of the wireless application protocol (WAP) forum which is described at http://www.wapforum.org. The forum and WAP is concerned with the delivery of data on a wireless network and, in particular, the ability of wireless devices, such as mobile telephones, to access data resources, such as those available on the Internet. The WAP protocol is used by microbrowsers stored on wireless devices to access data information encoded in a particular format for the WAP protocol, such as the wireless markup language (WML). WML is a content language specifically developed for wireless devices with limited text displays and which use prompt driven navigation to display text and command menus. WML therefore allows delivery of text which can be selected and requested using displayed prompts and the keys of a wireless device. Details concerning WAP and WML are available at http://www.wapforum.org. A similar protocol and language for delivery of content to wireless devices has been developed by Unwired Planet, Inc. (now known as Phone.com, Inc.) of California and details concerning their handheld device transport protocol (HDTP) and their handheld device markup language (HDML) are available at http://www.uplanet.com (http://www.phone.com). HDML breaks text to be displayed on a wireless device into cards which can be moved between one another by selecting "accept" or "previous" keys on a handheld device. Soft keys are also available for inclusion in the cards to navigate between different cards based on display prompts. Data can also be keyed in on the wireless device in response to a received prompt and forwarded back to a HDTP server. Whilst the work of the WAP forum and Unwired Planet is a significant advance, access to the content still requires a person to have access to a wireless device, such as a mobile phone, which includes a microbrowser that can request and display content encoded in WML or HDML. In accordance with the present invention there is provided a data access method, including: connecting to a caller using a voice call path; receiving a request for data from said caller on said call path; sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; receiving and translating said data in said prompt navigation language into voice data; and converting said voice data to voice for said caller on said call path. The present invention also provides a data access system, including: means for connecting to a caller using a voice call path; means for receiving a request for data from said caller on said call path; means for sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; means for receiving and translating said data in said prompt navigation language into voice data; and means for converting said voice data to voice for said caller on said call path. The present invention also provides a voice browser stored on a computer readable storage medium, including: code for receiving a request for data from a user; code for sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; code for receiving and translating said data in said prompt navigation language into voice data; and code for converting said voice data to voice for said user. In the context of the specification, a "prompt navigation language" is a content language, such as WML or HDML, which includes text data followed by link data or prompt data, without visual layout data. A preferred embodiment of the present invention is hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of a data access system with a voice browser; Figure 2 is a flow diagram of steps executed by a call flow module of the system; and Figure 3 is a flow diagram of steps executed by a page translator of the system. A data access system, as shown in Figure 1, includes an interactive voice response (IVR) platform 2 having a call flow module 8, a page translator module 10 and a text to speech module 16 stored on the platform. The IVR 2 also includes a telecommunications interface 18 for terminating calls received from a caller using a voice terminal 4, such as a standard telephone, so as to complete and connect to a communications path 20 between the caller 4 and the IVR 2. The IVR 2 also has an ISDN interface 22 to provide a permanent ISDN primary rate connection 24 to the Internet 12. The IVR 2 is a standard IVR platform which includes the interfaces 18 and 22 and the text to speech module 16. The IVR may, for example, be the First Contact IVR produced by Scitec. The text to speech module 16 may be the Learnout and Hauspie Tru Voice module. The Internet 12 includes at least one server 14 which is able to communicate with the page translator 10 using a standard protocol, such as HTTP, and stores prompt navigation language data, such as WML or HDML data. The modules 8, 10 and 16 and the interfaces 18 and 22 provide a voice browser for use by a caller 4. The modules 8, 10 and 16 are preferably implemented by computer programs, but can be implemented entirely or partly by hardware circuits, such as an ASIC, and may also be distributed over different communicating systems, as would be understood by those skilled in the art. The call flow module 8 executes the steps described below with reference to Figure 2. When a caller 4 makes a call to the IVR 2 the module 8 uses the line interface 18 to establish a call with the caller 4 and connect to and complete the call path 20 at step 30. The call flow module may await receipt of an identifying pin or security password to determine that the caller is authorised before proceeding to step 32. At step 32 the module 8 initialises a session with the page translator module 10 by forwarding an initialising message to the translator module 10. In response, call flow 8 will receive a default home universal resource locator (URL) from the translator 10 at step 34, which is stored for the caller 4. Call flow 8 then instructs the translator 10 at step 36, to access and download the data of the page at the location on the Internet 12 designated by the stored URL. Call flow 8 forwards the URL in a get page message, and the translator 10 obtains the page which is deconstructs into a number of data elements. In response to the get page message, the translator 10 returns to the call flow module a total number of elements for the page. Call flow 8 sets an element number count el num to 0 at step 38. It then determines at step 40 whether the final or total element number has been exceeded for the currently requested page. This condition is a trap for an error and will normally always return false. If it returns true and the final number is exceeded operation returns to step 34, otherwise operation proceeds to step 42. At step 42, the call flow module 8 instructs the translator 10, using a get element message, to obtain the element el num of the page. The translator 10 returns the data element and the text string of the element is forwarded, at step 44, to the text to speech module 16 for conversion into corresponding voice which is placed on the call path 20 for the caller 4 via the interface 18. The text strings of the data elements comprise voice data produced for the call flow module 8 by the translator 10. The call flow module 8, at step 46, determines whether the element el num includes a prompt requiring return of a digit. If it does, operation proceeds to step 48 where voice delivery is halted and a prompt provided for entry of a single key press by the caller 4. The caller 4 then needs to press a key on the caller's terminal 4 connected to the path 20 so as to forward a DTMF signal corresponding to the key pressed to the call flow module 8 via the interface 18. The module 8 receives the signal corresponding to the single key press at step 50 which is returned in a get link message, at step 60, to the translator 10. The translator 10 responds to the get link message by returning a URL to the call flow module 8 which is received at step 62. The URL returned by the translator 10 is checked at step 64 to determine whether a null URL has been returned, in which case the existing page continues to be announced to the caller 4, as the call flow module proceeds to step 58. If the URL is not a null, then it is stored by the call flow module 8 at step 66 and operation returns to step 36 to download the page corresponding to the new URL. If the element el num does not include a digit prompt, operation proceeds to step 52 to determine whether the element has a string prompt. A string prompt is one which calls for data entry by the caller so if the prompt is included in the element operation proceeds to step 54, where announcement to the caller is halted to await a sequence of key presses to be entered. The prompt will ask the user to enter the data used in the keys of the terminal and then press a final digit, such as "#". When the call flow module 8 detects that a sequence of key presses have been fully entered at step 56, the data inputted is passed to step 60 for formulation in a get link message for the translator 10. If the element el num does not include any prompts, as determined at steps 46 and 52, the variable el num is incremented at step 58 and operation returns to step 40. The call flow module 8 will cease execution of the steps when the caller 4 disconnects from the call path 20. The page translator module 10 operates in response to the messages received from the call flow module 8 and executes the steps described below with reference to Figure 3. The translator 10 accordingly waits for a message from the call flow 8 at step 82. On receiving a message, the message is stored at step 84 and action taken based on the form of the message is determined in steps 86, 90, 96 and 102. If the message is an initialising message, as determined at step 86, operation proceeds to step 88, otherwise operation proceeds to step 90. At step 88, the translator 10 simply forwards a default home page URL to call flow 8 and operation returns to step 82. If the message is determined to be a get page message at step 90, operation proceeds to step 92, otherwise operation proceeds at step 96. At step 92 the translator 10 forwards a request for the page designated by the URL in the get page message to the Internet 12 via the interface 22. The URL is sent using HTTP to a web server 14 which stores content in WML or HDML. The page retrieved by the translator is WML or HDML page. WML and HDML pages only comprise text data followed by link data or text data followed by prompt data. No visual layout data can be included with WML or HDML pages. Formatting is also restricted corresponding to the restricted display requirements of wireless devices. The translator 10 deconstructs the downloaded page into a number of elements which comprise text data followed by link data or text data followed by prompt data. The number of elements in the page is then determined and forwarded to the call flow module 8 at step 94. Operation then returns to step 82. If at step 96, the translator 10 determines that the message is a get element message, operation proceeds to step 98, otherwise operation proceeds to step 102. At step 98 the element designated by the el_num in the get element message is retrieved by the page translator and converted into voice data as a text string. Whilst the text in an element is simply placed in the text string, the link or prompt data in an element needs to be handled differently. For example link data including a URL to "CNN" is converted into a text string "press 1 for CNN or press 2 to continue" . A string in this format is recognised by the call flow module as being a "digit" prompt, in that it requires a single response by selection from a number of possible responses, such as a binary response set. For prompt data of the page, the data may comprise for example: < ENTRY KEY = "variable" > < ACTION TASK= "GO" DEST = "http://foo/cgi?$(variable)" > input your initials < /ENTRY > This will be translated by the translator into the text string as "input your initials by pressing the keys followed by a #" . The call flow module recognises that a string in this format as being a "string" prompt. The text string for the element el_num is then forwarded to the call flow module 8 at step 100 and operation returns to step 82. If the translator 10 determines the message is a get link message at step 102, operation proceeds to step 104, otherwise operation returns to step 82. At step 104, the translator 10 determines the link designated in the get link message which includes data corresponding to DTMF signals returned by the caller 4. The get link message also includes the element number el_num for which the data has been returned from the caller. Using the element number, the translator is able to determine whether the return data corresponds to a link or a prompt. For a link, using the example described above, if a DTMF signal corresponding to 1 is returned then the URL for CNN is obtained from the element stored by the translator 10. If a 2 is returned, then the translator simply provides a null URL for the link. If the get link message and the element number corresponds to a prompt, then variable substitution may need to be made for the URL obtained from the corresponding stored element. Using the example described above, if the caller enters DBW# then the initials DBW are substituted in the variable, and the link URL is determined to be http://foo/cgi?DBW. The link URL determined at step 104 is then returned at step 106 to the call flow module 8, and operation returns to step 82. As will be apparent from the above, the call flow module 8 and page translator 10 provide an efficient voice browser which has a number of significant advantages. As WML and HDML are languages which are used by wireless device microbrowsers, content developers are able to develop content for these microbrowsers as well as for people with telephones who can dial the IVR platform 2. This content is therefore available to people who would ultimately not have had access to the content, because they do not possess a device with a microbrowser or a computer system with access to the Internet. The syntactical complexity and visual display elements of HTML ensure that HTML pages cannot be unambiguously or correctly decoded by a voice browser. Whilst HTML content can be written to take a voice browser into account, this is invariably not the case, whereas the content and flow of control are clear and well defined in prompt navigation content languages such as WML and HDML. The prompt navigation languages are efficiently utilised by the IVR 2. The translation of WML or HDML pages by the IVR 2 also does not introduce a significant processor load, and accordingly a larger number of simultaneous connections to callers 4 can be maintained without complex or expensive hardware. Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings. For example, the IVR platform may also include a speech recognition module to process voice responses from callers 4 instead of DTMF signals sent in response to key presses.

Claims: CLAIMS: 1. A data access method, including: connecting to a caller using a voice call path; receiving a request for data from said caller on said call path; sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; receiving and translating said data in said prompt navigation language into voice data; and converting said voice data to voice for said caller on said call path. 2. A data access method as claimed in claim 1, wherein said translating includes deconstructing the prompt language navigation data into data elements including text data, link data or prompt data. 3. A data access method as claimed in claim 2, wherein said translating includes converting the data elements to respective text strings which comprise said voice data. 4. A data access method as claimed in claim 3, wherein said translating includes converting said link data to a text string representing a prompt for a single response. 5. A data access method as claimed in claim 3, wherein said translating includes converting said prompt data into a text string which represents a prompt for a string response. 6. A data access method as claimed in claim 4 or 5, wherein said converting said voice data includes processing said data elements sequentially and awaiting a response from said caller when the data element represents a prompt. 7. A data access method as claimed in claim 6, wherein said receiving a request includes receiving an input as the response to said prompt and returning said input with identification data for the data element of said prompt. 8. A data access method as claimed in claim 7, wherein said sending said request includes generating a communications request on the basis of said input and the data element corresponding to said identification data. 5 9. A data access method as claimed in any one of the preceding claims, wherein said prompt navigation language is WML. 10. A data access method as claimed in any one of the preceding claims, wherein said prompt navigation language is HDML. 10 11. A data access method as claimed in any one of the preceding claims, wherein said method is executed on an interactive voice response (IVR) platform. 12. A data access method as claimed in claim 11, wherein said communications network 15 includes the IVR platform. 13. A data access method as claimed in claim 12, wherein said communications network includes the Internet. 20 14. A data access system, including: means for connecting to a caller using a voice call path; means for receiving a request for data from said caller on said call path; means for sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; 25 means for receiving and translating said data in said prompt navigation language into voice data; and means for converting said voice data to voice for said caller on said call path. 15. A data access system as claimed in claim 1, wherein said translating means 30 deconstructs the prompt language navigation data into data elements including text data, link data or prompt data. 16. A data access system as claimed in claim 15, wherein said translating means converts the data elements to respective text strings which comprise said voice data. 17. A data access system as claimed in claim 16, wherein said translating means converts 5 said link data to a text string representing a prompt for a single response. 18. A data access system as claimed in claim 16, wherein said translating means converts said prompt data into a text string which represents a prompt for a string response. 10 19. A data access system as claimed in claim 17 or 18, wherein said converting means processes said data elements sequentially and awaits a response from said caller when the data element represents a prompt. 20. A data access system as claimed in claim 19, wherein said request receiving means 15 receives an input as the response to said prompt and returns said input with identification data for the data element of said prompt. 21. A data access system as claimed in claim 20, wherein said sending means generates a communications request on the basis of said input and the data element corresponding to 20 said identification data. 22. A data access system as claimed in any one of claims 14 to 21, wherein said prompt navigation language is WML. 25 23. A data access system as claimed in any one of claims 14 to 22, wherein said prompt navigation language is HDML. 24. An interactive voice response (IVR) platform comprising a data access system as claimed in any one of claims 14 to 23. 30 25. A data access system as claimed in any one of claims 14 to 23, wherein said communications network includes the data access system. 26. A data access system as claimed in claim 25, wherein said communications network includes the Internet. 27. A voice browser stored on a computer readable storage medium, including: 5 code for receiving a request for data from a user; code for sending said request to a location in a communications network determined by said request, said location including said data in a prompt navigation language; code for receiving and translating said data in said prompt navigation language into voice data; and 10 code for converting said voice data to voice for said user. 28. A voice browser as claimed in claim 27, wherein said translating code is adapted to deconstruct the prompt language navigation data into data elements including text data, link data or prompt data. 15 29. A voice browser as claimed in claim 28, wherein said translating code is adapted to convert the data elements to respective text strings which comprise said voice data. 30. A voice browser as claimed in claim 29, wherein said translating code is adapted to 20 convert said link data to a text string representing a prompt for a binary response. 31. A voice browser as claimed in claim 29, wherein said translating code is adapted to convert said prompt data into a text string which represents a prompt for a string response. 25 32. A voice browser as claimed in claim 30 or 31 , wherein said converting code is adapted to process said data elements sequentially and await a response from said caller when the data element represents a prompt. 33. A voice browser as claimed in claim 32, wherein said request receiving code is 30 adapted to receive an input as the response to said prompt and return said input with identification data for the data element of said prompt. 34. A voice browser as claimed in claim 33, wherein said sending code is adapted to generate a communications request on the basis of said input and the data element corresponding to said identification data. 35. A voice browser as claimed in any one of claims 27 to 34, wherein said prompt navigation language is WML. 36. A voice browser as claimed in any one of claims 27 to 35, wherein said prompt navigation language is HDML. 37. A voice browser as claimed in any one of claims 27 to 36, adapted to execute on an interactive voice response (IVR) platform. 38. A voice browser as claimed in claim 37, wherein said communications network includes the IVR platform. 39. A voice browser as claimed in claim 38, wherein said communications network includes the Internet.

Inventors: SCOTT ANDREW EWART, SCOTT, ANDREW, EWART
Applicants: SCOTT ANDREW EWART, TELSTRA R & D MAN PTY LTD, SCOTT, ANDREW, EWART, TELSTRA R & D MANAGEMENT PTY. LTD.
Application year: 1999
Main classification: H04M3
IPC codes: G06F17, H04M3, H04M7, H04Q1