Dialog management context sharing

#Spoken language processing systems include various modules and components for receiving speech input from a user, determining what the user said, and acting upon what the user said. In some implementations, a spoken language processing system includes an automatic speech recognition (“ASR”) module that receives audio input of a user utterance and generates one or more likely transcriptions of the utterance. Spoken language processing systems may also include a natural language understanding (“NLU”) module that receives textual input, such as a transcription of a user utterance, and determines the meaning of the text in a way that can be acted upon, such as by a computer application. Spoken language processing systems may also include a dialog manager (“DM”) that manages interaction of a user with the system, prompts the user for information that may be required to execute various applications or perform various functions, provides feedback to the user, etc. For example, a user of a mobile phone may make a spoken command to initiate a phone call. Audio of the spoken command can be transcribed by the ASR module, and the NLU module can determine the user's intent (e.g., that the user wants to initiate a phone call) from the transcription. The dialog manager can prompt the user for any additional information required to initiate the phone call (e.g., what number the user would like to call).

#In prompting users for information required to perform various functions, dialog managers can follow pre-determined scripts, follow rules regarding what information is required, etc. Some dialog managers may initiate a series of questions, with each question designed to obtain a particular type of information from the user. For example, when a user would like to schedule a flight, the dialog manager may prompt the user regarding what the user would like to do (DM: “What would you like to do?” User: “Book a flight.”), where the user will be travelling from (DM: “Where would you like to depart?” User: “Los Angeles”), where the user will be travelling to (DM: “Where would you like to go?” User: “Chicago”), etc. Some dialog managers allow a user to provide information, and the dialog manager can prompt the user for any additional required information (User: “I want to book a flight to Chicago.” DM: “Where would you like to depart?”). The user experience and perceived performance of dialog managers and other spoken language processing system features may be defined in terms of the number of prompts to which a user must respond, the accuracy of the system in interpreting user answers to the prompts, and the total amount of time and effort that must be expended to complete a spoken command or query.

#Embodiments of various inventive features will now be described with reference to the following drawings. Throughout the drawings, reference numbers may be re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate example embodiments described herein and are not intended to limit the scope of the disclosure.

#FIGS. 1A and 1B are block diagrams of illustrative interactions between a user, a dialog manager and various applications showing context sharing.

#FIG. 2 is a block diagram of illustrative interactions between a user, a dialog manager and various applications showing sharing of tagged contextual information.

#Spoken language processing systems can use dialog managers to manage interaction with users. One function of a dialog manager is to prompt a user for information that may be required to perform a task requested by the user. For example, a user may wish to book a flight to a certain location, such as Chicago, Ill. The user may say “I'd like to book a flight to Chicago.” The dialog manager may prompt the user regarding when the user would like to fly, to which airport in Chicago the user would like to fly, and the like. The dialog manager may initiate a flight booking application or service to book the flight, provide the user with confirmation, etc. Such an interaction between a user and a spoken language processing system may be referred to as a “dialog”—one or more user utterances associated with a particular task (e.g., one or more user utterances and optional system responses during which a user gives a command or requests information, and the spoken language processing system executes the command or provides the requested information). A “conversation” may be one or more dialogs relating to the same user task or which involve execution of the same application or function. After such a conversation, the spoken language processing system is not waiting for additional information to carry out a user command or respond to the request, and the user is not waiting for additional information or for execution of the command. A user may engage in multiple (e.g., two or more) such conversations in a given period of time.

#Some dialog managers store contextual information for a given conversation in order to resolve anaphora within a given conversation. The contextual information may include a map of all words spoken by a user and all words spoken to the user, or some subset thereof, for a given dialog or for the conversation as a whole. The context may be used later in the conversation to resolve anaphora. In the flight booking example, if a user says “When is the next flight there?” the contextual information may be used to help determine that “there” refers to “Chicago.” Typically, dialog managers treat each conversation separately. Users may be prompted to provide all information required to carry out a command or perform some other function in connection with a subsequent conversation, even if the user may have provided one or more required items of information in a prior conversation. This often occurs when, e.g., a subsequent conversation includes a command that is not an extension of the previous conversation or is not otherwise directly related to the previous conversation. Returning to the example above, if a user subsequently says “Tell me what the weather is going to be like there,” a conventional dialog manager may prompt the user for a location and a date. The dialog manager may do so even though the user previously specified a target location (Chicago, Ill.) and a date (the date of the flight) in the flight booking conversation because the new request is part of a new dialog or conversation involving execution of a different application than the flight booking application. Requiring a user to provide information that the user has recently provided is inefficient, can frustrate the user, and can generally result in a poor user experience.

#Some applications may be configured to provide information in addition to the information that was requested, or information in a different modality that what was requested. In the weather example above, a weather application or service may be accessed to obtain the weather forecast and provide the forecast to the user (e.g., synthesized speech indicating that “The weather will be 80 degrees and sunny.”) However, the weather application may also be able to provide more detailed forecasts (e.g., 7-day or hourly forecasts) or forecast in a different modality (e.g., a visual weather map) in addition to the synthesized speech read out of the forecast. Such additional information or information associated with a different modality may be suitable for use by a different application in response to a subsequent request from the user, such as request to send weather information to another device or to a contact's email address. Conventional dialog managers may not have any way of receiving and storing information provided by one application for the express purpose of later sharing it with another application rather than to be immediately (or substantially immediately) provided to the user in connection with the current user request or dialog. Instead, conventional dialog managers typically store only information provided by a user or to a user in connection with the immediate function, command, or conversation; there is no facility to share information between applications that was not first proved by or to the user.