Language selection

Search

Patent 2384618 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent Application: (11) CA 2384618
(54) English Title: METHOD FOR CUSTOMIZING AND RENDERING OF SELECTED DATA FIELDS
(54) French Title: PROCEDE DE PERSONNALISATION ET DE RESTITUTION DE CHAMPS DE DONNEES SELECTIONNES
Status: Deemed Abandoned and Beyond the Period of Reinstatement - Pending Response to Notice of Disregarded Communication
Bibliographic Data
(51) International Patent Classification (IPC):
  • H04M 3/493 (2006.01)
(72) Inventors :
  • IYER, PRAKASH (United States of America)
  • GOEL, PIYUSH (United States of America)
  • MOHINDRA, RAJEEV (United States of America)
  • SINHA, AMITABH (United States of America)
  • KROTHAPALLI, PRASAD (United States of America)
  • MAK, RONALD (United States of America)
  • VITTAL, SHASHI (United States of America)
(73) Owners :
  • EVERYPATH, INC.
(71) Applicants :
  • EVERYPATH, INC. (United States of America)
(74) Agent: GOWLING WLG (CANADA) LLP
(74) Associate agent:
(45) Issued:
(86) PCT Filing Date: 2000-09-06
(87) Open to Public Inspection: 2001-03-15
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): Yes
(86) PCT Filing Number: PCT/US2000/024546
(87) International Publication Number: WO 2001018692
(85) National Entry: 2002-03-08

(30) Application Priority Data:
Application No. Country/Territory Date
09/393,133 (United States of America) 1999-09-10

Abstracts

English 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.


French Abstract

La présente invention concerne un procédé dans lequel les éléments de données sélectionnés et identifiés au moyen d'une signature extraite d'une expression mathématiquement régulière de données peuvent être restitués au demandeur via un traducteur de langage approprié d'intérêt au moyen d'un système qui est conçu pour avoir accès à des éléments en se référant à la signature. Les traducteurs de langage d'intérêt peuvent comprendre des traducteurs de conversion texte-voix, des expressions orales enregistrées adressées aux éléments et des expressions textuelles simplifiées programmées pour correspondre à l'expression HTML. Dans un autre aspect de l'invention, le procédé comprend également l'identification des éléments sélectionnés, la personnalisation des éléments sélectionnés pour les rendre compatibles avec le contexte voulu, et la spécification ultérieure des éléments sélectionnés et personnalisés via un traducteur de langage approprié d'intérêt.

Claims

Note: Claims are shown in the official language in which they were submitted.


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.
24

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.
26

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
27

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.
28

Description

Note: Descriptions are shown in the official language in which they were submitted.


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

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Inactive: IPC expired 2020-01-01
Inactive: IPC expired 2020-01-01
Inactive: IPC expired 2019-01-01
Inactive: IPC from MCD 2006-03-12
Inactive: IPC from MCD 2006-03-12
Inactive: IPC from MCD 2006-03-12
Time Limit for Reversal Expired 2005-09-06
Application Not Reinstated by Deadline 2005-09-06
Deemed Abandoned - Failure to Respond to Maintenance Fee Notice 2004-09-07
Letter Sent 2003-04-07
Letter Sent 2003-04-07
Letter Sent 2003-04-07
Letter Sent 2003-04-07
Inactive: Correspondence - Transfer 2003-03-19
Inactive: Single transfer 2003-02-11
Inactive: Cover page published 2002-09-06
Inactive: Courtesy letter - Evidence 2002-09-03
Inactive: Notice - National entry - No RFE 2002-08-29
Inactive: Inventor deleted 2002-08-29
Application Received - PCT 2002-06-12
National Entry Requirements Determined Compliant 2002-03-08
Application Published (Open to Public Inspection) 2001-03-15

Abandonment History

Abandonment Date Reason Reinstatement Date
2004-09-07

Maintenance Fee

The last payment was received on 2003-08-22

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Fee History

Fee Type Anniversary Year Due Date Paid Date
Basic national fee - standard 2002-03-08
Registration of a document 2002-03-08
MF (application, 2nd anniv.) - standard 02 2002-09-06 2002-08-23
Registration of a document 2003-02-11
MF (application, 3rd anniv.) - standard 03 2003-09-08 2003-08-22
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
EVERYPATH, INC.
Past Owners on Record
AMITABH SINHA
PIYUSH GOEL
PRAKASH IYER
PRASAD KROTHAPALLI
RAJEEV MOHINDRA
RONALD MAK
SHASHI VITTAL
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Representative drawing 2002-09-04 1 9
Cover Page 2002-09-06 1 46
Abstract 2002-03-08 2 76
Claims 2002-03-08 5 159
Description 2002-03-08 23 729
Drawings 2002-03-08 1 17
Reminder of maintenance fee due 2002-08-29 1 109
Notice of National Entry 2002-08-29 1 192
Request for evidence or missing transfer 2003-03-11 1 105
Courtesy - Certificate of registration (related document(s)) 2003-04-07 1 130
Courtesy - Certificate of registration (related document(s)) 2003-04-07 1 130
Courtesy - Certificate of registration (related document(s)) 2003-04-07 1 130
Courtesy - Certificate of registration (related document(s)) 2003-04-07 1 130
Courtesy - Abandonment Letter (Maintenance Fee) 2004-11-02 1 176
Reminder - Request for Examination 2005-05-09 1 116
PCT 2002-03-08 5 276
Correspondence 2002-08-29 1 24
Fees 2002-08-23 1 31