<?xml version="1.0" standalone="yes"?>
<Paper uid="A92-1002">
  <Title>A Dialog Control Algorithm and Its Performance</Title>
  <Section position="2" start_page="0" end_page="0" type="metho">
    <SectionTitle>
1 A Voice-Interactive Dialog Machine
</SectionTitle>
    <Paragraph position="0"> A limited vocabulary voice dialog system designed to aid a user in the repair of electronic circuits has been constructed in our laboratory. The system contains a model of the device to be repaired, debugging and repair procedures, voice recognition and sentence processing mechanisms, a user model, language generation capabilities, and a dialog control system which orchestrates the behaviors of the various parts. This paper describes the *This research was supported by National Science Foundation Grant Number NSF-IRI-88-03802 and by Duke University.</Paragraph>
    <Paragraph position="1"> dialog control algorithm and the performance of the total system in aiding a series of subjects in the repair of an electronic circuit.</Paragraph>
  </Section>
  <Section position="3" start_page="0" end_page="9" type="metho">
    <SectionTitle>
2 Target Behaviors
</SectionTitle>
    <Paragraph position="0"> The purpose of the dialog control algorithm is to direct the activities of the many parts of the system to obtain efficient human-machine dialog. Specifically, it is aimed at achieving the following behaviors.</Paragraph>
    <Paragraph position="1"> Convergence to a goal. Efficient dialog requires that each participant understand the purpose of the interaction and have the necessary prerequisites to cooperate in its achievement. This is the intentional structure of \[Grosz and Sidner, 1986\], the goal-oriented mechanism that gives direction to the interaction. The primary required facilities are a problem solver that can deduce the necessary action sequences and a set of subsystems capable of carrying out those sequences.</Paragraph>
    <Paragraph position="2"> Subdialogs and effective movement between them. Efficient human dialog is usually segmented into utterance sequences, subdialogs, that are individually aimed at achieving relevant subgoals (\[Grosz, 1978\], \[Linde and Goguen, 1978\], \[Polanyi and Scha, 1983\], and \[Reichman, 1985\]). These are called &amp;quot;segments&amp;quot; by \[Grosz and Sidner, 1986J and constitute the linguistic structure defined in their paper. The global goal is approached by a series of attempts at subgoals each of which involves a set of interactions, the subdialogs.</Paragraph>
    <Paragraph position="3"> An aggressive strategy for global success is to choose the most likely subgoals needed for success and carry out their associated subdialogs. As the system proceeds on a given subdialog, it should always be ready to abruptly drop it if some other subdialog suddenly seems more appropriate. This leads to the fragmented style that so commonly appears in efficient human communication.</Paragraph>
    <Paragraph position="4"> A subdialog is opened which leads to another, then another, then a jump to a previously opened subdialog, and so forth, in an unpredictable order until the necessary subgoals have been solved for an overall success.</Paragraph>
    <Paragraph position="5"> Accounting for user knowledge and abilities. Cooperative problem solving involves maintaining a dynamic profile of user knowledge, termed a user model. This concept is described for example in \[Kobsa and Wahlster, 1988\] and \[Kobsa and Wahlster, 1989\], \[Chin, 1989\], \[Cohen and Jones, 1989\], \[Finin, 1989\], \[Lehman and Carbonell, 1989\], \[Morik, 1989\], and \[Paris, 1988\]. The user  model specifies information needed for efficient interaction with the conversational partner. Its purpose is to indicate what needs to be said to the user to enable the user to function effectively. It also indicates what should be omitted because of existing user knowledge.</Paragraph>
    <Paragraph position="6"> Because considerable information is exchanged during the dialog, the user model changes continuously. Mentioned facts are stored in the model as known to the user and are not repeated. Previously unmentioned information may be assumed to be unknown and may be explained as needed. Questions from the user may indicate lack of knowledge and result in the removal of items from the user model.</Paragraph>
    <Paragraph position="7"> Change of initiative. A real possibility in a cooperative interaction is that the user's problem solving ability, either on a given subgoal or on the global task, may exceed that of the machine. When this occurs, an efficient interaction requires that the machine yield control so that the more competent partner can lead the way to the fastest possible solution. Thus, the machine must be able to carry out its own problem solving process and direct the actions to task completion or yield to the user's control and respond cooperatively to his or her requests.</Paragraph>
    <Paragraph position="8"> This is a mixed-initiative dialog as studied by \[Kitano and Van Ess-Dykema, 1991\], \[Novick, 1988\], \[Whittaker and Stenton, 1988\], and \[Walker and Whittaker, 1990\].</Paragraph>
    <Paragraph position="9"> As a pragmatic issue, we have found that at least four initiative modes are useful: (1) directive - The computer has complete dialog control. It recommends a subgoal for completion and will use whatever dialog is necessary to obtain the needed item of knowledge related to the subgoal.</Paragraph>
    <Paragraph position="10"> (2) suggestive - The computer still has dialog control, but not as strongly. The computer will make suggestions about the subgoal to perform next, but it is also willing to change the direction of the dialog according to stated user preferences.</Paragraph>
    <Paragraph position="11"> (3) declarative - The user has dialog control, but the computer is free to mention relevant, though not required, facts as a response to the user's statements.</Paragraph>
    <Paragraph position="12"> (4) passive - The user has complete dialog control.</Paragraph>
    <Paragraph position="13"> The computer responds directly to user questions and passively acknowledges user statements without recommending a subgoal as the next course of action.</Paragraph>
    <Paragraph position="14"> Expectation of user input. Since all interactions occur in the context of a current subdialog, the user's input is far more predictable than would be indicated by a general grammar for English. In fact, the current subdialog specifies the focus of the interaction, the set of all objects and actions that are locally appropriate. This is the attentional structure described by \[Grosz and Sidner, 1986\] and its most important function in our system is to predict the meaning structures the user is likely to communicate in a response. For illustration, the opening of a chassis cover plate will often evoke comments about the objects behind the cover; the measurement of a voltage is likely to include references to a voltmeter, leads, voltage range, and the locations of measurement points.</Paragraph>
    <Paragraph position="15"> The subdialog structure thus provides a set of expected utterances at each point in the conversation and these have two important roles: (1) The expected utterances provide strong guidance for the speech recognition system so that error correction can be maximized. Where ambiguity arises, recognition can be biased in the direction of meaningful statements in the current context. Earlier researchers who have investigated this insight are \[Erman et al., 1980\], \[Walker, 1978\], \[Fink and Biermann, 1986\], \[Mudler and Paulus, 1988\], \[Carbonell and Pierrel, 1988\], \[Young et al., 1989\], and \[Young and Proctor, 1989\].</Paragraph>
    <Paragraph position="16"> (2) The expected utterances from subdialogs other than the current one can be used to indicate that one of those others is being invoked. Thus, expectations are one of the primary mechanisms needed for tracking the conversation as it jumps from subdialog to subdialog. This is known elsewhere as the plan recognition problem and it has received much attention in recent years. See, for example, \[Allen, 1983\], \[Litman and Allen, 1987\], \[Pollack, 1986\], and \[Carberry, 1990\].</Paragraph>
    <Paragraph position="17"> Systems capable of all of the above behaviors are rare as has been observed by \[Allen et al., 1989\]: &amp;quot;no one knows how to fit all of the pieces together.&amp;quot; One of the contributions of the current work is to present an architecture that can provide them all in the limited domair of electric circuit repair. \[Allen et al., 1989\] describe their own architecture which concentrates on representations for subdialog mechanisms and their interactiom, with sentence level processing. Our work differs fro~ theirs on many dimensions including our emphasis oR achieving mixed-initiative, real time, voice interactiv~ dialog which utilizes a user model.</Paragraph>
  </Section>
  <Section position="4" start_page="9" end_page="10" type="metho">
    <SectionTitle>
3 The Zero Level Model
</SectionTitle>
    <Paragraph position="0"> The system implemented in our laboratory (described in great detail in \[Smith, 1991\]) achieves the above bC/~ haviors sufficiently to enable efficient human-machine di.</Paragraph>
    <Paragraph position="1"> alogs in the electric circuit repair environment. The com.</Paragraph>
    <Paragraph position="2"> plexity of the system prevents its complete descriptior here. However, a zero level model has been devised fol pedagogical purposes which illustrates its principles o: operation. This model mimicks the mechanism of th~ dialog machine while omitting the huge array of detail., necessary to make a real system work. A later sectiot in this paper describes the actual implementation anC/ some of its major modules.</Paragraph>
    <Paragraph position="3"> The zero level model is the recursive subroutine Zmod Subdialog shown in figure 1. This routine is entered witl a single argument, a goal to be proven, and its actiont are to carry out a Prolog-style proof of the goal. A sid~ effect of the proof may be a resort to voice interaction~ with the user to supply necessary missing axioms, h  Transfer control depending on which expected response was received Successful response: Return with success Negative response: No action Confused response: Modify rule for clarification; prioritize rule for execution Interrupt: Match response to expected response of another subdialog; go to that subdialog (mode) If R is a general rule then Store its antecedents While there are more antecedents to process Do Grab the next one and enter ZmodSuh~ialog with it If the ZmodSubdialog exits with failure then terminate processing on rule R If all antecedents of R succeed, return wit h success</Paragraph>
  </Section>
  <Section position="5" start_page="10" end_page="11" type="metho">
    <SectionTitle>
NOTE: SUCCESSFUL COMPLETION OF THIS ROUTINE DOES NOT NECESSARILY MEAN TRANSFER OF CONTROL
TO THE CALLING ROUTINE. CONTROL PASSES TO THE SUBDIALOGUE SELECTED BY THE DIALOG CONTROLLER.
</SectionTitle>
    <Paragraph position="0"> fact, the only voice interactions the system undertakes are those called for by the theorem proving machinery.</Paragraph>
    <Paragraph position="1"> The ZmodSubdialog routine has a unique capability needed for proper modeling of subdialog behaviors. Specifically, its actions may be suspended at any time so that control may be passed to another subdialog, another instantiation of ZmodSubdialog that is aimed at achieving another goal. However, control may at a later time return to the current instantiation to continue its execution. In fact, a typical computation involves a set of ZmodSubdialog instantiations all advanced to some point in the proofs of their respective goals; control passes back and forth between them looking for the most likely chances of success until, finally, enough goals are proven to complete the global proof.</Paragraph>
    <Paragraph position="2"> The algorithm becomes understandable if an example is followed through in full detail. Assume that the following database of Prolog-like rules are contained in the system knowledge base.</Paragraph>
    <Paragraph position="3">  Further assume that ZmodSubdialog is entered with argument Goal = set(knob,10). Then in Prolog fashion, the routine grabs the rule R: set(knob,Y) ~-- find(knob),adjust(knob,Y), and attempts to prove set(knob,10). The algorithm offers three choices depending on whether R is trivial (a single predicate which is not vocalize(X)), tt is vocalize(X), or R is a rule with antecedents as is the case here. Thus, in this case the third alternative is followed, and the two antecedents are queued for sequential execution (find(knob) and adjust(knob,10)). Then the first antecedent is selected and ZmodSubdialog is entered with argument Goal = find(knob).</Paragraph>
    <Paragraph position="4"> The new subdialog to achieve find(knob) is short, however, since the user model indicates the user already knows how to find the knob because find(knob) exists as an available rule. In fact, ZmodSubdialog finds find(knob) in the rule base, enters the first choice (trivial) and returns with success. If find(knob) had not been found in the user model, the system might have engaged in dialog to achieve this goal. The subdialog control mechanism is not obligated to pass control back to the calling routine, but in this example we will assume that it does.</Paragraph>
    <Paragraph position="5"> Satisfactory proof of find(knob) means that the next antecedent at this level, adjust(knob,10), can be attempted, and ZmodSubdialog is entered with this goal.</Paragraph>
    <Paragraph position="6"> Here, our model selects R = Y ~-- usercan(Y), vocalize(Y), unifying Y with adjust(knob,lO). Then a deeper call to ZmodSubdialog finds usercan(adjust(knob,X)) in  the user model which means control passes to the antecedent vocalize(adjust(knob,10)). This yields another entry to ZmodSubdialog and a selection of the second branch. Here the system executes a voice output to satisfy vocalize(adjust(knob,10)): &amp;quot;Set the knob to one zero.&amp;quot; The handling of the goal find(knob) illustrates how the user model can act to satisfy the theorem proving process and prevent the enunciation of unneeded information. As the theorem proving process proceeds, the fact that a user knows something is represented in the knowledge base as an achieved goal. Theorem proving will encounter this and proceed without voice interaction. In the example, the model already indicates that the user knows how to find the knob so no voice interaction is needed for this goal.</Paragraph>
    <Paragraph position="7"> The handling of the goal adjust(knob,10) illustrates how the user model supports the theorem proving process by enabling voice dialog when it is needed. This goal could not be proven by application of rules available in the database and the proof was blocked from further progress. In our terminology, there was a &amp;quot;missing axiom&amp;quot; for the proof. So the system must either give up on this proof or try to fill in the missing axiom by resorting to voice dialog. In the current case, voice dialog was enabled by the user model fact usercan(adjust(knob,X)).</Paragraph>
    <Paragraph position="8"> This fact opens the way for a query to the user. If the query is positively answered, then the missing axiom is made available.</Paragraph>
    <Paragraph position="9"> The role of the user model is thus to supply or fail to supply axioms at the bottom of the proof tree. It both inhibits extraneous verbalism and enables interactions necessary to prove the theorem.</Paragraph>
    <Paragraph position="10"> Returning to the example computation of ZmodSubdialog, a voice output has just been given, and the system then records, for this output, the set of expected</Paragraph>
    <Paragraph position="12"> Expected responses are compiled from the domain knowledge base and from the dialog controller knowledge base.</Paragraph>
    <Paragraph position="13"> The user's response is then matched (unified) against the expected meanings and subsequent actions depend on which meaning fits best. Four different types of actions may occur at this point.</Paragraph>
    <Paragraph position="14"> (1) The user might respond with some paraphrase of &amp;quot;I set the knob to one zero,&amp;quot; or &amp;quot;Okay&amp;quot;, which would be interpreted as successful responses. The routine ZmodSubdialog would return with success.</Paragraph>
    <Paragraph position="15"> (2) The user might also answer &amp;quot;No&amp;quot; yielding a failure and another cycle around the theorem proving loop looking for an applicable rule.</Paragraph>
    <Paragraph position="16"> (3) The user might respond with &amp;quot;What color is the knob?&amp;quot; indicating, there may be a chance for a success here if there is further dialog.</Paragraph>
    <Paragraph position="17"> In fact, our system handles such a need for clarification by dynamically modifying the rule and reexecuting with a newly required clarification subdialog. Here the rule set(knob,10) find(knob), adjust(knob,10) becomes modified to set(knob,10) ~-- find(knob), vocalize(knob,white), adjust(knob,10). Reexecution will then yield an explanation of the knob color followed by the previous request reenunciated: &amp;quot;Set the knob to one zero.&amp;quot; (4) The user might respond with an utterance that matches no local expectation. Here the system examines expectations of other subdialogs and searches for an acceptable match. If one is found, control will pass to that subdialog.</Paragraph>
    <Paragraph position="18"> For example, if the response is, &amp;quot;The LED is flashing seven,&amp;quot; and if this is an appropriate response in some other subdialog, control will pass to it.</Paragraph>
    <Paragraph position="19"> The control of initiative in ZmodSubdialog is handled by special processing at the steps marked &amp;quot;mode.&amp;quot; Thus, in strongly directive mode, verbal outputs will be very positively stated, responses will be expected to be obedient, and interrupts to other subdialogs will be restricted. In less demanding modes, outputs will be weaker or merely suggestive, a wider range of responses will be allowed, and transitions to other subdialogs will be more freely permitted. In the most passive mode, there are few outputs except answers to questions, and an interrupt to any subdialog is acceptable.</Paragraph>
    <Paragraph position="20"> A very important part of the dialog system is the domain processor, the application dependent portion of the system. It receives all information related to the current problem and suggests debugging steps to carry the process further. We model calls to this processor with the rule: debug(X) ~-- (debuggingstep(X))*. This rule is called upon to debug device X with the predicate debug(X) and its effect is to specify a sequence ot debugging steps which will be specified dynamically as the problem unfolds and which will lead to repair of the device.</Paragraph>
  </Section>
  <Section position="6" start_page="11" end_page="12" type="metho">
    <SectionTitle>
4 The Implementation
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="11" end_page="12" type="sub_section">
      <SectionTitle>
4.1 An Integrated Architecture
</SectionTitle>
      <Paragraph position="0"> The implemented system is based on a computational model for dialog processing presented in \[Smith, 1991\].</Paragraph>
      <Paragraph position="1"> The model is applicable to the general class of task-oriented dialogs, dialogs where the computer is assistin~ the user in completing a task as the dialog ensues. The derived implementation consists of the following modules: null dialog controller - This is the supervisor of the dialog processing system. It provides the subdialog processing highlighted in the zero level model. In addition, it provides the complex algorithm required to properly handle arbitrary clarification subdialogs and interrupts as well as provide the dialog expectations needed to  assist with input interpretation. It also maintains all dialog information shared by the other modules and controls their activation.</Paragraph>
      <Paragraph position="2"> domain processor- As previously mentioned, it provides suggestions about debugging steps to pursue. In our system the domain processor assists users in circuit repair. It receives user-supplied domain information from the dialog controller and returns suggested debugging subgoals to the controller for consideration. The subgoal selection process weighs the level of expected usefulness of a subgoal with the number of times the subgoal has been previously selected. Consequently, the module may recommend challenging previously reported information if no noticeable progress in the task is being made. In this manner, the module and system can recover from erroneous inputs. If the dialog system is to be used to repair other devices, this is the module that needs to be replaced. null knowledge This is the repository of information about task-oriented dialogs including: (1) rules for proving completion of goals; (2) user model information including a set of rules for inferring user model information from user input; (3) rules for determining when a clarification subdialog should be initiated; and (4) rules for defining the expectations for the user's response as a function of the type of goal being attempted. Note that the predefined information of this module is easily modified without requiring changes to the dialog controller. theorem prover - This provides the general reasoning capability of the system. In order to allow the dialog controller to control the potentially arbitrary movement among subdialogs, the theorem prover has been made interruptible and put under the supervision of the dialog controller. Consequently, the theorem prover can maintain a set of partially completed proofs, and can activate different proofs as instructed by the dialog controller. It can also dynamically modify the proof structure, a key feature for handling clarification subdialogs. Foremost, the theorem prover is able to suspend itself when it encounters a missing axiom, permitting natural language interaction to assist in axiom acquisition. This contrasts with traditional theorem proving approaches (e.g. Prolog) which simply engage in backtracking when a missing axiom is encountered.</Paragraph>
      <Paragraph position="3"> linguistic interface - This consists of the generation and recognition modules. They use information on context and expectation as provided by the dialog controller. The linguistic generator was developed by Robin Gambill. It uses a rule-driven approach that takes as input an utterance specification which encapsulates the desired meaning and produces as output an English string that is sent to a text-to-speech converter for enunciation. Various approaches to generation have been described in \[Danlos, 1987\], \[Hovy, 1988\], \[Jacobs, 1987\], \[McKeown, 1985\], and \[Patten, 1988\]. The recognition module was designed to be able to recover from ungrammatical inputs. It will be described in greater detail below.</Paragraph>
    </Section>
    <Section position="2" start_page="12" end_page="12" type="sub_section">
      <SectionTitle>
4.2 Minimum distance parsing
</SectionTitle>
      <Paragraph position="0"> A challenging design problem in any natural language system is the development of a parser which will translate the lattice of words output by the speech recognizer into a phrase of some synthetic language (Prolog in our instance) which encapsulates the meaning of what was originally spoken. The design difficulty is exacerbated by the fact that due to speech recognition errors, the word lattice output by the speech recognizer is probably different from what the user spoke, and the fact that users will sometimes speak with a word order or sentence construction which the designers of the parser's grammar did not forsee. (These, and other problems associated with robust parsing of speech are further described in \[Eastman and McLean, 1981\], \[Hayes et aL, 1986\], and \[Young et al., 1989\].) In our system, parsing is accomplished using a minimum-distance parsing algorithm, similar to algorithms described in \[Aho and Peterson, 1972\], \[Lyon, 1974\], and \[Levinson, 1985\], but extended to accept a lattice as input, instead of a simple word list, and also extended to simultaneously perform syntax-directed translation \[Aho and Ullman, 1969\] into the target language. Minimum-distance parsing finds strings in a given context-free language which can be converted to a string of the input lattice with a minimum number of weighted insertions and deletions. When two or more strings are equidistant from the input, dialog expectation is used to break the tie. The minimum-distance parsing algorithm is very robust - it always finds at least one parse - but it is also computationally expensive. Our algorithm is faster than previously reported parsing algorithms of the same generality, but it still required careful hand-crafting and optimization on a fast machine in order to provide real-time response. It should also be noted that our recognition system is capable of selective verification of meaning. This is highlighted in the following sample dialogs.</Paragraph>
    </Section>
  </Section>
  <Section position="7" start_page="12" end_page="13" type="metho">
    <SectionTitle>
5 Sample Dialogs
</SectionTitle>
    <Paragraph position="0"> Figure 2 shows two dialogs obtained from actual usage of the system. These dialogs can be seen in \[Hipp and Smith, 1991\] that is part of the video presentation of the conference. The words in parentheses found beside certain user statements are the words actually provided by the speech recognizer. Where the discrepancy between the output of the speech recognizer and the words produced by the user is insignificant, they have been omitted.</Paragraph>
    <Paragraph position="1"> The first dialog is an entire dialog conducted in declarative mode. Particular points to notice from this user-controlled dialog are:  Dialog 1 - Declarative Mode (C denotes the computer, U the user, and R the recognizer)  1. C: 2. U: 3. C:  10. U: 11. C:  This is the circuit fix it shop. Hoe may I help you? I want to fix this rs111.</Paragraph>
    <Paragraph position="2"> I am familiar with that circuit. The LED is supposed to be displaying alternately flashing one and seven.</Paragraph>
    <Paragraph position="3"> The LED is displaying an alternately flashing one and the top corner of a seven. There is supposed to be a wire between connector nine nine and connector one zero zero. U: It is there.</Paragraph>
    <Paragraph position="4"> C: There is supposed to be a wire between connector nine nine and connector one zero two. U: There is no wire on connector one zero four. (R: stays know wire i connector one zero for) C: There is supposed to be a wire between connector one zero four and connector one zero two. \[User adds wire and verifies the circuit is repaired, a three step process.\] The circuit is working.</Paragraph>
    <Paragraph position="5"> Glad to have been of assistance. Good-bye.</Paragraph>
    <Paragraph position="6"> Dialog 2 - Directive Mode excerpt (begins just after computer describes what circuit does)  8. U: 9. C: I0: U: 11. C: 12. U: 13. C: 14. U: 15. C: 16. U: 17 C: 18 U: 19 C: 20 U: 21 C: 22 U: 23 C:  The LED is displaying nothing.</Paragraph>
    <Paragraph position="7"> What is the switch at when the LED is off? The switch is down.</Paragraph>
    <Paragraph position="8"> Put the switch up.</Paragraph>
    <Paragraph position="9"> Done.</Paragraph>
    <Paragraph position="10"> Put the knob to one zero.</Paragraph>
    <Paragraph position="11"> Which knob7 Near the top boundary and in the center is a green region. right of this green region is the control knob. The knob is at one zero.</Paragraph>
    <Paragraph position="12"> What is the LED displaying? The LED is displaying a one and seven at the same time. Put the knob to zero.</Paragraph>
    <Paragraph position="13"> Done.</Paragraph>
    <Paragraph position="14"> What is the LED displaying? The same thing. (R: the same same) Did you mean to say the LED is displaying the same thing? Now, in the middle 24. U: Yes.</Paragraph>
    <Paragraph position="15"> \[Eventually, a missing wire is detected and added, and the computer explicitly guides the user through the verification process. The entire dialog lasts 51 utterances.\]  (1) Successful processing of anaphoric reference at utterance 6.</Paragraph>
    <Paragraph position="16"> (2) Successful shifts to user-initiated subdialogs at utterances 8 and 10.</Paragraph>
    <Paragraph position="17"> (3) Successful recovery from speech recognition er null rors at utterance 8.</Paragraph>
    <Paragraph position="18"> The second dialog is an excerpt from a dialog conducted in directive mode (strongly computer-controlled dialog). The total dialog lasted 51 utterances in contrast to the 11 utterance declarative mode dialog. Particular points to notice from this excerpt include:  (1) Computer responses which are more directed and forceful in content than in dialog 1. (2) Successful handling of a clarification subdialog (utterances 13-16).</Paragraph>
    <Paragraph position="19"> (3) Successful verification of the implicit meaning  of a user utterance in the presence of speech recognition errors in utterance 22. In contrast with utterance 8 of diMog 1, the system decided an explicit verification subdialog was required to ascertain the meaning of the user's utterante. null</Paragraph>
  </Section>
class="xml-element"></Paper>