<?xml version="1.0" standalone="yes"?>
<Paper uid="W00-0303">
  <Title>Dialogue Management in the Mercury Flight Reservation System</Title>
  <Section position="2" start_page="0" end_page="0" type="intro">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> Dialogue modeling is a critical and challenging aspect of conversational systems, particularly when users are permitted flexibility with regard to defining the constraints of the task. For systems that adopt a strict system-initiated approach, it is feasible to define a set of states and state transitions depending on the usually small number of possible user actions at each state. However, if the user is permitted to say anything within the scope of the recognizer at any time, such a finite-state solution becomes unwieldy. We are interested in the development of mixed-initiative systems, where the system may make specific requests or suggestions, but the user is not required to be compliant. Instead of a finite state dialogue model, we choose to decompose dialogue state into a set of state variables.</Paragraph>
    <Paragraph position="1"> The activities for a given turn typically involve the sequential execution of a number of specialized routines, each of which performs a specific part of the dialogue requirements and alters the state variables in particular ways. To determine which of the operations should be performed, the system consults a dialogue control table, which is specified in a simple scripting language.</Paragraph>
    <Paragraph position="2"> This paper describes experiments with using this approach to dialogue modeling in the context of our Mercury flight reservation system. Mercury allows users to plan air travel between 226 cities worldwide.</Paragraph>
    <Paragraph position="3"> Following log-on, the user interacts with the system to select the flights of their trip. When the flight plan is completed, the system takes the initiative to offer to price and email the itinerary. Finally, the system asks the user a few questions to help determine user satisfaction.</Paragraph>
    <Paragraph position="4"> The overall system makes use of the GALAXY architecture \[Seneffet al (1999)\], which consists of a number of specialized servers that communicate with one another via a central programmable hub. An audio server captures the user's speech via a Dialogic board, and transmits the waveform to the speech recognizer \[Glass et al (1996)\]. The language understanding component \[Seneff (1992)\] parses a word graph produced by the recognizer and delivers a semantic frame, encoding the meaning of the utterance, to the discourse component. The output of the discourse component \[Seneff (1996)\] is the framein-context, which is transformed into a flattened E-form (electronic form) by the generation server. This E-form is delivered to the turn manager, and provides the initial settings of the dialogue state.</Paragraph>
    <Paragraph position="5"> The turn manager consults the dialogue control table to decide which operations to perform, and typically engages in a module-to-module subdialogue to retrieve tables from the database. It prepares a response frame, which may or may not include tabular entries. The response frame is sent to the generation component \[Glass (1994)\] which transforms it in parallel into both a text string and an annotated string that specifies the input controls for the speech synthesizer. Finally, the speech synthesizer transmits a waveform to the audio server which then relays the spoken response to the user over the telephone. The entire dialogue is recorded in detail in a log file for later examination.</Paragraph>
  </Section>
class="xml-element"></Paper>