User interface for translating natural language inquiries into database queries and data presentations

[0002] This invention relates to user interfaces and, more particularly, to an interface for a data presentation system.

[0003] 1. Background of the Invention

[0004] Current interfaces for data presentation systems and, specifically, for information visualization systems, typically only support so-called traditional input devices such as a mouse and/or keyboard. Recent developments in speech recognition have made it possible to provide other modes of interaction with information visualization systems. To this end, it would be relatively simple to provide a speech-based interface that has a one-to-one correspondence to a mouse interface. However, it has been shown that speech is not effective when used as a direct one-to-one replacement for either a mouse or a keyboard.

[0005] 2. Summary of the Invention

[0006] Problems and limitations of prior known data presentation system interfaces, for example, information visualization system interfaces, are overcome by employing so-called open-ended natural language inquiries to the interface that translates them into database queries and a set of information to be provided to a user. More specifically, a natural language inquiry is translated to database queries by determining if any complete database queries can be formulated based on the natural language inquiry and, if so, specifying which complete database queries are to be made.

[0007] In accordance with one aspect of the invention, knowledge of the information visualization presentation is advantageously employed in the interface to guide a user in response to the user's natural language inquiries.

[0008] In accordance with another aspect of the invention, knowledge of the data under exploration and knowledge of the information visualization presentation are advantageously employed in the interface to guide a user in response to the user's natural language inquiries.

[0009] In accordance with still another aspect of the invention, knowledge of the data under exploration, knowledge of the information visualization presentation and context information about the query dialogue are advantageously employed in the interface to guide a user in response to the user's natural language inquiries.

[0010] In one or more first prescribed embodiments of the invention, the set of data presentation information can be in audio, visual, or both audio-visual form.

[0011] In one or more other prescribed embodiments of the invention, the inquiry and data presentation information delivery process can be interactive between the user and the interface.

[0012] In one or more still other prescribed embodiments of the invention, one or more modes of user-interface interaction can be utilized. These modes of interaction can include text, speech, point and click, or the like.

[0013] A technical advantage of the invention is that a user is allowed to focus on answering questions supported by the interface, rather than on the specific mechanics of accessing data and creating presentations of the information.

[0014] FIG. 1 shows, in simplified block diagram form, details of a personal computer or workstation on which the invention may be practiced;

[0015] FIG. 2 shows, in simplified block diagram form, details of a system architecture on which an embodiment of the invention may be practiced;

[0016] FIG. 3 is a reactive constraint graph illustrating the SISL service logic 203 of FIG. 2 for a portion of a data-independent interface;

[0017] FIG. 4 is a reactive constraint graph illustrating the SISL service logic 203 of FIG. 2 for a portion of a natural language interface to organizational data;

[0018] FIG. 5 is a flow chart illustrating the steps employed in an embodiment of the invention;

[0019] FIG. 6 is a flow chart illustrating the steps employed in another embodiment of the invention;

[0020] FIG. 7 is a flow chart illustrating the steps employed in yet another embodiment of the invention;

[0021] FIG. 8 is a flow chart illustrating the steps employed in still another embodiment of the invention;

[0022] FIG. 9 is a flow chart illustrating the steps employed in a prescribed embodiment of the invention;

[0023] FIG. 10 is a flow chart illustrating the steps employed in another prescribed embodiment of the invention;

[0024] FIG. 11 is a flow chart illustrating the steps employed in yet another prescribed embodiment of the invention;

[0025] FIG. 12 is a flow chart illustrating the steps employed in still another prescribed embodiment of the invention;

[0026] FIG. 13 shows, in simplified block diagram form, details of an interactive system in which the invention may be advantageously employed;

[0027] FIG. 14 shows, in simplified block form, details of the SISL (Several Interfaces, Single Logic) architecture employed in the embodiment of FIG. 13;

[0028] FIG. 15 is a flowchart illustrating the steps in implementing the SISL architecture of FIG. 14;

[0029] FIG. 16 is a flowchart illustrating the steps in the process of executing reactive constraint graphs; and

[0030] FIG. 17A and FIG. 17B when connected A—A, B—B, C—C, and D—D is a flowchart illustrating the steps in the process of executing constraint nodes.

[0031] FIG. 1 shows, in simplified block diagram form, details of apparatus including an embodiment of the invention. Thus, shown is computer system 100 including central processor unit 101 interconnected via bus 102 with monitor and display 103, I/O controller 104, system memory 105, keyboard 106, mouse 107, removable disk drive 108, hard disk drive 109 and modem 110. Indeed, FIG. 1 illustrates but one arrangement that may be utilized in implementing an embodiment of the invention, and other similar arrangements, personal computers, workstations or the like, may be employed to equally practice one or more embodiments of the invention. Note that one or more databases, files, target application programs, etc. may be stored in system memory 105.

[0032] It is noted that although the embodiments of the invention are described herein as they relate to information visualization system interfaces, they are generally, equally applicable to data presentation system interfaces.

[0033] FIG. 2 shows, in simplified block diagram form, details of a system architecture 200 on which an embodiment of the invention may be practiced. Shown are SISL 201 including SISL grammar unit 202 and SISL service logic 203, InfoStill 204 including Task Manager 205, Presentation Manager 206, Data Warehouse 207 and Views 208, and viaVoice and JSAPI 209.

[0034] The natural language interfaces that may be employed in practicing the invention in architecture, i.e., system, 200 are separated into at least the following complementary components.

[0035] One interface component is a Data-independent natural language support for users to manipulate information visualization views. This interface allows users to control and select info V is views via natural language, where the voice commands are essentially at the same level as traditional mouse and keyboard commands. For example, the user might say “sort by largest column,” and may then interact with the updated view through a combination of natural language and mouse commands. This natural language interface is independent of the semantics of the data to be explored, and can be used across all data sets. However, it assumes that the user has some familiarity with the structure of the data and some experience with info V is environments.

[0036] Another interface component is a domain knowledge and interactive design to guide users in exploring a specific data set. This natural language interface is aimed at providing higher-level support for information visualization, tailored for a specific data set. In particular, it uses knowledge about the syntax and semantics of the data, as well as knowledge about info V is views, to guide the user in exploring a specific data set. The aim is to allow users who are unfamiliar with the structure of the data and/or with info V is tools to explore the data set naturally and effectively.

[0037] In particular, our approach has the following steps:

[0038] Select a data set for which to build a natural language interface.

[0039] Identify key threads of inquiry for this data set.

[0040] For each thread of inquiry, identify the class of database queries and info V is views that would be helpful in providing relevant answers about the data.

[0041] Build a dialogue system that interacts with the user to determine which threads of inquiry are of interest to the user. Using knowledge about the syntax and semantics of the data, this dialogue system should provide guidance to the user in exploring the data along these lines of inquiry and determine which database queries would aid the user in understanding the data. Using knowledge about info V is frameworks, the system should then automatically create the appropriate information visualization views via an info V is framework. The user thus does not need to be familiar with the structure of the data or have previous experience with info V is frameworks.

[0042] The system 200 thus guides the user in exploring the data by using domain-specific knowledge, and automatically creates a set of info V is views that aid in data analysis. The user may then interact with the generated views via a combination of natural language using both interfaces, and the traditional mouse and keyboard interface. This interface thus complements the data-independent natural language interface described earlier.

[0043] This unique approach to implementing such multi-modal interfaces to an info V is framework is to integrate SISL (Several Interfaces, Single Logic) 201, an approach for creating interactive services with multiple interfaces, with InfoStill 204, an existing info V is environment. We use SISL 201 to create a single service logic that is shared by several interfaces. These interfaces include natural language via automatic speech recognition on a desktop microphone or over the telephone, or text input through a graphical user interface or via the web. SISL grammars from 202 specify the user utterances that are recognized by the system. Dialogue management is specified by the SISL service logic 203, which also constructs the appropriate database query and chooses the appropriate view to display. It then sends the corresponding command to InfoStill 204, which displays and updates the relevant views.

[0044] InfoStill 204 is a task-oriented framework for analyzing data through information visualization. It supports data analysis tasks such as getting an overview of data tables from a data warehouse 207, interactively exploring data in search of trends within a linked views paradigm, and creating hierarchical, annotated presentations of results in the form of live documents (i.e., standard HTML web pages enhanced with linked Java applet visualizations). More importantly, InfoStill 204 supports users in mapping threads of inquiry to relevant interactive presentations of results.

[0045] Using this technology, we have implemented a data independent natural language interface of the kind described above, and have implemented a natural language interface tailored for employee databases. Importantly, both of these interfaces can be used in conjunction with the traditional point-and-click interface to InfoStill 204. This system is written in Java. ViaVoice 209, which is commercially available from International Business Machines (IBM), and its associated Java Speech API (JSAPI) library are used to perform automatic speech recognition, and run it on a standard Windows-based PC.

[0046] The overall system architecture 200 is shown in FIG. 2. In this architecture, the SISL service logic 203 uses a natural-language user interface implemented with IBM's ViaVoice 209 and interpreted with input from the speech grammar 202 to send commands to the InfoStill 204 info V is framework. Commands sent to the InfoStill Presentation Manager (PM) 206 are used to control and select visualization views, while commands sent to the InfoStill Task Manager (TM) 205 select data subsets and create views to present to the end-user. Note that a natural language user interface is realized using ViaVoice 209 through speech via a microphone, synthesized voice to a speaker, natural language text via a keyboard or the like. Similarly, other user interfaces, e.g., telephone, Web or the like, are realized through SISL 201. A graphical user interface is realized through InfoStill 204 using a mouse, monitor screen, keyboard or the like. More detailed information about SISL 201, InfoStill 204, and the connection between these two key components of our system architecture is described below.

[0047] It is becoming more and more commonplace for modern interactive services, such as those for personal banking or stock trading, to have more than one interface for accessing the same data. For example, many banks allow customers to access personal banking services from an automated teller machine, bank-by-phone interface, or web-based interface. Some telephone-based services even support automatic speech recognition and natural language understanding.

[0048] When multiple interfaces are provided to the same service, duplication can be a serious problem in that there may be a different service logic (i.e., the code that defines the essence of the service) for every different user interface to the service. Furthermore, to support natural language interfaces, services must allow users considerable flexibility in the way they input their service requests. Some of the desired capabilities include allowing requests to be phrased in various ways (e.g., needed information can appear in any order), prompting for missing information, correction of erroneous information, lookahead (to allow the user to speak several commands at once), and backtracking to earlier points in the service logic. Current approaches for multi-modal services are based on finite-state machines. The machines are often duplicated (in part or whole) for each different interface, and often every possible ordering of request must be described explicitly. The resulting finite state machines are huge and impossible to maintain.

[0049] SISL 201 is an architecture and domain-specific language for structuring services with multiple user interfaces. SISL 201 supports multiple user interfaces, allows flexibility in inputs, and enables service providers to support multiple interchangeable interfaces to a single consistent source of service logic and data.

[0050] FIG. 2 shows how SISL 201 is used in this invention and also serves to illustrate the use of SISL 201 for supporting multiple interfaces. The SISL service logic 203 communicates with multiple user interfaces. The interfaces include a speech engine using IBM's ViaVoice 209 and its associated Java Speech application programming interface (API) library, and a graphical user interface using InfoStill 204. As indicated, SISL 201 can communicate with other interfaces, such as telephones, Web servers or browsers, e-mail, and so on. The SISL service logic 203 and the multiple user interfaces communicate via events. The SISL service logic 203 communicates to user interfaces which information it is ready to accept next. Based on this information, the user interfaces prompt the user to provide the appropriate information and respond if the user requests help. The user interfaces then collect the information from the user and send it to the service logic. Any user interface that performs these functions can be used in conjunction with a SISL service logic 203. For example, SISL 201 may inform the natural-language interface that it can accept an organization e.g., if the user has said “Show me the size of the organization.” The interface may then prompt the user, e.g. by speaking “What organization do you want to see?” If the user responds with something that the natural-language interface recognizes as an organization, the interface will then generate a SISL event indicating the organization was detected. This event will then be processed by the SISL service logic 203. SISL 201 also provides a convenient framework for designing and implementing a variety of interfaces. The user interface (UI) designer need only specify a prompt and a help function that generate strings to be given as prompts to the user. For natural language interfaces, a set of speech grammars (the input to a speech recognition engine that permits it to efficiently and effectively recognize spoken input) is also required. From these functions and grammars, the SISL 201 infrastructure automatically generates user interfaces, and integrates them with the SISL service logic 203. For automatic speech recognition based interfaces, the SISL 203 infrastructure automatically generates a desktop interface based on the Java Speech API (JSAPI).

[0051] Further details of SISL 201 are described below.

[0052] InfoStill 204, short for Information Distillery, is a framework for information visualization (info V is) that aids users in the various tasks associated with performing data analyses. In practice, data analysis with an info V is environment involves a number of user tasks, such as developing a problem definition, identifying and retrieving appropriate data sources, exploring and analyzing the data, and recording the results of the analysis for presentation. This process is far from linear and typically involves many separate threads of investigation, some of which may be discarded as dead ends, together with considerable backtracking.

[0053] As indicated above, the major system components of the InfoStill 204 architecture are the Task Manager 205 and Presentation Manager 206; these obtain data from the Data Warehouse 207 and present it in the form of (dynamically-created) Views 208. InfoStill 204 uses a linked views paradigm, whereby users may interact with the displayed data (e.g., by selecting some of the graphics) and see the results of their actions propagated to other views.

[0054] The Task Manager 205 assists users in organizing their analysis process, breaking down their analysis into groups and sequences of tasks. For example, a user wishing to answer a question such as “How are the jobs in a given organization distributed among the departments within that organization?” must perform a series of tasks. First the analyst must obtain the data for the organization, departments, and jobs from the data warehouse. This task involves sub-tasks such as finding the appropriate data table, selecting fields from that table, and formulating a query to retrieve the desired data. The data must then be displayed as one or more views, an activity that itself has sub-tasks such as choosing data, choosing the type of view (bar charts, line charts, tables, etc.), and creating the view. Expertise about successful patterns of investigation may be stored in the form of task templates which users can use as starting points in their analysis process.

[0055] The Presentation Manager 206 displays the results of an analysis in the form of presentations, i.e., Views 208. The Presentation Manager 206 combines two paradigms. First, it is a workspace where users can interactively analyze data using linked views. Second, it is a reporting system, which allows the results of analyses to be saved for later examination. For example, the Task Manager may be asked to list the tables in the data warehouse or the fields within those tables, or to create a new database query. Similarly, the Presentation Manager 206 may be asked to create a new view using the results of a database query. This capability was originally used for scripting and bookmarks, but as the next section illustrates it has proved to be very useful when integrating SISL 201 with InfoStill 204.

[0056] SISL 201 is connected to InfoStill204 via the InfoStill 204 command API, thereby keeping a simple interface between the two systems. This means that InfoStill 2-4 is not a SISL 201 user interface, so InfoStill 204 does not generate SISL 201 events, nor does it respond to SISL 201 prompts for input. The commands sent by SISL service logic 203 to InfoStill 204 are passed to the Task Manager 205 and Presentation Manager 206, and executed. Results from queries, i.e., responses, are returned through the same API. The SISL natural-language interface logic is thus using InfoStill 204 to generate and display views of data in much the same way that a SISL banking logic would access and use the bank's accounting system to inspect and modify account balances. By restricting the interaction between SISL 201 and InfoStill 204 to the InfoStill API, we have the flexibility to run InfoStill 204 with multi-modal interfaces supported by SISL 201 or in a stand-alone mode without SISL 201. This also means that when InfoStill 204 is run with SISL 201, users can interact with InfoStill 204 through both the graphical users interface (GUI) included with InfoStill 204 and the alternative interaction modes provided by SISL 201. For example, the user might produce and display a group of views and perform a selection with the mouse. The user might then ask, using the voice interface, “How many people are currently selected?” In order to answer this question, SISL 201 must use the InfoStill 204 API to query the views (through the Presentation Manager 206) for the result, which is then given to the user (e.g., by generating speech on the voice interface).

[0057] A goal of system 200 is to provide data-independent natural language support for controlling and selecting Views 208 that have already been created through InfoStill 204. This natural language interface is intended to be independent of the semantics of the data to be explored, and thus must be usable across all InfoStill data sets. To implement this interface, we needed to write a SISL grammar 202 and SISL service logic 203 for generating Presentation Manager (PM) 206 events to send to InfoStill 204. As described above and depicted in FIG. 2, the automatic speech recognition engine used with SISL 201 matches user utterances against the SISL grammars from 202 and generates SISL events that are sent to the SISL service logic 203. In response to these events, the SISL service logic 203 performs actions such as prompting users for additional information, or sending PM 206 commands to InfoStill 204.

[0058] PM 206 commands are well-defined events for accomplishing the following types of user interactions: setting the current view, selecting data items or subsets within a view, identifying data items or objects within a view, hiding or showing data items or subsets in a view, and sorting data items or objects within a sortable view (e.g., sorting bars in a bar chart-alphabetically or by size). PM 206 commands focus on the interface to InfoStill 204 views 208 and are independent of the domain of the data being displayed within Views 208. Thus, the same SISL grammar 202 and SISL service logic 203 can be used to generate PM 206 commands for InfoStill Views 208 of any data set, independent of the domain of the data. Since PM 206 commands are well defined, the core SISL grammars from 202 and SISL service logic 203 for generating them are fairly straight-forward and can be easily written based on the existing mouse and menu GUI to the InfoStill Views 208. In order to leverage natural language features such as dialogue and context, however, we identified:

[0059] 1. common natural language alternatives for talking about views and interacting with them; and

[0060] 2. distinctions between the types of commands that are easy to speak but potentially difficult to specify with the GUI, and vice versa. In particular, we identified ways in which the GUI and natural language interfaces could be used to complement one another.

[0061] Consider the case of selecting bars in a bar chart. In the GUI interface, users can select bars with the mouse by clicking on individual bars or lassoing a group of bars. In addition, they can access other common selection actions such as “select all”, “unselect all” or “toggle all” directly from a popup menu. For the simple and short selection actions, the SISL grammar 202 can parse the spoken equivalents to the menu commands, as well as variations to the commands (e.g., to toggle the selection of bars in a bar chart, a user can say “toggle all”, “toggle all bars” or “toggle selection”). Speaking the selection of individual or groups of bars (i.e., selections essentially equivalent to those made with a mouse), however, introduces some interesting variations and subtleties. For example, selections such as “select the top ten bars” or “select all bars greater than 20” can be easy to say, but may be more cumbersome to specify with the mouse, especially for a larger number of similarly sized bars.

[0062] A combination of common natural language and info V is terminology is added to the SISL grammar 202 and the SISL service logic 203 for this interface. These extensions allow users more flexibility in natural language input to InfoStill 204. In particular, if a user specifies only partial information or inconsistent information, our interface will prompt the user and collect the remaining information. For example, if a user merely says “sort”, the interface will prompt the user as to the desired sorting criteria. Our interface also encapsulates a sequence of InfoStill 204 GUI commands into a single spoken command, such as “sort by first and third smallest columns”. The SISL service logic 203 then sends the appropriate sequence of PM 206 commands to InfoStill 204.

[0063] Excerpts from the SISL grammars from 202 and SISL service logic 203 used for doing sorting on a bar chart are as follows:

[0064] The “|” notation indicates choices among the subrules, while the [ ] notation indicates that the subrule inside the brackets is optional. The subrules inside <> specify that another subrule with the enclosed name is to be invoked. Here, <intval> refers to a subrule that matches against “first”, “third”, etc, and <bar> matches against different spoken alternatives for the phrase “bar” or “bars”. The * indicates that the enclosed expression may be matched multiple times. The expressions inside { } correspond to the SISL 201 (FIG. 2) events automatically sent to the SISL service logic 203.

[0065] FIG. 3 is a reactive constraint graph illustrating the SISL service logic 203 of FIG. 2 for a portion of a domain-independent interface. Initially, the SISL service logic 203 is in an idle node 301. In idle node 301, the SISL service logic 203 can accept a sort or select event, for example. If a sort event arrives from the speech recognition engine, the SISL service logic 203 changes state to the target of the arrow labeled sort, namely, node 302. If it next receives a select_replace event, it changes once again to node 303. It loops in this new node 303 upon receipt of either select_bypos 304 or select_bysize 305 events. It exits node 303 upon receipt of a selectdone event and goes to node 306. Upon receiving a sort_byselected event, it goes to node 307, which is a “leaf” node. When traversal reaches a leaf node, e.g., node 307, the appropriate PM 206 command is sent to InfoStill 204. Note that a leaf node 308 is reached directly from node 302 upon receiving a sort_byselected event. The end user can thus say “Sort by current selection”. This matches the <Sort> grammar rule, and causes the SISL sort and sort_byselected events to be sent to the SISL service logic 203. The SISL service logic 203 then sends a PM 206 command to InfoStill 204, corresponding to sorting by the currently selected data. Alternatively, the user might say. “Sort by first and third column.” The “first and third column” matches against the <select_bypos> subrule, since the “and third column” matches the <add_to_selection> subrule. Hence, the sort, select_replace, select_bypos(first), select_by_pos(third), select_done, and sort_by_selected events are sent to the service logic. The SISL service logic 203 then sends two PM 206 commands to InfoStill 204: one corresponding to sorting by the first column; and another corresponding to sorting by the third column. The SISL service logic 203 also remembers the context of the user dialogue. For example, if the user now says “And the fifth column”, the SISL service logic 203 remembers that a new selection had just been made for the basis of a sort. SISL service logic 203 thus sends PM 206 commands to InfoStill 204 corresponding to adding the fifth column to the current selection and sorting by it.

[0066] If the user is unsure about the sorting criteria, he/she may just say “Sort”. This matches the <sort> grammar rule, and causes a sort event to be sent to the SISL service logic 203. Since no other events have been sent, the SISL service logic 203 then prompts the user with “Do you want to sort by current selection, by size, by order, or by a new selection?” The user can then say the appropriate choice. If the user is completely unsure of what to say, he/she can simply say “I need help”. The service logic will receive a help event, and will prompt the user with “You may sort or select the data, or . . . ”

[0067] This sample SISL grammar 202 and SISL service logic 203 illustrate the power of using SISL 201 for processing speech commands to InfoStill Views 208. In particular, our interface increases the precision in data selection for large data sets, allows the user to speak a single sentence corresponding to a sequence of InfoStill GUI commands, and allows the user to give partial information, giving guidance as to the possible user options corresponding to that task. This natural language interface can be used across all data sets.

[0068] Domain knowledge and interactive design is employed in an interface to guide users in exploring a specific data set. This natural language interface is aimed at providing higher-level support for information visualization, tailored for a specific data set. It is thus closely related to the InfoStill Task Manager 205 (TM), which is designed to help users manage their data analysis tasks. An important aspect of this task to aid users in matching their intended analysis inquiries with a single View 208 or set of Views (together with the appropriate data variables to display) that aid in investigating these inquiries. A collection of such inquiries and corresponding info V is views are typically tailored to a particular data domain. Saving such a collection into a “task template” provides old and new InfoStill 204 users with a starting place for examining newer versions of the same data or similar data from the same domain. This is particularly useful for native or novice info V is users, who may know the types of analysis inquiries in which they are interested (e.g. “how has an organization evolved over time?”) but may not have knowledge about data set details nor knowledge about which views to use for exploring data.

[0069] The speech interface for generating TM 205 commands uses the notion of a task template in that:

[0070] 1. guides an end user to focus on and articulate an analysis inquiry of interest; and

[0071] 2. uses the system (in this case, the SISL service logic) to present the data and set of InfoStill Views 208 relevant to the user's inquiry.

[0072] In particular, the SISL grammar 202 and SISL service logic 203 leverage the dialogue and context features of natural language to dynamically generate the set of InfoStill Views 208 appropriate for the user's inquiry. The SISL service logic 203 manages a dialogue with the user to refine a vaguely worded analysis inquiry into a well-defined natural language query. The SISL service logic 203 then translates this query into InfoStill TM 205 commands. Unlike PM 206 commands that are well defined and data domain independent, TM 205 commands are more loosely defined and strongly dependent on the domain of the data; for example, inquiring about grocery store data when analyzing medical data would not be useful.

[0073] Thus, analysis inquiries of interest about an organizational database are:

[0074] “Where did people in [organization x) come from?”

[0075] “How many new hires were there in (organization x] during 1999?”

[0076] “Show me the new hires for [organization x].”

[0077] “What do people in [organization x] do?”

[0078] “Show me the contractors in [organization y].”

[0079] “Where do people in [organization y) live?”

[0080] “How has [organization z] grown over time?”

[0081] “How many people were in [organization z) in July 1999?”

[0082] For each thread of inquiry, the class of database queries and InfoStill Views 208 were identified that would be helpful in providing relevant answers about the organizational data. A SISL grammar 202 and SISL service logic 203 were generated to collect information from the user, conduct a dialogue with the user about his/her intended inquiries (from the identified set), refine these inquiries into complete and unambiguous queries, and generate corresponding TM 205 commands to send to InfoStill 204. The user can then interact with the generated views through a combination of the speech commands from the domain-independent natural language interface, and the InfoStill 204 GUI interface. For example, consider the inquiry “where did people in [organization x] come from?” The underlying query is ambiguous, since it might refer to either the organizations from which people came, or the geographic locations from which they came. The interface will thus prompt the user with “Do you mean organizations or locations?” When sufficient information has been gathered from the user to construct a complete and unambiguous query, the SISL service logic 203 generates an appropriate TM 205 command: for example, it may create a bar chart, values list and/or grid chart, displaying the appropriate data variables.

[0083] Excerpts from the SISL grammars from 202 and SISL service logic 203 used for conducting a dialogue about inquiries regarding “where did people in organization X come from?” and “how has organization X evolved over time?” are as follows:

[0084] FIG. 4 is a reactive constraint graph illustrating the SISL service logic 203 of FIG. 2 for a portion of a natural language interface to organizational data. In its initial node 401 the corresponding SISL service logic 203 can accept events corresponding to the types of inquiries. If it receives a peoplefrom event from the speech recognition engine, it changes to the target node, namely, node 403. It then requires a who event and which event, in either order before it can change to another node. When both events have been received, it needs either an organizations or locations event to change node. If an organizations event is received it goes to node 405. Then, upon receiving a whatorglevel event, it goes to node 406, which requires a when event. When the SISL service logic 203 is in node 403 and a locations event is received, it changes to node 404, which also requires a when event. When traversal reaches a leaf node, i.e., node 406 or node 404, the appropriate TM 205 command is sent from SISL service logic 203 to InfoStill 204.

[0085] FIG. 5 is a flow chart illustrating the steps employed in an embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 501 by a user inputting a natural language inquiry. Then, step 502 causes system 200 (FIG. 2) to employ knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. The set can include one or more complete database queries. However, if the set includes only one complete database query, that query is unambiguous. Knowledge about the information visualization technology is encoded in SISL service logic 203 in the form of a reactive constraint graph. Choice nodes represent the alternatives available to the user, while constraint nodes represent required sets of information. Leaf nodes contain a database query and corresponding information visualization views, e.g., presentation formats. Natural language input from the user is matched against the SISL grammars from 202, and appropriate events are sent to the SISL service logic 203. The reactive constraint graph is traversed according to these events. If control halts at a choice node or constraint node, it is determined that further information is needed from the user, and the user is prompted accordingly, as indicated below. Otherwise, if control halts at a leaf node, this indicates that the information given by the user can be translated into a set of complete and unambiguous database query (described in the leaf node). The leaf node also indicates which kind of information visualization views should be displayed. Step 503 tests to determine if at least one database query has been specified. If the test result in step 503 is NO, step 504 informs the user that the query is not supported. If the test result in step 503 is YES, at least one database query has been specified and step 505 queries the appropriate database. In step 506, the system 200 employs knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 507, the system 200 employs knowledge about information visualization technology to determine one or more formats and presents the formulated information in the determined one or more formats using one or more presentation modes. It should be noted that the presentation formats may be predetermined or dynamically determined from a set of formats. It is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. Additionally, the presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof.

[0086] It should be noted that as used herein the phrase “one or more” is intended to mean “one, more than one or any desired combination of the one or more”.

[0087] FIG. 6 is a flow chart illustrating the steps employed in another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 601 by a user inputting a natural language inquiry. Then, step 602 causes system 200 (FIG. 2) to employ knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. It is again noted that the set can include one or more complete database queries. However, if the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 502. Step 603 tests to determine if at least one database query has been specified. If the test result in step 603 is NO, in step 604 the system 200 is caused to employ knowledge about information visualization technology, and context information about the dialogue including any additional and/or corrected information to prompt the user for additional information. Context information about the dialogue is implicitly represented by the current state of the reactive constraint graph. It is also encoded in the service monitor 1402 (FIG. 14), in the form of event priorities. Then, in step 605 the user provides additional information and/or corrects previously provided information. Step 606 causes system 200 (FIG. 2) to employ knowledge about information visualization technology, and context information about the dialogue including the addition and/or corrected information to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Again, this realized in essentially the same manner as described above in relation to step 502 but with the addition of context information about the dialogue. Thereafter, control is returned to step 603 and steps 603 through 606 are iterated until step 603 yields a YES result. Upon step 603 yielding a YES result, thereby indicating that at least one database query has been specified, step 607 queries the appropriate database. In step 608, the system 200 employs knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 609, the system 200 employs knowledge about information visualization technology to determine one or more formats and presents the formulated information in the determined one or more formats using one or more presentation modes. It should be noted that the presentation format may be predetermined or dynamically determined from a set of formats. Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. Additionally, the presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof.

[0088] FIG. 7 is a flow chart illustrating the steps employed in yet another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 701 by a user inputting a natural language inquiry by employing one or more input modes. It is noted that any one of the input modes or any combination of the input modes may be employed to input the natural language inquiry. These input, i.e., interaction, modes may include text, voice, point and click, e.g., mouse, or the like using a telephone, personal computer, microphone, web, mouse, keyboard or the like, or any desired combination thereof. Then, step 702 causes system 200 (FIG. 2) to employ knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. It is again noted that the set can include one or more complete database queries. However, if the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 502. Step 703 tests to determine if at least one database query has been specified. If the test result in step 703 is NO, in step 704 the system 200 is caused to employ knowledge about information visualization technology, and context information about the dialogue including any additional and/or corrected information to prompt the user for additional information. Context information about the dialogue is implicitly represented by the current state of the reactive constraint graph. It is also encoded in the service monitor 1402 (FIG. 14), in the form of event priorities. Step 705 causes system 200 to prompt the user by employing a prescribed mode of or a combination of modes of a plurality of prescribed modes. In response to the prompts from step 705, the user provides additional information and/or corrects previously provided information via step 706 by employing one or more input modes. In step 707, the system 200 is caused to employ knowledge about information visualization technology, and context information about the dialogue including the additional and/or corrected information to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. If the set includes only one complete database query that query is unambiguous. Again, this realized in essentially the same manner as described above in relation to step 502 but with the addition of context information about the dialogue. Thereafter, control is returned to step 703 and steps 703 through 707 are iterated until step 703 yields a YES result. Upon step 703 yielding a YES result, thereby indicating that at least one database query has been specified, step 708 queries the appropriate database. In step 709, the system 200 employs knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 710, the system 200 employs knowledge about information visualization technology to determine one or more formats and presents the formulated information in the determined one or more formats using one or more presentation modes. These presentation modes may include at least text, voice, telephone, web, graphics, other visual or like and/or any desired combination thereof. Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. It should also be noted that the presentation formats may be predetermined or dynamically determined from a set of formats.

[0089] FIG. 8 is a flow chart illustrating the steps employed in still another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 801 by a user inputting a natural language inquiry by employing one or more input modes. Again, these input, i.e., interaction, modes may include text, voice, point and click, e.g., mouse, or the like using a telephone, personal computer, microphone, web, mouse, keyboard or the like, or any desired combination thereof. Then, step 802 causes system 200 (FIG. 2) to employ knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. If the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 502. Step 803 tests to determine if at least one database query has been specified. If the test result in step 803 is NO, in step 804 the user is informed by employing one or more presentation modes that the query is not supported. If the test result in 803 is YES, at least one database query has been specified and step 805 queries the appropriate database. In step 806, the system 200 employs knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 807 the system 200 employs knowledge about information visualization technology to determine one or more formats and presents the formulated information in the determined one or more formats using one or more presentation modes. The presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. It should also be noted that the presentation formats may be predetermined or dynamically determined from a set of formats.

[0090] FIG. 9 is a flow chart illustrating the steps employed in an embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 901 by a user inputting a natural language inquiry. Then, step 902 causes system 200 (FIG. 2) to employ knowledge about the data under exploration and knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one complete database query that query is unambiguous. Knowledge about the information visualization technology and knowledge about the data under exploration is encoded in SISL service logic 203 in the form of a reactive constraint graph. Choice nodes represent the alternatives available to the user, while constraint nodes represent required sets of information. Leaf nodes contain a database query and corresponding information visualization views. Natural language input from the user is matched against the SISL grammars from 202, and appropriate events are sent to the SISL service logic 203. The reactive constraint graph is traversed according to these events. If control halts at a choice node or constraint node, it is determined that further information is needed from the user, and the user is prompted accordingly. Otherwise, if control halts at a leaf node, this indicates that the information given by the user can be translated into a set of complete and unambiguous database query (described in the leaf node). The leaf node also indicates which kind of information visualization views should be displayed. Step 903 tests to determine if at least one database query has been specified. If the test result in step 903 is NO, step 904 informs the user that the query is not supported. If the test result in step 903 is YES, at least one database query has been specified and step 905 queries the appropriate database. In step 906, the system 200 employs domain knowledge about data under exploration and knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 907, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to determine one or more formats and presents the formulated information to the use in the determined one or more formats using one or more presentation modes. It should be noted that the presentation format may be predetermined or dynamically determined from a set of formats. Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. Additionally, the presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof.

[0091] FIG. 10 is a flow chart illustrating the steps employed in another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 1001 by a user inputting a natural language inquiry. Then, step 1002 causes system 200 (FIG. 2) to employ knowledge about the data under exploration and knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 902. Step 1003 tests to determine if at least one database query has been specified. If the test result in step 1003 is NO, in step 1004, the system 200 is caused to employ knowledge about data under exploration and knowledge about information visualization technology, and context information about the dialogue including any additional and/or corrected information to prompt the user for additional information. Context information about the dialogue is implicitly represented by the current state of the reactive constraint graph. It is also encoded in the service monitor 1402 (FIG. 14), in the form of event priorities. Then, in step 1005 the user provides additional information and/or corrects previously provided information. Step 1006 causes system 200 (FIG. 2) to employ knowledge about the data under exploration and knowledge about information visualization technology, and context information about the dialogue including the additional and/or corrected information to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one query that query is unambiguous. Again, this realized in essentially the same manner as described above in relation to step 902 but with the addition of context information about the dialogue. Thereafter, control is returned to step 1003 and steps 1003 through 1006 are iterated until step 1003 yields a YES result. Upon step 1003 yielding a YES result, thereby indicating that at least one database query has been specified, step 1007 queries the appropriate database. In step 1008, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 1009, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to determine one or more formats and presents the formulated information to the use in the determined one or more formats using one or more presentation modes. It should be noted that the presentation format may be predetermined or dynamically determined from a set of formats. Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. Additionally, the presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof.

[0092] FIG. 11 is a flow chart illustrating the steps employed in yet another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 1101 by a user inputting a natural language inquiry by employing one or more input modes. Again, these input, i.e., interaction, modes may include text, voice, point and click, e.g., mouse, or the like using a telephone, personal computer, microphone, web, mouse, keyboard or the like, or any desired combination thereof. Then, step 1102 causes system 200 (FIG. 2) to employ knowledge about the data under exploration and knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 902. Step 1103 tests to determine if at least one database query has been specified. If the test result in step 1103 is NO, in step 1104 the system 200 is caused to employ knowledge about data under exploration and knowledge about information visualization technology, and context information about the dialogue including any additional and/or corrected information to prompt the user for additional information. Context information about the dialogue is implicitly represented by the current state of the reactive constraint graph. It is also encoded in the service monitor 1402 (FIG. 14), in the form of event priorities. Step 1105 causes system 200 to prompt the user by employing a prescribed mode of or a combination of modes of a plurality of prescribed modes. In response to the prompts from step 1105, the user provides additional information and/or corrects previously provided information via step 1106 by employing one or more input modes. In step 1107, the system 200 is caused to employ knowledge about the data under exploration and knowledge about information visualization technology, and context information about the dialogue including the additional and/or corrected information to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one complete query that query is unambiguous. Again, this realized in essentially the same manner as described above in relation to step 902 but with the addition of context information about the dialogue. Thereafter, control is returned to step 1103 and steps 1103 through 1107 are iterated until step 1103 yields a YES result. Upon step 1103 yielding a YES result, thereby indicating that at least one database query has been specified and step 1108 queries the appropriate database. In step 1109, the system 200 employs domain knowledge about data and information visualization technology to formulate information to be supplied to the user. Then, in step 1110, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to determine one or more formats and presents the formulated information to the use in the determined one or more formats using one or more presentation modes. These presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. It should also be noted that the presentation formats may be predetermined or dynamically determined from a set of formats.

[0093] FIG. 12 is a flow chart illustrating the steps employed in still another embodiment of the invention implemented by the system architecture 200 of FIG. 2. The inquiry process starts in step 1201 by a user inputting a natural language inquiry by employing one or more input modes. Again, these input, i.e., interaction, modes may include text, voice, point and click, e.g., mouse, or the like using a telephone, personal computer, microphone, web, mouse, keyboard or the like, or any desired combination thereof. Then, step 1202 causes system 200 (FIG. 2) to employ knowledge about the data under exploration and knowledge about information visualization technology to translate the natural language inquiry into one or more database queries by determining whether a set of complete database queries can be formulated and, if so, specifying the one or more database queries to be made. Note that if the set includes only one complete database query that query is unambiguous. This is realized in essentially the same manner as described above in relation to step 902. Step 1203 tests the determination of step 1202 if a complete and unambiguous query can be formulated. If the test result in step 1203 is NO, in step 1204 the user is informed by employing one or more presentation modes that the query is not supported. If the test result in step 1203 is YES, at least one database query has been specified and step 1205 queries the appropriate database. In step 1206, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to formulate information to be supplied to the user. Then, in step 1207, the system 200 employs knowledge about data under exploration and knowledge about information visualization technology to determine one or more formats and presents the formulated information to the use in the determined one or more formats using one or more presentation modes. The presentation modes may include at least text, voice, telephone, web, graphics, other visual or the like and/or any desired combination thereof. Again, it is further noted that the formats may include text, graphics, screen views, e.g., charts, etc., or the like. It should also be noted that the presentation formats may be predetermined or dynamically determined from a set of formats.

[0094] FIG. 13 shows, in simplified block diagram form, details of an interactive system in which the invention may be advantageously employed. It should be noted that the arrangement shown in FIG. 13 is but one example of an application of the invention. Indeed, a plurality of different user interfaces and/or one more identical user interfaces may be employed as desired.

[0095] Specifically, shown in FIG. 13 is SISL (Several Interfaces, Single Logic) service unit 1301; home/office computer 1302 used as a customer and/or provider interface, including automatic speech recognition having a natural language understanding, if desired, that is interfaced to SISL service unit 1301 via an Internet link 1303; telephone 1304 also used as a customer and/or provider interface that is interfaced to SISL service unit 1301 via a telephone network 1305 including, for example, touch-tone, i.e., multi-frequency, signaling; and computer 1306 used as a customer and/or provider interface, which may also have automatic speech recognition including natural language understanding, that is interfaced to SISL service unit 1301 via a local area network (LAN). A key advantage of SISL is that all user interfaces to a service share the same single service logic. SISL provides a clean separation between the service logic and the software for a variety of user interfaces including but not limited to Java applets, HTML pages, speech-based natural language dialog, and telephone-based voice access. In this example, SISL is implemented using the JAVA programming language.

[0096] At the outset it is felt best to describe some of the principles employed in implementing the flexible interactive service including an embodiment of the invention. For simplicity and clarity of exposition, these principles will be presented in the context of a so-called Any-Time Teller banking service employing the invention. The Any-Time Teller is an interactive banking service. The service is login protected; customers must authenticate themselves by entering an identifier (login) and PIN, i.e., personal identification number, (password) to access the functions. As customers may have many money accounts, most functions require the customer to select the account(s) involved. Once authenticated, the customer may:

[0097] Make a deposit.

[0098] Make a withdrawal. The service makes sure the customer has enough money in the account, then withdraws the specified amount.

[0099] Transfer funds between accounts. The service prompts the customer to select a source and target account, and a transfer amount, and performs the transfer if (1) the customer has enough money in the source account, and (2) transfers are permitted between the two accounts.

[0100] Get the balance of an account. Display the balance with respect to all posted transactions.

[0101] View the transactions of an account. Display the transactions for the selected account.

[0102] See the last transaction. Display the last action the customer performed.

[0103] The transfer capability of the Any-Time Teller requires the collection of three events: the source account (src), target account (tgt), and dollar amount (amt). There are five constraints that those input events must meet before a transfer can take place:

[0104] c1: src must be a valid account

[0105] c2: tgt must be a valid account

[0106] c3: amt must be greater than zero

[0107] c4: amt must be less than or equal to the balance of src

[0108] c5: the bank must allow transfers from src to tgt

[0109] The service should check whether or not a constraint is violated as soon as possible; hence, it must be prepared to react when only a subset of the three events is present. The service must then prompt for the remaining events.

[0110] Some basic principles are now considered related to the design and implementation of interactive services with multiple and varied user interfaces. These principles are especially important in the presence of multiple interfaces including those based on spoken natural language.

[0111] Lesser Order=greater Freedom

[0112] The source account, target account, and dollar amount of the transfer capability should be independent events that can be collected in any order, where all three events are necessary to perform a transfer. By making explicit independent and dependent events, it in clear what events may be reordered without affecting the behavior of the service. This points the way to our first principle of the service specification:

[0113] Principle 1: Specify the service logic as a set of constraints on events and introduce a constraint between two events only when absolutely necessary for the correct functioning of a service. That is, the service logic should be able to accept independent input events in different orders.

[0114] Eliminate Errors Only

[0115] It is often desirable for a service to respond as soon as possible with error conditions about user input. Since a constraint on the input events may refer to any arbitrary subset of those events, it is desirable that the service logic should be able to accept arbitrary subsets of events at any time.

[0116] Principle 2: The service logic should accept an incomplete input, i.e., subsets of the universe of possible events.

[0117] I Take That Back!

[0118] Unfortunately, humans often change their mind and/or make mistakes. Whenever possible, services must accommodate these shortcomings of our species, providing a capability to correct information or back out of a transaction. This leads to our third principle:

[0119] Principle 3: The service logic should allow the user to back up to correct or update previously submitted information at any time. A closely related principle is:

[0120] Principle 4: The service logic should allow the user to back up to previous points in the service.

[0121] Ready or not?

[0122] Services that obey the above principles generalize from linear user interactions to potentially allow multiple points of interaction to be enabled at a given instant. This information serves as an abstraction of the current control point of the service, and can be handled in a different manner by different user interfaces. For example, in automatic speech recognition interfaces, the information about currently enabled events is used by the user interface in two ways:

[0123] to appropriately prompt the user for information, thus compensating for the lack of visual cues; and

[0124] to effectively parse the information provided by the user.

[0125] A user interface need not respond to all currently enabled events of the service. Thus, different user interfaces can formulate different queries to the user even though the control point in the underlying service logic, as revealed by the current set of enabled events, is the same. The decoupling that we are seeking between the user interface and the service logic, therefore points the way to our last principle of the service specification:

[0126] Principle 5: At any point in the service, the service logic must automatically report to the user interfaces all currently enabled events, user prompts, help, and ways to revert back to previous points in the service.

[0127] User interfaces have two main responsibilities with respect to the SISL architecture that reflect the two-way information flow between the user interface and service logic:

[0128] Based on the events received from the service logic, via the service monitor, prompt the user to provide the appropriate information and respond if the user requests help.

[0129] Collect the information from the user and transform the information into events to be sent to the service logic, via the service monitor.

[0130] Indeed, any user interface (UI) that performs these functions can be employed in conjunction with a SISL service logic. Additionally, SISL provides a convenient framework for designing and implementing web-based, applet-based, automatic speech recognition-based and telephone voice-based interfaces. To implement such user interfaces, the UI designer need only specify two functions corresponding to the prompt and help mechanism. For automatic speech recognition interfaces, a set of speech grammars, i.e., the input to a speech recognition engine that permits it to efficiently and effectively recognize spoken input, together with a third function that specifies which grammars to enable is also required.

[0131] The required functions are:

[0132] A prompt function that generates the string to be given as the prompt to the user. An example, in pseudo code form is shown below. The SISL infrastructure automatically causes automatic speech recognition-based interfaces to speak the prompt string. Web-based interfaces automatically display the prompt string, as well as, radio buttons corresponding to the possible transaction choices. For the other prompt events, text fields are automatically displayed, while submit buttons are automatically displayed for enabled events that allow the user to return to earlier points in the service.

[0133] A help function that generates the string to be given as the prompt to the user. An example, in pseudo code form is also described below.

[0134] A grammar function that enables the correct set of grammar rules; this function is only needed for automatic speech recognition-based interfaces. An example, in pseudo code form is described below.

[0135] As indicated, portions of the prompt and help functions shared by an automatic speech recognition-based interface, web-based interface and telephone-based voice interface for the Any-Time Teller banking service in pseudo code form. The prompt and help functions pseudo code is self explanatory and is as follows:

[0136] Portions of the grammar rules, against which the automatic speech recognition engine will parse spoken input from the user, pseudo code is self explanatory and is as follows:

[0137] A portion of the associated grammar function shared by an automatic speech recognition-based interface and a telephone-based voice interface pseudo code is self explanatory and is as follows:

[0138] From these functions and grammars, the SISL infrastructure automatically coordinates the collection and event transformation mechanisms, and integrates the user interface with the service logic and the service monitor. For automatic speech recognition-based interfaces, the SISL infrastructure automatically generates a desktop interface based on JAVA Speech API (Application Programming Interface). To enable telephone-based voice access to the service, SISL automatically generates VoiceXML pages, which specify the voice dialog to be carried out on a telephony platform. For Web-based interfaces, the SISL infrastructure automatically generates HTML (Hypertext Markup Language) pages. It is noted that SISL provides a mechanism for the UI designer to customize the look and feel of the interface.

[0139] FIG. 14 shows, in simplified block form, details of the SISL (Several Interfaces, Single Logic) architecture employed in the embodiment of FIG. 13. The SISL architecture together with the event communication protocol provides modularity between the service logic 1401 and user interfaces 1404. In particular, two features of the event communication protocol allow service logic 1401 to function completely without knowledge of the specifics of the individual user interfaces 1404. These features are: (1) events are multicast from service logic 1401 via service monitor 1402 to user interfaces 1404 and, consequently, service logic 1401 does not need to know the destinations of these events; and (2) the source of the events from the user interfaces 1404 is not recorded and, consequently, the service logic 1401 does not know which one or more of user interfaces 1404 sent the events. Service monitor 1402 is responsible for maintaining this communication protocol. This modularity allows service providers to provide interchangeable user interfaces 1404, or add new ones, to a single consistent source of service logic and data.

[0140] Specifically, shown in FIG. 14 are service logic unit 1401, service monitor 1402 and user interfaces 1404-1 through 1404-N. The key principle underlying SISL is that all user interfaces 1404 to a service share a single service logic 1401. All communications between the service logic 1401 and its multiple user interfaces 1404 are through events, via a service monitor 1402. Events from the service logic 1401 are broadcast to the user interfaces 1404 via 1403 to the service monitor 1402 and, then, via 1405 as a set of enabled events to the user interfaces 1404. At the outset of the service, for example the Any-Time Teller banking service, each user interface 1404 registers with the service monitor 1402 to indicate which events it is interested in receiving. After collecting information from the user, the user interfaces 1404 send events to the service monitor 1402 via bi-directional links 1405; the service monitor 1402 does not record the source of these events. The service monitor 1402 passes the events, one at a time, via 1403 to the service logic 1401. Details of a service monitor, which can be advantageously employed for service monitor 1402, are described in U.S. patent application Ser. No. 09/386,093, filed Aug. 30, 1999 and assigned to the assignee of this application.

[0141] Event communication supports decoupling of the service logic 1401 and the user interfaces 1404, and allows service providers to provide interchangeable user interfaces 1404, or add new ones, to a single consistent source of service logic 1401 and data.

[0142] In each round of interaction, the SISL infrastructure automatically sends out a set of events via 1403 from the service logic 1401 to the service monitor 1402, corresponding to the events that are currently enabled in the service logic 1401. There are three kinds of events: prompt events, up events, and notify events. Prompt events indicate to the user interface what information to communicate to the user and what information the service is ready to accept. There are three kinds of prompt events:

[0143] prompt_choice events are disjunctive choices currently enabled in the service logic 1401. For example, after the user has successfully logged into the Any-Time Teller banking service, a choice among the different transaction types is enabled. The service logic 1401 sends a prompt_choice_deposit, prompt_choice_withdrawal event, and a prompt_choice_transfer event, and so forth, via 1403 to the service monitor 1402.

[0144] prompt_req events are the events currently required by the service logic 1401. For example, suppose the user has chosen to perform a transfer transaction. The Any-Time Teller requires that the user input a source account, a transfer account, and amount, and hence sends prompt_req_src, prompt_req_tgt, and prompt_req_amt events via 1403 to the service monitor 1402.

[0145] prompt_opt events are events enabled in the service logic 1401, for which the user may correct previously given information. For example, suppose the user is performing a transfer and has already provided his/her source and target accounts, but not the amount. The service logic 1401 sends prompt_opt_src, prompt_opt_tgt, and prompt_req_amt events via 1403 to the service monitor 1402. This indicates that the user may override the previously given source and target accounts with new information.

[0146] Up events correspond to prior points in the service logic 401 to which the user may go back. For example, the service logic 1401 sends an up_MainMenu event via 1403 to the service monitor 1402. This allows the user to abort any transaction and go back up to the main menu.

[0147] Notify events are simply notifications that the user interface 1404 should give the user; for example, that a transaction has completed successfully or that information provided by the user was incorrect or inconsistent.

[0148] FIG. 15 is a flowchart illustrating the steps in implementing the SISL architecture of FIG. 14. Specifically, the implementation process is started via step 1501. Then, step 1502 causes the SISL service logic to be written in SISL. Step 1503 causes the service monitor 1402 to be written. Thereafter, a plurality of user interfaces UI-1 thorough UI-N are developed in steps 1504-1 through 1504-N.

[0149] FIG. 16 is a flowchart illustrating the steps in the process of executing reactive constraint graphs. Specifically, step 1601 obtains a root node (n). Then step 1602 tests to determine if the obtained node is a data based choice node. If the test result in step 1602 is No, step 1603 tests to determine whether the obtained node is an event based choice node. If the tests result in step 1603 is NO, step 1604 tests to determine if the obtained node is an action node. If the test result in step 1604 is YES, step 1605 causes the execution of the action, the execution of the notification associated with node “n” and sets “n=child node”, as determined from the current obtained node. If the test result in step 1604 is NO, step 1606 causes the execution of the process of the constraint flowchart of FIG. 15, as described below, until a new child node is determined and, then, assigns “n” to the determined new child node. Returning to step 1602, if the test result is YES, the node is data based, and step 1607 causes a unique arc “a” to be selected from node “n” whose precondition is TRUE. Then step 1608 causes the execution of an action and notification associated with arc “a”. Thereafter, step 1608 sets “n=child” node of “a”. Returning to step 1603, if the test result is YES, the node is event based, and step 1609 causes a wait for any event “e” that is the label of some arc “a” from node “n” or is the uplabel of some ancestor node of node “n”. Then, step 1610 tests to determine if event “e” is the uplabel of some ancestor node of node “n”. If the test result in step 1610 is YES, step 1611 causes control to be transferred to the ancestor node. If the test result in step 1610 is NO, control is passed to step 1608, which is then effected as described above. Reactive constraints are discussed further below.

[0150] FIG. 17A and FIG. 17B when connected A—A, B—B, C—C, and D—D is a flowchart illustrating the steps in the process of executing constraint nodes. Specifically, step 1701 causes the entry action to be executed. Then, step 1702 causes initialization of a table to be one entry for each event occurring in an associated constraint; value to FALSE; and data to EMPTY. Thereafter, step 1703 causes a prompt_req to be sent to service monitor 1402 for every event “e” whose value is set to FALSE in the table, and a prompt_opt to be sent to service monitor 1402 for every event “e” whose value is set to TRUE in the table. Step 1704 waits for an event “e” that occurs in any associated constraint, or is the uplabel of an ancestor node. Then, step 1705 tests to determine whether event “e” is an uplabel of an ancestor node. If the test result instep 1705 is YES, control is transferred to the ancestor node via step 1706. If the test result in step 1705 is NO, step 1707 causes event “e” to be set TRUE in the table, and assigns data to be “e's” data. Then, step 1708 tests to determine if any constraints are enabled. If the test result in step 1708 is YES, step 1709 causes the next enabled constraint to be evaluated. Then, step 1710 tests to determine whether the evaluated constraint has been satisfied. If the test result in step 1710 is NO, the constraint is not satisfied and step 1711 causes the execution to be effected of the violation action and the notification of violated constraint. Step 1712 causes the setting of event “e” to be False in the table and clears “e's” data. Thereafter, step 1713 tests to determine if a child node is specified. If the test result in step 1713 is YES, step 1714 causes control to be transferred to the specified child node. Returning to step 1708, if the test result is NO, there are no remaining constraints that are enabled and step 1715 causes the execution of the satisfaction action and the notification of all satisfied constraints. Then, step 1716 tests to determine whether all constraints have been satisfied. If the test result in step 1716 is YES, step 1717 causes the child node to be determined and, then, transfers control to it. If the test result in step 1716 is NO, control is returned to step 1703 and appropriate ones of steps 1703 through 1717 are iterated until either step 1706 is reached, or step 1714 is reached, or step 1717 is reached. Returning to step 1710, if a YES result is obtained, control is returned to step 1708 and steps 1708 through 1710 are iterated until either step 1708 yields a NO result or step 1710 yields a NO result. Then, the processes, as described above regarding steps 1708 or 1710 yielding a NO result are repeated. Returning to step 1713, if the test result is NO, the child node is not specified and control is returned to step 1703. Thereafter, appropriate ones of steps 1703 through 1717 are iterated until either step 1706, or step 1714 or step 1717 is reached.

[0151] Further details of the SISL architecture are described in U.S. patent application Ser. No. 09/386,094, filed Aug. 30, 1999 and assigned to the assignee of this application.

[0152] The above-described embodiment is, of course, merely illustrative of the principles of the invention. Indeed, numerous other methods or apparatus may be devised by those skilled in the art without departing from the spirit and scope of the invention.