Method and system for authoring tasks using a user interface authoring platform

Abstract

This application relates to methods and systems for authoring tasks using a user interface authoring platform. Aspects of this disclosure provide third-party application authors with a user interface authoring platform that automates and simplifies the task definition process while also providing the ability to leverage pre-existing language understanding models and normalization and parsing modules provided by the operating system on which the Conversational Understanding (CU) system resides, or by other third parties. Specifically, this disclosure provides a method and system for authoring tasks using a user interface authoring platform.

Description

[0001] This application is a divisional application of the invention patent application with an international application date of February 3, 2017, international application number PCT / US2017 / 016318, which entered the Chinese national phase on June 15, 2018, Chinese national application number 201780004859.1, and invention name: "Method and system for creating tasks using a user interface creation platform." Technical Field

[0002] Embodiments of the present application relate generally to user interface platforms, and more particularly to systems and methods for authoring tasks using a user interface authoring platform. Background Art

[0003] A conversation understanding system allows a user to interact with a computing device by voice to perform one or more tasks of interest to the user. Typically, such a conversation understanding system uses one or more language understanding models to collect various information based on the user's voice or conversation to identify the user's intent, and then performs tasks based on the identified intent. Tasks may include, for example, the execution of a query, the execution of an application hosted on the user's computing device, the subscription of a third-party service, or the display of information. Typically, third-party application designers are responsible for designing their own language understanding models and multi-turn dialog processing, which interface with the conversation understanding system of the host where their application resides to call their application in response to the user's spoken conversation. Various aspects have been proposed with respect to these and other general considerations. In addition, although relatively specific issues have been discussed, it should be understood that these aspects should not be limited to solving the specific problems identified in the background technology. Summary of the Invention

[0004] In summary, the present disclosure relates to a user interface platform that provides third-party application experience designers with the ability to define executable tasks based on parameters and select or author corresponding language understanding models that can be used in a spoken dialogue system. Specifically, the present disclosure provides third-party application experience designers with a simplified and semi-automated approach to authoring tasks that can be performed using a spoken dialogue system. Thus, aspects of the present disclosure provide a tool that provides application experience designers with the ability to define tasks and leverage pre-existing language understanding models, as well as normalization and parsing modules, for task understanding and execution using a user interface authoring platform.

[0005] In one aspect, the present disclosure relates to a method for authoring a task using a user interface authoring platform, the method comprising: receiving a definition of a task at the user interface authoring platform; receiving a selection of an intent that will trigger the task at the user interface authoring platform; receiving parameters that refine the execution of the task at the user interface authoring platform; and receiving an identification of a third-party application for executing the task at the user interface authoring platform.

[0006] In another aspect, the present disclosure relates to a system comprising: at least one processing unit; and at least one memory storing computer-executable instructions, which, when executed by the at least one processing unit, cause the system to perform a method, the method comprising: receiving a definition of a task at a user interface authoring platform; receiving a selection of an intent that will trigger the task at the user interface authoring platform; receiving parameters that refine the execution of the task at the user interface authoring platform; and receiving an identification of a third-party application for performing the task at the user interface authoring platform.

[0007] In another aspect, the present disclosure relates to a signal-excluding computer-readable memory storage device storing a set of instructions that, when executed, perform a method for authoring a task using a user interface authoring platform, the method comprising: receiving a definition of a task at the user interface authoring platform; receiving a selection of an intent that will trigger the task at the user interface authoring platform; receiving parameters that refine the execution of the task at the user interface authoring platform; and receiving an identification of a third-party application for executing the task at the user interface authoring platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 Illustrated is a schematic block diagram of an example network that can be used to author third-party experiences using a user interface platform.

[0009] Figure 2 Illustrated is an example method for specifying tasks using a user interface authoring platform.

[0010] Figure 3 Illustrate a sample user interface authoring platform for defining tasks.

[0011] Figure 4 Illustrated is an example user interface authoring platform for identifying one or more intents that will trigger a task.

[0012] Figure 5 A sample screenshot illustrating the user interface authoring platform for defining parameters.

[0013] Figure 6Illustrated is an example user interface authoring platform for recognizing parsers.

[0014] Figure 7 Illustrated is a sample user interface authoring platform for identifying validation conditions.

[0015] Figure 8 Illustrated is a sample user interface authoring platform for defining final actions.

[0016] Figure 9 Illustrated is a sample user interface authoring platform for editing dialog behaviors.

[0017] Figure 10 Illustrated is a screenshot of an exemplary integrated development environment (IDE) that can be used to define tasks.

[0018] Figure 11 is a block diagram illustrating example physical components of a computing device in which aspects of the present disclosure may be practiced.

[0019] Figure 12A and Figure 12B is a simplified block diagram of a mobile computing device in which aspects of the present disclosure may be practiced.

[0020] Figure 13 is a simplified block diagram of a distributed computing system in which aspects of the present disclosure may be practiced.

[0021] Figure 14 A tablet computing device for performing one or more aspects of the present disclosure is illustrated. DETAILED DESCRIPTION

[0022] Various embodiments will be described in detail with reference to the accompanying drawings, wherein like reference numerals represent like parts and assemblies throughout the various views. Reference to various embodiments does not limit the scope of the appended claims. Furthermore, any examples set forth in this specification are not intended to be limiting, but merely to set forth some of the many possible embodiments for the appended claims.

[0023] Conversational Understanding ("CU") systems assist users in performing various tasks by engaging in conversations with them using a spoken dialogue system, which may involve, for example, one or more question-and-answer polls. Conversational Understanding systems can be used to implement intelligent digital assistant applications, such as the CORTANA digital assistant application offered by Microsoft of Redmond, Washington. Conversational Understanding systems use a Language Understanding ("LU") model to identify spoken words and flag words that are important or relevant to a particular task. A task can be defined as the execution of a transactional action or the provision of information in response to a user request. Such tasks can include, for example, the performance of an internet query, the display of results, the execution of an application, the procurement of a third-party service, and so on. Tasks can be defined in terms of parameters, where parameters are containers that specify the entities to be collected and their semantic meaning within the task. An entity is a representation of knowledge or understanding; for example, a preference for "delivery" or "take-out" is an entity. Additionally, an entity can be an object, such as a specific address or restaurant. A task such as booking a taxi may require parameters such as a starting location, a pickup time, and the number of passengers required before the task can be performed. As another example, a task to make a call using a phone application might require parameters such as the name of the business or person to which the call is directed, or a phone number. As yet another example, a task to book a hotel might require parameters such as the name of the city, the date of booking, and the identification of a specific hotel. Tasks can also include optional parameters. For example, in the taxi example, optional parameters might be the identification of the destination location or the type of car desired; and in the hotel example, optional parameters might be the hotel's star rating or its proximity to a specific area of ​​the selected city. These optional parameters are not required for the task to be performed, but can assist the application responsible for performing the task in further refining the task to be performed.

[0024] A session between a user and a CU system using one or more LU models is intended to obtain from the user information necessary to satisfy those required parameters (and in some aspects optional parameters) in order to perform the desired task. Further, the CU system maintains a record of the information obtained during the session with the user as it relates to defined parameters that are necessary (and in some aspects optional) to perform the task. In addition, the CU system can infer information outside of the session, such as inferring the user's location or language requirements. In some aspects, the CU system can provide the obtained information to the user as a way to verify the accuracy of the obtained information. For example, the CU system can display the obtained information to the user, or can verbally identify the obtained information, thereby providing the user with confirmation of the CU system's understanding of the task execution and the corresponding parameters obtained. In various aspects, the CU system can modify the information obtained during the user session to resolve speech recognition or understanding errors, language understanding errors, parameter parsing errors, or errors as requested by the user.

[0025] Additionally, the CU system may require the user to provide further information necessary for task execution via voice or text prompts. For example, the CU system may have predefined or automatically generated prompts that elicit further information or clarification from the user to meet the necessary parameters necessary for task execution.

[0026] Furthermore, during the session, the CU system may provide the user with matching or suggested valid options from which to select before the execution of the task to satisfy the parameters. The CU system may provide the user with information obtained during the session by, for example, displaying the collected information on a display of the device, or by, for example, reading the collected information aloud. The CU system may further require the user to confirm the accuracy of the provided information as the last step before the task is executed. At this point, in the session, the user may, for example, confirm or edit the information or cancel the execution of the task completely. In one example, the user may confirm or edit the information through voice or gestures such as typing, touching, or moving the device. Based on the confirmation response received from the user, the CU system may execute the identified task. Based on the edit information response received from the user, the CU system may repeat the session or search for the selected information to be edited. Based on the cancellation response received from the user, the CU system may completely terminate the conversation and task execution process.

[0027] The aspects disclosed herein provide a user interface authoring platform that automates and simplifies the task definition process while also providing the ability to leverage pre-existing language understanding models and normalization and parsing modules provided by an operating system or cloud-based service on which the CU system resides, or provided by other third parties. The systems and methods disclosed herein provide tools that can be used to create interfaces between third-party applications and the CU system. Although reference is made to third-party applications and third-party application authors, the novel aspects provided herein can be extended to any application or application author. In addition, because the CU system is complex and difficult to design, the systems and methods disclosed herein provide third-party applications with the ability to leverage existing CU systems and models. Therefore, third-party application authors can use the user interface authoring platform to efficiently and more simply define tasks and leverage pre-existing language understanding models to identify those defined tasks.

[0028] Figure 1 A schematic block diagram of an example network 100 that can be used to author third-party experiences using a user interface platform is illustrated. Network 100 includes one or more third-party computing devices 102, a server 104 hosting a user interface authoring platform 106, and a database 108 storing, among other things, language understanding models and normalization and parsing modules. In this example aspect, third-party computing devices 102, server 104, and database 108 are connected via a data communications network 110, such as the Internet.

[0029] Various aspects described herein relate to providing a user interface authoring platform 106. The user interface authoring platform 106 is a tool for automating and streamlining the task authoring process. In some aspects, the user interface authoring platform 106 operates remotely on a server that is accessible via a data communication network 110 by one or more third-party client devices 102. In other aspects, the user interface authoring platform 106 operates locally on one or more third-party client devices 102.

[0030] As will be described in further detail herein, the user interface authoring platform 106 is an authoring tool designed to provide third-party application authors with the ability to specify tasks and select or author one or more language understanding models that the CU system can use to identify and execute the specified tasks. Specifically, the user interface authoring platform 106 guides third-party application authors in defining tasks based on one or more required parameters, and even optional parameters, necessary to complete the task. The user interface authoring platform 106 also provides the optional ability for authors to specify validation conditions, which define one or more validity conditions that must exist for one or more parameters to execute the task. Additionally, the user interface authoring platform 106 allows third-party application authors to select one or more language understanding ("LU") models from a database 108 that extract the information necessary to identify the appropriate task and the corresponding parameters from the user's speech or conversation. LU models are used to annotate or analyze spoken or textual input and can be specific to a specific domain. For example, an LU model can be specifically designed to recognize utterances (e.g., speech or textual input) related to the task of making restaurant reservations in the restaurant domain. Such an LU model can be used to identify words or phrases to determine user intent related to a specific domain and can also be used to populate the parameters of the task. For example, a specific LU model can be used for the task of making restaurant reservations. This LU model can be applied to the spoken phrase "Is there a table for four people at Andy's Mexican Restaurant tonight at 6:30?" to identify the task of making a restaurant reservation and the parameters required to perform the task, such as the specific restaurant desired to be reserved [Andy's Mexican Restaurant], the number of people [four], and the time [6:30 PM]. It will be appreciated that a single task can create multiple intents, as will be described in further detail herein.

[0031] The user interface authoring platform 106 provides third-party application authors with the ability to select one or more pre-existing LU models. If an LU model does not already exist in the database 108, the user interface authoring platform 106 provides third-party application authors with the ability to create one or more new LU models. The user interface authoring platform 106 also allows third-party application authors to select one or more normalization or parsing modules from the database 108 that convert user input into a standardized format. If a normalization or parsing module does not already exist in the database 108, the user interface authoring platform 108 allows third-party application authors to create such a module. Each of these aspects is described in further detail herein.

[0032] The client device 102 can be any computing device, such as, for example, a cellular phone, a personal digital assistant, a laptop computer, a desktop computer, or a tablet computer. As described herein, the client device 102 hosts an intelligent digital assistant application. Furthermore, the client device 102 stores one or more applications that can be executed thereon using the intelligent digital assistant application. Such applications can refer to, for example, applications that are provided with the device, such as a phone application, an internet browser application, an email application, a weather application, a note application, a text messaging application, a calendar application, a camera application, a map application, and the like. Other third-party applications can also be installed on the client device 102, such as, for example, a taxi booking application, a hotel booking application, a social media application, a gaming application, and the like. Thus, a third-party application author can use the user interface authoring platform 106 to create one or more tasks that execute a particular third-party application installed on the client device 102.

[0033] Figure 2 An example method 200 for specifying a task using the user interface authoring platform 106 is illustrated. As described herein, the user interface authoring platform 106 allows third-party application designers to specify tasks and corresponding parameters, as well as select an appropriate LU model for analyzing and extracting speech to determine user intent related to the defined task. Task specification includes identifying whether the value of each parameter is provided by the user or inferred by the CU system, specifying how to request information from the user if additional input is required, identifying whether the labeled input is sufficient to include information that satisfies one or more defined parameters, and combining the labeled user input as user input with other already collected parameters to normalize and resolve entities representing the specific parameters. In the taxi booking task example, a parser can combine previously collected parameters representing the user's location with labeled user input representing the user's desired taxi type to determine whether the requested taxi type is available. If the taxi type is available, the parser can provide a product identifier. Alternatively, if the taxi type is not available, the parser can provide an error message indicating that the requested taxi type is not available at the location. In another example, such as a phone call experience, the system can use previously collected parameters indicating the contact to be called along with a labeled user input indicating the type of phone number (e.g., work, home, or mobile) to facilitate identifying the actual phone number to dial.

[0034] It should be understood that the user interface authoring platform 106 can be used to guide authors in creating tasks, selecting LU models, intents, parameters, parsers, validation conditions, etc. The user interface authoring platform 106 can guide authors throughout the authoring process by providing suggestions to authors in response to selections provided by the author or in response to an understanding of the author's goals in light of the task. For example, an author can enter a query, and the user interface authoring platform 106 can respond by providing suggestions for possible intents, slot tags, parameters, parsers, validation conditions, etc.

[0035] Furthermore, while the description and examples provided herein describe a specific implementation using platform 106, the novel aspects of the present disclosure may also be implemented using an integrated development environment (IDE), such as, for example, Visual Studio provided by Microsoft of Redmond, Washington. Such an implementation using an IDE allows authors to provide task specifications using text-based developer tools that are not based on a web portal. Such an IDE may also provide support for discovery, auto-completion, suggestions, and syntax correction of task definition files. Reference Figure 10 An example IDE is shown and described.

[0036] In the task definition operation 202, the user interface authoring platform 106 prompts the third-party application author (hereinafter referred to as "author") to define a task. Specifically, defining a task may involve identifying one or more of a task name and an associated description. In one example, the user interface authoring platform 106 may present a dialog box prompting the author to identify the name of the task performed by a particular application. For example, for a taxi service application, the task may be identified as "BookTaxi". In other examples, the task may be defined as "FindScores" for a sports application. The task definition operation 202 may also prompt the author to add a description of the task to be performed by the CU system. In the above example, the "BookTaxi" task name may be associated with a description such as, for example, "The task of booking a taxi can be achieved using Cortana." In the task definition operation 202, the user interface authoring platform 106 also prompts the author to select at least one LU domain or category associated with the task. Language understanding models can be organized by their related domains. Therefore, the selection of the LU domain filters out the relevant LU models that can be selected by the author from the multiple possible related LU models stored in the database 108. In the "BookTaxi" example, the selected domain may be "taxi" or "transportation", and for the "FindScores" example, the selected domain may be "sports". Thus, the identification of the domain may narrow the author's choices of LU models that can be selected. These domains may be selected from one or more available domains and saved in the database 108. It will be understood that a task may have one or more LU models associated with it. Thus, the author may select more than one LU model. Each LU model may be independent of the other. For example, in the BookTaxi task example, one selected LU model may be a transportation LU model and another selected LU model may be a time and date LU model. Reference Figure 3 An example of a task definition operation 202 is further illustrated and described.

[0037] In select trigger domain operation 204, the author may select one or more additional trigger domains associated with the identified task from database 108. Generally, a trigger domain is considered a collection of trigger intents, each including slot tags that identify information required to perform the task. In one example, the "alarm" trigger domain may include trigger intents for various actions that can be taken, such as "add_alarm," "modify_alarm," "query_alarm," and "delete_alarm," where the corresponding slot tags required to satisfy those trigger intents may be, for example, "alarm_name," "alarm_time," and so on. Therefore, it will be appreciated that in operation 202, the selected LU domain is associated with one or more trigger intents and corresponding slot tags. If the domains selected in operation 202 do not include all the intents required to perform the task, the author may select one or more additional trigger domains in operation 204 that include one or more additional trigger intents for task execution. Therefore, the user interface authoring platform 106 may prompt the author to select another trigger domain to be used to trigger task execution. Based on the selected trigger domain and the associated LU model, the user interface authoring platform 106 can prompt the author to select one of the populated trigger intents associated with the selected trigger domain. In the taxi booking example, an additional domain such as "restaurant" can be selected, and the user interface authoring platform 106 can populate one or more intents associated with the selected restaurant domain, particularly including intents such as the "add_tip" intent and corresponding slot labels such as "tip_amount". Thus, the author can use one or more pre-existing domains to author a task. Additionally or alternatively, the author can use the user interface authoring platform 106 to create a new intent and build an LU model specific to the newly created intent. Thus, the author can create a new domain entirely or augment the selected domain.

[0038] Each selected intent can be associated with one or more LU models that include common phrases or words associated with performing the task. Continuing with the taxi example, the LU model can be pre-selected based on the intent, or the author can select a corresponding LU model. In one example, for the "book a taxi" intent, the author can use the LU model associated therewith, or the author can select another LU model, such as, for example, the Book Taxi LU model. The Book Taxi LU model can specifically relate to identifying speech (including words and phrases) associated with the intent to book a taxi. Alternatively, if the desired LU model is not available, the author can create a new LU model corresponding to a specific task. It will be understood that more than one intent and more than one model can be selected to trigger a task.

[0039] Alternatively or additionally, the author can use the user interface authoring platform 106 to whitelist or hardcode certain queries or phrases that trigger the defined tasks. Thus, if the CU system receives the exact spoken query, the task will be triggered and the selected LU model can be used to assist the CU system in performing the task. Figure 4 An example of a select domain trigger operation 204 is further illustrated and described.

[0040] In the LU model coverage determination 206, the user interface authoring platform 106 may query the author whether the existing LU model(s) stored in the database 108 are sufficient to trigger the execution of the task. If the stored LU model(s) are insufficient to trigger the execution of the task, the process proceeds to operation 208, where the author may add one or more LU models not previously stored in the database 108. In some examples, the author may create such LU models to trigger the execution of the defined task. In some examples, the author may also save the created models in the database 108.

[0041] Alternatively, if it is determined at LU model coverage decision 206 that the stored LU model is sufficient to trigger execution of the defined task, then flow proceeds to define parameters operation 210. Figure 5The define parameter operation 210 is further illustrated and described. In the define parameter operation 210, parameters are identified and defined. As described herein, a task can be described by one or more parameters that must be satisfied before the task is executed. Parameters specify the task and the pieces of information that the CU system needs to collect before the task is executed. Parameters relate to the task defined in operation 202 and provide information for the task defined in operation 202. Parameters can correspond to information that must be collected or processed by the CU system before the task can be executed. For example, a parameter can correspond to information such as the starting location of the "BookTaxi" task. Parameters can be grouped into required parameters or optional parameters, where required parameters are pieces of information that must be collected for the task to be executed, and optional parameters are parameters that further refine the task but are not required for task execution, or whose default or inferred values ​​are sufficient for task execution. Additionally, whether a parameter is required or optional can be expressed based on the state or value of other parameter values ​​evaluated at runtime. The value of each parameter is collected by the CU system or inferred by the system. For example, if a parameter requires the location of a person, the person can provide this information or the CU system can use the device's GPS system to determine the person's location. Alternatively or additionally, if time is a parameter, a person may provide the time to the CU system or the system may infer to use the current time or some other time if no time is specified.

[0042] In the define parameters operation 210, for each parameter, the user interface authoring platform 106 may populate the parameter's name, parameter type, and one or more slot labels associated with the particular parameter (e.g., for the "BookTaxi" task, the slot labels may be, for example, "origin_location" and "end_location"). In one example implementation, the author may be asked to provide or select a name for the parameter, a description of the parameter, a parameter type, one or more parameter slot labels, an appropriate parser for the parameter, a selection indicating whether the parameter is a unique value, and a selection indicating whether the parameter requires user confirmation. Additionally, one or more dialog behaviors may be used to define how the system obtains information for each parameter. In some embodiments, a dialog behavior may be defined as a prompt that is displayed or otherwise provided to the user, and in other embodiments, a dialog behavior is defined differently. As described with reference to Figure 9 As shown, dialog acts can thus be defined as prompts and / or user experience / user interface. Figure 2, in defining parameter operations, the information collection dialog behavior can be, for example, a missing value dialog behavior, a disambiguation dialog behavior, a no result dialog behavior, a suggestion dialog behavior, a selection dialog behavior for prompting the user to select from a small list of possible values, and a confirmation dialog behavior for prompting the user to confirm the value of the parameter. The one or more dialog behaviors can be used to define a user interface implementation for obtaining such information related to each parameter from the user. Specifically, the author can define one or more user interfaces that can be provided to the user for simply displaying information to the user or obtaining information for task execution. In the "BookTaxi" task example, in response to receiving information related to the "destination_location" parameter, a dialog behavior can be used to define a map user interface that can be displayed on the user device and shows the pick-up location. Further, in the "BookTaxi" task example, in response to receiving a pick-up location that cannot be found or determined by the system, another dialog behavior can be used to define an interactive map on the user device or a selectable list of nearby or possible locations. Reference Figure 9 An example user interface illustrating how an author edits a dialog act is shown and described.

[0043] Referring back to define parameter operation 210, a parameter description may be a text string that provides more details about the parameter. For example, in the taxi example, for the parameter name "end_location", the associated description may be "The destination location of the trip".

[0044] The parameter type can categorize the parameter. For example, the parameter type of the "end_location" parameter can be of type "Place". The type can be a predefined type understood by the CU system. Therefore, by setting the type to "Place", the CU system can understand that the end_location parameter corresponds to a latitude / longitude coordinate. It is understood that the parameter type can be defined by the author or selected from a list of parameter types.

[0045] One or more slot tags are used as input to parse the parameter. In this example, the slot tags "absolute_location," "place_type," and "place_name" can be selected, each of which corresponds to a specific type of location information tagged in the user input utterance. For example, "One Microsoft Way" can be tagged as "absolute_location," while "the Space Needle" can be tagged as "place_name." In summary, the set of slot values ​​corresponding to instances of "absolute_location," "place_type," and "place_name" will be used to parse the user input into one or more place entities, which will form the possible values ​​of the parameter end_location.

[0046] The parser selected for each parameter can be used to inform the CU system how to parse or understand the detected keywords. In this example, "PlaceResolver" can be selected, which informs the system that the provided parameter is associated with latitude and longitude coordinates. In the "BookTaxi" task example, for the car preference parameter, the CU system extracts the user's car preference from the natural language query. Based on the parser provided, the CU system determines or resolves the car preference into a car identifier. In some examples, it is understood that the parser can be authored by the experience author.

[0047] A missing value dialog behavior can be defined by the author, which instructs the CU system to request a parameter value from the user if the parameter value is not obtained from the query. For example, a missing value dialog action can be a prompt string, such as "Where would you like to go?" for the "end_location" parameter. Dialog behaviors can also be used to specify an associated user experience, such as displaying a prompt string on a device's display or verbally providing a prompt to the user. The author can also use dialog behaviors to select or define a user interface to be displayed to the user and used to obtain such parameter information. In the "end_location" parameter example, the author can select a map user interface to display a selectable map that allows the user to simply select a destination location instead of verbally providing or typing in the destination location. In another example, such as in a "BookRestaurant" task with a "reservation_time" parameter, the author can select a user interface to display a selectable list from which the user can select an appropriate time as the reservation time.

[0048] A disambiguation dialog behavior can be defined by the author that instructs the CU system to request the user to verify a specific value of a parameter in order to resolve ambiguities that may arise due to multiple potential values ​​of the parameter obtained by the CU system. For example, in response to extracting two different locations from a natural language query, the CU system can display a list of obtained values ​​and a prompt such as "Please select your destination location." In other examples, the CU system may simply prompt the user to restate the destination location without providing a choice. The author can also define a user interface dialog behavior that is displayed or otherwise provided to the user in response to receiving conflicting information fragments. In one example, the author can define a dialog behavior that displays a list of conflicting information fragments on the user's device and requests the user to select the correct information, or requests the user to provide information manually or verbally if none of the displayed information is suitable.

[0049] A no-result dialog behavior can be defined by the author that instructs the CU system to indicate that no results are returned. For example, using the user interface authoring platform 106, the author can use a dialog behavior to select or define a user interface that indicates that no results are returned.

[0050] Suggestion dialogue behaviors can be defined by the author, which instruct the CU system to provide one or more suggestions to the user in response to no results being returned. For example, the author can use a dialogue behavior to define a prompt such as "Please select a location" and an associated user interface that includes a list of suggested locations or a map showing the suggested locations.

[0051] In identify parser operation 212, for each parameter, the user interface authoring platform 106 specifically identifies the parser selected in identify parameters operation 210. For example, identify parser operation 212 may include identifying the name and relative path of the library where the selected parser resides and the identification of the function name within the parser library.

[0052] Authors can also define a failure dialog behavior that provides a failure prompt to the user if a parameter cannot be resolved. In one example, for a location-based parameter, the author can define a dialog behavior that provides a text string that quotes "I'm sorry, I cannot resolve the location right now." Figure 6 Identify parser operations 212 are further illustrated and described.

[0053] In the identify validation conditions operation 214, the user interface authoring platform 106 allows the author to define the conditions that must be met before the task is completed and what the system should do if one or more of these conditions are violated. In one example, when booking a taxi, the validation conditions will ensure that the start and end locations can be reached using only ground transportation. In another example, for an email sending task, the validation conditions will ensure that the subject and body of the email are not empty before the email is sent. Figure 7 Further illustrated is an identify verification condition operation 214 .

[0054] In the final task identification operation 216, the final action or task can be defined. In one example, the final task identification operation 216 may prompt the author to provide a name for the final action and a list of each required and optional input parameter that needs to be provided for the task to execute. The final task identification operation 216 may further prompt the user to provide a resolver associated with the final action. The final action resolver is responsible for providing the final piece of information to be displayed to the user or performing an action on the user's behalf. For example, in the taxi example, the final action resolver is responsible for placing the taxi order based on the received information. In one example, the final action resolver may also include returning a confirmation code that can be displayed to the user. In the final task identification operation 216, the author may define a confirmation dialog behavior that prompts the user to confirm the task execution before it is executed. In the taxi example, the author may define a confirmation dialog behavior that includes a prompt such as "Would you like me to book this trip now?" Alternatively, in the final task identification operation 216, the author may define a confirmation failure dialog behavior that prompts the user to confirm that the task was not executed. The task may not be performed based on the user's interaction with the system or based on the elapse of a predetermined time period. In the taxi example, a confirmation failure dialog behavior such as "I will not book this trip. What would you like to change?" can be defined and provided to the user. In the final task identification operation 216, the author can define a completion dialog behavior that specifies a completion prompt to be displayed or otherwise provided to the user in the event that the task is performed. In the taxi example, a dialog behavior such as "You have booked a taxi. Your booking ID is <id>(Yourtaxi has been booked.Your booking ID is <id>)" can be provided to the user.

[0055] Thus, method 200 provides third-party application authors with the ability to define one or more tasks that can be performed using the CU system of the device, as well as the ability to author one or more dialog acts. When defining a task, method 200 allows the third-party application author to utilize a third-party LU model to extract keywords from a natural language query to satisfy required and optional parameters associated with the task, and utilize one or more third-party parsers used by the CU system to understand the detected keywords to facilitate task completion.

[0056] Figure 3 The diagram shows the definition of Figure 2 An example screenshot 300 of the user interface authoring platform for the task described in the task definition operation 202 is shown. As shown in the example screenshot 300, the user interface authoring platform 106 includes a text box 302 for providing a task name and a text box 304 for providing a task description. The user interface authoring platform 106 also provides a drop-down menu 306 with a list of LU models from which the author can select. In other embodiments, the LU model can be provided by the user rather than selected by the user.

[0057] Figure 4 The diagram is used as a reference Figure 2 4. The example user interface authoring platform 106 includes an example user interface authoring platform for selecting one or more triggering domains and identifying one or more related intents as described in the select triggering domain operation 204. As shown in the example screenshot 400, in one example, if additional domains and intents are desired, the user interface authoring platform 106 includes a drop-down menu 402 for selecting additional domains for triggering a particular task. Based on the additional domains selected in the menu 402, one or more corresponding intents can be automatically populated in the intent drop-down menu 404 that the author can select from. As described herein, the selected intent will be the basis of the model that is used to trigger the execution of the task. The example screenshot 400 also includes a selection box 406 that identifies whether the author wants to whitelist or hardcode the triggering queries. If selected, the selection box 406 will reveal an additional input text box for the experience author to provide a list of triggering queries (not shown).

[0058] Figure 5 The diagram is used to define the reference Figure 2 500 . As shown in the example screenshot 500 , the user interface authoring platform 106 may include a menu 502 identifying the name of the parameter and a menu 504 identifying a description of the parameter. It should be understood that the menus 502 and 504 may be pre-populated based on the selected user intent associated with the parameter. The user interface authoring platform 106 may also include a menu 506 identifying a type for classifying the parameter. It should be understood that the menu 506 may be a drop-down menu from which the author can select the appropriate parameter type. Additionally, the user interface authoring platform 106 may include a menu 508 for providing or selecting one or more slot labels mapped to a particular parameter. The user interface authoring platform 106 may include a menu 510 for providing or selecting a parser for the selected parameter.

[0059] The user interface authoring platform 106 may also include a menu 512 for defining a dialog behavior that instructs the CU system to request a parameter value from the user if the parameter value is not available from the query (e.g., a missing value dialog behavior). In some embodiments, menu 512 is a drop-down menu that includes one or more prompt strings from which the author can select. In other embodiments, the author can provide the prompt string. In yet other embodiments, other dialog behaviors are provided, such as corresponding user experiences / interfaces. The selections may also be displayed to the author, allowing the author to view prompts for each selection from menu 512.

[0060] In addition, the user interface authoring platform 106 may include a menu 514 for defining a dialog behavior that instructs the CU system to request the user to verify a specific value of a parameter in order to resolve ambiguity that may arise due to the CU system obtaining multiple potential values ​​for the parameter (e.g., a disambiguation dialog behavior). In some embodiments, similar to menu 512, menu 514 may be a drop-down menu that includes one or more disambiguation prompts from which the author can select, or the author may provide prompts and corresponding user experiences / interfaces. This selection may also be displayed to the author.

[0061] The user interface authoring platform 106 may also include a selection box 516 indicating whether the parameter is a unique value and a selection box 518 indicating whether the parameter requires user confirmation.

[0062] It should be understood that Figure 5 This is merely exemplary, and each menu 502-514 may each be a drop-down menu of possible dialogue acts that the author can select from. There may also be an associated selection button, such as an "add" button, allowing the author to add a selected dialogue act from one of the menus 502-514. In such an example, once the selected dialogue act is added, the dialogue act may be displayed in the display, allowing the author to view each selected dialogue act. As described herein with reference to the define parameters operation 210, there may also be additional functionality that allows the author to define one or more associated user interfaces. It should therefore be understood that Figure 5 This is for illustration only and is not intended to limit the disclosure to the configurations illustrated.

[0063] Figure 6 The diagram shows the reference Figure 2 6 illustrates an example screenshot of the user interface authoring platform 106 for identifying parsers as described in the example screen shot 600. As shown in the example screen shot 600, the user interface authoring platform 106 includes a menu 602 for providing or selecting one or more parsers and a menu 604 for providing a directory path to the library where the selected parser resides. The user interface authoring platform 106 may also include a menu 606 for providing a specific function name or category name within the identified parser library. Further, the user interface authoring platform 106 may include a menu 608 for defining a dialog behavior, such as a parsing failure prompt dialog behavior that indicates whether a parameter cannot be parsed. In some embodiments, the menu 608 is a drop-down menu that includes one or more failure prompt strings from which the author can select. In another example, once a failure prompt string is selected, it can be displayed to the author, allowing the author to review each selected failure prompt string from the menu 608 and the corresponding user experience / interface.

[0064] It should be understood that Figure 6 This is merely exemplary, and each of menus 602-608 may be a drop-down menu from which the author can select possible dialogue acts. There may also be an associated selection button, such as an "add" button, allowing the author to add a selected dialogue act from one of menus 602-608. In such an example, once the selected dialogue act is added, the dialogue act may be shown in the display, allowing the author to view each selected dialogue act. As described herein with reference to recognition parser operation 212, there may also be additional functionality that allows the author to define one or more associated user interfaces. It should therefore be understood that Figure 6 This is for illustration only and is not intended to limit the disclosure to the configuration shown.

[0065] Figure 7 The diagram shows the reference Figure 2 An example screenshot 700 of the user interface authoring platform 106 for identifying validation conditions, as described in the identify validation condition operation 214 of FIG. As described herein, the user interface authoring platform 106 also provides the ability to specify validation conditions, which define one or more valid conditions that must exist in one or more parameters for task execution. As shown in example screenshot 700, the user interface authoring platform 106 includes a menu 702 for specifying a condition name and a corresponding menu 704 for providing the directory path of the library where the selected validation condition resides. The user interface authoring platform 106 may also include a menu 706 for providing a specific function name or category name within the identified validation condition library. In one example, once a value is provided in menu 706 for providing a specific name, a drop-down box 708 and a text box 710 may appear. For example, drop-down menu 708 may contain additional function specification parameters that need to be provided to fully implement the function. Selecting each parameter from menu 708 may generate a value corresponding to that parameter in text box 710, allowing the author to edit or otherwise modify the value or provide a new value if one is not already provided. Additionally, menu 712 may list Figure 5 The author can select one or more parameters of the task from the drop-down menu 712 to be used as input parameters for the validation function.

[0066] Figure 8 The diagram shows the reference Figure 2 800 . As shown in the example screenshot 800 , the user interface authoring platform 106 includes a text box 802 for providing a name for the final action and a text box 804 for providing a list of required and optional input parameters for task execution. The user interface authoring platform 106 may further include a text box 806 for providing a parser associated with the final action. The user interface authoring platform 106 may further include a menu 808 for defining a confirmation dialog behavior to be provided to the user before the task is executed. The user interface authoring platform 106 may further include a menu 810 for defining a confirmation failure dialog behavior in the event that the task is not executed. The user interface authoring platform 106 may further include a menu 812 for defining a completion dialog behavior.

[0067] Figure 9 An example user interface authoring platform 106 for editing a dialog act is illustrated. As shown, dialog act editor 900 includes a text box 902 for entering a prompt string. The prompt string represents a prompt to be displayed or spoken to the user. The prompt string can be manually entered into text box 902 or, alternatively or additionally, can be selected from a list of prompts. For example, these prompts can be selected from a list of prompts stored in database 108.

[0068] Dialog act editor 900 also includes a user interface menu 904 for selecting a user experience or user interface. As shown in this example, user interface menu 904 is a drop-down menu that allows the author to select a user interface or experience from previously created templates. Based on the selected template, parameters 906 may be populated. Therefore, the author can choose to populate any of parameters 906.

[0069] Dialog act editor 900 further provides the author with the ability to also identify prompt hints 908. Prompt hints 908 are suggestions that may be provided to the user based on parameters requesting additional information.

[0070] Dialogue act editor 900 also provides the author with the ability to identify language understanding model constraints 910. In this example, language understanding model constraints 910 define which parameters are required and which are optional. In one example, for the taxi booking example, a pickup location is required, which is identified as a "hard constraint" in dialogue act editor 900, while other parameters, such as the destination location, can be optional.

[0071] Figure 10 The screenshot 1000 of the exemplary integrated development environment (IDE) that can be used for defining task is illustrated.IDE is that the author can define and edit the example embodiment of task, and wherein IDE also comprises the automatic completion feature for assisting the author.Example integrated development environment is software application, and it provides the ability that uses the class editor such as text editor or other source code editor and the construction tool of construction task and the debugger for debugging error in author code to define task for the author.This IDE can be the Visual Studio that Microsoft of Redmond, Washington provides for example.Example IDE allows the author to use the text class developer tool that is not based on network portal to provide task to specify.Such IDE can also provide support for discovery, automatic completion, suggestion and grammar correction of task definition file.IDE can assist the author to build task model in development environment.In this environment, model can be built with software code, and in some embodiments, model can be the structured document such as XML.

[0072] It should be understood that Figure 3-10 is representative of an example user interface authoring platform, and other configurations are possible. It should also be understood that in some examples text boxes are illustrated, but it should be understood that some information provided via the user interface authoring platform may be selected from the database 108 .

[0073] Figure 11 is a block diagram illustrating the physical components (e.g., hardware) of a computing device 1100 in which aspects of the present disclosure may be practiced. The computing device components described below may have computer-executable instructions for implementing a user interface authoring platform 1120 on a computing device that includes computer-executable instructions for the user interface authoring platform 1120 that may be executed to employ the methods disclosed herein. In a basic configuration, the computing device 1100 may include at least one processing unit 1102 and system memory 1104. Depending on the configuration and type of the computing device, the system memory 1104 may include, but is not limited to, volatile memory (e.g., random access memory), non-volatile memory (e.g., read-only memory), flash memory, or any combination of these memories. The system memory 1104 may include memory suitable for running the user interface authoring platform 1120 or for processing thereon. Figure 1 The operating system 1105 of one or more components of the computing device 1100 may be suitable for controlling the operation of the computing device 1100. In addition, embodiments of the present disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. Figure 11 1108. The computing device 1100 may have additional features or functionality. For example, the computing device 1100 may also include additional data storage devices (removable and / or non-removable), such as, for example, magnetic disks, optical disks, or tapes. Such additional storage Figure 11 This is illustrated by a removable storage device 1109 and a non-removable storage device 1110 .

[0074] As described above, a plurality of program modules and data files may be stored in system memory 1104. When executed on processing unit 1102, program module 1106 (e.g., user interface authoring platform 1120) may perform processes including, but not limited to, the aspects described herein. Other program modules may be used in accordance with various aspects of the present disclosure, and in particular, to provide a user interface authoring platform.

[0075] Furthermore, embodiments of the present disclosure may be practiced in electrical circuits comprising discrete electronic components, in packaged or integrated electronic chips containing logic gates, in circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, embodiments of the present disclosure may be practiced via a system on a chip (SOC) wherein Figure 11 Each or more components illustrated in the can be integrated onto a single integrated circuit. Such a SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") onto the chip substrate as a single integrated circuit. When operated via the SOC, the functions described herein regarding the client switching protocol capability can be operated via application-specific logic integrated with other components of the computing device 1100 on a single integrated circuit (chip). Embodiments of the present disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. Additionally, embodiments of the present disclosure may be practiced within a general-purpose computer or in any other circuit or system.

[0076] The computing device 1100 may also have one or more input devices 1112 such as a keyboard, mouse, pen, sound or voice input device, touch or slide input device, etc. Output devices 1114 may also be included, such as a display, speakers, printer, etc. The above devices are examples, and other devices can be used. The computing device 1100 may include one or more communication connections 1116 that allow communication with other computing devices 1150. Examples of suitable communication connections 1116 include, but are not limited to, radio frequency (RF) transmitters, receivers, and / or transceiver circuits; universal serial bus (USB), parallel and / or serial ports.

[0077] The term computer-readable media as used herein may include computer storage media. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures or program modules. System memory 1104, removable storage device 1109 and non-removable storage device 1110 are all examples of computer storage media (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other products that can be used to store information and can be accessed by computing device 1100. Any such computer storage media may be part of computing device 1100. Computer storage media does not include carrier waves or other propagated or modulated data signals.

[0078] Communication media may be embodied by computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0079] Figure 12A and Figure 12B A mobile computing device 1200 is illustrated, such as a mobile phone, a smart phone, a wearable computer (such as a smart watch), a tablet computer, a laptop computer, etc., with which embodiments of the present disclosure may be practiced. In some aspects, the client may be a mobile computing device. Figure 12A , illustrates one aspect of a mobile computing device 1200 for implementing these aspects. In a basic configuration, the mobile computing device 1200 is a handheld computer having both input and output elements. The mobile computing device 1200 typically includes a display 1205 and one or more input buttons 1210 that allow a user to enter information into the mobile computing device 1200. The display 1205 of the mobile computing device 1200 can also function as an input device (e.g., a touch screen display). If included, an optional side input element 1215 allows for additional user input. The side input element 1215 can be a rotary switch, a button, or any other type of manual input element. In alternative aspects, the mobile computing device 1200 can incorporate more or fewer input elements. For example, in some embodiments, the display 1205 may not be a touch screen. In yet another alternative embodiment, the mobile computing device 1200 is a portable telephone system, such as a cellular phone. The mobile computing device 1200 can also include an optional keyboard 1235. The optional keyboard 1235 can be a physical keyboard or a "soft" keyboard generated on the touch screen display. In various embodiments, the output elements include a display 1205 for displaying a graphical user interface (GUI), a visual indicator 1220 (e.g., a light emitting diode), and / or an audio transducer 1225 (e.g., a speaker). In some aspects, the mobile computing device 1200 integrates a vibration transducer for providing tactile feedback to the user. In yet another aspect, the mobile computing device 1200 integrates input and / or output ports, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., an HDMI port), for sending signals to or receiving signals from external devices.

[0080] Figure 12B 1 is a block diagram illustrating the architecture of one aspect of a mobile computing device. That is, a mobile computing device 1200 can integrate a system (e.g., architecture) 1202 for implementing some aspects. In one embodiment, the system 1202 is implemented as a "smartphone" capable of running one or more applications (e.g., a browser, email, calendar, contact manager, messaging client, game, and media client / player). In some aspects, the system 1202 is integrated into a computing device, such as an integrated personal digital assistant (PDA) and wireless phone.

[0081] One or more applications 1266 can be loaded into memory 1262 and run on or in association with operating system 1264. Examples of applications include phone dialers, email programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, messaging programs, and the like. System 1202 also includes a non-volatile storage area 1268 within memory 1262. Non-volatile storage area 1268 can be used to store persistent information that should not be lost if system 1202 loses power. Applications 1266 can use and store information in non-volatile storage area 1268, such as emails or other messages used by email applications. A synchronization application (not shown) also resides on system 1202 and is programmed to interact with a corresponding synchronization application resident on the host computer to synchronize information stored in non-volatile storage area 1268 with corresponding information stored on the host computer. As should be appreciated, other applications may be loaded into memory 1262 and executed on mobile computing device 1200 , including instructions for providing a user interface authoring platform as described herein.

[0082] The system 1202 has a power supply 1270, which can be implemented as one or more batteries. The power supply 1270 can further include an external power source, such as an AC adapter or a powered docking cradle to supplement or charge the batteries.

[0083] System 1202 may also include a radio interface layer 1272 that performs the function of sending and receiving radio frequency communications. Radio interface layer 1272 facilitates wireless connectivity between system 1202 and the "outside world" via a communications carrier or service provider. Transmissions to and from radio interface layer 1272 are controlled by operating system 1264. In other words, communications received by radio interface layer 1272 can be passed to application programs 1266 via operating system 1264, and vice versa.

[0084] The visual indicator 1220 can be used to provide a visual notification, and / or the audio interface 1274 can be used to generate an audible notification via the audio transducer 1225. In the illustrated embodiment, the visual indicator 1220 is a light emitting diode (LED) and the audio transducer 1225 is a speaker. These devices can be directly coupled to the power supply 1270 so that when they are activated, they remain on for the duration commanded by the notification mechanism, even if the processor 1260 and other components may be turned off to save battery power. The LED can be programmed to remain on indefinitely until the user takes action to indicate the power-on state of the device. The audio interface 1274 is used to provide audible signals to the user and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 1225, the audio interface 1274 can also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. According to an embodiment of the present disclosure, the microphone can also be used as an audio sensor to facilitate control of the notification, as will be described below. The system 1202 may also include a video interface 1276 that enables operation of the onboard camera 1230 to record still images, video streams, and the like.

[0085] The mobile computing device 1200 implementing the system 1202 may have additional features or functionality. For example, the mobile computing device 1200 may also include additional data storage devices (removable and / or non-removable), such as magnetic disks, optical disks, or tapes. Such additional storage Figure 12B 1268 is shown in FIG.

[0086] As described above, data / information generated or captured by the mobile computing device 1200 and stored via the system 1202 can be stored locally on the mobile computing device 1200, or the data can be stored on any number of storage media that can be accessed by the device via the radio interface layer 1272, or via a wired connection between the mobile computing device 1200 and a separate computing device associated with the mobile computing device 1200, such as a server computer in a distributed computing network such as the Internet. As will be appreciated, such data / information can be accessed via the radio interface layer 1272 or via a distributed computing network, and thus via the mobile computing device 1200. Similarly, such data / information can be readily transferred between computing devices for storage and use, according to well-known data / information transfer and storage components, including email and collaborative data / information sharing systems.

[0087] Figure 13 One aspect of the architecture of a system for processing data received at a computing system from a remote source, such as a personal computer 1304, tablet computing device 1306, or mobile computing device 1308, as described above, is illustrated. The content displayed at the server device 1302 may be stored in different communication channels or other storage types. For example, a directory service 1322, a web portal 1324, a mailbox service 1326, an instant messaging storage 1328, or a social networking site 1330 may be used to store various documents. The user interface authoring platform 1020 may be employed by a client communicating with the server device 1302, and / or the user interface authoring platform 1020 may be employed by the server device 1302. The server device 1302 may provide data to and from a client computing device, such as a personal computer 1304, a tablet computing device 1306, and / or a mobile computing device 1308 (e.g., a smart phone), over a network 1315. For example, the above description of Figures 1-10 The depicted computer system may be embodied in a personal computer 1304, a tablet computing device 1306, and / or a mobile computing device 1308 (e.g., a smartphone). In addition to receiving graphics data that may be used for pre-processing at a graphics originating system or post-processing at a receiving computing system, any of these embodiments of the computing device may obtain content from memory 1316.

[0088] Figure 14 An exemplary tablet computing device 1400 that can perform one or more aspects disclosed herein is illustrated. In addition, the aspects and functions described herein can be operated on a distributed system (e.g., a cloud-based computing system) in which application functions, memory, data storage and retrieval, and various processing functions can be remotely operated from each other via a distributed computing network such as the Internet or an intranet. Various types of user interfaces and information can be displayed via an onboard computing device display or via a remote display unit associated with one or more computing devices. For example, various types of user interfaces and information can be displayed and interacted with on a wall surface onto which various types of user interfaces and information are projected. Interactions with a variety of computing systems capable of practicing embodiments of the present invention include keystroke typing, touchscreen typing, voice or other audio typing, gesture typing, in which the associated computing device is equipped with detection (e.g., camera) capabilities for capturing and interpreting user gestures for controlling functions of the computing device, and the like.

[0089] For example, various aspects of the present disclosure are described above with reference to block diagrams and / or operational descriptions of methods, systems, and computer program products according to various aspects of the present disclosure. The functions / acts noted in the blocks may not occur in the order shown in any flowchart. For example, depending on the functions / acts involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order.

[0090] The description and explanation of one or more aspects provided in this application are not intended to limit or restrict the scope of the disclosure claimed in any way. The various aspects, examples and details provided in this application are considered to be sufficient to convey ownership and enable others to make and use the disclosed best mode claimed. The disclosure claimed should not be interpreted as being limited to any aspect, example or details provided in this application. No matter whether illustrated and described in combination or individually, various (structure and method) features are intended to be selectively included or omitted to produce an embodiment with a specific feature set. In the case where the description and explanation of the application has been provided, those skilled in the art can conceive of variations, modifications and alternative aspects that fall within the spirit of the broader aspects of the overall inventive concept embodied in this application, that do not depart from the disclosed broad scope claimed.

[0091] The various embodiments described above are provided as illustrations only and should not be construed as limiting the appended claims. Those skilled in the art will readily appreciate that various modifications and changes may be made without following the example embodiments and applications illustrated and described herein and without departing from the true spirit and scope of the appended claims.< / id> < / id>

Claims

1. A method for authoring a task using a user interface authoring platform, the method comprising: Receive the definition of the task; receiving a selection of a definition of an intent that will trigger the task; receiving parameters that refine performance of the task based on the definition of the selected intent; receiving an indication of a parser for the parameter, wherein the parser is operable to identify data from the received input associated with the parameter; receiving information defining a dialog to prompt a user to provide additional information regarding the parameter; as well as An identification of the execution of the task is received.

2. The method according to claim 1, further comprising: Based on receiving the definition of the task, at least one language understanding model related to the defined task is provided.

3. The method of claim 2, wherein the at least one language understanding model is stored in a shared database of one or more language understanding models.

4. The method of claim 1 , wherein receiving the definition of the task further comprises: A definition of at least one dialog act is received. 5 . The method of claim 4 , wherein the at least one dialog act is one of: a missing value dialog act, a disambiguation dialog act, a no-result dialog act, a suggestion dialog act, a selection dialog act, and a confirmation dialog act.

6. The method of claim 1 , wherein receiving a selection of the intent to trigger the task further comprises: A selection of a triggering domain corresponding to the intent that will trigger the task is received.

7. The method of claim 1 , wherein receiving the parameter that refines the execution of the task further comprises: Receives the name of the parameter; Receive the type of the parameter; receiving a condition for the parameter, the condition indicating whether the parameter is one of a required parameter and an optional parameter; Receiving one or more slot tags as input to parse the parameters; as well as A parser for the argument is received.

8. The method according to claim 1, further comprising: Receives one or more validation conditions.

9. A system comprising: at least one processing unit; as well as at least one memory storing computer-executable instructions that, when executed by the at least one processing unit, cause the system to perform a method comprising: Receive the definition of the task; receiving a selection of an intent that will trigger the task; receiving parameters that refine the execution of the task; receiving parameters that refine performance of the task based on the selected definition of the intent; receiving an indication of a parser for the parameter, wherein the parser is operable to identify data from the received input associated with the parameter; receiving information defining a dialog to prompt a user to provide additional information about the parameter; and An identification of a third-party application for performance of the task is received.

10. The system of claim 9, wherein receiving the definition of the task comprises: A selection of a primary language understanding model for the task stored in a shared database is received.

11. The system of claim 9, wherein receiving a selection of the intent to trigger the task further comprises: A selection of a triggering domain corresponding to the intent that will trigger the task is received.

12. The system of claim 9, wherein receiving parameters that refine the execution of the task further comprises: Receives the name of the parameter; Receive the type of the parameter; receiving a condition for the parameter, the condition indicating whether the parameter is one of a required parameter and an optional parameter; Receiving one or more slot tags as input to parse the parameters; as well as A parser for the argument is received.

13. The system of claim 9, further comprising: receives at least one dialog act definition, The at least one dialog act is one of: a missing value dialog act, a disambiguation dialog act, a no-result dialog act, a suggestion dialog act, a selection dialog act, or a confirmation dialog act.

14. A computer-readable memory storage device, excluding signals, storing a set of instructions that, when executed, perform a method for authoring a task using a user interface authoring platform, the method comprising: Receive the definition of the task; receiving a selection of an intent that will trigger the task; receiving parameters that refine the execution of the task; receiving parameters that refine performance of the task based on the selected definition of the intent; receiving an indication of a parser for the parameter, wherein the parser is operable to identify data from the received input associated with the parameter; receiving information defining a dialog to prompt a user to provide additional information regarding the parameter; as well as An identification of a third-party application for performance of the task is received.

15. The computer-readable memory storage device of claim 14, wherein receiving the definition of the task comprises: A selection of a primary language understanding model for the task is received.

16. The computer-readable memory storage device of claim 14, further comprising: A definition of at least one dialog act associated with the dialog is received, wherein the at least one dialog act is one of: Missing Values ​​Dialog Behavior, Disambiguation dialogue behavior, No result dialogue behavior, Suggested dialogue behavior, Select a dialogue behavior, or Confirm the dialogue behavior.

17. The computer-readable memory storage device of claim 14, wherein receiving a selection of the intent that will trigger the task further comprises: A selection of a triggering domain corresponding to the intent that will trigger the task is received.

18. The computer-readable memory storage device of claim 14, further comprising: Receives one or more validation conditions.

19. The computer-readable memory storage device of claim 14, wherein receiving parameters that refine the execution of the task further comprises: Receives the name of the parameter; Receive the type of the parameter; receiving a condition for the parameter, the condition indicating whether the parameter is one of a required parameter and an optional parameter; Receiving one or more slot tags as input to parse the parameters; as well as A parser for the argument is received.

20. The computer-readable memory storage device of claim 19, further comprising: Receives the definition of a dialog act that requests the value of the parameter.

Images