(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(19) World Intellectual Property Organization
`International Bureau
`
`(43) International Publication Date
`14 February 2002 (14.02.2002)
`
`(10) International Publication Number
`
`WO 02/12982 A2
`
`(51) International Patent Classification7:
`
`G06F
`
`(21) InternationalApplication Number:
`
`PCT/US01/25036
`
`(22) International Filing Date:
`
`8 August 2001 (08.08.2001)
`
`CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH,
`GM, IIR, IIU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC,
`LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW,
`MX, MZ, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK,
`SL, TJ, TM, TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW.
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(30) Priority Data:
`09/634,108
`
`8 August 2000 (08.08.2000)
`
`US
`
`(71) Applicant: OBJECT SERVICES AND CONSULTING,
`INC. [US/US]; 2725 Deep Valley Trail, Plano, TX 75203
`(US).
`
`(74) Agent: LANGLEY, H., Dale, Jr.; The Law Office of II.
`Dale Langley, Jr., PC., 610 West Lynn, Austin, TX 78703
`(US).
`
`(81) Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU,
`
`Designated States (regional): ARIPO patent (GII, GM,
`KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian
`patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European
`patent (AT, BE, CH, CY, DE, DK, ES, PI, FR, GB, GR, 1]},
`IT, LU, MC, NL, PT, SE, TR), OAPI patent (BF, BJ, CF,
`CG, CI, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD,
`TG).
`
`Published:
`without international search report and to be republished
`upon receipt of that report
`
`For iwo—lezter codes and other abbreviations, refer to the "Guid-
`ance Notes on Codes andAbbreviations " appearing at the begin-
`ning ofeach regular issue ofthe PCT Gazette.
`
`(54) Title: GUIDED NATURAL LANGUAGE INTERFACE SYSTEM AND METHOD
`
`Einta-(nu
`
`.------x,,----.-.—.....
`
`U: WP“!-
`-umumu--Mn:
`
`
`
`02/12982A2
`
`(57) Abstract: A method of guided natural language interface includes inputting to a thin client a query, communicating to an in-
`terface intermediary, communicating to an interface descriptor data source, generating an interface descriptor, communicating the
`interface descriptor to the interface intermediary, communicating the interface descriptor to a parser farm, requesting an appropriate
`parser corresponding to the to the interface descriptor, assigning an appropriate parser, parsing, communicating a translation from
`O the step of parsing, to the interface intermediary, and communicating the translation to the thin client. The thin client can be geo-
`graphically remote from any or all of the steps other than the step of inputting, such that the method is performed over a disparate
`3
`enterprise, such as a network, for example, the Internet.
`
`GOOGLE EXHIBIT 1011
`
`Page 1 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`GUIDED NATURAL LANGUAGE INTERFACE SYSTEM AND METHOD
`
`Background of the Invention
`
`The present
`
`invention generally relates
`
`to computers and computing and, more
`
`particularly, to natural language interfaces (NLI) for user interfacing with computing devices to
`
`interact with computer applications,
`
`for example, database programs, on such devices or
`
`interconnected devices, by inputting stated questions or commands in natural language, such as
`
`English language and grammar, to which the devices and applications respond.
`
`Computational
`
`linguistics and natural
`
`language processing are rather specialized
`
`computing disciplines
`
`that
`
`relate to the computer user and his ability and mode of
`
`communication with computing devices.
`
`In the sub-area of natural language processing, more
`
`specific areas of research and development include information retrieval from text (for example,
`
`using keywords as in conventional search engines, such as GoogleTM); question answering from
`
`databases, knowledgebases, or text (for example,
`
`linguistically motivated techniques using
`
`grammars and lexicons but also pattern—based techniques); natural language generation; natural
`
`language translation;
`
`text-to—speech; speaker recognition; ontologies (such as, for example,
`
`WordnetTM), and conversational analysis. A natural language interface (NLI), as the name
`
`implies, is a particular mode or method of user interaction with a computing device or devices in
`
`which the user employs natural
`
`language, such as the English language and grammar,
`
`to
`
`communicate inputs, for example, queries and commands, to the devices and applications of the
`
`devices. NLIs can often be desired modes for communicating with computing devices, software
`
`applications, and related hardware and software components, depending on the particular
`
`application or discipline for the devices and in the case of experienced as well as less-
`
`sophisticated users.
`
`Certain types of natural language interfaces are conventional.
`
`In the conventional NLIs,
`
`the user types or speaks unconstrained commands (including queries) with the expectation that
`
`the system will understand the speech acts and take the desired action (e. g., return an answer).
`
`As can be understood, there are limitations to the capabilities of the conventional NLIs. For
`
`example, computing power and features have not previously been adequate to encompass all
`
`possible variations and uses of language and grammar. Moreover,
`
`the tremendously large
`
`numbers and variables of words, contexts, and meanings with any natural language are nearly
`
`impossible to accurately process under all applicable language rules and variations.
`
`Because of the limitations of computing and NLIs in the past, computing users who
`
`interface using NLIs have typically not fully understood the limited scope and capabilities, or
`
`“coverage”, of the particular NLIs (such as, in terms of the subset of natural language a system
`
`Page 2 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`2
`
`understands,
`
`typically delimited by lexical, semantic, grammatical, and domain coverage
`
`boundaries). Consequently, NLI commands and language are often not fully or properly
`
`interpreted or understood by the NLI or computing system having such interface, and the user
`
`likely will not have sufficient command of the natural language subset and limitations of the NLI
`
`and extensive training or learning can be required in order to make appropriate and desired use
`
`of capabilities of the NLI and related system. The NLIS have not necessarily made interfacing
`
`more inherently understandable or easier to the user.
`
`In other words, the typical user of natural
`
`language commands and NLIS for interfacing with computing devices can risk overshooting or
`
`undershooting the underlying application system's capabilities, because of the limitations of
`
`those capabilities with the present states of computing capacity and technologies and because of
`
`the limits of the user’s knowledge and understanding.
`
`In addition to the implications to computing users who interface via NLIs, computer and
`
`software developers of NLIs for applications have the overwhelming and virtually impossible
`
`task of defining a large number of all possible words, grammar rules, and domain translations
`
`necessary in efforts to increase NLI coverage. Because of the magnitude of the efforts in such
`
`development, NLI creation is an expensive process, even to retarget from one database to
`
`another. All conventional NLIs have limited and mismatch of coverage problems.
`
`In the past,
`
`this has often caused users who experience the coverage problems to grow frustrated, and fail to
`
`make full use or entirely discontinue use of conventional NLIs.
`
`Previously, NLIS have generally been delivered with a set of limited form or “canned”
`
`example queries. Users of the NLIs have been encouraged to use these examples or only slight
`
`variations thereof to obtain satisfactory results. Nonetheless, these example queries, even if only
`
`slightly varied, often tend to interfacing failures or unexpected or incorrect results. Several
`
`conventional NLI products include: Microsoft Easy QueryTM, ELFTM, and iPhraseTM. No doubt,
`
`there are other conventional NLIs and other NLI products. All such known NLI technologies
`
`have been limited, however, in acceptability to few useful applications and to very narrow and
`
`simple applications in any event, and none have become pervasively used or available in the
`
`industry. This is the result of the problems of the conventional NLIs.
`
`Of particular note in the early l980’s, Texas Instruments developed the so-called
`
`“NLMenu” system, a natural language interface technology that sought to address certain of the
`
`foregoing problems of NLIs. NLMenu employed substantially the same grammar, lexicon, and
`
`parsing found in all other NLI systems at the time and even those conventional to date. One
`
`nuance at the time of the NLMenu system was that the typical parser was modified in the system
`
`to parse a partial sentence and,
`
`then, predictively find all next legal completions (i.e.,
`
`the
`
`Page 3 of 85
`
`

`
`WO 02/12982
`
`3
`
`PCT/US01/25036
`
`I
`
`acceptable next words or phrases under the NLMenu interface lexicon and grammar) and display
`
`these legal completions in a constellation menu (i.e., a menu displayed to the user that lists all
`
`next lexical choices organized by grammatical category). The user was then able to select from
`
`the constellation menu a next word or phrase in the menu, which word or phrase was an
`
`appropriate legal completion of the particular natural language input sentence, query, command
`
`or other sequence. The NLMenu system is described in U.S. Patent No. 4,829,423, and certain
`
`additional aspects are described in U.S. Patents Nos. 4,688,195 and 5,083,268.
`
`As with the other conventional NLIs,
`
`the NLMenu system presented many of the
`
`problems previously described. Moreover, the NLMenu system is quite limited in that it is a
`
`single—user system in which constellation menus are displayed on the user’s computing device
`
`and interact with a single, complex full—featured parser. The constellation menus show a single
`
`screen—shot of the user’s display of the entire lexicon useable by the user to interface in the
`
`natural language, but this is a disadvantage because the menus occupy considerable screen area
`
`of the user’s display and often obscure other entities or features displayed on the screen that can
`
`be the subject of the user’s efforts in lodging a natural language query. Switching among and
`
`moving features around on the screen of the display can be inconvenient for the user.
`
`Furthermore,
`
`the parser of the NLMenu system is full—feat11red and so useful for various
`
`situations, but in many instances the parser is excessive in features and cumbersome (i.e.,
`
`overkill) where alternative and simpler kinds of parsers are more useful and practical.
`In
`general,
`the NLMenu system has been useable for certain applications, but not others.
`
`Particularly, the system is not particularly effective for use in present computing environments,
`
`in which scalability, multi-user capability, wide area and remote geographic networking, and
`
`reduced or “thin client” hardware and software is desired.
`
`The present invention overcomes these and other problems of the prior technology.
`
`Summary of the Invention
`
`Embodiments of the present invention include systems and methods for
`
`light—weight
`
`guided NLI client interfaces and supporting parser farms on servers, available concurrently and
`
`in real time to a plurality of users, over disperse and geographically disparate networks, such as
`
`the Internet.
`
`An embodiment is a system for a natural language interface. The system includes a client
`
`device, a server device, and a communications network interconnecting the client device and the
`
`server device.
`
`Another embodiment is a system for a natural language interface. The system includes a
`
`thin client, a parser farm, a parser, a first communications network for communicatively
`
`Page 4 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`4
`
`connecting the thin client and the parser farm, and a second communications network for
`
`communicatively connecting another element selected from the group consisting of the parser
`
`farm and the parser.
`
`Yet another embodiment is a system for a natural language interface. The system
`
`includes a thin client, an interface intermediary, a first communications network connecting the
`
`thin client and the interface intermediary, an interface descriptor data source, a second
`
`communications network connecting the interface descriptor data source and the interface
`
`intermediary, a command intermediary, a third communications network connecting the
`
`command intermediary and the interface intermediary, a parser farm, a fourth communications
`
`network connecting the parser
`
`farm and the interface intermediary,
`
`a parser, a fifth
`
`communications network communicatively connecting the parser to the parser farm, and a sixth
`
`communications network for communicatively connecting the parser and the interface
`
`intermediary.
`
`Another embodiment of the system is a method of a natural language interface. The
`
`method includes inputting to a thin client a query, requesting an appropriate parser for the query,
`
`assigning an appropriate parser, parsing the query, and returning a parsed translation.
`
`Yet another embodiment is a method of parsing. The method includes inputting a query
`
`at a first location and parsing the query at a second location.
`
`Another embodiment is a method of a natural language interface. The method includes
`
`inputting to a thin client a query, communicating to an interface intermediary, communicating to
`
`an interface descriptor data source, generating an interface descriptor, communicating the
`
`interface descriptor to the interface intermediary, communicating the interface descriptor to a
`
`parser farm, requesting an appropriate parser corresponding to the interface descriptor, assigning
`
`an appropriate parser, parsing, communicating a translation from the step of parsing,
`
`to the
`
`interface intermediary, and communicating the translation to the thin client.
`
`Brief Description of the Drawing
`
`The present invention may be better understood, and its numerous objects, features, and
`
`advantages made apparent to those skilled in the art by referencing the accompanying drawings.
`
`Fig 1 illustrates embodiments of a client—server system, including a client device and a
`
`server device, communicatively connected by a network, such as the Internet, for serving as a
`
`natural language interface system.
`
`Page 5 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`5
`
`Fig. 2 illustrates embodiments of a method of operation of the client-server system of
`
`Fig. 1, providing a multi-user, multi—device, geographically disparate communications system
`
`having a natural language interface.
`
`Fig. 3 illustrates embodiments of a system for a natural language interface over a network
`
`of multiple and geographically disparate users and devices, such as the Internet.
`
`Fig. 4 illustrates embodiments of a method of a natural language interface over a network
`
`of multiple and geographically disparate users and devices, such as the Internet.
`
`Fig. 5 illustrates embodiments of a natural language interface system, as found in one
`
`such exemplary system referred to as the LingoLogic (LL) system.
`
`Fig. 6 illustrates embodiments of a distinctive avatar employed to initiate a query or
`
`command of the natural language interface system of Fig. 5.
`
`Fig. 7 illustrates embodiments of a sequence of web-links and a popup menu used to
`
`specify a query or command of the natural language interface system of Fig. 5.
`
`Fig. 8 illustrates embodiments of a cascading menu used to specify a query or command
`
`of the natural language interface system of Fig. 5.
`
`Fig. 9 illustrates embodiments of phrase buttons used to specify a query or command of
`
`the natural language interface system of Fig. 5 .
`
`Fig. 10 illustrates embodiments of a type-in display used to specify a query or command
`
`of the natural language interface system of Fig. 5.
`
`Fig. 11 illustrates embodiments of a drop down menu used to specify a query or
`
`command of the natural language interface system of Fig. 5.
`
`Fig. 12 illustrates embodiments of inputs and outputs of a Portable Specification Editor.
`
`Fig. 13 illustrates embodiments of methods of importing an ODBC database schema into
`
`the Portable Specification Editor.
`
`Fig. 14 illustrates embodiments of a screen—shot of the Portable Specification Editor,
`
`illustrating how an interface designer can create a portable specification from a database schema
`
`that can then be used to auto-generate a guided natural language interface.
`
`Fig. 15 illustrates embodiments of a simple expert used to specify a value in a query or
`
`command of a natural language interface system.
`
`Page 6 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`6
`
`Fig. 16 illustrates embodiments of a data source expert used to specify a value in a query
`
`or command of a natural language interface system, wherein the value is shown during and after
`
`invocation of the expert.
`
`Fig. 17 illustrates embodiments of a translation of a sample query into SQL,
`
`in
`
`accordance with a natural language interface system, such as the LingoLogic system.
`
`Fig. 18 illustrates embodiments of execution results of a sample query in a tabular format
`
`for a natural language interface system, such as the LingoLogic system.
`
`The use of the same reference symbols in different drawings indicates similar or identical
`
`items.
`
`Detailed Description
`
`In computing, communications and processing devices, embodiments provide guided
`
`interfaces to such devices and their applications, which guided interfaces are operable as
`
`distributed parts of a guided language processor to client devices and server devices, such as in a
`
`computer or communications network.
`
`Particularly, completion—based interfaces, such as
`
`grammar—driven menu—based restricted language interfaces (or so-called “natural
`
`language
`
`interfaces” (NLI)), and also other interfaces such as guided navigation of categories, path
`
`expressions, and languages other than natural languages, as well as speech interfaces to such
`
`guided interfaces, are operable distributed among client and server elements. This distribution
`
`enables predictive parsing, as well as translation and execution, concurrently and in real time,
`
`supporting pluralities of users to simultaneously specify pluralities of queries or commands
`
`interfaced to pluralities of devices and applications, including over a network or other distributed
`
`computing environment. The embodiments are operable, for example, on the Internet and World
`
`Wide Web network. Additionally, embodiments are operable in local area networks and even on
`
`a single computer or device.
`
`Referring to Fig. 1, a system 100 for a communicative network includes a server element
`
`102 and a client element 104. The client element 104 is communicatively connected to the
`
`server element 102 by a communicative connector 106. The server element 102 is any of a wide
`
`variety of processing or communications devices, such as, for example, a computer, a processor,
`
`a circuit, memory or other element within a processor or processing device, or any device
`
`including any such matter, which server element 102 is capable of functioning to receive a
`
`communicated request and appropriately respond. The client element 104 is also any of a wide
`
`variety of processing or communications devices, such as, for example,
`
`those previously
`
`mentioned, which client element 104 is capable of sending or causing the sending of a request
`
`Page 7 of 85
`
`

`
`W0 02/12932
`
`PCT/US01/25036
`
`7
`
`and receiving a communicated response. The communicative connector 106 is any of a wide
`
`variety of communication channels and elements therefor, including, for example, a wire, a
`
`circuit, a bus, a cable, a wired or wireless communications network, or any other device or
`
`component
`
`that allows
`
`for communications, electrical or otherwise, between elements
`
`functioning to communicate in a client—server manner. For purposes hereof, a client—server
`
`system or function is to be broadly construed to include any and all communicative arrangements
`
`in which elements, devices, or components intercommunicate, directly or through intermediary
`
`systems, by generation of a request, receipt of the request, generation of a response, and
`
`occurrence of the response. The client—server system and function, as so construed, includes
`
`client—server operations over a network, such as the Internet or World Wide Web, another wide
`
`area network, a local area network, and even within a device among elements, components, or
`
`peripherals of the device, such as within a single computer or other processing device.
`
`In operation, the system 100 operates, at least in part, in a client—server manner, such that
`
`the client element 104 delivers a request over the communicative connector 106 to the server
`
`element 102. The server element 102 receives the request and directly or indirectly processes it.
`
`The server element 102 then appropriately responds
`
`to the request,
`
`for example, by
`
`communicating a response signal back to the client element 104 over the communicative
`
`connector 106. Although the communicative connector 106 is illustrated in Fig. 1 as a simple
`
`line connection between the client element 104 and the server element 102, it is to be understood
`
`that
`
`the communicative connector 106 can be any of a wide variety of communicating
`
`intermediate devices,
`
`connections,
`
`and elements of a network or
`
`system that
`
`are
`
`communicatively connected to enable inter-communications in the client—server manner just
`
`described. For example,
`
`the communicative connector 104 in certain embodiments is the
`
`Internet and each of the client element 104 and the server element 102 is a separate, disparate
`
`processing device connected to the Internet. Of course, as has been more fully described, all
`
`other network or interconnection of devices or components is possible and included within the
`
`scope of the embodiments.
`
`Referring to Fig. 2, a method 200 operable on the system 100 of Fig. 1 includes a step
`
`202 of inputting a query or command to a client.
`
`In the step 202, for example, a human user
`
`inputs, via input components such as a keyboard to a computing device as the client, a database
`
`or other application query in a natural language, such as English grammar and lexicon, through a
`
`natural language interface (NLI).
`
`In a step 204, a request is made, such as via the client to
`
`another device, for example, a server, for an appropriate parser for parsing the particular NLI
`
`input of the step 202.
`
`Page 8 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`8
`
`Referring to Figs. 1 and 2, in conjunction, if, for example, the method 200 operates on a
`
`system 100 that includes the Internet as the communicative connector 106 between a client
`
`element 104 and the server element 102, the step 202 of inputting is performed at the Client
`
`element 104 and the step 204 of requesting an appropriate parser is communicated over the
`
`communicative connector 106 to the server element 102. The server element 102 can maintain
`
`or make accessible a selection of parser from among one or more parsers of a so-called “parser
`
`farm”.
`
`In this manner, an appropriate parser for the particular input from the client element 104
`
`is useable, and the parser need not (although it may be) available in or at the client element 104
`
`itself.
`
`In the trade, the term “thin client” is sometimes used to refer to a client in a client—server
`
`system which does not itself have substantial processing or operative capability within the client,
`
`and such thin client relies on other units, such as a server, for processing and operative
`
`capabilities available on the client’s request. The method 200 is particularly applicable to such
`
`thin client environments, as those skilled in the art will understand and appreciate.
`
`Continuing to refer to Fig. 2, a step 206 of the method 200 assigns the appropriate parser
`
`for parsing the input of the step 202. The appropriate parser, in any instance, will depend on
`
`several variables, including, for example, the numbers and types of parsers available for the
`
`application and the particular system 100 and method 200 capabilities and operations. Selection
`
`of parsers among several choices is subject to many possibilities. On selection of the parser in
`
`the step 206, the parser in a step 208 performs a parse of the query or command input in the step
`
`202. The step 208 is repeated until a well formed grammar constituent is specified. Once the
`
`parse in the step 208 is completed, a step 210 returns a translation from the parser of the parsed
`
`query or command.
`
`Referring to Figs. 1 and 2, in conjunction, in a possible example in which the method 200
`
`operates on a system 100 that includes the Intemet as the communicative connector 106 as
`nrevinnslv menrinned, the annrnnriate narser remiested and chosen in the stem 204 is resident rm
`
`Page 9 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`9
`
`smart phone, a set top box, a Palm” device, a toy controller, a remote control and any other
`
`device having functions of input and request communication. The user of the thin client 302 is
`
`most likely a human user, however, it can alternatively be a software or hardware agent which
`
`interacts with the thin client 302 to input and receive responses.
`
`Maintained on the thin client 302 can be a host application (not shown), such as a
`
`software program, embedded program, or hardware functional unit, which initiates a
`
`communicative interaction by the thin client 302 with other elements of the implementation 300.
`
`Examples of host applications are a web browser, Microsoft Wordm, or a specialized or other
`
`stand-alone application.
`
`In addition, the thin client 302 can include a target application (not shown) that receives a
`translation (as hereafter described) of a query or command corresponding to the input to the thin
`
`client 302 and returns results (as hereafter described), including status messages, for example,
`
`for display on the thin client 302. The target application can be included in or the same as, or
`
`different or distinct from, the host application of the thin client 302. Several exemplary types of
`
`target applications include database management system (DBMS) systems, word processors,
`
`game programs, robots with sensors and feedback,
`
`toys, video cassette recorders (VCRs),
`
`military equipment, and other machines and devices with software interfaces.
`
`The thin client 302 can include various elements, including, for example, an input/output
`
`display that the user can use to construct queries and commands and View results. The thin client
`
`302 can be any of a variety of presently available and even future applications and devices, for
`
`example, as simple as a web page with no onboard processing, where the query or command
`
`then-input by the user plus choices for next inputs are displayed, or the thin client 302 can be
`
`implemented using compiled,
`
`interpreted, or scripted languages such as C/C++, Java, or
`
`Javascript. The thin client 302 can even be generated on—the—fly, such as by an interface
`
`intermediary 312 hereafter discussed. Moreover, depending on the particulars of
`
`the
`
`implementation 300, the thin client 302 can run or operate as an independent process or within
`
`another environment (not shown), such as a web browser, or as a plug-in or extension within
`
`another application (not shown).
`
`The implementation 300 also includes an interface descriptor data source 304. The
`
`interface descriptor data source is software or hardware that performs logical operations and
`
`memory for locating and accessing one or more interface descriptors 306. Each interface
`
`descriptor 306 is a data structure that describes a guided interface, such as a NLI, of the
`
`Page 10 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`10
`
`implementation 300. For example, the interface descriptor for the particular guided interface can
`
`have the format:
`
`<LL properties, grammar, lexicon, portable specification, experts, tran.slati0ns>.
`
`Of course, other fonnats are possible to achieve the same objective of describing the particular
`
`guided interface that is appropriate to the implementation 300, for the particular user and thin
`
`client 302.
`
`In operation of the implementation 300, the interface descriptor 306 (or a reference,
`
`direct or indirect, to the interface descriptor) is found, located, derived, or otherwise presented or
`
`obtained by the interface descriptor data source 304. For example, the interface descriptor data
`
`source 304 can obtain the interface descriptor 306 on a web page or possibly from the interface
`
`descriptor data source 304, itself. The interface descriptor data source 304, upon locating or
`
`otherwise obtaining the relevant interface descriptor 306 makes the interface descriptor 306
`
`available to the implementation 300, such as by sending the interface descriptor 306 (or a
`
`reference or handle to it) to a parser farm 308 in order to initialize an appropriate parser 310, as
`
`hereinafter further detailed. Exemplary types of the interface descriptor data source include
`
`traders, databases, search engines, and other logical operators and applications.
`
`An interface intermediary 312 also is included in the implementation 300. The interface
`
`intermediary 312 interacts with the thin client 302, the interface descriptor data source 304, and
`
`the parser farm 308 and parser 310. The interface intermediary 312 functions to directly interact
`
`with the parser 310, including by receiving next items to display as dictated by the parser 310
`
`and preparing displays dictated by the parser 310 for the thin client 302. The interface
`
`intermediary also receives selections from the thin client 302 based on input
`
`thereto and
`
`generations by the thin client 302, and delivers or returns these to the parser 310. The interface
`
`intermediary 312 can be part of or inherent in the thin client 302 and its operations or,
`
`alternatively, separate from the thin client 302 at the location of the thin client 302 (such as a
`
`peripheral or application to the thin client 302), on a separate, disparate server device, or
`
`otherwise. Location of the interface intermediary separate and distinct from the thin client 302
`
`lessens download burdens and processing requirements of the thin client 302.
`
`The parser farm 308 of the implementation 300 serves to manage one or more of the
`
`parsers 310 available to the thin client 302 via the interface descriptor data source 304 and
`
`interface intermediary 312. The parser farm 308 manages the parsers 310 as a database or other
`
`access source, either by assigning or dictating use of an existing parser 310 of or available to the
`
`parser farm 308 or by creating or generating a new parser 310 and assigning or dictating use of
`
`Page 11 of 85
`
`

`
`WO 02/12982
`
`PCT/US01/25036
`
`11
`
`the new parser 310 for the implementation 300 and its operation. The parser farm 308 can, for
`
`example, make available for use the new parser 310, by returning to the implementation 300 an
`
`applicable handle or other locater for the parser 310.
`
`The parser 310 of the implementation is a program or other sequence of steps or logical
`
`operations that receives input in the form of sequential source program instructions, interactive
`
`online commands, markup tags, or some other defined interface and breaks them into parts (for
`
`example, the nouns (objects), verbs (methods), and their attributes or options) that can then be
`
`managed by other programming or elements (for example, other components of an application or
`
`device). The parser 310 can also check to see that all input has been provided that is necessary.
`
`hi the implementation 300, the parser 310 is initialized based on the interface descriptor 306
`
`from the interface descriptor data source 304. Once the parser 310 is so initialized, the parser
`
`310 generates a choice list, accepts a choice, and iterates. The parser 310 can, but need not
`necessarily, operate by creating a parse tree, as is common. In such case, the parser 310 employs
`
`the parse tree to generate translations of the parser 310 related to the parse tree.
`
`The
`
`implementation 300 can support an extensible collection of kinds and types of parsers, including,
`
`for example, the NLMenu parser mentioned in the background description.
`
`Another element of
`
`the implementation,
`
`a command intermediary 314, accepts
`
`translations output by the parser 310, sends the translation to the target application, receives the
`
`result, and interfaces and manages interactions between the target application and the
`
`input/output display to the user. Additionally or alternatively, the parser ‘310 routes the result to
`
`some other external application, element or process (not shown) for proc