KR20020042831A - Method For Customizing And Rendering Of Selected Data Fields - Google Patents

Abstract

The present invention relates to a method in which data elements are provided and identified by a signature extracted from a mathematical regular expression of data that can be rendered to a queryer via a suitable corresponding language translator, by a system suitable for accessing the elements via a reference by signature. to provide. The language translator may include a text-to-speech translator, a stored textual expression mapped to the elements, and a simple textual expression programmed to match an HTML expression. According to another form of the invention, the invention further comprises the identification of the selected element, customization of the selected element for rendering suitable for the intended context and further specification of the selected element and the customized element via a suitable language translator. .

Description

Method For Customizing And Rendering Of Selected Data Fields}

At present, a large amount of useful information is available in HTML format. However, HTML is primarily designed as a means of access in a specified visual context, a form of graphical user interface designed to be used with a web browser. You need to make the HTML data accessible through other interfaces and readers. The present invention described herein focuses on such a need.

The present invention is directed to rendering customized data in other formats including audio format and limited visual format. In particular, the present invention relates to rendering data in a hypertext markup language (HTML) in other forms such as an audio format or a visual format other than the source format.

1 is a block diagram of a system according to the invention, wherein the runtime engine employs the identified elements according to the invention, with a rendering tool suitable for retrieving information from an HTML page;

2 is a flowchart of sample translation in accordance with the present invention.

According to the present invention, data selected and identified by a signature extracted from a mathematical regular expression of data in a computer network system corresponds to a query by a system suitable for accessing elements via a reference by the signature. A method is provided that can be rendered via a suitable language translator. The language translator may include text for the speech translator, a simplified textual expression programmed to match the stored aural expression and the HTML expression mapped to the elements. According to another embodiment of the present invention, the method further comprises identifying the selected element, customizing the selected element for rendering suitable for the intended sentence, and another specification of the selected and customized element through an appropriate language translator of interest. More).

It is an important recognition of the present invention that an HTML page can be represented by a regular expression. It is also an important recognition of the present invention that only the elements need to be selected and the actual values of the elements need not be selected so that the values can be dynamically updated and rendered to the current values.

Hereinafter, with reference to the detailed description in conjunction with the accompanying drawings, the present invention may be further understood.

1 shows a block diagram of a system 101 with major runtime components and associated elements. The web page 11 is retrieved from the host web server 12 to the translator 20, which is then shared to create a so-called WML page 23 and a runtime object 24 shared shared store. The corresponding target language document 21 is retrieved from the persistent store 14. The designer 13 previously selects some data (hereinafter referred to as "component" 17) from the HTML or source language page 11 and uses the runtime engine 22 to extract real-time data from the HTML page. This creates a unique signature for the runtime environment. The runtime engine 22 interfaces with the phone server or other rendering server 26 and the user 28 accesses the real time information requested from the host web server in a format provided through the rendering server 26. At runtime, runtime translator 20 acts as a browser to download HTML pages from the site to host web server 12. The translator 20 also retrieves the script of the target language (the language written for AML) from the shared persistence store 14 in certain embodiments. The corresponding AML script for each web page tells the translator how to create the runtime object 24. These runtime objects 24 are supplied to the runtime engine 22 and then talk to the caller. The runtime engine 22 reads the text and issues a prompt to the user 28 by phone or other interface device using text-to-speech or text-to-reduced text technology. Each time telephone caller 28 responds, engine 22 converts the caller response to text using speech recognition technology or text-on-nine (hereafter referred to as T9). . The translator 20 can then submit the response data back to the host web server 12 from the caller, and then continue in such a way that the host web server interprets and responds to the request.

Since the script can be set to encode the inter-page flow and retain the URL of the web page, the translator can request the appropriate web page. At runtime, the host web server 12 is assumed to be connected to a conventional web browser.

In addition to creating a runtime object 24, the runtime translator 20 can also generate a WML file for a third party application that uses the WML file. Audio-enabled sites accessed from the portal may use customized applets.

An important aspect of runtime operation is the translation process. The following describes the translation process.

A. Translation

This section explains how the various components are rendered from the previous section.

A.1 Translation: Form

See below for a translation of the sample form. Each input element of the form is represented by "STEP". The step element has a prompt element that informs the user of the nature of the input and an input element that draws input from the user. 2 is a flowchart of a sample translation described herein.

<Dialog Name = "Logon" greeting = "Logon Page">

<component Name = "Longon" TYPE = "FORM"

position = 1> </ component>

<STEP Name = "Longon">

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

</ PROMPT>

<INPUT TYPE = "DIGIT" NAME = "SignonAccountNumber"

NEXT = "# F2"> </ INPUT>

</ STEP>

<STEP Name = "F2">

<PROMPT> Please speak your password </ PROMPT>

<INPUT TYPE = "STRING" NAME = "Signon Password" NEXT = "# F3"> </ INPUT>

</ STEP>

<STEP Name = "F3">

<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 = "Start 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"> Option 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"> Position </ 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 sourse page.]

<FORM>

NAME = "F4"

PARAMETERS = "StartAnchor = $ amlvar (StartAnchor) & SignonPass

word = $ amlvar (SignonPassword) & SignonAccountNumber = $ amlvar

(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 a transition from a given step. For example, referring to FIG. 2, in the first step F1 (logon step), the prompt asks for the user's eight digit account number and receives it by voice input and goes to step F2. In the logon step, the name attribute of the input element, SignonAccountNumber, is a "global" variable and can later be accessed as $ amlvar (SignonAccountNumber). Subsequently, at step F2, the prompt asks for a password and, upon receiving an input, proceeds to step F3. Step F3 is a list of options from which the user can select one of many options. After selecting one option, the user proceeds to step F4. The parameter attribute specifies the parameters needed to proceed to the action url, and finally the prompt provides feedback about what is being done to the user. The flow element defines the transition point to the next step. Given a destination url, designers and runtime systems can determine the next AML page needed to continue browsing.

A recognition grammar specifies a name for a variable (eg, X) that specifies its value, and the step has a variable name corresponding to the starter. In some cases, they may not be the same, for example when they are shared between many different input steps they are all coded with different variable names. In that case, the RENAME element will help define the mapping from the recognition variable name to the variable name of the step. If the grammar assigns multiple variables, then you need to specify one rename element for each variable. For example, in the following code segment all variables are assigned by syntax, and they are remapped to the variable names used in the following example code.

<STEP Name = "stock">

<PROMPT> What would you like to trade? </ PROMPT>

<INPUT TYPE> = "GRAMMAR" GRAMMAR = "StockTrade2"

onError = "# error">

<RENAME VARNAME = "TradeType" GRAMMARNAME = "A1">

<RENAME VARNAME = "Symbol" GRAMMARNAME = "A2">

<RENAME VARNAME = "OrderType" GRAMMARNAME = "A3">

<RENAME VARNAME = "LimitPrice" GRAMMARNAME = "A4">

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

<RENAME VARNAME = "Quantity" GRAMMARNAME = "A6">

</ INPUT>

</ STEP>

If for some reason the (speech) recognition engine does not understand what you say, you get an error. If the on error attribute is not specified, it is manipulated in the default way. That is, the prompt is repeated several times until the recognition is correct. You can choose to replace the default behavior with an error step of your own definition. In the following example, the error step is defined as a global step by the user. This step defines the actions taken in case of various errors. The step can be accessed as a global step, i.e. from another subsequent aml page.

<STEP name = error global = true>

<switch name = $ amlvar (amlerror.type)>

<case value = RECOGNITION_FAILURE

next = "# recognition_failure"> </ case>

<case value = CALLER_TIMEOUT

next = "# caller_timeout"> </ case>

<switch>

</ STEP>

<STEP name = recognition_failure>

<prompt >> I did not understand what you said. </ propmt>

<switch name = $ amlvar (amlerror.number_errors_page)>

<case value = 1 next = "# first_error"> </ case>

<case value = 1 next = "# second_error"> </ case>

<case value = 1 next = "# third_error"> </ case>

</ switch>

</ STEP>

<STEP name = first_error>

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

</ STEP>

<STEP name = second_error>

<prompt> $ amlvar (lastshadowprompt) </ prompt>

</ STEP>

<STEP name = third_error>

<prompt> Giving up! </ prompt>

<INPUT type = none next = "navigation">

</ STEP>

A.2 Translation: Tables

The table can be read in multiple ways. This section describes two possible methods. One way is to read the first column of the table at a time and ask the user if they want to proceed. Another way is to allow the user to barge at any time, reading all the rows of the table at once.

A.2.1 One Row At A Time

When the user logs on to the system, the user can use a browser to translate a page with a table of headline news, for example, of a special stock symbol. Selected cells in this table are of special interest. They can specify date, time and headline news respectively. Each column of the table is a news headline for stock symbols. The corresponding AML page is shown below for such an example. It contains both an identification part and a translation part. The identification part comprises cells 1, 3, 5 selected for illustration from a column of the table consisting of a repeating loop and an html page. There is only one step on this page, the Headline. It has a prompt and an input element. The input element of this step belongs to the loop element that loops over the component specified by the component attribute. In conjunction with the input element, there is another prompt that sounds for each iteration of the loop. In this example, the prompt associated with the loop is specified in terms of an array variable, $ amlvar (Headlines [index] .date), meaning the date variable for the current row.

The next attribute has multiple connotation for the option tag. In other words,

(1) next = "# goto": indicates the continuation at goto

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

(3) Next, if next is specified as anything else, ie next = "$ amlvar (c.continue)" or next = http: //www.amazon.com/select/select.cgi, the next step Is traversing the anchor element.

The "next" attribute for the option that follows the prompt per iteration has two possible values. That is, (ⅰ) continue, which is a reserved word that indicates that the system proceeds to the next iteration of the loop. (Ii) $ amlvar (headline [index] .news.url), which specifies that if the user says "Yes" the system should transition to the specified url. Subsequent flow elements define the AML pages required to continue browsing. Here is the AML code with the built-in hearing prompt:

<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 increment = 1

end = $ amlvar (headlines.length) next = # query> </ LOOP>

</ STEP>

<STEP name = "query">

<PROMPT>

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 No to go to the next healine

</ PROMPT>

<INPUT type = optionlist grammar = ". YesNoNavigation">

<OPTION next = "return"> No </ OPTION>

<OPTION NEXT = $ amlvar (Headlines [index] .url) "> Yes

</ OPTION>

</ INPUT>

</ STEP>

<FLOW

Name = "datailflow"

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 Columns Together

All rows can be read one by one and the user can be prompted for direction at the end of the reading. They can be enhanced to add support for barge-in, ie allow the user to interrupt playing of the list in the middle.

<STEP Name = "Headlines">

<PROMPT>

Here are the headlines. If you want to hear the complet story say Yes for the headline

</ PROMPT>

<LOOP name = headlines loopindex = index

next = "# query" start = 0 increment = 1

end = $ amlvar (Headlines.length)>

</ LOOP>

</ STEP>

<STEP name = "query">

<PROMPT>

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>

<option next = "return"> No </ OPTION>

</ INPUT>

</ STEP>

The pants-in need to say yes only if they want the user to hear the news and want to hear detailed news. This minimizes the number of things the user must say.

A.3 Translation: Variable Looping Elements

As another example, assume the following translation of the variable looping example. The step after component identification is not much different from the rendering of the table in the previous example.

<STEP Name = "resultssection">

<PROMPT>

Here are the book search result. If you want to hear more

details about a book say Yes

</ PROMPT>

<LOOP name = resultssection2 loopindex = index

start = 0 increment = 1 end = $ amlvar (resultssection2.length)

next = "# part">

</ LOOP>

</ STEP>

<STEP name = "part">

<PROMPT>

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>

<INPUT NAME = "choice" TYPE = OPTIONLIST bargein = true

grammar = ". YesNoNavigation"

onError = "# error">

<option NEXT = "$ amlvar (resultssection2 [index] .detail)">

yes </ OPTION>

<option next = "return"> no </ OPTION>

</ INPUT>

</ STEP>

A.4 Translation: Alternate Structures

In the repeating structure of the previous example, each column had the same structure and the selected cell provided the necessary input. This section shows an example where the column structures are not the same.

Example 1

The following table can be rendered with different prompts for different cases of 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 Name = "transactionList" next = "# finish">

<LOOP name = transactionList loopindex = index

start = 0 end = $ amlvar (transactionList.length) increment = 1

next = "# iteration">

LOOP>

</ STEP>

</ STEP name = "# finish">

<PROMPT> You have now heard your entire transaction list.

Should I return to the main menu?

</ PROMPT>

<INPUT TYPE = OPTIONLIST grammar = ". YesNoNavigation"

NAME = "choice"

onError = "# error">

<option NEXT = "/ trading / center" Value = "yes">

yes <OPTION>

<option Next = "# exit" Value = "no"> no </ option>

</ INPUT>

</ STEP>

<STEP name = "iteration" next = "return">

<SWITCH name = transactionList [index] .define>

<CASE value = "INTEREST" next = "# interest> </ CASE>

<CASE value = "DIVIDEND" next = "# dividend"> </ CASE>

<CASE value = default next = "# default"> </ CASE>

</ SWITCH>

</ STEP>

</ STEP name = "interest>

<PROMPT> Interest $ amlvar (transactionList [index] .ico12) was

posted on $ amlvar (transactionList [index] .ico15). </ PROMPT>

<INPUT type = none next = "return">

</ STEP>

</ STEP name = "dividend">

<PROMPT> Dividend $ amlvar (transactionList [index] .dcol2) was

posted on amlvar (transactionList [index] .dco15)

for stock symbol $ amlvar (transactionList [index] .dcol1).

</ PROMPT>

<INPUT type = none next = "return">

</ STEP>

</ STEP name = "default">

<PROMPT> A $ amlvar (transactionList [index] .co14)

$ amlvar (transactionList [index] .co13) shares at

$ amlvar (transactionList [index] .co12) of

$ amlvar (transactionList [index] .co11) was posted on

$ amlvar (transactionList [index] .co15).

</ PROMPT>

<INPUT type = none next = "return">

</ STEP>

Example 2

The following AML code renders a trade history table. There are two loops, one through the stock symbol and the other through the transaction history loop for each symbol.

<Dialog Name = "allstocks" greeting = "This is the Trade History page">

<!-Loop over all the stocks one by one>

<STEP Name = "allstocks">

<loop name = stocks bargein = true loopindex = index1

start = 0 increment = 1 end = $ amlvar (stocks.length)

next = "# iteration1">

</ loop>

</ STEP>

<STEP name = "iteration1">

<PROMPT> Please say yes if you want to listen to the orders for

$ amlvar (stocks [index1] .stock).

</ PROMPT>

<INPUT TYPE = "OPTIONLIST" GRAMMAR = ". YesNo" NAME

= "choice">

<option Next = "# stock1" Value = "Yes"> </ option>

<option Next = "return" Value = "No"> </ option>

</ INPUT>

</ STEP>

<!-For each stock, loop over the trades for that stock>

<STEP Name = "stock1" next = return>

<LOOP NAME = stock1 loopindex = index2 next = "# iteration2"

start = 3 increment = 1 end = $ amlvar (stock1.length)

order = $ amlvar (stock1 [index2] .closed) direction = descend>

</ LOOP>

</ STEP>

<STEP name = "iteration2">

<switch name = stock1 [index] .define>

<case value = "CLOSED" next = "# closed"> </ case>

<case value = "OPEN" next = "# open"> </ case>

</ switch>

</ STEP>

<! Prompt for open trades>

<STEP name = "open">

<PROMPT>

$ amlvar (stock1 [index2] .orderno) is currently open, and is a

$ amlvar (stock1 [index2] .action)

for $ amlvar (stock1 [index2] .qty) shares of

$ amlvar (allstocks [index1] .stock) at price

$ amlvar (stock1 [index2] .price). It was posted on

$ amlvar (stock1 [index2] .date) with a time limit of

$ amlvar (stock1 [index2] .limit)

</ PROMPT>

<INPUT type = none next = "return">

</ STEP>

<! prompt for closed trades>

<STEP name = "closed">

<PROMPT>

$ amlvar (stock1 [index2] .order no) was a

$ amlvar (stock1 [index2] .action) for

$ amlvar (stock1 [index2] .qty) shares of

$ amlvar (allstocks [index1] .stock) at price

$ amlvar (stock1 [index2] .price). It was posted on

$ amlvar (stock1 [index2] .date) with a time limit of

$ amlvar (stock1 [index2] .limit) The transaction was closed

on $ amlvar (stock1 [index2] .date2) and the action was

$ amlvar (stock1 [index2] .action2).

</ PROMPT>

<INPUT type = none next = "return">

</ STEP>

B. Flow: Specialized urls / form actions

Transitions from a page of html to another page of html can be enabled either as a url or as a form action element. They also define the ranking among the corresponding audio page specifications according to the invention. Thus, it may have a mapping called "flow" that defines a destination url and a destination voice element. For simplicity and perhaps easier navigation, raw url and raw page information will also be stored. The url can have a static part and a dynamic part. In the operation, the structure attribute for the component specification to specify the variable urls is reused.

In the GUI section, there are two levels of conversion of html pages to audio "programs". At the first level, individual html pages are converted to the corresponding audio pages. At the second level, all audio pages are displayed and the user is forced to form a transition between the various audio pages using the urls / form action method in the corresponding html component. For each url transition, an audio element is formed, which will be kept internally in the mapping of "urls-> audioid" where audioid is the identifier of the audio page.

The url transition is specified using a flow element. The flow element specifies the url and its corresponding dialog. Consider the following href statement in the html page:

<a

HREF = "/ trading / generic /? FormName = DelayedQuotes"

NAME = CompanyNewsTARGET = "CCBodyi"

onMouseOver = "parent.self.status = 'Company News'; return true">

<u> Company </ u>

</a>

If the user can traverse this url, then the corresponding flow specification would be:

<flow

Name = "CompanyNews"

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

Sourceaudio = logon

Destination = "... trading / generic /? FormName = DelayedQuotes"

Destinationaudio = headlines>

</ flow>

Similarly, in the Amazon home page example, the form component is selected, and then the mode of operation for ranking is implicitly selected. Therefore, it is necessary to form a flow element for it. For example, a form element begins with:

<form method = "post"

action = "/ exec / obidos / generic-quicksearch-query / 002-0363237-

2566852 ">

The destination url when the form is submitted

http://www.amazon.com/exec/obidos/generic-quicksearch-query / 002-0363237 -2566852 It has a static part: http://www.amazon.com/exec/obidos/generic-quicksearch-query / and a variable part: 002-0363237-2566852. The variable part is the session-id assigned to the new session coming into the amazon.com page. The flow component for these pages 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.amazon.com/exec/obidos/generic-

quicksearch-query / <amlvar name = sessionid> "

sourceaudio = homepage

destinationaudio = Resultpage>

</ flow>

The caller / speech user may navigate between different audio steps using navigation commands such as back, forward, stop continue, and refresh. The transition is formed between the steps represented by the transition step. The back and forward instructions will direct the caller back or forward to the next transition phase, respectively. A stop will terminate the current rendering or background execution of the session. The continue will work from where it was stopped. Refresh will play when the html page normally diagnoses the session. Thus, in the following AML language code, the headline phase is represented as a transition phase using an 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 name = headlines loopindex = index

next = "# query" start = 0 increment = 1

end = $ amlvar (headlines.length)>

</ LOOP>

</ STEP>

Not all steps need to be converted. Thus, internally, the form will be translated in multiple stages and the user is always able to translate to the first stage of the form.

C. AML (DTD Specification)

C.1 overall document

The following is the specification of audio language AML. Other languages can be generated according to this example of syntax and subject to constraints that are modified or formed to work in the intended medium. Accordingly, these specifications are illustrative and not restrictive.

<! ELEMENT DIALOG (component│form│step│flow) *>

<! ATTLIST dialog #audio page element

name CDATA #name of object

url CDATA #sructure of url

greeting CDATA #information greeting user on entering audio page

#this is read out when user reachesthis

audio page for the

#first time, or thereafter while navigating through the

#audio pages

cookies CDATA #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 CDATA #ordinal element number of component in the patent 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

sructure 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) *>

<! ATTLIST idloop

ignore

(ALL│ALL_BUT_FIRST│ALL_BUT_LAST│LAST│EVEN│ODD)

name CDATA #name of component

loopindex CDATA #name of loop index

>

<! ELEMENT FLOW

<! ATTLIST flow #flow 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

desinationaudio CDATA; #desination audio page id

desinationstep CDATA; #starting step in new audio

element

>

<! ELEMENT AMLVAR>

<! ATTLIST amlvar #variable element--

name CDATA; #name of variable

type (char│int│money│dete│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 step #that enclose loop and switch

>

<! ELEMENT input (option│rename) *>

<! ATTLIST step

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 aml variable

GRAMMARNAME CDATA #grammar slot name

>

The invention has been described with reference to specific embodiments. Other embodiments will be apparent to those skilled in the art. Accordingly, it is not intended that the invention be limited, except as indicated by the appended claims.

Claims (33)

In a computer network system having a storage means for source data and a means for identification of the small stator, an aural or other visual form for the representation of two-dimensional data that is part of a mathematical regular expression. In a method of rendering in a visual form, the expression is a signature obtained from analysis of a mathematical regular element, and the rendering method is Responsive to an inquiry from a user, retrieving the signature from the storage means; Retrieving the current value of the corresponding element from the source means as indicated by the signature; Translating the current value into an output via a preselected language translator; And Rendering the output to the user. The method of claim 1, And the preselected language translator is a text to speech translator. The method of claim 1, And said preselected language translator is a set of stored auditory equations mapped to preselected values for each of said elements. The method of claim 1, And said preselected language translator comprises a simplified textual engine mapped to a preselected value for each of said elements. Means for receiving source language information from a host web server that specifies web elements; Means for receiving a mathematical regular expression identifying at least one web element specified by the source language information; And means for using the source language information and the mathematical regular expression to generate target language information such that a runtime engine can present the identified web element. The method of claim 5, And the source language information comprises HTML data. The method of claim 5, And said target language information comprises HTML data. The method of claim 5, And the target language information comprises a runtime object. The method of claim 5, And the identified web element includes flow control information. The method of claim 5, And the identified web element includes a list of options. The method of claim 5, And wherein said identified web element comprises a table. The method of claim 5, And wherein the identified web element includes a request for logon information. The method of claim 5, The runtime engine comprises a text-to-speech engine. The method of claim 5, The translator comprises a text-to-speech engine. The method of claim 5, The translator comprises an auditory equation that maps to a preselected value for the identified web element. The method of claim 5, And the translator comprises a simplified textual expression that maps to a preselected value for the identified web element. Receiving source language information from a host web server that specifies web elements; Receiving a mathematical regular expression identifying at least one web element specified by the source language information; And Generating target language information from the source language information and the mathematical regular expression so that a runtime engine can present the identified web element. Receiving source language information from a host web server that specifies web elements; Receiving a mathematical regular expression identifying at least one web element specified by the source language information; And And store program code for causing a computer to perform steps of generating target language information from the source language information and the mathematical regular expression so that a runtime engine can present the identified web element. media. Receiving HTML page information from a host web server; Retrieving a target language script from a persistent store; Translating the HTML page information according to the target language script to generate translated HTML page information; Presenting the translated HTML page information to a user via a rendering device. The method of claim 19, And wherein said translating comprises extracting dynamically updatable data from said HTML page information. The method of claim 19, The translated HTML page information is presented audibly. The method of claim 19, Wherein the translated HTML page information includes a runtime object. The method of claim 19, The presenting step includes interactively providing a prompt element to the user and receiving an input element from the user. The method of claim 19, And the rendering device is a telephone. The method of claim 19, And the HTML page information is a web page. The method of claim 19, Identifying selected HTML page information to be translated. A method for providing interactive user access to web page information, the method comprising: Receiving web page information from a host web server; Converting the web page information into a current presentation dialog comprising a presentation page presentable to a user through a rendering device; Receiving a current presentation page transition from the user; Defining a presentation element by mapping a transition page to a web page information target and a transition step corresponding thereto; Receiving a user navigation command; And And if the received user navigation command matches the presentation element, generating a transition step in which a dialog corresponding to the web page information target is presented. The method of claim 27, And the transition page is a page presented to the user just before the step of receiving the presentation page transition. The method of claim 27, And the navigation command comprises a backward command causing the preceding dialog to be presented. The method of claim 27, The navigation command, A backward instruction that causes the user to return to the next transition step, and Forward instructions for directing the user to the next transition step. The method of claim 27, The navigation command, A stop instruction that terminates execution of the corresponding current rendering device, and And a continue command to initiate execution of the corresponding rendering device from where the execution was stopped. The method of claim 27, And the navigation command includes a refresh command to refresh the HTML page currently under investigation. The method of claim 27, Wherein the presentation page comprises an audio page and the presentation element is an audio element.