Techniques for conversational processing using contextual data

Abstract

Techniques are described for using data stored in association with context levels for users to improve efficiency and accuracy of dialog processing tasks. A dialog system stores historical dialog data associated with a plurality of configured context levels. The dialog system receives an utterance and identifies terms for disambiguation from the utterance. Based on the determined context level, the dialog system identifies relevant historical data stored to a database. The historical data can be used to perform tasks such as resolving ambiguity based on user preferences, disambiguating named entities based on previous dialog, and identifying previously generated answers to queries. Based on the context level, the dialog system can efficiently identify relevant information and use the identified information to provide a response.

Description

[0001] Cross-references to related applications

[0002] Under 35 USC 119(e), this application claims the benefit and priority of U.S. Application No. 62 / 899,649, filed September 12, 2019, entitled “CONTEXT-BASEDDIALOG TECHNIQUES”, and U.S. Application No. 17 / 003,250, filed August 26, 2020, the contents of which are incorporated herein by reference in their entirety for all purposes. Technical Field

[0003] This disclosure generally relates to dialogue systems. More specifically, but not in a limiting manner, this disclosure describes techniques for using historical context levels to influence dialogue tasks such as named entity linking and result ordering. Background Technology

[0004] More and more devices are now enabling users to interact directly with them using voice or spoken words. For example, users can converse with such devices in natural language, asking questions or making statements requesting certain actions. In response, the device performs the requested action or answers the user's question using voice output. Because interacting directly with voice is a more natural and intuitive way for humans to communicate with their environment, the popularity of such voice-based systems is growing at an astronomical rate.

[0005] Current dialogue systems have limited ability to utilize context. Systems exist that can discern contextual information based on recent input. For example, some existing systems can parse pronouns by identifying the person named in the last sentence received by the system. However, in traditional systems, contextual information is not fully utilized. Summary of the Invention

[0006] This disclosure generally relates to dialogue systems. More specifically, techniques for using historical context levels to influence dialogue tasks such as named entity linking and result ordering are described. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, etc.

[0007] In some embodiments, the dialogue system receives spoken utterances from a user. The dialogue system processes the spoken utterances to identify terms for disambiguation. The dialogue system determines the context level of the terms for disambiguation from a plurality of predefined context levels. Based on the determined context level, the dialogue system uses a database that stores multiple user values ​​associated with the context level to identify the value of the term, and uses the identified value to disambiguate the term.

[0008] In some aspects, the dialogue system also generates a logical form for spoken utterances based on disambiguated terminology, generates a response based on this logical form, and outputs the response to the user. In some aspects, the dialogue system also identifies stored execution results from a database based on the logical form, wherein the response is also generated based on the execution result. In some aspects, the dialogue system also stores the representation of spoken utterances, their logical form, and the response in a database.

[0009] In some aspects, identifying the value involves: selecting a database for that context level from multiple context-level-based databases based on the determined context level, and querying the selected database using the user's identifiers and terms to identify the value. In some aspects, the dialogue system also identifies stored data from multiple previous conversations with the user in the database and analyzes the identified data to calculate the value. In some aspects, multiple predefined context levels include immediate context, short-term context, medium-term context, and long-term context.

[0010] The embodiments also include systems and computer-readable media (e.g., non-transient computer-readable storage) configured to perform the methods described herein.

[0011] The above and other features and embodiments will become more apparent from the following description and accompanying drawings. Attached Figure Description

[0012] Figure 1 This is a simplified block diagram illustrating a dialogue system according to certain embodiments.

[0013] Figure 2 This illustrates certain embodiments. Figure 1 A simplified diagram of the context-level database for a dialogue system.

[0014] Figure 3 This is a simplified flowchart depicting a method for context-based dialogue processing according to certain embodiments.

[0015] Figure 4 This is a simplified flowchart depicting additional context-based dialogue processing techniques according to certain embodiments.

[0016] Figure 5 It describes, according to certain embodiments, the method for generating [something]. Figure 3-4 A simplified flowchart of the context-based value-based methods used in the processing.

[0017] Figure 6 A simplified diagram of the distributed system used to implement the embodiments is depicted.

[0018] Figure 7This is a simplified block diagram of a cloud-based system environment according to certain embodiments, in which various storage-related services can be provided as cloud services.

[0019] Figure 8 An exemplary computer system that can be used to implement certain embodiments is shown. Detailed Implementation

[0020] In the following description, specific details are set forth for purposes of explanation in order to provide a thorough understanding of certain embodiments. However, it will be apparent, however, that various embodiments may be practiced without these specific details. These figures and descriptions are not limiting. The word “exemplary” as used herein means “serving as an example, instance, or illustration.” Any embodiment or design described herein as exemplary is not necessarily to be construed as preferred or superior to other embodiments or designs.

[0021] Voice-enabled systems capable of conversing with users via voice input and voice output can take various forms. For example, such systems can be provided as standalone devices, as digital or virtual assistants, as voice-enabled services, etc. In each of these forms, the system is capable of receiving voice or speech input, understanding the input, generating a response or taking an action in response to the input, and outputting a response using voice output. In some embodiments, the conversational functionality in such a voice-enabled system is provided by a conversational system or infrastructure (“conversational system”). The conversational system is configured to receive voice or speech input, interpret the voice input, maintain the conversation, possibly perform one or more actions based on the interpretation of the voice input, prepare appropriate responses, and output the responses to the user using voice or speech output.

[0022] As mentioned above, context is used in a very limited way in traditional dialogue systems. While traditional systems can track very short-term context (e.g., from the current dialogue session), they do not manage user context data in a systematic way. Therefore, traditional systems may require additional inputs and outputs to resolve ambiguities. For example, if a user says "my favorite airline" or "the person I talked to this morning," a traditional dialogue system may not have access to the necessary information to resolve the meaning of such user input. In this case, the dialogue system must request the necessary information and receive and process responses, which increases the overall length of the dialogue session and the time and computational resources required to answer queries.

[0023] The techniques described herein improve the efficiency of dialogue processing tasks by using historical dialogue data stored in association with different context levels for different users. Implementations allow access to historical queries, including associated context, logical form, execution results, date and time, and other metadata. The dialogue system disclosed herein can maintain information about users, such as what type of health insurance they have, where they work, which airlines they prefer to book with, etc. The dialogue system uses context-level information (e.g., immediate, short-term, medium-term, and long-term contexts) to understand user requests. The dialogue system can track a range of different contexts and use these contexts as a source of preference for understanding user requests. The dialogue system can use this information to process requests involving contextual data (e.g., "call back my HR representative who just called") and also indirectly influence the interpretation of the current request based on previously successful requests.

[0024] In some embodiments, when a user interacts with the dialogue system, the system can remember the user's previous preferences and essentially use these preferences as background assumptions. For example, a user requests the dialogue system to book a flight. The dialogue system stores information indicating that the user previously selected to fly with a specific airline. When the system generates a result, it ranks flights from that specific airline higher than flights from other airlines.

[0025] In some embodiments, the system systematically personalizes results through named entity linking. Named entity linking can involve connecting named entities (e.g., people, things, etc.) to entries in a database. For example, a dialogue system in a car receives the voice input, “Take me to Starbucks®.” The dialogue system must select a specific Starbucks® from several potential locations. The specific instance of linking the word “Starbucks” to a Starbucks® coffee shop is an example of using named entity linking to personalize results, which can be achieved efficiently using the contextual data described herein.

[0026] In some embodiments, different levels of context are established, such as short-term, medium-term, and long-term. Short-term context can be used to preserve pronouns. Medium-term context can be used to answer requests such as, “Call back the HR person I spoke with this morning.” Long-term context can include preferences, such as whether a person likes or dislikes flying with a particular airline. Data at each context level can be maintained and used in different ways.

[0027] In some embodiments, the dialogue system performs a disambiguation task to resolve ambiguity. Such a task may include named entity links when the user omits relevant details (e.g., "Give me flights to Tampa" without specifying an airline or date). The dialogue system maintains a user-specific database of historical voice input and / or other data associated with the user, which can be used to determine various levels of context for resolving such ambiguity.

[0028] In some embodiments, the dialogue system may make a determination (e.g., resolve ambiguities) based on explicit and / or implicit preferences previously expressed by the user. Explicit preferences may correspond to user statements. Implicit preferences may be expressed by the user selecting an item from a list of options presented to the user, by the user visiting a location, etc.

[0029] Figure 1 An example of a dialogue system 100 according to some embodiments is shown. The dialogue system 100 is configured to receive voice or speech input 104 (also referred to as voice utterances) from a user 102. The dialogue system 100 can then interpret the voice input. The dialogue system 100 can maintain a dialogue with the user 102 and may perform one or more actions or enable one or more actions to be performed based on the interpretation of the voice input. The dialogue system 100 can prepare an appropriate response and output the response to the user using voice or speech output.

[0030] In some embodiments, the processing performed by the dialogue system is implemented by a pipeline of components or subsystems, including a voice input component 105, a wake word detection (WD) subsystem 106, an automatic speech recognition (ASR) subsystem 108, a natural language understanding (NLU) subsystem 110, the NLU subsystem 110 including a named entity recognizer (NER) subsystem 112, a semantic parser subsystem 114, a context subsystem 115, a dialogue manager (DM) subsystem 116, a natural language generator (NLG) subsystem 118, a text-to-speech (TTS) subsystem 120, a voice output component 124, and one or more context-level databases (130-136). The subsystems listed above may be implemented solely in software (e.g., using code, programs, or instructions executable by one or more processors or cores), in hardware, or a combination of hardware and software. In some implementations, one or more subsystems may be combined into a single subsystem. Additionally or alternatively, in some implementations, the functionality performed by a particular subsystem described herein may be implemented by multiple subsystems.

[0031] Voice input component 105 includes hardware and software configured to receive voice input 104. In some cases, voice input component 105 may be part of dialogue system 100. In some other instances, voice input component 105 may be separate from and communicatively coupled to dialogue system 100. Voice input component 105 may, for example, include a microphone coupled to software configured to digitize the voice input and transmit it to wake word detection subsystem 106.

[0032] The wake word detection (WD) subsystem 106 is configured to listen to and monitor an audio input stream in response to input corresponding to a specific sound, word, or phrase (referred to as a wake word). When a wake word configured for the dialogue system 100 is detected, the WD subsystem 106 is configured to activate the ASR subsystem 108. In some implementations, the user may be provided with the ability to activate or deactivate the WD subsystem 106 (e.g., by speaking the wake word and pressing a button). When activated (or operating in active mode), the WD subsystem 106 is configured to continuously receive and process the audio input stream to identify audio or speech input corresponding to the wake word. When audio input corresponding to the wake word is detected, the WD subsystem 106 activates the ASR subsystem 108.

[0033] As described above, the WD subsystem 106 activates the ASR subsystem 108. In some implementations of the voice-enabled system, mechanisms other than a wake word can be used to trigger or activate the ASR subsystem 108. For example, in some implementations, a button on the device can be used to trigger ASR subsystem 108 processing without a wake word. In such implementations, the WD subsystem 106 may not be provided. When a button is pressed or activated, voice input received after button activation is provided to the ASR subsystem 108 for processing. In some implementations, the ASR subsystem 108 can be activated upon receiving input to be processed.

[0034] The ASR subsystem 108 is configured to receive and monitor spoken speech input after a trigger or wake-up signal (e.g., a wake-up signal may be sent by the WD subsystem 106 when a wake-up word is detected in the speech input, a wake-up signal may be received when a button is activated, etc.), and convert the speech input into text. As part of its processing, the ASR subsystem 108 performs speech-to-text conversion. The spoken utterance or speech input may be in natural language form, and the ASR subsystem 108 is configured to generate corresponding natural language text in the language of the speech input. The speech input received by the ASR subsystem 108 may include one or more words, phrases, clauses, sentences, questions, etc. The ASR subsystem 108 is configured to generate text utterances for each spoken clause and feed these text utterances to the NLU subsystem 110 for further processing.

[0035] NLU subsystem 110 receives text generated by ASR subsystem 108. The text received by NLU subsystem 110 from ASR subsystem 108 may include text utterances corresponding to spoken words, phrases, clauses, etc. NLU subsystem 110 translates each text utterance (or a series of text utterances) into its corresponding logical form.

[0036] In some implementations, the NLU subsystem 110 includes a Named Entity Recognizer (NER) subsystem 112 and a Semantic Parser (SP) subsystem 114. The NER subsystem 112 performs named entity linking by matching named entities with unique identities. Named entity linking can be considered a disambiguation task because it involves identifying the appropriate identity corresponding to a set of possible identities for a given named entity. For example, the named entity “Erik Erickson” can be linked to one of several identities, including developmental psychologist Erik Erikson, television commentator Erik Erikson, conductor Eric Ericson, and actor Eric Ericson. The appropriate identity can be identified based on context. For example, the NLU subsystem 110 receives the voice input “Find the books written by Erik Erikson.” The NLU subsystem 110 can determine that among the possible Erik Eriksons, the developmental psychologist is someone who has written multiple books. Therefore, the named entity “Erik Erikson” is linked to the developmental psychologist Erik Erikson.

[0037] NER subsystem 112 receives text utterances as input, identifies named entities within the text utterances, and tags the text utterances with information associated with the identified named entities. The tagged text utterances are then fed to SP subsystem 114, which is configured to generate logical forms for each tagged text utterance (or a series of tagged text utterances). The logical forms generated for the utterances can identify one or more intents corresponding to the text utterances. The intent of an utterance identifies its purpose. Examples of intents include "order pizza" and "find directions." For instance, an intent can identify the action requested to be performed.

[0038] In addition to intent, the logical form generated for text utterance can also identify slots (also called parameters or independent variables) used for the identified intent. A slot is a predefined attribute, which can be a parameter of one or more intents. Slots can be labeled by the NLU subsystem 110 and matched with entities or other information. For example, the city “Moscow” can be matched with specific slots based on context, such as toloc.city_name if someone wants to buy a flight to Moscow, fromloc.city_name if someone wants to buy a flight departing from Moscow, and so on. Slot filling can be considered a sequence labeling problem and can be solved using techniques such as recurrent neural networks. For example, for the voice input “I want to order a large Italian sausage pizza with mushrooms and olives”, the NLU subsystem 110 can identify the intent to order a pizza. The NLU subsystem 110 can also identify and fill slots such as pizza_size (fill with large) and pizza_toppings (fill with mushrooms and olives). The NLU subsystem 110 can generate logical forms using machine learning-based techniques, rules (which can be domain-specific), or a combination of both. The logical form generated by the NLU subsystem 110 is then fed into the DM subsystem 116 for further processing.

[0039] In some embodiments, the NLU subsystem 110 includes a context subsystem 115. The context subsystem 115 can determine the context of terms identified from received utterances. Terms can be words, phrases, sentences, or word groups. Examples of terms include “the restaurant I went to last Friday,” “coffee shop,” and “my favorite airline.” The context subsystem 115 can use the determined context to identify information to disambiguate terms and / or perform actions associated with the terms, as described herein. References are provided below. Figure 3-4 The techniques for using context for dialogue processing are described in more detail. In some embodiments, the context subsystem 115 is communicatively coupled to multiple context-level databases (e.g., context-level 1 database (DB) 130, context-level 2 DB 132, context-level 3 DB 134, ..., context-level N DB 136). The context subsystem 115 can retrieve useful information from selected context-level databases based on the determined context level.

[0040] DM subsystem 116 is configured to manage dialogue with a user based on logical forms received from NLU subsystem 110. As part of dialogue management, DM subsystem 116 is configured to track dialogue state, initiate the execution of one of several actions or tasks, or perform one of several actions or tasks itself, and determine how to interact with the user. These actions may include, for example, querying one or more databases, generating execution results, and other actions. For example, DM subsystem 116 is configured to interpret intents identified in the logical forms received from NLU subsystem 110. Based on the interpretation, DM subsystem 116 may initiate one or more actions requested by the voice input provided by the user, as interpreted by it. In some embodiments, DM subsystem 116 may perform such actions using information stored in context-level databases (e.g., context-level 1 DB 130, context-level 2 DB 132, context-level 3 DB 134, ..., context-level N DB 136). For example, if DM subsystem 116 has identified the answer to a question, DM subsystem 116 may retrieve the answer from the appropriate context-level database.

[0041] In some embodiments, the DM subsystem 116 performs dialogue state tracking based on current and past voice input and on a set of rules (e.g., dialogue policies) configured for the DM subsystem 116. These rules may specify different dialogue states, transition conditions between states, actions to be performed when in a particular state, etc. These rules may be domain-specific. In some embodiments, machine learning-based techniques (e.g., machine learning models) may also be used. In some embodiments, a combination of rules and machine learning models may be used. The DM subsystem 116 also generates responses to be transmitted back to the users involved in the dialogue. These responses may be based on actions initiated by the DM subsystem 116 and their results. The responses generated by the DM subsystem 116 are fed to the NLG subsystem 118 for further processing.

[0042] NLU subsystem 110 and / or DM subsystem 116 can communicatively couple to multiple context-level based databases (e.g., Context Level 1 DB 130, Context Level 2 DB 132, Context Level 3 DB 134, ..., Context Level N DB 136). Each context-level database 130-136 can store data specified for a particular context level among multiple context levels. For example, context levels can include immediate context, short-term context, intermediate context, and long-term context. Immediate context can correspond to a previously requested topic (e.g., within a conversation session). Short-term context can correspond to voice input within a conversation session (e.g., possibly earlier than a previous request in the conversation). Intermediate context can correspond to specific things that the user might remember and might specifically mention (e.g., "The HR representative I spoke with this morning"). Long-term context can correspond to user preferences learned by the system from previous conversations and user behavior (e.g., the user prefers to fly with American Airlines). Storing conversation history in association with context levels can accelerate database queries by narrowing search fields to relevant entries. For example, immediate context can be used for pronoun parsing, while long-term context can be used for named entity inlining or ranking results. The following is for reference. Figure 2 Further examples of data types stored in a context-level database are provided.

[0043] In some embodiments, each context-level database is used to bind data to different types of context-levels. For example, context-level 1 DB 130 is used for immediate context-related data, context-level 2 DB 132 for short-term context-related data, context-level 3 DB 134 for medium-term context-related data, and context-level N DB 136 for long-term context-related data. Context-level 1 DB 130 can be used to store data from the current conversation session (e.g., the last received voice input). When evaluating this data, it can be moved and / or copied to a longer-term database. For example, after a conversation session terminates, data related to that conversation session is deleted from context-level 1 DB 130 and stored in context-level 2 DB 132. Data can also be copied and / or moved to a long-term database based on information identified by the dialogue system 100. For example, if it is determined that data in context-level 2 DB 132 is related to general user preferences, such data can be stored in context-level N DB 136.

[0044] Alternatively or additionally, the dialogue system 100 may store dialogue history in a database in association with context levels in different ways (e.g., without using a separate database). For example, dialogue history data may be tagged with context levels, pointers may specify context levels, or other appropriate means may be used to organize history data by context levels.

[0045] In some implementations, the dialogue system 100 can manage context along different "dimensions." For example, time is one dimension, while "discourse level," "dialogue level," "short-term," "medium-term," etc., are contexts along the time dimension. Context can also be identified and used along other dimensions, such as geography. Examples of geographical context include "local geography," "city level," "state level," "country level," etc.

[0046] NLG subsystem 118 is configured to generate natural language text corresponding to the response generated by DM subsystem 116. The text can be converted into speech by TTS subsystem 120. TTS subsystem 120 receives the text from NLG subsystem 118 and converts each of them into speech or audio, which can then be output to the user via audio or speech output component 124 of the dialogue system (e.g., a speaker or a communication channel coupled to an external speaker). In some cases, speech output component 124 may be part of dialogue system 100. In some other instances, speech output component 124 may be separate from and communicatively coupled to dialogue system 100.

[0047] As described above, the various subsystems of the collaborative dialogue system 100 provide functionality that enables the dialogue system 100 to receive voice input 104 and respond using voice output 122, and to maintain dialogue with the user using natural language speech. These various subsystems can be implemented using a single computer system or using multiple collaborative computer systems. For example, for a device implementing a voice-enabled system, the subsystems of the dialogue system 100 described above can be implemented entirely on the device with which the user interacts. In some other implementations, some components or subsystems of the dialogue system 100 can be implemented on the device with which the user interacts, while other components can be implemented remotely, possibly on other computing devices, platforms, or servers.

[0048] As described above, in some embodiments, the dialogue system 100 can be implemented using a pipeline of subsystems. In some embodiments, one or more subsystems can be combined into a single subsystem. In some embodiments, functionality provided by a particular subsystem can be provided by multiple subsystems. A particular subsystem can also be implemented using multiple subsystems.

[0049] In some embodiments, machine learning techniques can be used to implement one or more functions of the dialogue system 100. For example, supervised machine learning techniques, such as those using neural networks (e.g., deep neural networks), can be used to implement one or more functions of the dialogue system 100. As an example, a neural network can be provided, trained to perform the ASR functions, and such a trained model can be used by the ASR subsystem 108 for its processing. Such a neural network implementation can take speech input as input and output text utterances to an NLU subsystem. Other subsystems of the dialogue system 100 can also use machine learning-based models.

[0050] Figure 2 An example of a context-level database 200 is shown (e.g., Figure 1 (Context level 1 DB 130, context level 2 DB 132, context level 3 DB 134, or context level N DB 136). See the above references. Figure 1 The dialogue system 100 may include or be communicatively coupled to multiple context-level databases (e.g., context-level 1 DB 130, context-level 2 DB 132, context-level 3 DB 134, ... context-level N DB 136) storing historical data 201 at different context levels, such as immediate context, short-term context, medium-term context, etc.

[0051] In some embodiments, the context-level database 200 is a storage unit and / or device (e.g., a file system, database, table collection, or other storage mechanism) for storing data related to previous conversational sessions. The context-level database 200 may include multiple different storage units and / or devices. The context-level database 200 may be local to the conversational system 100 (e.g., local storage) and / or connected to the conversational system 100 via a network (e.g., cloud storage).

[0052] The context-level database 200 can store historical data 201 related to user conversations. Historical data 201 may include user identifiers (IDs) (user IDs (user ID A 202A, ..., user ID N 202N)), context values ​​(204A, ..., 202N), conversation data (206A, ..., 206N), conversation metadata (208A, ..., 208N), and execution results (210A, ..., 210N).

[0053] In some embodiments, historical data 201 is stored in association with a specific user and can be indexed using a user ID (e.g., user ID A 202A, ..., user ID N 202N). A user ID is a personal identifier, such as a name, alphanumeric identifier, nickname, etc. For a given user, context values ​​(204A, 204N), dialogue data (206A, 206N), dialogue metadata (208A, 208N), and execution results (210A, 210N) can be stored in the context-level database 200 in association with the corresponding user ID.

[0054] Context values ​​(e.g., context value 204A, ..., context value 204N) may include information learned by the dialogue system 100 during previous conversations with a particular user. For example, in the long term, the dialogue system 100 may know that a particular user's favorite restaurant is Sue's Diner in Boise, Idaho. In the medium term, the dialogue system 100 may know that in the past week, a particular user met with John Jones on Wednesday and Tiffany Smith on Friday. Such information can be stored as context values ​​(204A, 204N).

[0055] In some embodiments, context values ​​(204A, 204N) are stored as values ​​of key-value pairs. For example, the key "the coffee shop I went to yesterday" is stored as an association with the value "Beach Beans in Key West, Florida," while "favorite airline" is stored as an association with the value "United®." Other examples of key-value pairs include name=Sam, color=red, book=Bible, etc. A "key" is an attribute, and a "value" is the value of that attribute. In some embodiments, the key may be stored as a vector representation of the item to facilitate matching with data processed by the dialogue system 100.

[0056] In some implementations, the context values ​​(204A, 204N) may also include contextual information from other sources (e.g., in addition to conversation history data). Such context values ​​(204A, 204N) may include user preferences and activities obtained from employment records, internet caches, location tracking data, etc. For example, conversation system 100 may be linked to an email server from which the conversation system retrieves the user's emails. As another example, conversation system 100 may obtain and store the user's internet search history. As an additional example, conversation system 100 may obtain and store activity-based records associated with the user, such as employee records, medical records, and / or purchase history.

[0057] In some embodiments, the dialogue data (206A, 206N) includes information combined with information stored from previous dialogue sessions. The dialogue data (206A, 206N) may include historical queries received by the dialogue system 100 and responses provided by the dialogue system 100. For example, a dialogue session may occur as follows:

[0058] User voice input: Book me a flight to Cincinnati.

[0059] The dialogue system outputs: Okay, which day?

[0060] User voice input: July 10th

[0061] The dialogue system outputs: Do you prefer morning, afternoon, or evening?

[0062] User voice input: Afternoon.

[0063] The system outputs: Okay, I have an Ohio Airlines flight at 2 p.m.

[0064] User voice input: I prefer American Airlines.

[0065] The system outputs: Okay, we'll choose the American Airlines flight at 3:30.

[0066] The dialogue system 100 stores dialogue logs associated with users in a context-level database 200. The dialogue system 100 can update the context-level database 200 as additional dialogues occur. For example, the dialogue system 100 can store historical data 201 corresponding to multiple dialogues with a specific user in the context-level database 200.

[0067] Each user's dialogue data (206A, 206N) may include textual utterances or other representations generated based on spoken utterances received from the user over many dialogue sessions (e.g., over several days or years). The dialogue data (206A, 206N) may also include logical forms. For example, based on a given utterance from a previous dialogue session, the dialogue system 100 may generate and store a logical form generated by the dialogue system 100 based on that utterance.

[0068] In some embodiments, the dialogue metadata (208A, 208N) is metadata associated with historical dialogue sessions. The dialogue metadata (208A, 208N) may include date, time, location, receiving device (e.g., car, telephone, smart TV, etc.). For a given dialogue data 206A, the corresponding dialogue metadata 208A can be mapped directly or through the associated user ID A 202A to the dialogue data 206A.

[0069] In some embodiments, the execution results (210A, 210N) include information retrieved based on historical queries. A given execution result 210A can be mapped to corresponding dialogue metadata 208A, dialogue data 206A, context value 204A, and user identifier 202A. As an example, dialogue data 206A includes the historical query “How tall is the Statue of Liberty?”. Based on the historical query, the dialogue system 100 previously performed an internet search and identified execution result 210A as “305 feet”. Such execution results (210A, 210N) can be associated with related data 202A-208N and stored in the context-level database 200 to accelerate future queries.

[0070] Figure 3 A simplified flowchart illustrating a method for context-based dialogue technology is presented. Figure 3 The processing illustrated can be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processor, core) of a corresponding system, hardware, or combination thereof. The software can be stored on a non-volatile storage medium (e.g., a storage device). Figure 3 The methods presented and described below are intended to be illustrative and non-limiting. Although Figure 3 Various processing steps that occur in a specific sequence or order are described, but this is not intended to be limiting. In some alternative embodiments, these steps may be performed in a different order, or some steps may be performed in parallel. In some embodiments, Figure 3 The processing described herein can be performed by the NLU subsystem 110 and other components of the aforementioned dialogue system 100.

[0071] At 302, the dialogue system receives spoken words from the user. The dialogue system may receive spoken words from the user, for example, via voice input component 105. Spoken words may be received as waveforms. Spoken words may be language-specific and may be in the form of natural language queries. Spoken words may specify the question the user wants the dialogue system to answer, specify one or more actions the user wants the dialogue system to initiate (e.g., “I want a medium sausage pizza”), etc.

[0072] In some embodiments, input may be received in text form instead of voice input (as in 302), for example, when a user types text while chatting with a conversational system. The techniques described in this disclosure can be used with systems that receive input in the form of spoken voice or text input or a combination thereof.

[0073] At 304, the dialogue system processes spoken utterances to identify terms used for disambiguation. Terms can be single or phrases that collectively convey ideas. Examples of "terms" used here include "dinner restaurant," "the coffee shop I went to this morning," "he," "my boss," "my wife," and "my favorite bar." Processing spoken utterances may include (e.g., by ASR subsystem 108) generating text utterances based on the spoken utterances. ASR subsystem 108 can then pass the generated text utterances to NLU subsystem 110 for further processing. The NLU subsystem can then initiate the generation of the logical form of the text utterances. The NLU subsystem can begin recognizing words and performing named entity linking, slot filling, and other tasks.

[0074] In this processing, the NLU subsystem can identify certain terms associated with ambiguity. For example, the term "she" might have a vague interpretation because it could refer to various different individuals previously mentioned by the user providing the voice input. As another example, the term "the coffee shop I went to on Thursday" might be ambiguous because the coffee shop is not obvious from the current voice input. As yet another example, the term "my favorite ice cream" might be ambiguous because the user's favorite ice cream is not obvious from the current voice input.

[0075] At 306, the dialogue system (e.g., context subsystem 115) determines the context level of the term used for disambiguation from a plurality of predefined context levels. Context subsystem 115 may determine the context level based on the term used for disambiguation identified at 304 and / or other words in the spoken utterance processed at 304. Context subsystem 115 may use machine learning models and / or rules to determine the context level. For example, if a particular keyword indicates that the context is intermediate (e.g., “last week,” “Thursday,” etc.), the context level is determined to be intermediate. As another example, if the utterance indicates that the user’s overall preferences or characteristics are to be identified (e.g., by including terms such as “my favorites,” “my doctor,” “my assistant,” etc.), the context level is determined to be long-term.

[0076] In some cases, the dialogue system can traverse context levels as needed (for example, the dialogue system can initially assign short-term context levels, and if no relevant data is identified in the short-term context level database, the dialogue system can reassign the context level to a medium-term one, and so on).

[0077] At 308, the dialogue system (e.g., context subsystem 115) identifies the value of a term based on the context level determined at 306. Context subsystem 115 uses a database storing multiple values ​​of the user associated with the context level to identify the value of the term. In some embodiments, such as Figure 1 As shown, the dialogue system includes or is communicatively coupled to multiple databases, each for a different context level. In such an implementation, the context subsystem 115 selects a database for the context level identified at 306. For example, if the context level determined at 308 is intermediate, the dialogue system identifies a database for intermediate context level data.

[0078] The context subsystem 115 can query a selected database using a user identifier and terms used to identify values. For example, the context subsystem 115 can execute an SQL query using parameters that include terms used to disambiguate (e.g., the key of a key-value pair). The query can also include the user identifier and one or more additional words identified from spoken utterances.

[0079] In some embodiments, the value identified at 308 is a context value stored in context-level database 200 (e.g., context values ​​204A, 204N). Context subsystem 115 can identify the stored context values ​​by querying context-level database 200 using terms for disambiguation. In some embodiments, context values ​​are stored as part of key-value pairs. The key can be a term for disambiguation or a term derived therefrom. The key can be used to formulate a query to retrieve the stored context value (e.g., a query could be: find the value of "key=favorite airline"). In some cases, additional words or phrases from received voice input can also be used to formulate a query (e.g., a query could be: find the value of "key=favorite airline" and "location=USA"). This can be useful if different preferences are configured based on different context dimensions (e.g., if different domestic and international airline preferences are configured).

[0080] Alternatively or additionally, in some implementations, historical data 201 may be stored in a single database or in multiple databases not assigned to a specific context level. In such implementations, techniques such as using pointers to data to indicate the context level of various historical data stored in one or more context level databases can be used to associate context levels with values. In such implementations, the dialog system can use techniques such as including the context level as a parameter in a query to the database to identify data based on context, rather than identifying the context-based database. For example, the dialog system can use the query: "Find the value of key=favorite airline" and "context level=mid-term" to retrieve the stored context value.

[0081] As described above regarding box 306, in some cases, the context subsystem 115 can traverse context levels while identifying a specific value. For example, given the statement "Please book a ticket with my favorite airline," the dialogue system will disambiguate "favorite airline," i.e., determine the value of the airline. First, the dialogue system may consider the utterance-level context and find that the value cannot be found from the stored utterance-level data. Next, the dialogue system queries the session-level data in the database. If the user has already identified his favorite airline in the dialogue, then potentially, the session-level context can be used to determine the value of the favorite airline. Next, assuming that the favorite airline cannot be determined at the session level, the dialogue system can sequentially query the time-period contexts of "short-term" (defined by a time period such as 1 month), "medium-term" (e.g., 6 months), and "long-term" (e.g., 1 year). For each time period, the dialogue system can query the appropriate database using the key "favorite airline" until one or more matching values ​​are identified.

[0082] In some embodiments, the NLU subsystem 110 may compute the value using other historical data 201 stored in a context-level database (e.g., dialogue data (206A, 206N), dialogue metadata (208A, 208N), and / or execution results (210A, 210N)) instead of retrieving the stored context value. The NLU subsystem 110 may use the historical data 201 to compute values ​​for using statistical analysis and / or machine learning models to eliminate terminological ambiguity, as referenced below. Figure 5 Further description.

[0083] At 310, NLU subsystem 110 uses the value identified at 308 to dissolve ambiguity of the term. In some cases, the value identified at 308 can be used directly to dissolve ambiguity of the term. For example, NLU subsystem 110 can dissolve ambiguity of the term "coffee shop" by linking the term "coffee shop" to the named entity "Joe's coffee" based on the stored key-value pair: key=coffee shop, value="Joe's coffee".

[0084] In some embodiments, terminology disambiguation can be performed by the NLU subsystem 110 within the context of named entity linking. For example, the term used for disambiguation is the word "Moscow," and it is unclear from the instantaneous voice input whether the user is referring to Moscow in Russia or Moscow in Idaho. The NLU subsystem 110 determines that the user habitually engages in conversations related to Moscow in Idaho. Therefore, the NLU subsystem 110 links the term "Moscow" to the named entity Moscow in Idaho.

[0085] In some embodiments, disambiguation of terminology can be performed by the NLU subsystem 110 in the context of slot filling. For example, the received spoken utterance may not explicitly include a slot value, but the user's history contains a large number of similar requests, all of which include the same value for that slot. Therefore, the NLU subsystem 110 suggests the value for that slot. As a specific example, if a user has a history of habitually booking flights to New York, and the current voice input does not specify a destination city, then at 308, the system can fill the destination city slot with "New York" based on the user's historical data identified from the database.

[0086] In some embodiments, disambiguation of terms can be performed by the NLU subsystem 110 within the context of the ranking results. For example, the NLU subsystem 110 may prepare to display multiple options to the user (e.g., multiple coffee shops in Bellevue). If the user has explicitly or implicitly expressed a preference for a particular coffee shop, the NLU subsystem 110 may rank that coffee shop higher, as reflected in historical data identified from the database at point 308.

[0087] In some embodiments, terminology ambiguity can be disambiguated by the NLU subsystem 110 within the context of pronoun and noun phrase reference resolution. For example, the term is "her," and the NLU subsystem 110 identifies the corresponding contact, "Mom," based on the immediate context in the database. The NLU subsystem 110 can provide a response to a speech input corresponding to a ranking result (e.g., identifying a birthday based on linking "her" to "Mom" and looking up the associated birthday to provide the speech output "Mom's birthday is June 1st").

[0088] In some cases, in addition to the value identified at 308, the NLU subsystem 110 can use additional factors when dissolving terminological ambiguity. For example, the NLU subsystem 110 can use values ​​that combine additional contextual dimension factors (e.g., based on temporal and geographic context) to dissolve terminological ambiguity. As a specific example, the NLU subsystem 110 can perform named entity linking based on a combination of location and contextual preferences (e.g., location accounts for 60% and historical coffee shop selection accounts for 40%). As another example, the utterance “point a way to McDonald’s®” will produce different answers depending on whether the user is at work, at home, or traveling in different cities. Therefore, in some embodiments, the dialogue system can use multiple contexts corresponding to different dimensions to dissolve terminological ambiguity.

[0089] In some embodiments, at 304-306, the NLU subsystem 110 can identify multiple values ​​corresponding to multiple respective context levels. In this case, disambiguation of terms may include selecting one of the values ​​or sorting the values. For example, the NLU subsystem 110 may use configured rules to select one of multiple potential values. As a specific example, the rule may specify the selection of the value determined from the shortest-term context being evaluated. If the user's short-term context data produces the value "Airline A" and the user's medium-term context data produces the value "Airline B", then in one example, Airline A may be selected because it is the most recent (i.e., using the newer context). Alternatively, the rule may specify the selection of the longest-term context because the long-term context uses the largest user data baseline. In some other embodiments, the NLU subsystem 110 may output two airlines to the user and allow the user to select one.

[0090] Figure 4 A simplified flowchart illustrating the additional context-based dialogue technology is depicted. Figure 4 The processing illustrated can be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processor, core) of a corresponding system, hardware, or combination thereof. This software can be stored on a non-volatile storage medium (e.g., a storage device). Figure 4 The methods presented and described below are intended to be illustrative and non-limiting. Although Figure 4 Various processing steps that occur in a specific sequence or order are described, but this is not intended to be limiting. In some alternative embodiments, these steps may be performed in a different order, or some steps may be performed in parallel. In some embodiments, Figure 4 The processing described herein can be performed by the NLU subsystem 110, the DM subsystem 116, and other components of the aforementioned dialogue system 100. Figure 4 The processing can be done Figure 3 Execute after processing.

[0091] At 402, the dialogue system generates a logical form for the spoken utterance received at 302, based on the disambiguated terms at 310. The NLU subsystem of the dialogue system can generate the logical form using the disambiguated terms and any additional words identified when processing the spoken utterance at 304. The logical form can also be generated based on the context level determined at 306. The NLU subsystem (e.g., Figure 1The semantic parser subsystem 112 of the NLU subsystem 110 can use semantic parsing to generate logical forms. Semantic parsing can be performed using machine learning algorithms such as recurrent neural networks (RNNs) or graph parsers. The resulting logical forms can be of various forms, such as lambda calculus, abstract meaning representation (AMR), or Python or Java expressions. (See, for example, Liang, Lambda Dependency-Based Compositional Semantics, arXiv: 1309.4408 (2013); Yin and Neubig, A Syntactic Neural Model for General-Purpose Code Generation, arXiv: 1704.01696 (2017); Banarescu et al., Abstract Meaning Representation for Sembanking, Proceedings of 7th Linguistic Annotation Workshop (2013)).

[0092] At 310, the NLU subsystem 110 can generate a logical form that includes values ​​for disambiguating terms. For example, the value might identify a user's favorite bar as "Joe's Place". The logical form generated based on the spoken utterance "What time does my bar open?" could include "Joe's Place" as a slot in the logical form. Alternatively or additionally, the logical form could include information obtained by the dialogue system based on the disambiguated value (e.g., an address, a pointer to information, etc.).

[0093] In some implementations, SP subsystem 112 generates a logical form that includes contextual information, which DM subsystem 116 and NLG subsystem 118 can use at 408 to generate a response. For example, the logical form may include pointers to entries in the appropriate context-level database (e.g., context-level 1 DB 130, context-level 2 DB 132, context-level 3 DB 134, or context-level N DB 136), which can be used to efficiently retrieve information for preparing a response. For instance, when dialogue system 100 analyzes a utterance, it can identify from the context-level database the execution result from a previous dialogue involving the value in question. As a concrete example, a user is asking for “Maria’s phone number.” The dialogue system previously identified Maria’s phone number in a dialogue from the previous week and stored the execution result, including that phone number, in the context-level database. The logical form may include pointers to the phone number and / or the phone number itself.

[0094] At 404, the dialog system identifies the stored execution result from the database based on the logical form. The dialog system can use the pointer received from the logical form to retrieve the execution result from the database. Continuing the example above, DM subsystem 116 receives a logical form from NLU subsystem 110 that includes a pointer to Maria's phone number. DM subsystem 116 can then use this pointer to retrieve Maria's phone number from the context-level database.

[0095] At 406, the dialogue system generates a response based on the logical form and execution result. The DM subsystem 116 and / or the NLG subsystem 118A can recognize the information requested by the user and package that information into a natural language form. In some cases, this may involve using the execution result retrieved at 404. Alternatively or additionally, the DM subsystem 116 can perform an action to retrieve the requested information (e.g., via looking up another database or internet query, by sending an email or text message, etc.). Continuing with the phone number example above, the DM subsystem 116 can use a pointer to a context-level database to recognize Maria's phone number and add words to generate a natural language response – "Maria's number is 515-567-4444. Would you like to call her now?"

[0096] Therefore, the response can be based on Figure 3The response is generated by a disambiguation task performed during processing. The response may include the results of named entity linking (e.g., a weather forecast for Moscow, Idaho next week determined based on a named entity corresponding to Moscow, Idaho). Alternatively or additionally, the response may include the results of slot filling (e.g., information about flights to New York determined based on filling the destination city slot with New York). Alternatively or additionally, the response may include the results of ranking the results (e.g., listing several coffee shops in order based on context-based preferences).

[0097] In some embodiments, the response may include multiple values ​​retrieved from a database. For example, the dialogue system may include two possible choices for a favorite airline in the response and generate a response such as, “Over the past month, airline A appears to be your favorite airline, while over the past 6 months, airline B appears to be your favorite airline. Please choose whether you want to book (1) airline A or (2) airline B.” As another example, the dialogue system may rank four coffee shops near the user’s current geographic location, prioritizing the option for that chain based on the user’s historical preferences for that chain, where the response includes a list of those four coffee shops in ranking order.

[0098] At 408, the dialogue system outputs the generated response to the user. The dialogue system can provide the response as output via the speech output component 124 (e.g., to a user who speaks uttering input at 202). The dialogue system can convert the text response generated by the dialogue manager subsystem 116 and the natural language generation subsystem 118 into speech output via the text-to-speech subsystem 120. Alternatively or additionally, the dialogue system can provide the response by displaying the text response on a display component.

[0099] In some respects, after outputting a response to the user, the dialogue system updates its database. The dialogue system can store information such as the representation of the spoken utterance (e.g., the text utterance derived from the spoken utterance), its logical form, and the information from the response in the database. This information can then be used to improve the dialogue system's understanding of user preferences, thereby improving the processing of future queries.

[0100] Figure 5 A simplified flowchart illustrating the additional context-based dialogue technology is depicted. Figure 5 The processing illustrated can be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processor, core) of a corresponding system, hardware, or combination thereof. This software can be stored on a non-volatile storage medium (e.g., a storage device). Figure 5 The methods presented and described below are intended to be illustrative and non-limiting. Although Figure 5Various processing steps that occur in a specific sequence or order are described, but this is not intended to be limiting. In some alternative embodiments, these steps may be performed in a different order, or some steps may be performed in parallel. In some embodiments, Figure 5 The processing described herein can be performed by the NLU subsystem 110, the DM subsystem 116, and other components of the aforementioned dialogue system 100. Figure 5 The processing can be done Figure 3 Executed before or after processing. For example, Figure 5 The processing can generate and store data in a context-level database 200 and... Figure 3 and Figure 4 The values ​​used in the processing. Alternatively or additionally, Figure 5 The processing can be done Figure 3 and Figure 4 This is executed after processing to update historical data 201 in context-level database 200. Alternatively or additionally, Figure 5 The processing can be used as Figure 3 It is performed as part of the processing (e.g., to identify the value at 308).

[0101] In a 502 error, the dialogue system identifies stored data from a database of multiple previous conversations with the user. (See above reference.) Figure 2 As described, the context-level database 200 may include historical data 201 stored in association with different users. Based on user identifiers, a user's historical data can be selected. This historical data may include context values, dialogue data, dialogue metadata, and / or execution results.

[0102] In some respects, dialogue systems identify stored data from multiple previous conversations from one or more context-level databases. For example, in some cases, a dialogue system may use a selected database (e.g., a short-term context database, a medium-term context database, or a long-term context database) to generate values. In other cases, a dialogue system may retrieve information from multiple context-level databases (e.g., to determine long-term preferences, a dialogue system may identify new data from a short-term context database and older data from a long-term context database).

[0103] In some embodiments, the dialogue system can also identify additional data not generated from the dialogue session. For example, the dialogue system can retrieve information from a user's employer, such as the user's health insurance provider, address, income, colleagues' names, etc. As another example, the dialogue system can obtain information from a user's internet history, such as websites visited, search terms, etc. As yet another example, the dialogue system can obtain Global Positioning System (GPS) data associated with a specific user from the GPS-enabled user device the user uses to interact with the dialogue system. Such information may or may not be stored in a context-level database 200.

[0104] At 504, the dialogue system analyzes the data identified at 502 to calculate a value. The dialogue system can use statistical analysis and / or machine learning models to calculate the value identified at 308. As an example, if a user booked 22 flights over two years via the dialogue system, the dialogue system can access stored data on multiple different airlines selected by the user. The dialogue system can perform statistical analysis to identify the most frequently selected airlines. In some cases, the dialogue system can perform such statistical analysis filtering to a specific context-relevant time period (e.g., by identifying the airlines the user booked most frequently in the past week). This can be assisted by using dialogue metadata (208A, 208N) to link the user's selection to a time period (e.g., by subtracting the dialogue metadata value representing the time when a specific utterance was received from the current time value). Alternatively or additionally, the dialogue system can perform other types of statistical analysis, such as identifying the median of a set of preferences, the rate of change of preferences, etc. In some embodiments, the dialogue system can apply machine learning models to data in a database to predict values ​​such as user preferences.

[0105] In some respects, dialogue systems can compute values ​​based on implicit preferences. For example, data indicating that a user selected an item from a list of options one or more times can be stored (e.g., if a user selects a particular gas station multiple times from a displayed list, the dialogue system can infer a preference for that gas station even if the user doesn't actually say its name to the system). As another example, dialogue systems can use location data to compute values ​​indicating implicit preferences (e.g., if GPS data indicates that a user has repeatedly shopped at a particular store, the dialogue system can use that information to reinforce the user's preference for the store indicated by the spoken input received and stored for the user).

[0106] At 506, the dialogue system can store the calculated value in a database. If the value indicates a long-term preference, the dialogue system can store the calculated value in a long-term context database and / or have an indicator that the context is a long-term context. If the value indicates a medium-term value (e.g., the name of the song the user was listening to that morning, the last person called, etc.), the calculated value can be stored in a medium-term context database and / or have an indicator that the context is a medium-term context. In some respects, the dialogue system can calculate the value in runtime—for example, during the process of identifying the value at 308. In this case, the value may or may not be subsequently stored in the database (i.e., the value can be calculated in real time, rather than retrieved from the database). Alternatively or additionally, these values ​​can be generated periodically—e.g., weekly. Figure 5 The processing can be performed to generate and / or update a set of key-value pairs stored for a specific user.

[0107] According to an embodiment, the present invention provides a dialogue system comprising: a component for receiving spoken utterances from a user; a component for processing the spoken utterances to identify terms for disambiguation; a component for determining a context level of the terms for disambiguation from a plurality of predefined context levels; a component for preparing a response based on the context level and the disambiguated terms; and a component for outputting the response to the user.

[0108] According to an embodiment, the dialogue system further includes: a component for identifying the value of a term using a database that stores multiple values ​​of the user associated with the context level based on a determined context level; a component for disambiguating the term using the identified value; a component for generating a logical form of spoken utterance based on the disambiguated term; and a component for preparing a response based on the logical form.

[0109] According to an embodiment, the dialogue system also includes a component for identifying stored execution results from the database based on logical form, and the response is also generated based on the execution results.

[0110] According to an embodiment, the dialogue system also includes components for storing the representation, logical form, and response of spoken utterances in a database.

[0111] According to an embodiment, identifying the value includes: selecting a database for the determined context level from a plurality of context-level-based databases; and querying the selected database using the user's identifiers and terms to identify the value.

[0112] According to an embodiment, the dialogue system also includes components for identifying stored data of multiple previous dialogues with the user from a database; and components for analyzing the identified data to calculate the value.

[0113] The techniques described here offer several advantages. Utilizing stored historical information in response to voice input allows dialogue systems to respond more accurately without constantly asking the user to clarify the same points. This can lead to reduced latency in providing output in response to received queries. Furthermore, by storing contextual information associated with different context levels, dialogue systems can speed up the process of providing responses. For example, if a dialogue system determines that the information of interest is in one of five different context-level databases, it can identify which context-level database is appropriate. The dialogue system can then query a smaller dataset (e.g., approximately one-fifth of the data volume in the example of five databases), resulting in faster query execution.

[0114] By using a context-based database to retrieve the results of previous executions, additional reductions in latency and computational resources can be provided. For example, if the system has already retrieved the lyrics to a user's favorite song, the lyrics can be quickly retrieved from the context database if the user requests them a second or third time. Therefore, the techniques described herein can reduce latency and computational resource usage at multiple levels.

[0115] The aforementioned infrastructure can be implemented in a variety of different environments, including cloud environments (which can be of various types, including private, public, and hybrid cloud environments), enterprise environments, hybrid environments, etc.

[0116] Figure 6 A simplified diagram of a distributed system 600 for implementing an embodiment is depicted. In the illustrated embodiment, the distributed system 600 includes one or more client computing devices 602, 604, 606, and 608 coupled to a server 612 via one or more communication networks 610. The client computing devices 602, 604, 606, and 608 can be configured to execute one or more applications.

[0117] In various embodiments, server 612 may be adapted to run one or more services or software applications capable of performing dialogue tasks based on historical context.

[0118] In some embodiments, server 612 may also provide other services or software applications that may include non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services, such as to users of client computing devices 602, 604, 606, and / or 608 under a Software as a Service (SaaS) model. Users operating client computing devices 602, 604, 606, and / or 608 may then use one or more client applications to interact with server 612 to utilize the services provided by these components.

[0119] exist Figure 6 In the configuration shown, server 612 may include one or more components 618, 620, and 622 that implement the functions performed by server 612. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. It should be understood that various different system configurations are possible and may differ from distributed system 600. Therefore, Figure 6 The embodiments shown are examples of distributed systems for implementing the systems of the embodiments, and are not intended to be limiting.

[0120] According to the teachings of this disclosure, a user can use client computing devices 602, 604, 606, and / or 608 to influence a dialogue task using historical context. The client device can provide an interface that enables the user to interact with the client device. The client device can also output information to the user via this interface. Although Figure 6 Only four client computing devices are depicted, but any number of client computing devices can be supported.

[0121] Client devices can include various types of computing systems, such as portable handheld devices, general-purpose computers such as personal computers and laptops, workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors, or other sensing devices. These computing devices can run various types and versions of software applications and operating systems (e.g., Microsoft Windows®, Apple Macintosh®, Unix® or Unix-like operating systems, such as Google Chrome). TM OS refers to Linux or Linux-like operating systems, including various mobile operating systems (e.g., Microsoft Windows Mobile®, iOS®, Windows Phone®, Android, etc.). TMPortable handheld devices can include cellular phones, smartphones (e.g., iPhone®), tablets (e.g., iPad®), personal digital assistants (PDAs), etc. Wearable devices can include Google Glass® head-mounted displays and other devices. Gaming systems can include various handheld gaming devices, Internet-enabled gaming devices (e.g., Microsoft Xbox® game consoles with or without Kinect® gesture input, Sony PlayStation® systems, various gaming systems provided by Nintendo®, etc.). Client devices are capable of running a variety of applications, such as various Internet-related applications, communication applications (e.g., email applications, Short Message Service (SMS) applications), and can use various communication protocols.

[0122] One or more networks 610 may be any type of network familiar to those skilled in the art, which may use any of a variety of available protocols to support data communication, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Switching), AppleTalk®, etc. By way of example only, one or more networks 610 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating under any IEEE 1002.11 protocol suite, Bluetooth®, and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0123] Server 612 may consist of one or more general-purpose computers, special-purpose server computers (e.g., including PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server groups, server clusters, or any other suitable arrangement and / or combination. Server 612 may include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization, such as one or more flexible pools of logical storage devices that can be virtualized to maintain the server's virtual storage devices. In various embodiments, server 612 may be adapted to run one or more services or software applications that provide the functionality described in the foregoing disclosure.

[0124] The computing system in server 612 can run one or more operating systems, including any of the operating systems discussed above, as well as any commercially available server operating system. Server 612 can also run any of a variety of additional server applications and / or middleware applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, JAVA® servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle®, Microsoft®, Sybase®, IBM® (International Business Machines), etc.

[0125] In some implementations, server 612 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client computing devices 602, 604, 606, and 608. As an example, data feeds and / or event updates may include, but are not limited to, Twitter® feeds, Facebook® updates, or real-time updates and continuous data streams received from one or more third-party information sources, which may include real-time events related to sensor data applications, financial automated reporting systems, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and the like. Server 612 may also include one or more applications for displaying data feeds and / or real-time events via one or more display devices of client computing devices 602, 604, 606, and 608.

[0126] The distributed system 600 may also include one or more data repositories 614, 616. In some embodiments, these data repositories may be used to store data and other information. For example, one or more of data repositories 614, 616 may be used to store information such as conversation history. Data repositories 614, 616 may reside in various locations. For example, the data repository used by server 612 may be local to server 612 or may be located remotely to server 612 and communicate with server 612 via a network-based connection or a dedicated connection. Data repositories 614, 616 may be of different types. In some embodiments, the data repository used by server 612 may be a database, such as a relational database, such as a database provided by Oracle Corporation® and other vendors. One or more of these databases may be adapted to be able to store, update, and retrieve data from and in response to SQL-formatted commands.

[0127] In some embodiments, the application may also use one or more of data repositories 614, 616 to store application data. The data repository used by the application may be of different types, such as a key-value repository, an object repository, or a general repository supported by a file system.

[0128] In some embodiments, the context-based dialogue processing capabilities described in this disclosure may be provided as a service via a cloud environment. Figure 7 This is a simplified block diagram of a cloud-based system environment according to certain embodiments, in which various context-based dialogue processing services can be provided as cloud services. Figure 7 In the illustrated embodiment, cloud infrastructure system 702 can provide one or more cloud services that can be requested by users using one or more client computing devices 704, 706, and 708. Cloud infrastructure system 702 may include one or more computers and / or servers, which may include those described above with respect to server 612. The computers in cloud infrastructure system 702 may be organized as general-purpose computers, dedicated server computers, server groups, server clusters, or any other suitable arrangement and / or combination.

[0129] One or more networks 710 can facilitate data communication and exchange between clients 704, 706, and 708 and cloud infrastructure system 702. One or more networks 710 may include one or more networks. Networks may be of the same type or different types. One or more networks 710 may support one or more communication protocols, including wired and / or wireless protocols, to facilitate communication.

[0130] Figure 7 The embodiments depicted are merely one example of a cloud infrastructure system and are not intended to be limiting. It should be understood that in some other embodiments, the cloud infrastructure system 702 may have more... Figure 7 The components depicted may have more or fewer components, may combine two or more components, or may have different component configurations or arrangements. For example, although Figure 7 Three client computing devices are depicted, but in alternative embodiments any number of client computing devices can be supported.

[0131] The term cloud service is generally used to refer to services provided to users on demand by a service provider's systems (e.g., cloud infrastructure systems 702) via communication networks such as the Internet. Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's systems are different from the customer's own on-premises servers and systems. The cloud service provider's systems are managed by the cloud service provider. Therefore, customers can use cloud services provided by the cloud service provider without having to purchase separate licenses, support, or hardware and software resources for these services. For example, the cloud service provider's systems can host applications, and users can subscribe to and use applications on demand via the Internet without having to purchase the infrastructure resources to run the applications. Cloud services are designed to provide easy, scalable access to applications, resources, and services. Several providers offer cloud services. For example, Oracle Corporation®, based on Redwood Coast, California, offers several cloud services, such as middleware services, database services, Java Cloud services, etc.

[0132] In some embodiments, cloud infrastructure system 702 may use different models, such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and other models including hybrid service models, to provide one or more cloud services. Cloud infrastructure system 702 may include a set of applications, middleware, databases, and other resources capable of providing various cloud services.

[0133] The SaaS model enables applications or software to be delivered as a service to customers via communication networks (such as the Internet) without requiring customers to purchase the underlying application's hardware or software. For example, the SaaS model can be used to provide customers with access to on-demand applications hosted by a cloud infrastructure system. Examples of SaaS services offered by Oracle Corporation® include, but are not limited to, a variety of services such as human resources / capital management, customer relationship management (CRM), enterprise resource planning (ERP), supply chain management (SCM), enterprise performance management (EPM), analytics services, and social applications.

[0134] The IaaS model is generally used to provide infrastructure resources (such as servers, storage, hardware, and network resources) as cloud services to customers, providing elastic computing and storage capabilities. Oracle Corporation® offers a variety of IaaS services.

[0135] The PaaS model is typically used to provide platform and environment resources as a service that enable customers to develop, run, and manage applications and services without having to purchase, build, or maintain those resources. Examples of PaaS services offered by Oracle Corporation® include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), data management cloud services, and various application development solutions services.

[0136] Cloud services are typically delivered in an on-demand, self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. For example, a customer can subscribe to one or more services provided by cloud infrastructure system 702 via a subscription order. Cloud infrastructure system 702 then performs processing to deliver the service requested in the customer's subscription order. For instance, cloud infrastructure system 702 uses historical context to influence a dialogue task. Cloud infrastructure system 702 can be configured to provide one or more cloud services.

[0137] Cloud infrastructure system 702 can provide cloud services through different deployment models. In a public cloud model, cloud infrastructure system 702 can be owned by a third-party cloud service provider, and cloud services are provided to any general public customer, which can be an individual or a business. In some other embodiments, under a private cloud model, cloud infrastructure system 702 can operate within an organization (e.g., within a business organization) and provide services to customers within that organization. For example, customers can be various departments within the enterprise, such as human resources, payroll, etc., or even individuals within the enterprise. In some other embodiments, under a community cloud model, cloud infrastructure system 702 and the services provided can be shared by several organizations in the relevant community. Various other models, such as hybrid models described above, can also be used.

[0138] Client computing devices 704, 706, and 708 can be of different types (such as...) Figure 2 The devices 202, 204, 206, and 208 depicted in this disclosure are capable of operating one or more client applications. Users can use the client devices to interact with the cloud infrastructure system 702, such as requesting services provided by the cloud infrastructure system 702. For example, a user can use the client device to request the context-based dialogue processing service described in this disclosure.

[0139] In some embodiments, the processing performed by the cloud infrastructure system 702 for providing context-based dialogue processing services may involve big data analytics. This analytics may involve using, analyzing, and manipulating large datasets to detect and visualize various trends, behaviors, relationships, etc., within the data. This analytics may be performed by one or more processors, potentially processing data in parallel, performing simulations using the data, etc. For example, big data analytics may be performed by the cloud infrastructure system 702 to recognize intent based on received voice input. The data used for this analytics may include structured data (e.g., data stored in a database or structured according to a structured model) and / or unstructured data (e.g., data blob (binary large objects)).

[0140] like Figure 7 As shown in the embodiments, the cloud infrastructure system 702 may include infrastructure resources 730, which are used to assist in the provision of various cloud services provided by the cloud infrastructure system 702. Infrastructure resources 730 may include, for example, processing resources, storage or memory resources, networking resources, etc.

[0141] In some embodiments, to facilitate the efficient provision of these resources to support the various cloud services offered by the cloud infrastructure system 702 to different customers, these resources can be bundled into resource sets or resource modules (also referred to as "pods"). Each resource module or pod may include a pre-integrated and optimized combination of one or more types of resources. In some embodiments, different pods may be pre-provided for different types of cloud services. For example, a first set of pods may be provided for a database service, and a second set of pods may be provided for a Java service, the second set of pods including a different combination of resources than the pods in the first set, and so on. For some services, resources allocated for providing the service can be shared between services.

[0142] The cloud infrastructure system 702 itself can internally use services 732 that are shared by different components of the cloud infrastructure system 702 and facilitate the provision of services by the cloud infrastructure system 702. These internally shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, etc.

[0143] Cloud infrastructure system 702 may include multiple subsystems. These subsystems may be implemented in software or hardware, or a combination thereof. Figure 7As shown, the subsystem may include a user interface subsystem 700 that enables users or customers of the cloud infrastructure system 702 to interact with the cloud infrastructure system 702. The user interface subsystem 700 may include various interfaces, such as a web interface 712, an online store interface 714 (where cloud services provided by the cloud infrastructure system 702 are advertised and available for purchase by consumers), and other interfaces 716. For example, a customer may use a client device to request (service request 734) one or more services provided by the cloud infrastructure system 702 using one or more of interfaces 712, 714, and 716. For example, a customer may access an online store, browse cloud services provided by the cloud infrastructure system 702, and place a subscription order for one or more services provided by the cloud infrastructure system 702 that the customer wishes to subscribe to. A service request may include information identifying the customer and one or more services that the customer wishes to subscribe to. For example, a customer may place a subscription order for a context-based conversational processing service provided by the cloud infrastructure system 702. As part of the order, the customer may provide voice input to identify the request.

[0144] In some embodiments, such as Figure 7 In the illustrated embodiment, cloud infrastructure system 702 may include an order management subsystem (OMS) 720 configured to process new orders. As part of this process, OMS 720 may be configured to: create an account for a customer (if not yet completed); receive billing and / or accounting information from the customer that will be used to charge the customer for providing the requested service; verify customer information; place an order for the customer after verification; and coordinate various workflows to prepare the order for supply.

[0145] Once correctly verified, OMS 720 can then invoke the Order Provisioning Subsystem (OPS) 724, which is configured to provision resources for the order, including processing, storage, and networking resources. Provisioning can include allocating resources for the order and configuring resources to assist the service requested by the customer's order. The method and type of resources provisioned for the order can depend on the type of cloud service the customer has already subscribed to. For example, according to a workflow, OPS 724 can be configured to determine the specific cloud service being requested and identify multiple pods that may already be pre-configured for that specific cloud service. The number of pods allocated to the order can depend on the size / amount / level / scope of the requested service. For example, the number of pods to be allocated can be determined based on the number of users the service needs to support, the duration of the requested service, etc. The allocated pods can then be customized for the specific requesting customer to provide the requested service.

[0146] Cloud infrastructure system 702 may send a response or notification 744 to the requesting client, indicating when the requested service is now ready for use. In some cases, information (e.g., a link) enabling the client to begin using and taking advantage of the benefits of the requested service may be sent. In some embodiments, for clients requesting context-based conversational processing services, the response may include a response generated based on the identified intent.

[0147] Cloud infrastructure system 702 can provide services to multiple customers. For each customer, cloud infrastructure system 702 is responsible for managing information related to one or more subscription orders received from the customer, maintaining customer data related to the orders, and providing the requested services to the customer. Cloud infrastructure system 702 can also collect usage statistics about customers' use of the subscription services. For example, it can collect statistics on storage usage, data transfer volume, number of users, system startup time, and system downtime. This usage information can be used to charge customers. For example, billing can be done on a monthly basis.

[0148] Cloud infrastructure system 702 can provide services to multiple customers in parallel. Cloud infrastructure system 702 can store information about these customers, which may include proprietary information. In some embodiments, cloud infrastructure system 702 includes an Identity Management Subsystem (IMS) 728, which is configured to manage customer information and provide separation of managed information, ensuring that information associated with one customer cannot be accessed by another customer. IMS 728 can be configured to provide various security-related services, such as identity services, information access management, authentication and authorization services, and services for managing customer identities, roles, and related capabilities.

[0149] Figure 8 An exemplary computer system 800 is shown that can be used to implement certain embodiments. For example, in some embodiments, the computer system 800 can be used to implement the ASR subsystem, NLU subsystem, and any of the various server and computer systems described above. Figure 8 As shown, the computer system 800 includes various subsystems, including a processing subsystem 804 that communicates with multiple other subsystems via a bus subsystem 802. These other subsystems may include a processing acceleration unit 806, an I / O subsystem 808, a storage subsystem 818, and a communication subsystem 824. The storage subsystem 818 may include non-transient computer-readable storage media, including storage medium 822 and system memory 810.

[0150] Bus subsystem 802 provides a mechanism for enabling various components and subsystems of computer system 800 to communicate with each other as intended. While bus subsystem 802 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 802 can be any of several types of bus architectures, including memory buses or memory controllers, peripheral buses, local buses using any of various bus architectures, etc. For example, such architectures may include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses, which may be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard, etc.

[0151] Processing subsystem 804 controls the operation of computer system 800 and may include one or more processors, application-specific integrated circuits (ASICs), or field-programmable gate arrays (FPGAs). Processors may include single-core or multi-core processors. The processing resources of computer system 800 may be organized into one or more processing units 832, 834, etc. A processing unit may include one or more processors, one or more cores from the same or different processors, a combination of cores and processors, or other combinations of cores and processors. In some embodiments, processing subsystem 804 may include one or more dedicated coprocessors, such as graphics processors, digital signal processors (DSPs), etc. In some embodiments, some or all of the processing units of processing subsystem 804 may be implemented using custom circuitry, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0152] In some embodiments, the processing units in the processing subsystem 804 can execute instructions stored on system memory 810 or computer-readable storage medium 822. In various embodiments, the processing units can execute various program or code instructions and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed may reside on system memory 810 and / or computer-readable storage medium 822, possibly including one or more storage devices. With appropriate programming, the processing subsystem 804 can provide the various functions described above. When the computer system 800 is executing one or more virtual machines, one or more processing units can be assigned to each virtual machine.

[0153] In some embodiments, the processing acceleration unit 806 may optionally be used to perform custom processing or to offload some processing performed by the processing subsystem 804 to accelerate the overall processing performed by the computer system 800.

[0154] I / O subsystem 808 may include devices and mechanisms for inputting information to and / or outputting information from or via computer system 800. Generally, the term input device is used to encompass all possible types of devices and mechanisms for inputting information to computer system 800. User interface input devices may include, for example, keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor that enables users to control and interact with input devices, the Microsoft Xbox® 360 game controller, and devices that provide interfaces for receiving input using gestures and verbal commands. User interface input devices may also include eye-gesture recognition devices such as the Google Glass® blink detector, which detects eye movements from the user (e.g., “blinking” when taking a picture and / or making menu selections) and translates the eye gestures into input for the input device (e.g., Google Glass®). In addition, the user interface input device may include a voice recognition sensing device that enables the user to interact with the voice recognition system via voice commands.

[0155] Other examples of user interface input devices include, but are not limited to, 3D mice, joysticks or pointing sticks, game controllers, and graphics tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may include, for example, medical imaging input devices such as computed tomography (CT), magnetic resonance imaging (MRI), positional emission computed tomography (PEC), and medical ultrasound imaging devices. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0156] Generally, the term "output device" is used to encompass all possible types of devices and mechanisms for outputting information from a computer system 800 to a user or other computer. User interface output devices may include display subsystems, indicator lights, or non-visual displays such as audio output devices. Display subsystems may be cathode ray tubes (CRTs), flat panel devices (such as those using liquid crystal displays (LCDs) or plasma displays), projection devices, touchscreens, etc. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0157] Storage subsystem 818 provides a repository or data store for storing information and data used by computer system 800. Storage subsystem 818 provides a tangible, non-transitory, computer-readable storage medium for storing basic programming and data constructs that provide the functionality of certain embodiments. Storage subsystem 818 may store software (e.g., programs, code modules, instructions) that provides the aforementioned functionality when executed by processing subsystem 804. This software may be executed by one or more processing units of processing subsystem 804. Storage subsystem 818 may also provide a repository for storing data used in accordance with the teachings of this disclosure.

[0158] Storage subsystem 818 may include one or more non-transient storage devices, including volatile and non-volatile storage devices. For example... Figure 8 As shown, the storage subsystem 818 includes system memory 810 and computer-readable storage medium 822. System memory 810 may include multiple memories, including volatile main random access memory (RAM) for storing instructions and data during program execution and non-volatile read-only memory (ROM) or flash memory where fixed instructions are stored. In some implementations, the basic input / output system (BIOS), containing basic routines such as those that help transfer information between elements within the computer system 800 during startup, may typically be stored in ROM. RAM typically contains data and / or program modules currently operated and executed by the processing subsystem 804. In some implementations, system memory 810 may include various different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), etc.

[0159] As an example, not a limitation, such as Figure 8As shown, system memory 810 can load an executing application 812, which may include various applications such as web browsers, middleware applications, relational database management systems (RDBMS), program data 814, and operating system 816. As an example, operating system 816 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, Palm® OS, etc.

[0160] Computer-readable storage medium 822 may store programming and data structures that provide functionality for certain embodiments. Computer-readable storage medium 822 may provide computer-readable instructions, data structures, program modules, and other data for computer system 800. Software (programs, code modules, instructions) that provides the above-described functionality when executed by processing subsystem 804 may be stored in storage subsystem 818. As an example, computer-readable storage medium 822 may include non-volatile memory such as hard disk drives, disk drives, optical disc drives (such as CD ROMs, DVDs, Blu-ray® discs, or other optical media). Computer-readable storage medium 822 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash memory drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. The computer-readable storage medium 822 may also include solid-state drives (SSDs) based on non-volatile memory, such as flash-based SSDs, enterprise flash drives, solid-state ROMs, etc.; volatile memory-based SSDs, such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs; and hybrid SSDs using a combination of DRAM and flash-based SSDs.

[0161] In some embodiments, the storage subsystem 818 may further include a computer-readable storage medium reader 820, which may also be connected to a computer-readable storage medium 822. The reader 820 may receive data from a storage device such as a disk, flash drive, etc., and configure it to read data from that storage device.

[0162] In some embodiments, the computer system 800 may support virtualization technologies, including but not limited to the virtualization of processing and memory resources. For example, the computer system 800 may provide support for executing one or more virtual machines. In some embodiments, the computer system 800 may execute programs such as hypervisors that facilitate the configuration and management of virtual machines. Each virtual machine may be allocated memory, computing (e.g., processor, core), I / O, and networking resources. Each virtual machine typically runs independently of other virtual machines. Virtual machines typically run their own operating systems, which may be the same as or different from the operating systems executed by other virtual machines executed by the computer system 800. Therefore, the computer system 800 may run multiple operating systems simultaneously.

[0163] The communication subsystem 824 provides interfaces to other computer systems and networks. The communication subsystem 824 serves as an interface for receiving data from the computer system 800 and sending data to other systems. For example, the communication subsystem 824 enables the computer system 800 to establish communication channels via the Internet to one or more client devices for receiving and sending information to the client devices. For example, the communication subsystem can be used to communicate with a database to import contextual information from a client database (e.g., to retrieve the name of an individual's health insurance provider from a database maintained by an individual's employer).

[0164] The communication subsystem 824 may support wired and / or wireless communication protocols. For example, in some embodiments, the communication subsystem 824 may include radio frequency (RF) transceiver components (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rate for Global Evolution)), WiFi (IEEE 802.XX series standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and / or other components for accessing wireless voice and / or data networks. In some embodiments, in addition to or instead of a wireless interface, the communication subsystem 824 may provide a wired network connection (e.g., Ethernet).

[0165] The communication subsystem 824 can receive and send data in various forms. For example, in some embodiments, among other forms, the communication subsystem 824 can receive input communications in the form of structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc. For example, the communication subsystem 824 can be configured to receive (or send) data feeds 826 in real time from users of social media networks and / or other communication services such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0166] In some embodiments, the communication subsystem 824 may be configured to receive data in the form of a continuous data stream, which may include an event stream 828 of real-time events and / or event updates 830, which may be continuous or unbounded in nature and without an explicit end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial automated reporting machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, etc.

[0167] The communication subsystem 824 can also be configured to transmit data from computer system 800 to other computer systems or networks. The data can be transmitted in various forms, such as structured and / or unstructured data feeds 826, event streams 828, event updates 830, etc., to one or more databases that can communicate with one or more streaming data source computers coupled to computer system 800.

[0168] The computer system 800 can be of a variety of types, including handheld portable devices (e.g., iPhone® cellular phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), personal computers, workstations, mainframes, kiosks, server racks, or any other data processing systems. Due to the constantly evolving nature of computers and networks, Figure 8 The description of the computer system 800 depicted herein is intended only as a concrete example. It has more than Figure 8 Many other configurations of the system shown, with more or fewer components, are also possible. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0169] While specific embodiments have been described, various modifications, changes, alternative structures, and equivalents are possible. The embodiments are not limited to operating in certain specific data processing environments but can operate freely in multiple data processing environments. Furthermore, although some embodiments have been described using a specific series of transactions and steps, it will be apparent to those skilled in the art that this is not intended to be limiting. Although some flowcharts describe operations as sequential processes, many operations can be performed in parallel or concurrently. Moreover, the order of operations can be rearranged. The process may have other steps not included in the diagrams. Various features and aspects of the above embodiments can be used individually or in combination.

[0170] Furthermore, while certain embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also possible. Some embodiments may be implemented solely in hardware, or solely in software, or using a combination thereof. The various processes described herein can be implemented in any combination on the same processor or different processors.

[0171] When a device, system, component, or module is described as being configured to perform certain operations or functions, this configuration can be achieved, for example, by designing electronic circuits to perform the operations, by programming programmable electronic circuits (such as microprocessors), for example, by executing computer instructions or code, or by a processor or core programmed to execute code or instructions stored on a non-volatile memory medium, or any combination thereof. Processes can communicate using a variety of technologies, including but not limited to conventional technologies for inter-process communication, and different pairs of processes can use different technologies, or the same pair of processes can use different technologies at different times.

[0172] Specific details are set forth in this disclosure to provide a thorough understanding of the embodiments. However, embodiments may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail to avoid obscuring the embodiments. This specification provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of other embodiments. Rather, the foregoing description of the embodiments will provide those skilled in the art with an enabling description for implementing various embodiments. The function and arrangement of elements can be varied.

[0173] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will be apparent that additions, deletions, omissions, and other modifications and changes can be made therein without departing from the broader spirit and scope of this disclosure. Therefore, although specific embodiments have been described, they are not intended to be restrictive. Various modifications and equivalents are within the scope of this disclosure. These modifications include any related combinations of the disclosed features. In summary, the features of the disclosure are summarized as follows:

[0174] Configuration 1. According to an embodiment, a computer-implemented method is provided. The method includes: receiving spoken utterances from a user by a dialogue system; processing the spoken utterances by the dialogue system to identify terms for disambiguation; determining, by the dialogue system, a context level for the terms for disambiguation from a plurality of predefined context levels; identifying values ​​of the terms by the dialogue system using a database based on the determined context level, the database storing multiple values ​​of the user associated with the context level; and using the identified values ​​to disambiguate the terms.

[0175] Configuration 2. In a particular aspect of the method, the method further includes: generating a logical form of the spoken utterance by the dialogue system based on disambiguated terminology; generating a response by the dialogue system based on the logical form; and outputting the response to the user by the dialogue system.

[0176] Configuration 3. In a particular aspect of the method, the method further includes: the dialogue system identifying stored execution results from the database based on the logical form, wherein the response is also generated based on the execution results.

[0177] Configuration 4. In a particular aspect of the method, the method further includes: storing the representation of the spoken utterance, the logical form, and the response in a database by the dialogue system.

[0178] Configuration 5. In a particular aspect of the method, identifying the value includes: selecting a database for the determined context level from a plurality of context-level-based databases; and querying the selected database using the user's identifier and the term to identify the value.

[0179] Configuration 6. In a particular aspect of the method, the method further includes: the dialogue system identifying stored data of multiple previous dialogues with the user from the database; and analyzing the identified data to calculate the value.

[0180] Configuration 7. In a particular aspect of the method, the plurality of predefined context levels include immediate context, short-term context, medium-term context, and long-term context.

[0181] Configuration 8. According to some embodiments, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores a plurality of instructions executable by one or more processors, which, when executed by the one or more processors, cause the one or more processors to perform instructions for processing, the processing including: receiving spoken utterance from a user; processing the spoken utterance to identify terms for disambiguation; determining a context level for the terms for disambiguation from a plurality of predefined context levels; using a database to identify values ​​of the terms based on the determined context level, the database storing a plurality of values ​​of the user associated with the context level; and using the identified values ​​to disambiguate the terms.

[0182] Configuration 9. In a particular aspect of the non-transient computer-readable storage, the processing further includes: generating a logical form of the spoken utterance based on disambiguated terms; preparing a response based on the logical form; and outputting the response to the user.

[0183] Configuration 10. In a particular aspect of the non-transient computer-readable storage, the processing further includes: identifying stored execution results from the database based on the logical form, wherein the response is also generated based on the execution results.

[0184] Configuration 11. In a particular aspect of the non-transient computer-readable storage, the processing further includes storing the representation of the spoken utterance, the logical form, and the response into a database.

[0185] Configuration 12. In a particular aspect of the non-transient computer-readable storage, identifying the value includes: selecting a database for the determined context level from a plurality of context-level-based databases; and querying the selected database using the user's identifier and the term to identify the value.

[0186] Configuration 13. In a particular aspect of the non-transient computer-readable storage, the process further includes: identifying stored data of multiple previous conversations with the user from the database; and analyzing the identified data to calculate the value.

[0187] Configuration 14. In a particular aspect of the non-transient computer-readable storage, the plurality of predefined context levels include immediate context, short-term context, medium-term context, and long-term context.

[0188] Configuration 15. According to some embodiments, a system is provided. The system includes: one or more processors; a memory coupled to the one or more processors, the memory storing a plurality of instructions executable by the one or more processors, the plurality of instructions including instructions that, when executed by the one or more processors, cause the one or more processors to perform processing, the processing including: receiving spoken utterances from a user; processing the spoken utterances to identify terms for disambiguation; determining a context level for the terms for disambiguation from a plurality of predefined context levels; using a database to identify values ​​of the terms based on the determined context level, the database storing a plurality of values ​​of the user associated with the context level; and using the identified values ​​to disambiguate the terms.

[0189] Configuration 16. In a particular aspect of the system, the processing further includes: generating a logical form of the spoken utterance based on disambiguated terminology; preparing a response based on the logical form; and outputting the response to the user.

[0190] Configuration 17. In a particular aspect of the system, the processing further includes: identifying stored execution results from the database based on the logical form, wherein the response is also generated based on the execution results.

[0191] Configuration 18. In a particular aspect of the system, the processing further includes storing the representation of the spoken utterance, the logical form, and the response in a database.

[0192] Configuration 19. In a particular aspect of the system, identifying the value includes: selecting a database for the context level from a plurality of context-level-based databases based on the determined context level; and querying the selected database using the user's identifier and the term to identify the value.

[0193] Configuration 20. In a particular aspect of the system, the processing further includes: identifying stored data of multiple previous conversations with the user from the database; and analyzing the identified data to calculate the value.

[0194] Configuration 21. According to some embodiments, a system is provided. The system includes: components for receiving spoken utterances from a user; components for processing the spoken utterances to identify terms for disambiguation; components for determining a context level of the terms for disambiguation from a plurality of predefined context levels; components for preparing a response based on the context level and the disambiguated terms; and components for outputting the response to the user.

[0195] Configuration 22. In a particular aspect of the system, the system further includes: components for identifying values ​​of the terms using a database based on a determined context level, the database storing multiple values ​​of the user associated with the context level; components for using the identified values ​​to disambiguate the terms; components for generating a logical form of the spoken utterance based on the disambiguated terms; and components for preparing the response based on the logical form.

[0196] Configuration 23. In a particular aspect of the system, the system further includes: a component for identifying stored execution results from the database based on the logical form, wherein the response is also generated based on the execution results.

[0197] Configuration 24. In a particular aspect of the system, the system further includes: components for storing the representation of the spoken utterance, the logical form, and the response in a database.

[0198] Configuration 25. In a particular aspect of the system, identifying the value includes: selecting a database for the context level from a plurality of context-level-based databases based on the determined context level; and querying the selected database using the user's identifier and the term to identify the value.

[0199] Configuration 26. In a particular aspect of the system, the system further includes: components for identifying stored data of multiple previous conversations with the user from the database; and components for analyzing the identified data to calculate the values.

Claims

1. A method for context-based dialogue processing, comprising: The dialogue system receives spoken words from the user. The spoken utterances are processed by the dialogue system to identify terms used for disambiguation; The dialogue system determines the context level of terms used for disambiguation in a plurality of predefined context levels, wherein the plurality of predefined context levels include immediate context, short-term context, medium-term context and long-term context; Based on the determined context level, the dialogue system uses a database to identify the value of the term, and the database stores multiple values ​​of the user associated with the context level; as well as The dialogue system uses the identified values ​​to eliminate ambiguity in the terms.

2. The method according to claim 1, further comprising: The dialogue system generates the logical form of the spoken utterance based on deambiguous terminology; The dialogue system generates a response based on the logical form. as well as The dialogue system outputs the response to the user.

3. The method according to claim 2, further comprising: The dialogue system identifies the stored execution results from the database based on the logical form. The response is also generated based on the execution result.

4. The method according to claim 2 or 3, further comprising: The dialogue system stores the representation of the spoken utterance, its logical form, and the response in the database.

5. The method according to any one of claims 1 to 3, wherein identifying the value comprises: Based on the determined context level, select multiple context-level databases for the context level; as well as The selected database is queried using the user's identifier and the terminology to identify the value.

6. The method according to any one of claims 1 to 3, further comprising: The dialogue system identifies stored data from the database of multiple previous conversations with the user; as well as The identified data is analyzed to calculate the value.

7. A non-transient computer-readable storage medium storing a plurality of instructions executable by one or more processors, the plurality of instructions including instructions that, when executed by the one or more processors, cause the one or more processors to perform processing, the processing comprising: From the user's spoken words; The spoken utterance is processed to identify terms used for disambiguation; Determine the context level of the term used for disambiguation in a plurality of predefined context levels, wherein the plurality of predefined context levels include immediate context, short-term context, medium-term context and long-term context; Based on the determined context level, a database is used to identify the value of the term, and the database stores multiple values ​​of the user associated with the context level; as well as Use the identified values ​​to eliminate ambiguity in the terminology.

8. The non-transient computer-readable storage device according to claim 7, wherein the processing further comprises: The logical form of the spoken utterance is generated based on the unambiguous terminology. Prepare a response based on the aforementioned logical form; as well as The response is output to the user.

9. The non-transient computer-readable storage device according to claim 8, wherein the processing further comprises: Based on the aforementioned logical form, the stored execution results are identified from the database. The response is also generated based on the execution result.

10. The non-transient computer-readable storage device according to claim 8 or 9, wherein the processing further comprises: The representation of the spoken utterance, its logical form, and the response are stored in the database.

11. The non-transitory computer-readable memory of any one of claims 7 to 9, wherein, Identifying the value includes: Based on the determined context level, select a database from multiple context-level databases for the context level; and The selected database is queried using the user's identifier and the terminology to identify the value.

12. The non-transient computer-readable storage memory according to any one of claims 7 to 9, wherein the processing further comprises: Identify stored data from the database regarding multiple previous conversations with the user; as well as The identified data is analyzed to calculate the value.

13. A system for context-based dialogue processing, comprising: One or more processors; A memory coupled to the one or more processors, the memory storing a plurality of instructions executable by the one or more processors, the plurality of instructions including instructions that, when executed by the one or more processors, cause the one or more processors to perform processing, the processing including: From the user's spoken words; The spoken utterance is processed to identify terms used for disambiguation; Determine the context level of the term for disambiguation among a plurality of predefined context levels, wherein the plurality of predefined context levels include immediate context, short-term context, medium-term context, and long-term context; Based on the determined context level, a database is used to identify the value of the term, the database storing multiple values ​​of the user associated with the context level; and Use the identified values ​​to eliminate ambiguity in the terminology.

14. The system of claim 13, wherein the processing further comprises: The logical form of the spoken utterance is generated based on the unambiguous terminology. Prepare a response based on the aforementioned logical form; as well as The response is output to the user.

15. The system of claim 14, wherein the processing further comprises: Based on the aforementioned logical form, the stored execution results are identified from the database. The response is also generated based on the execution result.

16. The system according to claim 14 or 15, wherein the processing further comprises: The representation of the spoken words, the logical form, and the response are stored in the database.

17. The system of any one of claims 13 to 15, wherein, Identifying the value includes: Based on the determined context level, select a database from multiple context-level databases for the context level; and The selected database is queried using the user's identifier and the terminology to identify the value.

18. The system according to any one of claims 13 to 15, wherein the processing further comprises: Identify stored data from the database regarding multiple previous conversations with the user; as well as The identified data is analyzed to calculate the value.

19. A dialogue system, comprising: A component used to receive spoken words from the user; Components for processing the spoken utterance to identify terms used for disambiguation; Components for determining the context level of the term for disambiguation among multiple predefined context levels, wherein the multiple predefined context levels include immediate context, short-term context, medium-term context, and long-term context. A component for preparing a response based on the context level and using unambiguous terms; as well as A component used to output the response to the user.

20. The dialogue system according to claim 19, further comprising: A component for identifying the value of the term using a database based on a determined context level, the database storing multiple values ​​of the user associated with the context level; Components used to eliminate ambiguity of the terms using the identified values; A component used to generate the logical form of the spoken utterance based on unambiguous terms; as well as Components used to prepare the response based on the logical form.

21. The system of claim 20, further comprising: A component for identifying stored execution results from the database based on the logical form. The response is also generated based on the execution result.

22. The system of claim 20, further comprising: A component for storing the representation of the spoken utterance, the logical form, and the response into the database.

23. The system of claim 20, wherein, Identifying the value includes: Based on the determined context level, select a database from multiple context-level databases for the context level; and The selected database is queried using the user's identifier and the terminology to identify the value.

24. The system of claim 20, further comprising: A component for identifying stored data from the database related to multiple previous conversations with the user; as well as Components used to analyze the identified data to calculate the value.

Images