WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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.
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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.
2
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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.1 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>
<STEP Name = "Logon">
<PROMPT> Please speak the eight digits in your account number
</PROMPT>
<INPUT TYPE="DIGITS" NAME="SignonAccountNumber"
NEXT = "#F2"> </INPUT>
</STEP>
<STEP Name = "F2">
<PROMPT> Please speak your password </PROMPT>
<INPUT TYPE="STRING" NAME="SignonPassword" NEXT =
"#F3 "></INPUT>
</STEP>
<STEP Name = "F3">
<PROMPT> Please choose from one of the following options.
Account Overview, Stock Trading, Options Trading, Mutual Fund
3
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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--"StartAnchor"
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)"
4
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
Component="Logon">
<PROMPT> Attempting to Log on to Charles Schwab
</PROMPT>
</FORM>
<flow
Name = "formflow"
Source=" https://trading2.schwab.com/tradinglsignon/."
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 F1, 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
5
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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:
<STEP Name = "stock">
<PROMPT> What would you like to trade? </PROMPT>
<INPUT TYPE = "GRAMMAR" GRAMMAR=".StockTrade2"
onError=-"#error">
<RENAME VARNAME="TradeType"
GRAMMARNAME--"A 1 ">
<RENAME VARNAME "Symbol"
GRAMMARNAME--''A2 ">
<RENAME VARNAME="OrderType"
GRAMMARNAME="A3">
<RENAME VARNAME="LimitPrice"
GRAMMARNAME="A4">
<RENAME VARNAME="TimeLimit"
GRAMMARNAME--"AS ">
<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 aml pages.
<STEP name=error global=true>
<switch name=$amlvar(amlerror.type)>
6
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<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. </prompt>
<switch name=$amlvar(amlerror. number_errors_page)>
<case value=1 next "#first error"> </case>
<case value=2 next="#second error"> </case>
<case value=3 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
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.
7
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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., $amlvar(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.url),
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 increment=1
end=$amlvar(headlines.length) next=#query></LOOP>
</STEP>
8
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<STEP name="query">
<PROMPT>
News on Date $amlvar(Headlines[index].date) at
S 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>
<INPUT type=optionlist grammar=".YesNoNavigation">
<OPTION next "return" > No </OPTION>
<OPTION NEXT="$amlvar(headlines[index].url)"> Yes
</OPTION>
</INPUT>
1 S </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>
9
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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>
<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>
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.
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<STEP Name = "resultssection">
<PROMPT>
Here are the book search results. 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">
<fLOOP >
</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 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.
11
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
Example 1
The following table can be rendered with different prompts for different
cases in the table as follows:
Stock PriceQuantity Operation Date
IFMX 10.50100 BUY 5/25/98
ORCL 51.5 200 SELL 5/26/98
IBM 171.5DIVIDEND 5/27/98
IBM 51.5 INTE
<STEP Name="transactionList" next="#finish">
<LOOP name=transactionList loopindex=index
start=0 end=Samlvar(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>
12
WO 01/18692 CA 02384618 2002-03-08 pCT/US00/24546
<CASE value="DIVIDEND" next="#dividend"></CASE>
<CASE value=default next="#default"></CASE>
</SWITCH>
</STEP>
<STEP name="interest>
<PROMPT> Interest $amlvar(transactionList[index].icol2) was
posted on $amlvar(transactionList[index].icol~). </PROMPT>
GINPUT type=none next="return">
</STEP>
<STEP name--"dividend">
<PROMPT> Dividend $amlvar(transactionList[index].dcol2) was
posted on amlvar(transactionList[index].dcol5)
for stock symbol $amlvar(transactionList[index].dcoll).
</PROMPT>
<INPUT type=none next="return">
</STEP>
<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].colt) was posted on
$amlvar(transactionList[index].col5).
</PROMPT>
<INPUT type=none next="return">
</STEP>
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.
<Dialog Name="allstocks" greeting = "This is the Trade History page">
<!-Loop over all the stocks one by one >
13
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<STEP Name = "allstocks">
<loop name=stocks bargein=true loopindex=index)
start=0 increment=1 end=$amlvar(stocks.length)
next "#iterationl">
</loop>
</STEP>
<STEP name="iteration)">
<PROMPT>Please say yes if you want to listen to the orders for
$amlvar(stocks[index)].stock).
</PROMPT>
<INPUT TYPE = "OPTIONLIST" GRAMMAR=".YesNo" NAME
_ "choice">
<option Next="#stockl" Value="Yes"> </option>
<option Next="return" Value="No"> </option>
</INPUT>
</STEP>
<~-For each stock, loop over the trades for that stock >
<STEP Name = "stock)" next=return>
<LOOP NAME=stock) loopindex=index2 next-"#iteration2"
start=3 increment=1 end=$amlvar(stockl.length)
order=$amlvar(stockl [index2].closed) direction=descend >
</LOOP>
</STEP>
<STEP name="iteration2">
<switch name=stock) [index].define>
<case value="CLOSED" next="#closed"> </case>
<case value="OPEN" next "#open"></case>
</switch>
</STEP>
14
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<! 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>
<INPUT type=none next="return">
</STEP>
<!prompt for closed trades>
<STEP name--"closed">
<PROMPT>
$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(stockl[index2].date) with a time limit of
$amlvar(stockl [index2].limit). The transaction was closed
on $amlvar(stockl [index2].date2) and the action was
$amlvar(stockl [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
WO 01/18692 CA 02384618 2002-03-08 pCT/US00/24546
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
16
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
necessary to define the flow element for it. The form element starts off for
example as
follows:
<form method="post"
action="/exec/obidos/generic-quicksearch-query/002-0363237-
2566852" >
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"
1 S 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=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>
17
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
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 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.1 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 CDATA # name of object
url CDATA # structure of url
greeting CDATA # 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 CDATA # any associated cookies with page, may be
necessary for
18
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
# 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 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 obj ect>
<~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
19
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<!ELEMENT idloop (component~idswitch~idloop)*>
<!ATTLIST idloop
ignore
S (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
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 l, 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.
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
visible (true~false) # visible part of text, i.e., what you
see on
# the screen, see Section S.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 (YEN) # default is yes (Y)
grammar CDATA # grammar describing what to expect
21
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
# 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
22
WO 01/18692 CA 02384618 2002-03-08 PCT/US00/24546
<!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 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.
23
