WO2001018692A2

WO2001018692A2 - Method for customizing and rendering of selected data fields

Info

Publication number: WO2001018692A2
Application number: PCT/US2000/024546
Authority: WO
Inventors: Prakash Iyer; Piyush Goel; Rajeev Mohindra; Amitabh Sinha; Prasad Krothapalli; Ronald Mak; Shashi Vittal
Original assignee: Everypath, Inc.
Priority date: 1999-09-10
Filing date: 2000-09-06
Publication date: 2001-03-15
Also published as: JP2003532129A; CN1461445A; EP1344149A2; AU7355200A; KR20020042831A; CA2384618A1; WO2001018692A3

Abstract

A method is provided whereby data elements selected and identified by means of a signature extracted from a mathematically regular expression of data can be rendered through an appropriate language translator of interest to the querier by means of a system which is adapted to access elements through reference by signature. Language translators of interest can include text to speech translators, stored aural expressions mapped to the elements and simplified textual expressions programmed to match the HTML expression. As a further aspect of the invention, the method further includes identification of the selected elements, customization of the selected element for rendering suitable for the intended context, and further specification of the selected and customized elements via a suitable language translator of interest.

Description

METHOD FOR CUSTOMIZING AND RENDERING OF SELECTED

DATA FIELDS

BACKGROUND OF THE INVENTION This invention relates to rendering of customized data in different formats, including aural and limited visual formats. This invention relates specifically to rendering of data in a HyperText Markup Language (HTML) in another form such as an audio format or a visual format other than the source format.

A great deal of valuable information is now available in HTML format. However, HTML is primarily designed for access in a specific visual context, namely by means of a graphical user interface of the type designed for use with web browsers. There is a need to make HTML data accessible via other interfaces and readers. The invention herein described is intended to address an important aspect of that need.

SUMMARY OF THE INVENTION

According to the invention, in a computer network system, a method is provided whereby data elements selected and identified by means of a signature extracted from a mathematically regular expression of data can be rendered through an appropriate language translator of interest to the querier by means of a system which is adapted to access elements through reference by signature. Language translators of interest can include text to speech translators, stored aural expressions mapped to the elements and simplified textual expressions programmed to match the HTML expression. As a further aspect of the invention, the method further includes identification of the selected elements, customization of the selected element for rendering suitable for the intended context, and further specification of the selected and customized elements via a suitable language translator of interest.

It is an important recognition of the present invention that HTML pages can be represented by regular expressions. It is also an important recognition of the invention that only elements need to be selected, and that the actual values of the elements need not be selected, thus permitting the values to be dynamically updated and rendered with the current value.

The invention will be better understood by reference to the following detailed description in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of a system according to the invention in which a runtime engine employs the identified elements according to the invention with an appropriate rendering tool to retrieve information from an HTML page.

Figure 2 is a flow chart of a sample translation according to the invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS Figure 1 shows a block diagram of a system 101 with the major runtime components and related elements. Web pages 11 are retrieved from a host web server 12 into a translator 20, which in turn retrieves corresponding target language documents 21 from the shared persistent store 14 to produce so-called WML pages 23 and runtime objects 24. A designer 13 has previously selected some data, henceforth called a "component" 17, from an HTML or source language page 11 so that a unique signature has been automatically generated that is employed by the runtime environment via the runtime engine 22 in order to extract real time data from the HTML page. The runtime engine 22 interfaces with a phone server or other rendering server 26, and the user 28 accesses requested real time information from the host web server in the format provided through the rendering server 26. At run time, the runtime translator 20 acts like a browser to the host Web server 12 as it downloads HTML pages from the site. The translator 20 also retrieves scripts of the target language, in a specific embodiment, a language created for this purpose called AML, from the shared persistent store 14. For each Web page, the corresponding AML script tells the translator how to create the runtime objects 24. These runtime objects 24 feed into the runtime engine 22, which in turn interacts with the caller. The runtime engine 22 reads text and issues prompts over the phone or other interface device to the user 28 using text-to-voice or text to reduced text technology. Whenever the phone caller 28 speaks his responses, the engine 22 uses either voice recognition technology or text-on-nine (herein called T9) to convert caller responses to text. The translator 20 can then submit response data from the caller back to the host Web server 12 which in turn interprets and responds to the request..

Because scripts may be set to encode the inter-page flow and contain the URLs of the Web pages, the translator can request the appropriate Web pages. At run time, the host Web server 12 believes that it is connected to a conventional Web browser. Besides creating the runtime objects 24, the runtime translator 20 can also create WML files for third party applications that use such files. Callers to audio-enabled sites accessed from a portal can also use a customized applet.

An important aspect of the runtime operation is the translation process. Hereafter the translation process is explained.

A. Translation

In this section is described how the various components from the previous section are rendered.

A.l Translation: forms The translation for a sample form appears below. Each input element of this form appears as a "STEP". A step element has a prompt element which informs the user of the nature of this input, and an input element which gathers the input from the user. Figure 2 is a flow chart of the sample translation herein described.

<Dialog Name="Logon" greeting = "Logon Page"> component Name = "Logon" TYPE = "FORM" position= 1 ></component>

<PROMPT> Please speak the eight digits in your account number </PROMPT>

<PROMPT> Please speak your password </PROMPT> <INPUT TYPE="STRING" NAME="SignonPassword" NEXT = "#F3"></INPUT> </STEP>

<PROMPT> Please choose from one of the following options. Account Overview, Stock Trading, Options Trading, Mutual Fund Trading, Corporate Bond Trading, Real-Time Quotes, Account Balances and Position. </PROMPT>

<INPUT TYPE = "OPTIONLIST" NAME = "StartAnchor" NEXT="#F4" grammar=.optionlist

//[comment: The grammar defines what the user is expected to say or input at this point. If the user says something else, an error is raised and is handled according to the onError step.] onError=#error> <RENAME VARNAME="S tart Anchor"

GRAMMARNAME="X">

//[comment: The forgoing is the mapping between the variable name and the grammar name.]

<option Value="Ccbodyi">Account Overview </OPTION> <option Value="TradingEQ">Stock Trading </OPTION>

<option Value="TradingOpt">Options Trading </OPTION>

<option Value="TradeMF">Mutual Fund Trading </OPTION> <option Value="TradeCorpBonds">Corporate Bond

Trading </OPTION>

<option Value="Quotes">Real-Time Quotes </OPTION> <option Value="Balance">Account Balances </OPTION> <option Value="Position">Positions </OPTION> </INPUT>

</STEP>

//[comment: The following is for a form. In a form, hidden variables, actions and methods are always pulled from the HTML or source page.] <FORM

NAME = "F4"

PARAMETERS="StartAnchor=$amlvar(StartAnchor)&SignonPas sword=$amlvar(SignonPassword)&SignonAccountNumber=$amlv ar(SignonAccountNumber)" Component="Logon">

<PROMPT> Attempting to Log on to Charles Schwab </PROMPT>

</FORM>

<flow

Name = "formflow"

Source- ' https://trading2.schwab.com trading/signon/." Sourceaudio=logon Destination- ' ...trading/generic/?FormName=DelayedQuotes"

Destinationaudio=headlines

Destinationstep = headlines> </flow> </Dialog>

An attribute defines the transition from a given step. For example, referring to Figure 2, in the first step FI, the logon step, the prompt asks for the user's eight digit account number, and upon receiving it in the spoken input, it makes a transition to step F2. In the logon step, the name attribute of the input element, SignonAccountNumber is a "global" variable and can be later accessed as

$amlvar(SignonAccountNumber). Continuing in step F2, the prompt asks for the password, and upon receiving the input, it makes the transition to step F3. Step F3 is an optionlist, where the user can select one of many options. After selecting an option, the user is transitioned to the next step which is F4. The parameters attribute specifies the parameters that need to be passed to the action url, and finally, the prompt provides the user with a feedback on what is being done. The flow element defines the transition to the next step - given the destination url, the designer and the runtime system can determine the next AML page necessary to continue the browsing.

The recognition grammar specifies a name for the variable, say X, into which it places the value, and the step has a variable name corresponding to the input

(Startanchor). In some cases, these may not be the same, e.g., when the grammar is shared between many different input steps, and they have been all coded with different variable names. In that case, a RENAME element will help define the mapping from the recognition variable name to the step's variable name. If the grammar assigns multiple variables, we would need to specify one rename element for each of the variables. For example, in the following code segment, all the variables are assigned by the grammar, and they are remapped to variable names used in the code of the following further example:

<PROMPT> What would you like to trade? </PROMPT> <INPUT TYPE = "GRAMMAR" GRAMMAR=".StockTrade2" onError="#error"> <RENAME VARNAME="TradeType"

GRAMMARNAME="A1 ">

<RENAME VARNAME="TimeLimit" GRAMMARNAME="A5"> <RENAME VARNAME="Quantity"

GRAMMARNAME="A6">

</INPUT> </STEP>

If for some reason the (voice) recognition engine does not understand what the user has said, an error condition is raised. If no onError attribute is specified it is handled in the default way: the prompt is repeated a few times until recognition is correct. The user may choose to replace the default behavior with an error step of her or his own definition. In the following example, an error step is defined by the user as a global step. The step defines actions in the case of various errors. The step is global, i.e., it can be accessed from other subsequent ami pages.

</STEP>

<prompt> > I did not understand what you said. </prompt> <switch name=$amlvar(amlerror. number_errors_page)>

<prompt> $amlvar(lastprompt) </prompt> </STEP>

<prompt> $amivar(lastshadowprompt) </prompt> </STEP>

<prompt> Giving up! </prompt> <INPUT type=none next="navigation"> </STEP>

A.2 Translation: tables

Tables can be read out in multiple ways. This section describes two possible ways. One way is to read out one row of a table at a time, asking the user if they want to proceed further. Another way is to read out all the rows of the table one at a time, allowing the user to barge in at any time. A.2.1 One row at a time

After the user logs on to a system, he or she can use the browser to transition for example to a page with a table of headline news for a particular stock symbol. Selected cells of this table are of particular interest. They can specify, the date, time, and the headline news, respectively. Each row of the table is a news headline for the stock symbol. The corresponding AML page for such an example appears below. It contains both the identification and the translation parts. The identification comprises the rows of the table constituting a loop of the iteration, and the cells 1, 3, and 5 selected for instantiation from the html page. There is only one step, namely Headlines, in this page. It has a prompt and an input element. The input element for this step is inside a loop element which loops over the component specified by the component attribute. Associated with the input element is another prompt which is spoken out for each iteration of the loop. The prompt associated with the loop in this example is specified in terms of an array variable, e.g., Samlvar(Headlines[index].date), which refers to the date variable for the current row.

The next attribute has multiple connotations for the option tag :

(1) next="#goto": indicates that the continuation is at the step named goto

(2) next="return": return back to invoking step

(3) else: If next is specified as anything else, e.g., next="$amlvar(c. continue)", or next=http://www.amazon.com select/select.cgi, then the next step is traversing an anchor element.

The "next" attribute for the options following the prompt in each iteration has two possible values: (i) continue, which is a reserved word indicating that the system proceed to the next iteration of the loop, and (ii) $amlvar(headlines[index].news.ur_), which specifies that if the user says "Yes" the system must transition to the url specified. The subsequent flow element defines the AML page which is required to continue the browsing. The following is the AML code with the aural promts embedded: <DIALOG name=headlines greeting— 'news headline"> //...component definition would be here...// <STEP Name = "Headlines'^

<PROMPT> This is a list of all the headlines </PROMPT> <LOOP name=headlines loopindex=index start=0 increments end=$amlvar(headlines. length) next=#query></LOOP> </STEP> <STEP name="query">

News on Date $amlvar(Headlines[index].date) at time $amlvar( Headlines[index].time) $amlvar(Headlines[index].news).

If you want to hear the complete story say Yes or say No to go to the next headline

</PROMPT>

</ΓNPUT>

</STEP>

<FLOW

Name = "detailflow" Source="/parser/test/schwab/news.html" Sourceaudio=headlines

Destination="/parser/test/schwab/<amlvar>.html" Destinationaudio=/parser/test/schwab/detail.vox DestinationStep="detail"> </FLOW> </DIALOG>

A.2.2 All rows together

All the rows can be read out one after the other, and the user may be prompted for directions at the end of the reading. The can be enhanced to add support for barge-in, that is, to allow the user to interrupt the playing of the list in the middle.

<STEP Name = "Headlines'^ <PROMPT> Here are the headlines. If you want to hear the complete story say Yes for the headline </PROMPT>

</LOOP> </STEP>

News on Date $amlvar(Headlines[index].date) at time $amlvar( Headlines[index].time) $amlvar(Headlines[index] .news). </PROMPT>

<INPUT NAME = "choice" TYPE=OPTIONLIST BARGEIN=TRUE grammar = ".YesNoNavigation" onError=#error> <option NEXT="$amlvar(headlines[index].url) " > Yes

</OPTION>

Barge-in allows the user to listen to the news and say yes only when they want to listen to the detailed news. This minimizes the number of things the user needs to say.

A.3 Translation: variable looping elements

Consider the following translation for the variable looping example for another sample. At the stage after component identification, there is not much difference from the rendering of the table in the previous example. <STEP Name = "resultssection"> <PROMPT>

Here are the book search results. If you want to hear more details about a book say Yes </PROMPT>

</LOOP > </STEP>

Title $amlvar(resultssection2[index]. title] ships in $amlvar(resultssection2 [index] . shipping) . The authors for this book are $amlvar(resultssection2[index]. author). It is a $amlvar(resultssection2 [index]. type) and was published in $amlvar(resultssection2[index].date). The price is $amlvar(resultssection2 [index] .price). </PROMPT>

A.4 Translation: Alternate structures

In the previous examples of iterative structures, each row had the same structure, and selected cells provided the necessary input. In this section are examples where the row structure is not the same. Example 1

The following table can be rendered with different prompts for different cases in the table as follows:

Stock Price Quantity Operation Date

IFMX 10.50 100 BUY 5/25/98

ORCL 51.5 200 SELL 5/26/98 IBM 171.5 DIVIDEND 5/27/98

IBM 51.5 INTE

</STEP>

<PROMPT> You have now heard your entire transaction list. Should I return to the main menu?

</PROMPT>

</SWITCH> </STEP>

<PROMPT> Interest Samlvar(transactionList[index].icol2) was posted on $amlvar(transactionList[index].icol5). </PROMPT> <INPUT type=none next="return"> </STEP>

<PROMPT> Dividend Samlvar(transactionList[index].dcol2) was posted on amlvar(transactionList[index].dcol5) for stock symbol $amlvar(transactionList[index].dcoll).

</PROMPT>

<STEP name="default"> <PROMPT> A $amlvar(transactionList[index].col4) transaction of

$amlvar(transactionList[index].col3) shares at $amlvar(transactionList[index].col2) of $amlvar(transactionList[index].coll) was posted on $amlvar(transactionList[index].col5). </PROMPT>

Example 2 The following AML code renders a trade history table. There are two loops - one over the stock symbols and one for the trade history for each symbol.

</STEP>

<PROMPT>Please say yes if you want to listen to the orders for $amlvar(stocks[indexl]. stock).

</PROMPT>

</INPUT> </STEP>

<! — For each stock, loop over the trades for that stock > <STEP Name = " stock 1 " next=τeturn>

</switch> </STEP> <! Prompt for open trades> <STEP name="open" > <PROMPT>

$amlvar(stockl[index2].orderno) is currently open, and is a $amlvar(stockl[index2]. action) for $amlvar(stockl[index2].qty) shares of $amlvar(allstocks[indexl]. stock) at price $amlvar(stockl[index2]. price). It was posted on $amlvar(stockl[index2].date) with a time limit of $amlvar(stockl[index2]. limit).

</PROMPT>

<! prompt for closed trades>

$amlvar(stockl[index2]. order no) was a $amlvar(stockl [index2]. action) for $amlvar(stockl[index2].qty) shares of

$amlvar(allstocks[indexl]. stock) at price $amlvar(stockl[index2].price). It was posted on $amlvar( stock l[index2]. date) with a time limit of $amlvar( stock l[index2]. limit). The transaction was closed on Samlvar(stockl[index2].date2) and the action was

$amlvar(stock 1 [index2] . action2) . </PROMPT>

<INPUT type=none next="return"> </STEP> B. Flow: specifying urls/form actions

Transitions from a page in html to another page in html are made possible because of url or the action element of a form. These also define traversals between the corresponding audio page specifications according to the invention. So it is possible to have a mapping called "flow" which defines the destination url and the destination voice element. For purpose of simplicity and perhaps easier searching source url and source page information will also be stored. A url can have a static and a dynamic part. In operation the the structure attribute for component specification to specify variable urls is re-used. In the GUI part, there are two levels in converting html pages to an audio

"program". In the first level, individual html pages are converted to the corresponding audio pages. In the second level, all audio pages are displayed, and the user is permitted to define transitions between various audio pages using the urls/form action methods in the corresponding html components. For each url transition, an audio element gets defined, which will be internally maintained in a mapping of "urls->audioid", where audioid is the identifier of the audio page.

The url transitions are specified using the flow element. The flow element specifies the url and its corresponding dialog. Consider the following href statement in an html page: <a

HREF="/trading/generic/?FormName=DelayedQuotes" NAME=CompanyNews TARGET="CCBodyi" onMouseOver="parent.self.status='Company News';return true"> <u>Company</u> </a>

If the user is allowed to traverse this url (a destination address), then the corresponding flow specification will be:

<flow

Name = "CompanyNews"

Source=" https://trading2.schwab.com/trading/signon/."

Sourceaudio=logon

Destination- '...trading/generic/?FormName=DelayedQuotes" Destinationaudio=headlines>

</flow>

Similarly, if the form component in the Amazon home page example is selected, then the action method has been implicitly chosen for traversal. It is hus necessary to define the flow element for it. The form element starts off for example as follows:

The destination url when the form is submitted is: http://www.amazon.com/exec/obidos/generic-quicksearch-query/002-0363237-2566852. This has a static part: http://www.amazon.com/exec/obidos/generic-quicksearch-query/, and a variable part: 002-0363237-2566852. The variable part is a session-id which is assigned to a new session coming to the amazon.com page. A flow component for this page can then be defined as follows: <flow name= "Resultsflow" source="http://www.amazon.com/exec/obidos/generic- quicksearch-query/<amlvar name=sessionid»" destination="http://www.am azon.com/exec/obidos/generic- quicksearch-query/<amlvar name-sessionid>" sourceaudio=homepage destinationaudio=Resultspage>

</flow>

The caller/voice user can navigate between different audio steps using the navigational commands: back, forward, stop, continue, and refresh. The transitions are defined between steps marked as transitional steps. Back and forward commands will take the caller backwards or forwards to the next transitional step, respectively. Stop will terminate current rendering or background execution of the session. Continue will begin work from where it was stopped. Refresh will refresh the html page currently being examined the session. Thus in the following AML language code, the headlines step can be marked as a transition step using the attribute transition (which is "false" by default):

<STEP Name = "Headlines" transition=true> <PROMPT> Here are the headlines. If you want to hear the complete story say Yes for the headline </PROMPT>

</LOOP> </STEP>

Not all steps need to be transitional. Thus, internally, a form may be translated to multiple steps, and the user can be forced to always transition to the first step of the form.

C. AML (DTD specification)

C.l Overall document

The following is a specification for the audio language AML. Other languages could be created following this example of syntax and modified to operate in an intended medium or subject to defined restrictions. Hence, this specification is intended to be illustrative and not limiting.

<!ELEMENT DIALOG (component|form|step|flow)*> <! ATTLIST dialog # audio page element name CD AT A # name of object url CD ATA # structure of url greeting CD ATA # information greeting user on entering audio page

# this is read out when user reaches this audio page for the # first time, or thereafter while navigating through the

# audio pages cookie CD ATA # any associated cookies with page, may be necessary for # identification

>

Identification

<!ELEMENT COMPONENT (component|idloop|idswitch)*>

<! ATTLIST component # component element - type CDATA # type of object form/table/tr/td/input etc. position CDAIA # ordinal element number of component in the parent container url CDATA # identifying url. url are case sensitive name CDATA # name of component htmlname CDATA # Name on the html document id CDATA # ID of html object dimension CDATA

# for forms #of visible controls in the form # for a table number of rows # for a tr number of cells visible (true|false) # set to "true" if the nonvisible data needs to be stripped structure CDATA #structure object>

<!ELEMENT idswitch (idcase)*> <! ATTLIST idswitch name CDATA # what do you switch on?>

<!ELEMENT idcase (component|idloop|idswitch)*> <! ATTLIST idcase define CDATA

# used to define component types, later # in rendering to identify type of

# component being rendered > <!ELEMENT idloop (component|idswitch|idloop)*>

>

<!ELEMENT FLOW

<!ATTLIST flow # f ow element name CDATA; # name of element source CDATA; # structure specification of source url destination CDATA; # structure specification of destination url sourceaudio CDATA; # source audio page id destinationaudio CDATA; # destination audio page id destinationstep CDATA; # starting step in new audio element

>

<!ELEMENT AMLVAR>

<! ATTLIST amlvar # variable element — name CDATA # name of variable type (char|int|money|date|time) # what is the type of this variable

# this is used for rendering, e.g.,

# if it is of type date, and looks like

# 1/10/99, it would be rendered as

# October 1, 1999 format CDATA # for date/time/money, what is the format

# of this variable on the html page

# mmddy4/y4/ etc render CDATA # how is this rendered to the caller

# mmddy4/y4/ etc. visible (true|false) # visible part of text, i.e., what you see on

# the screen, see Section 5.5 >

Rendering

<! ELEMENT FORM (prompt)> <! ATTLIST form # form element name CDATA # name of object parameters CDATA # &-separated list of parameters to be passed component CDATA # name of component in identification

>

<!ELEMENT step (prompt)(input|switch|loop)> <! ATTLIST step name ID REQUIRED

Transition (true|false) # transitional step for navigation

Next CDATA # what is the next step after this step.

Valid ony for steps # that enclose loop and switch >

<! ELEMENT input (option|rename)*>

<!ATTLIST input name ID # next CDATA # what is the next step after this step bargein (Y|N) # default is yes (Y) grammar CDATA # grammar describing what to expect # from the user at this point; some default

# grammars available, such as yes/no, etc. keypad CDATA # grammar describing keypad stuff onError CDATA # error handling step if there is a

# problem in this

# input from the user type (TEXT|DIGITS|OPTIONLIST|NONE)

>

<!ELEMENT option (CDATA)>

<! ATTLIST option value CDATA # value of option next C DATA # what is the next step

>

<!ELEMENT switch (case)*> <!ATTLIST switch component CDATA # what do you switch on?

>

<! ELEMENT case >

<! ATTLIST case value CDATA # value for this case; next CDATA # step containing body of case

>

<! ELEMENT prompt (CDATA)> <! ATTLIST prompt wavefile CDATA #wavefile containing prompt

> <! ELEMENT loop> <! ATTLIST loop component CDATA # name of component on which to loop on next CDATA # step containing body of loop loopindex CDATA # name of loop index start CDATA # starting value for loop index

(default 0) end CDATA # ending value for loop index

(default # length of component) increment CDATA # loop index increment (default 1) order CDATA # part of component on which it needs to # be sorted direction (ascend|descend) # render in ascending/descending order if >

<! ELEMENT rename > <! ATTLIST rename

VARNAME CDATA # name of ami variable GRAMMARNAME CDATA # grammar slot name >

The invention has been described with reference to specific embodiments. Other embodiments will be evident to those of ordinary skill in the relevant art. It is therefore not intended that the invention be limited, except as indicated by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. In a computer network system having storage means for source data and for identification of said source data, a method for rendering a representation of two-dimensional data which is part of a mathematically regular expression, in aural or other visual forms, said representation being a signature derived from analysis of a mathematically regular element, said method of rendering comprising: in response to a query from a user, retrieving said signature from said storage means; retrieving a current value of said element of interest, as designated by said signature, from said source means; translating said current value through a preselected language translator into an output; and providing said output to said user.

2. The method according to claim 1 wherein said preselected language translator is a text to speech translator.

3. The method according to claim 1 wherein said preselected language translator is a set of stored aural expressions mapped to preselected values for each one of said elements.

4. The method according to claim 1 wherein said preselected language translator comprises an engine of simplified textual expressions mapped to preselected values for each one of said elements.

5. A system, comprising: means for receiving from a host web server source-language information specifying web elements; means for receiving a mathematically regular expression identifying at least one web element specified by the source-language information; and means for using the source-language information and the mathematically regular expression to generate target-language information for enabling a runtime engine to present the identified web element.

6. The system of claim 5, wherein the source-language information includes HTML data.

7. The system of claim 5, wherein the target-language information includes HTML data.

8. The system of claim 5, wherein the target-language information includes runtime objects.

9. The system of claim 5, wherein the identified web element includes flow control information.

10. The system of claim 5, wherein the identified web element includes a list of options.

11. The system of claim 5, wherein the identified web element includes a table.

12. The system of claim 5, wherein the identified web element includes a request for logon information.

13. The system of claim 5, wherein runtime engine includes a text-to-speech engine.

14. The system of claim 5, wherein the translator includes a text-to-speech engine.

15. The system of claim 5, wherein the translator includes an aural expression mapped to a preselected value for the identified web element.

16. The system of claim 5, wherein the translator includes a simplified textual expression mapped to a preselected value for the identified web element.

17. A method, comprising receiving from a host web server source-language information specifying web elements; receiving a mathematically regular expression identifying at least one web element specified by the source-language information; and generating from the source-language information and the mathematically regular expression target-language information for enabling a runtime engine to present the identified web element.

18. A computer-readable storage medium storing program code for causing a computer to perform the steps of: receiving from a host web server source-language information specifying web elements; receiving a mathematically regular expression identifying at least one web element specified by the source-language information; and generating from the source-language information and the mathematically regular expression target-language information for enabling a runtime engine to present the identified web element.

19. A method, comprising: receiving HTML page information from a host web server; retrieving target-language scripts from a persistent store; translating the HTML page information in accordance with the target-language scripts to produce translated HTML page information; and presenting the translated HTML page information to a user via a rendering device.

20. The method of claim 19, wherein said translating includes extracting dynamically updateable data from the HTML page information.

21. The method of claim 19, wherein the translated HTML page information is presented aurally.

22. The method of claim 19, wherein the translated HTML page information includes runtime objects.

23. The method of claim 19, wherein said presenting includes interactively supplying a prompt element to a user and receiving an input element from a user.

24. The method of claim 19, wherein said rendering device is a phone.

25. The method of claim 19, wherein the HTML page information is a web page.

26. The method of claim 19, further comprising identifying selected HTML page information to be translated.

27. A method for providing interactive user access to web page information, comprising: receiving web page information from a host web server; converting the web page information to a current presentation dialog including presentation pages that are presentable to a user via a rendering device; receiving from the user a current presentation page transition; defining a presentation element as mapping a transitional page to a web page information target and a corresponding transitional step; receiving user navigational commands; and causing transitional step wherein a dialog corresponding to the web page information target is presented if a received user navigational command corresponds to the presentation element.

28. The method of claim 27, wherein the transitional page is a page presented to a user immediately prior to receiving the presentation page transition.

29. The method of claim 27, wherein the navigational commands include a backward command causing a prior dialog to be presented.

30. The method of claim 27, wherein the navigational commands include a backward command taking the user backwards to a next transitional step, and a forward command taking the user forwards to a next transitional step.

31. The method of claim 27, wherein the navigational commands include a stop command that terminates corresponding current rendering device execution, and a continue command that begins corresponding rendering device execution from where such execution was stopped.

32. The method of claim 27, wherein the navigational commands include a refresh command that refreshes an HTML page currently being examined.

33. The method of claim 27, wherein said presentation pages include audio pages and said presentation element is an audio element.