DETAILED ACTION
This action is in response to the Amendment dated 23 July 2024. Claim 1 has been amended. Claims 2-30 have been added. No claim has been canceled. Claims 1-30 remain pending and have been considered below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-2, 4, 6 and 10-30 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-29 of prior U.S. Patent No. US12079584B2 to DUA (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because all the features recited are included in the corresponding claims of the ‘584 patent.
It is clear that all the elements of the application claim 1 are to be found in reference patent claim 1 and claim 8 (as the application claim 1 fully encompasses reference patent claims 1 and 8). The difference between the application claim 1 and the reference patent claims 1 and 8 lies in the fact that the reference application claim includes many more elements and is thus much more specific. Thus the invention of claims 1 and claim 8 of the reference patent is in effect a “species” of the “generic” invention of the application claim 1. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993). Since application claim 1 is anticipated by claim 1 and claim 8 of the reference patent, it is not patentably distinct from claim 1 of the reference patent. Please see the correspondence below:
Instant Application ‘464
Reference Patent ‘584
Claim 1:
Claim 1: A modeling system for creating interactive conversation models for use by an intelligent assistant system, the modeling system comprising one or more processors, one or more displays, and memory storing instructions configured to be executed by the one or more processors to cause the modeling system to:
display a canvas region of a graphical user interface for creating conversation models;
display a conversation-element menu comprising a plurality of graphical conversation- element menu objects each representing a respective conversation-element type;
create a visual representation of a conversation, the visual representation comprising one or more graphical conversation-element objects, wherein creating the visual representation comprises:
detecting a conversation-element placement input from a user, wherein the input comprises selection of one of the conversation-element menu objects and indication of a location on the canvas region; and
in response to detecting the conversation-element placement input, displaying, at the indicated location on the canvas region, a graphical conversation-element object within the visual representation of the conversation, wherein the graphical conversation-element object indicates that a conversation-element represented by the graphical conversation-element object is of a conversation-element type corresponding to the selected conversation-element menu object,
and the conversation-element is a service execution conversation-element associated with an application programming interface (API);
and generate and store a model of the conversation in accordance with the one or more graphical conversation-element objects of the visual representation of the conversation,
wherein generating and storing the model of the conversation in accordance with the service execution conversation-element comprises generating instructions to call the API and to store a response returned from the API call during execution of the conversation model.
Claim 1 + Claim 8:
Claim 1: A modeling system for creating interactive conversation models for use by an intelligent assistant system, the modeling system comprising one or more processors, one or more displays, and memory storing instructions configured to be executed by the one or more processors to cause the modeling system to:
display a canvas region of a graphical user interface for creating conversation models;
display a conversation-element menu comprising a plurality of graphical conversation-element menu objects each representing a respective conversation-element type;
create a visual representation of a conversation, the visual representation comprising one or more graphical conversation-element objects, wherein creating the visual representation comprises:
detecting a conversation-element placement input from a user, wherein the input comprises selection of one of the conversation-element menu objects and indication of a location on the canvas region; and
in response to detecting the conversation-element placement input, displaying, at the indicated location on the canvas region, a graphical conversation-element object within the visual representation of the conversation, wherein the graphical conversation-element object indicates that a conversation-element represented by the graphical conversation-element object is of a conversation-element type corresponding to the selected conversation-element menu object;
in response to detecting the conversation-element placement input, display a conversation-element fields menu separate from the canvas region, wherein the conversation-element fields menu comprises one or more field portions prompting the user to enter condition information for a first condition of a plurality of conditions, wherein the first condition is associated with the conversation-element, and to enter evaluation order information specifying a position of the first condition in an evaluation order in which the plurality of conditions are arranged; detect a data entry input for the one or more field portions of the conversation-element, wherein the data entry input indicates the first condition; determine whether the data entry input indicates the position of the first condition in the evaluation order in which the plurality of conditions are arranged; in accordance with a determination that the data entry input indicates the position of the first condition in the evaluation order,
generate and store a model of the conversation in accordance with the one or more graphical conversation-element objects of the visual representation of the conversation
and based at least in part on the data entry input indicating the first condition and indicating the position of the first condition in the evaluation order, such that the conversation model is configured to evaluate the first condition associated with the conversation-element in accordance with the evaluation order information specifying the position of the first condition in the evaluation order in which the plurality of conditions are arranged; and
in accordance with a determination that the data entry input does not indicate the position of the first condition in the evaluation order, generate and store the model of the conversation in accordance with the one or more graphical conversation-element objects of the visual representation of the conversation and based at least in part on the data entry input indicating the first condition, such that the conversation model is configured to evaluate the plurality of conditions in a random order.
Claim 8: The modeling system of claim 1, wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to call an API during execution of the conversation model.
Claim 2
Claim 17
Claim 4
Claim 15
Claim 6
Claim 19
Claim 10
Claim 2
Claim 11
Claim 3
Claim 12
Claim 4
Claim 13
Claim 5
Claim 14
Claim 6
Claim 15
Claim 7
Claim 16
Claim 9
Claim 17
Claim 10
Claim 18
Claim 11
Claim 20
Claim 12 to Claim 20
Claim 21
Claim 1
Claim 22
Claim 21
Claim 23
Claim 22
Claim 24
Claim 23
Claim 25
Claim 24
Claim 26
Claim 25
Claim 27
Claim 26
Claim 28
Claim 27
Claim 29
See claim 1 + Claim 8
Claim 30
See claim 1 + Claim 8
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-5, 8, 10-17, 19-20, 24 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1).
As to claim 1, YAO teaches:
a modeling system for creating interactive conversation models for use by an intelligent assistant system (See par. 0016 regarding embodiments of the inventive system and methods that are directed to a conversational agent design platform to design conversational agents; as taught by YAO),
the modeling system comprising one or more processors, one or more displays, and memory storing instructions configured to be executed by the one or more processors (See Fig. 9, par. 0066-0076 regarding system 1500 includes processor 1501, memory 1503, and devices 1505-1508 via a bus; as taught by YAO)
to cause the modeling system to: display a canvas region of a graphical user interface for creating conversation models (See Fig. 6A, par. 0053 regarding the canvas design section 602; as taught by YAO);
display a conversation-element menu comprising a plurality of graphical conversation- element menu objects each representing a respective conversation-element type (See Fig. 6A, par. 0053 regarding the node library section 601 that includes a dialogue node section 604, an NLU section 605, and bots section 606; as taught by YAO);
create a visual representation of a conversation, the visual representation comprising one or more graphical conversation-element objects, wherein creating the visual representation comprises: detecting a conversation-element placement input from a user, wherein the input comprises selection of one of the conversation-element menu objects and indication of a location on the canvas region (See Fig. 6B, par. 0054 regarding a user that can select any of the nodes from node library section 601 into a design area, i.e., canvas 602, for example, by dragging and dropping the selected node or nodes into canvas 602 to provision or design a conversational agent; as taught by YAO);
and in response to detecting the conversation-element placement input, displaying, at the indicated location on the canvas region, a graphical conversation-element object within the visual representation of the conversation, wherein the graphical conversation-element object indicates that a conversation-element represented by the graphical conversation-element object is of a conversation-element type corresponding to the selected conversation-element menu object (See Fig. 6B, par. 0054 regarding assuming a user has dragged and dropped input node 601, router node 602, and output node 603 into the canvas, the input node 601 corresponds to a chat interface to receive utterances and output node is configured to send an output as a response to the utterances back to the chat interface, i.e., the sender of utterances; as taught by YAO);
and the conversation-element is a service execution conversation-element associated with an application programming interface (API) (See par. 0044 where a web API node can request extra information on the web (e.g., accessing weather services, image search engine); as taught by YAO);
and generate and store a model of the conversation in accordance with the one or more graphical conversation-element objects of the visual representation of the conversation (See Fig. 5, par. 0051 wherein once the conversational agent has been configured via design GUI 510, an executable image of the conversational agent can be generated by compiling the source code of the nodes involved by agent compiler 510, which may be stored as a part of conversational agents 535; as taught by YAO).
YAO does not expressly teach wherein generating and storing the model of the conversation in accordance with the service execution conversation-element comprises generating instructions to call the API and to store a response returned from the API call during execution of the conversation model.
In similar field of endeavor, WHITTEN teaches wherein generating and storing the model of the conversation in accordance with the service execution conversation-element comprises generating instructions to call the API and to store a response returned from the API call during execution of the conversation model (see figs. 1-10, par. 0029, wherein FIG. 1 is a block diagram of one example of a computing system architecture 100. Architecture 100 shows visual bot designer computing system 102 that generates an interface 104 for interaction by an author (or user) 106. Visual bot designer computing system 102 also includes one or more processors or servers 108, data stores 110, application programming interfaces (APIs) 112 and it can include other items 114. In one example, system 102 also includes a language generation system 116, a natural language understanding system 118, and it can include other items 120, all of which are coupled to API 112. It will be noted that the language generation system 116, natural language understanding system 118 and other items 120 can be separate from visual bot designer computing system 102, and accessed by API 112; see also par. 0032, wherein Application programming interface 112 illustratively facilitates communication among various items in computing system 102 and it can implement bot design functionality 113; see also par. 0038, wherein bot storage logic 149 interacts with data store 110 to store the bot, and deployment logic 151 can be used to deploy the bot to a desired channel; see also pars. 0034, 0072 and 0076; as taught by WHITTEN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO system to include the teachings of WHITTEN wherein generating and storing the model of the conversation in accordance with the service execution conversation-element comprises generating instructions to call the API and to store a response returned from the API call during execution of the conversation model. Such a person would have been motivated to make this combination as the API can provide access to different sources for providing items and information for designing BOTs. In this manner, the user can provide authoring inputs on any of the user interfaces, and the visual bot designer computing system generates and displays updates on the other parts of the user interface utilizing the API, and then store the BOT logic. This technique for BOT design increases efficiency in BOT generation. It also facilitates re-use or modification of bot components easier, which increases processing efficiency. Because the bot designer is highly intuitive, it also increases design accuracy (WHITTEN, fig. 1, pars. 0001-0006 and 0028).
As to claim 2, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein the service execution conversation-element includes an endpoint field configured to indicate an endpoint for the API call (See Fig. 6D, par. 0056 where if checkbox 615 is selected, the conversation flow will end; as taught by YAO).
As to claim 3, YAO and WHITTEN teach the limitations of claim 2. WHITTEN further teaches wherein the endpoint field is configured to indicate a URL associated with the API (see par. 0121, wherein FIG. 9N is a user interface display 530 that can be used by author 106 to insert an action which causes the bot logic flow to make an HTTP request. Actuator 532 allows author 106 to select a method of making the request. For instance, one method is to retrieve information from a given server using the URL. Another only retrieves the header section. Another method can send data to the server. These are just a few examples. Text box 534 allows author 106 to identify a URL where the request is to be made; as taught by WHITTEN).
As to claim 4, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein the service execution conversation-element includes a return variable field configured to store a value corresponding to the response returned from the API call (See par. 0036 where the two most basic uses of state nodes include adding system utterances to define what the system will present to the user and updating the user variables. All of the user variables persist throughout the entire interaction. Whenever an enter node receives a message, all of the user variables are available and these variables can be used in entrance conditions when router node 203 decides which of the enter nodes to select; as taught by YAO).
As to claim 5, YAO and WHITTEN teach the limitations of claim 4. YAO further teaches wherein the service execution conversation-element is configured to allow the value to be referenced by one or more other conversation-elements in the conversation model (See par. 0036 where all of the user variables persist throughout the entire interaction. Whenever an enter node receives a message, all of the user variables are available and these variables can be used in entrance conditions when router node 203 decides which of the enter nodes to select. State nodes include an attribute such as a checkbox that says Dialogue ends here. If that box is checked in a specific state node, whenever that state node is executed, the conversation ends; as taught by YAO).
As to claim 8, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein the service execution conversation-element includes at least one of: a field configured to accept a script to be executed before the API call is made; or a field configured to accept a script to be executed after the API call is made (See par. 0034 where in between the enter node and the state node, there may be other intermediate nodes 212-213. All of the inter-node communication that happens between the enter node, which receives messages from the router, and the last state node, which sends messages back to the router, happen through wires representing the APIs between the nodes; see also par. 0035, wherein each state node includes a code editor where arbitrary executable code such as JavaScript code can be added. This code will run any time the state node receives a message; as taught by YAO).
As to claim 10, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches:
wherein creating the visual representation of the conversation further comprises: detecting a conversation-element linking input from a user indicating an association within the conversation between two conversation-elements represented by two graphical conversation-element objects of the visual representation of the conversation (See Fig. 5, par. 0047 where a user can use a pointing device such as a mouse or cursor to draw a wire or link to connect an output port of the first node to an input port of the second node on design GUI 510; as taught by YAO);
in response to detecting the conversation-element linking input, displaying a flow indicator on the canvas region indicating an association between the two graphical conversation- element objects (See Fig. 6B, par. 0077 where a connection between an output of a first node and an input of a second node represents a relationship between the first node and second node; as taught by YAO).
As to claim 11, YAO and WHITTEN teach the limitations of claim 2. YAO further teaches wherein generating and storing a model of the conversation in accordance with the one or more graphical conversation-element objects of the visual representation comprises generating and storing the model in accordance with the flow indicator (See Fig. 6G, par. 0058 where the user can specify that this state node, when invoked, will end the conversation session by selecting attribute “dialogue ends here.” Once the user clicks the OK button, all of the settings are saved, for example, by node design module 525 as a part of a conversational agent being designed; as taught by YAO).
As to claim 12, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to initiate execution of the conversation model (See Fig. 6G, par. 0029 where execution of the flow (running the conversation) happens through the flow of messages among the nodes in the network. In a conversation, messages typically originate from input node 201; as taught by YAO).
As to claim 13, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to finalize execution of the conversation model (See Fig. 6D, par. 0056 where the user can also specify whether this state node will end the conversation by marking checkbox 615. If checkbox 615 is selected, the conversation flow will end; as taught by YAO).
As to claim 14, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to receive input during execution of the conversation model (See Fig. 6D, par. 0056 where if checkbox 616 is marked, the system will wait for further user input without terminating the conversation session; as taught by YAO).
As to claim 15, YAO and WHITTEN teach the limitations of claim 6. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to provide output during execution of the conversation model (See Fig. 6D, par. 0056 where the system automatically generates source code in field 613. In addition, the user can specify what information to be returned to the sender via field 614. When this state node is invoked by receiving a message from its corresponding enter node 604, the information will be obtained from field 614 and transmitted back to router node 602 and presented to the user via output node 603; as taught by YAO).
As to claim 16, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to execute a subsequent step, during execution of the conversation model, in accordance with one or more predefined conditions being satisfied (See par. 0032 where the choices presented to the router are the enter nodes in the flow. The router will only consider enter nodes with entrance conditions that are satisfied at that point in the conversation; as taught by YAO).
As to claim 17, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to execute script during execution of the conversation model (See par. 0035 where each state node includes a code editor where arbitrary executable code such as JavaScript code can be added. This code will run any time the state node receives a message; as taught by YAO).
As to claim 19, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches
wherein the instructions further cause the modeling system to: in response to detecting the conversation-element placement input, display a graphical interface element prompting the user to enter data associated with a field of the conversation- element (See Fig. 6B, par. 0054 regarding assuming a user has dragged and dropped input node 601, router node 602, and output node 603 into the canvas, the input node 601 corresponds to a chat interface to receive utterances and output node is configured to send an output as a response to the utterances back to the chat interface, i.e., the sender of utterances; as taught by YAO); and detect a data entry input for the field of the conversation-element (See Figs. 7E-7F, par. 0061 wherein the condition is configured to match the intent property provided by NLU node 710, in this example, the positive response intent for enter node 606. Similarly, as shown in FIG. 7F, the condition for enter node 605 is negative response intent. Thus, at runtime, if the input contains any of the utterances as shown in FIG. 7B, NLU node 610 may determine an intent of positive response and enter node 606 may be invoked by router node 602; as taught by YAO); wherein generating and storing the model of the conversation is based at least in part on the data entry input (See Fig. 5, par. 0051 wherein once the conversational agent has been configured via design GUI 510, an executable image of the conversational agent can be generated by compiling the source code of the nodes involved by agent compiler 510, which may be stored as a part of conversational agents 535; as taught by YAO).
As to claim 20, YAO and WHITTEN teach the limitations of claim 19. YAO further teaches wherein the data entry input indicates at least one of: an utterance, an output value, a schema name, a response variable, a response type, an endpoint, a return variable, a parameter, an executable script, or a condition (See Fig. 6B, par. 0054 where input node 601 corresponds to a chat interface to receive utterances; see also Fig. 6B, par. 0058 where output node is configured to send an output as a response to the utterances back to the chat interface, i.e., the sender of utterances; see also Fig. 6C, par. 0055 where the user can rename node 604 via field 611, in this example, “initial state”; see also par. 0036 where the two most basic uses of state nodes include adding system utterances to define what the system will present to the user and updating the user variables. All of the user variables persist throughout the entire interaction. Whenever an enter node receives a message, all of the user variables are available and these variables can be used in entrance conditions when router node 203 decides which of the enter nodes to select; see also Fig. 6D, par. 0056 where the user can specify what information to be returned to the sender via field 614. When this state node is invoked by receiving a message from its corresponding enter node 604, the information will be obtained from field 614 and transmitted back to router node 602 and presented to the user via output node 603. Furthermore, the user can also specify whether this state node will end the conversation by marking checkbox 615; see also Fig. 6D, par. 0056 where if checkbox 615 is selected, the conversation flow will end; see also par. 0035 where each state node includes a code editor where arbitrary executable code such as JavaScript code can be added; as taught by YAO).
As to claim 24, YAO and WHITTEN teach the limitations of claim 1. YAO further teaches wherein the instructions further cause the modeling system to: after generating and storing the model of the conversation, execute the conversation model (See Fig. 1, par. 0020 where conversational engine 101 may be loaded into a memory and executed by one or more processors; as taught by YAO).
As to claim 29, YAO and WHITTEN teach a method for creating interactive conversation models for use by an intelligent assistant system. Moreover, claim 29 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rationale as claim 1.
As to claim 30, YAO and WHITTEN teach a non-transitory computer-readable storage medium storing instructions for creating interactive conversation models for use by an intelligent assistant system. Moreover, claim 30 discloses substantially the same limitations as claim 1. Therefore, it is rejected with the same rationale as claim 1.
Claims 6-7 and 22 is rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1) and further in view of GELFENBEYN (US20170116982A1).
As to claim 6, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not teach wherein the service execution conversation-element includes a parameters field configured to accept one or more parameters corresponding to execution of the API call.
In similar field of endeavor, GELFENBEYN teaches wherein the service execution conversation-element includes a parameters field configured to accept one or more parameters corresponding to execution of the API call (See Fig. 7, par. 0072 where during operation (e.g., within a dialog session), dialog manager 330 may control dialog flows according to input and output contexts. The input contexts represent some of the pre-conditions for intent execution. A particular intent will trigger only if a certain input context(s) is present in a user request or as result of execution of previous intents. If several intents can be triggered based on the same context, then a decision about which intent is to be executed can be based on a weight of the intent related to the context, age of context, and other parameters as specified in the preferences; as taught by GELFENBEYN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of GELFENBEYN wherein the service execution conversation-element includes a parameters field configured to accept one or more parameters corresponding to execution of the API call. Such a person would have been motivated to make this combination as a dialog system can include a dialog system engine responsible for receiving user voice inputs, transforming them into text inputs, interpreting the text inputs, generating appropriate responses to the text inputs, and delivering responses to users. Interpreting inputs and finding proper responses can utilize artificial intelligence algorithms. Thus, despite the growing demand for dialog systems, creating the dialog systems remains a complex engineering task (GELFENBEYN, par. 0004).
As to claim 7, YAO, WHITTEN and GELFENBEYN teach the limitations of claim 6. WHITTEN further teaches wherein the parameters field is configured to accept values specified in JSON format
(see par. 0045, wherein FIG. 4 is a block diagram showing one example of a set of design user interfaces 104, in more detail. In the example shown in FIG. 4, design user interfaces 104 illustratively include menu pane 200, navigation pane 202, visual authoring canvas 122, selection-driven property pane 124 and JSON file display pane 126. Menu pane 200 can include a plurality of different menu selectors 204-206. Navigation pane 202 can include a plurality of dialog selectors 208-210. When author 106 actuates one of the selected dialog selectors 208-210, the author is navigated to the corresponding dialog, which is displayed on visual authoring canvas 122, property pane 124 and JSON file pane 126. The author 106 can then actuate any of a variety of different actuators 212-220 to take actions to perform design operations on the selected dialog. In the example shown in FIG. 4, those actuators include an add intent actuator 212, a delete intent actuator 214, a show intent actuator 216, a new trigger actuator 218, and it can include other actuators 220. Navigation pane 202 can also illustratively include a new dialog actuator 222. When author 106 actuates new dialog actuator 222, the author is provided with an interface that allows author 106 to begin designing a new dialog using visual authoring canvas 122, selection-driven property pane 124, and/or JSON file pane 126; see also par. 0066, wherein author 106 may edit the JSON string displayed on JSON file display pane 126. In response, API 112 uses code translator/generator 146 which accesses schema 144 to identify how that edited JSON string should be represented in the other interfaces 104; see also pars. 0022-0023, 0030, 0033, 0049 and 0132; as taught by WHITTEN).
As to claim 22, YAO and WHITTEN teach teaches the limitations of claim 1. YAO and WHITTEN do not teach wherein the instructions further cause the modeling system to: receive key input from a user indicating a key to be uniquely associated with the model of the conversation; verify that the key is unique amongst a set of other respective keys for a set of other conversation models; wherein generating and storing the model of the conversation is performed in accordance with verifying that the key is unique.
In similar field of endeavor, GELFENBEYN teaches wherein the instructions further cause the modeling system to: receive key input from a user indicating a key to be uniquely associated with the model of the conversation; verify that the key is unique amongst a set of other respective keys for a set of other conversation models; wherein generating and storing the model of the conversation is performed in accordance with verifying that the key is unique (See par. 0047 where the second type can include developer entities, for example, any unique group of synonyms mapped to a reference value such that a developer can create a food type entity by making an entry with a reference value of “vegetarian” with synonyms of “veg” and “veggie”; as taught by GELFENBEYN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of GELFENBEYN wherein the instructions further cause the modeling system to: receive key input from a user indicating a key to be uniquely associated with the model of the conversation; verify that the key is unique amongst a set of other respective keys for a set of other conversation models; wherein generating and storing the model of the conversation is performed in accordance with verifying that the key is unique. Such a person would have been motivated to make this combination as a dialog system can include a dialog system engine responsible for receiving user voice inputs, transforming them into text inputs, interpreting the text inputs, generating appropriate responses to the text inputs, and delivering responses to users. Interpreting inputs and finding proper responses can utilize artificial intelligence algorithms. Thus, despite the growing demand for dialog systems, creating the dialog systems remains a complex engineering task (GELFENBEYN, par. 0004).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1) and further in view of LAIBSON (US20190342397A1).
As to claim 9, YAO and WHITTEN teach teaches the limitations of claim 1. YAO and WHITTEN do not expressly teach wherein the service execution conversation-element is configured to authenticate the API call using a secure token.
In similar field of endeavor, LAIBSON teaches wherein the service execution conversation-element is configured to authenticate the API call using a secure token (see figs. 1-7, par. 0057, wherein the federation service may take the client PKI Certificate information and the query string parameters and use them to identify which cloud computing service account and cloud computing service role to assume, authenticate that the requester has the access rights to request the credentials, make an API Call to a secure token service to assume the role, receive the temporary credentials, and return the temporary credentials to the user; as taught by LAIBSON).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of LAIBSON wherein the service execution conversation-element is configured to authenticate the API call using a secure token. Such a person would have been motivated to make this combination as it is beneficial for the user to be able to have secure requests sent out to ensure no unauthorized access is granted to intruders (see also LAIBSON, par. 0001).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1) and further view of KRISHNAMURTHY (US20160364377A1).
As to claim 18, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not each wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to associate the conversation with an embedded conversation.
In similar field of endeavor, KRISHNAMURTHY teaches wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to associate the conversation with an embedded conversation (See par. 0073 where in the association maps for the compounded and compounding utterances, the LPKBS inserts the same natural language phrase object for the relative sentence part type. The LPKBS repeats the step of mapping unmapped natural language phrase objects till each of the remnant phrases are mapped to a sentence part type to handle nested compounding utterances or additional compounding utterances; as taught by KRISHNAMURTHY).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of KRISHNAMURTHY wherein generating and storing the model of the conversation comprises generating and storing, in accordance with the conversation-element type, instructions to associate the conversation with an embedded conversation. Such a person would have been motivated to make this combination as there is a long felt but unresolved need for a method and system that processes textual data in multiple natural languages. Moreover, there is a need for a method and system that processes textual data in a domain independent way by targeting semantics of textual data, and that extracts structured information that can be used for disparate computational purposes comprising, for example, business applications, answering questions, translations (KRISHNAMURTHY, par. 0013).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) ) in view of WHITTEN et al. (US20210136008A1) and further view of YUE et al. (US11210593B1).
As to claim 21, YAO and WHITTEN teach the limitations of claim 20. YAO and WHITTEN do not expressly teach wherein the data entry input indicates an order for the condition.
In similar field of endeavor, YUE teaches wherein the data entry input indicates an order for the condition (See figs. 14-15, col. 23, ln. 38, wherein in some example embodiments, operation mimicry system 100 may evaluate output 1510 using predetermined conditions 1520 to determine a next functional unit, e.g., 1410C, to be executed. In some example embodiments, multiple conditions 1520 may be evaluated in a predetermined order; see also col. 23, ln. 43, wherein in FIG. 15, three conditions 1520 are labeled with numbers 1, 2, and 3, indicating an example order of evaluation. A jump 1530 may occur when a condition is met by the data in the output 1510 and prompts the execution of a functional unit 1410 that is not the next functional unit, e.g., 1410A to 1410C, in an otherwise default sequential set of functional units 1410. In an example embodiment, conditions 1520 may analyze specific components of a view-structure (e.g., a textview or a button) and/or values present in the results of an API call or function call. For example, condition 1520 may determine whether or not a component of a view-structure in output 1510 includes certain component types. In another example, a condition 1520 may check whether a specific pattern is included in a view-structure component (e.g., if a string describing a time is displayed in an edit text component of the view-structure). A condition 1520 may similarly analyze output 1510 based on a data type or value contained in output 1510, for example determining whether a certain value is returned as output 1510 from an API call; as taught by YUE).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of YUE wherein the data entry input indicates an order for the condition. Such a person would have been motivated to make this combination as normally many automated virtual assistants require a precise format to enter a request, and the processing limitations of automated virtual assistants result in computing configurations that are limited in terms of processing capabilities which makes the process for completing tasks through an automated virtual assistant laborious, time-consuming, repetitive, and tedious. Thus, adding conditions and jumps to the process makes the process more streamlined and intelligent where the users need not to go through the complete cycle if the interactions are no more relevant (also see YUE, col. 1, ln.39).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) ) in view of WHITTEN et al. (US20210136008A1) and further in view of KANNAN et al. (US20180129484A1).
As to claim 23, YAO and WHITTEN teach teaches the limitations of claim 1. YAO and WHITTEN do not expressly teach wherein the instructions further cause the modeling system to: after generating and storing the model of the conversation, display a visual preview of execution of the conversation model.
In similar field of endeavor, KANNAN teaches wherein the instructions further cause the modeling system to: after generating and storing the model of the conversation, display a visual preview of execution of the conversation model (See Fig. 7 and 8A-B, par. 0025 where the tool further permits the developer to preview the user interfaces for each state in the conversation flow under development in each of a variety of device contexts, and also preview a runtime simulation of the conversation flow, without having to manually adapt the machine conversation for each desired context or code control logic for executing the runtime simulation; as taught by KANNAN).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of KANNAN wherein the instructions further cause the modeling system to: after generating and storing the model of the conversation, display a visual preview of execution of the conversation model. Such a person would have been motivated to make this combination as different inputs and outputs may be provided for different types of computing devices and in different computing contexts, it may be difficult to efficiently adapt a conversation (e.g. for making a restaurant reservation) authored for one computing device context, such as mobile, to a different context, such as desktop, holographic, small screen, or audio-only. As such, a developer may have to develop a different agent for each desired context in which the developer wishes to use a particular conversation flow (KANNAN, par. 0013).
Claims 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1) and further in view of GALITSKY (US20190272323A1).
As to claim 25, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not teach wherein the instructions further cause the modeling system to validate data for the conversation model.
In similar field of endeavor, GALITSKY teaches wherein the instructions further cause the modeling system to validate data for the conversation model (See figs. 40 and 42, par. 0088 where rhetoric classification application 102 can validate argumentation present in input text 130. An exemplary process is discussed with respect to FIG. 40. In an example, rhetoric classification application 102 determines a presence of argumentation, for instance, by using rhetoric agreement classifier 120. Rhetoric classification application 102 can then determine whether a detected argument is valid or invalid; as taught by GALITSKY).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of GALITSKY wherein the instructions further cause the modeling system to validate data for the conversation model. Such a person would have been motivated to make this combination as existing solutions that use argument mining can extract arguments from text and evaluate an extraction accuracy but cannot perform further analysis of extracted arguments. In another example, existing solutions that use logical artificial intelligence are able to validate simple arguments but cannot validate more complex arguments due to a reliance on an insufficiently robust dataset (GALITSKY, par. 0005).
As to claim 26, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not teach wherein validating data comprises one or more of validating that a key identifying the model is unique amongst a set of keys, validating that data entered by a user into a field of a conversation-element of the model satisfies predefined criteria, and validating that the model does not include an impermissible overlap of an utterance with another conversation model.
In similar field of endeavor, GALITSKY teaches wherein validating data comprises one or more of validating that a key identifying the model is unique amongst a set of keys, validating that data entered by a user into a field of a conversation-element of the model satisfies predefined criteria, and validating that the model does not include an impermissible overlap of an utterance with another conversation model (See par. 0443 where rhetoric classification application 102 can verify that the claim, or target claim, in the text is valid, i.e., is not logically attacked by other claims, and is consistent with external truths, i.e., rules; as taught by GALITSKY).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of GALITSKY wherein validating data comprises one or more of validating that a key identifying the model is unique amongst a set of keys, validating that data entered by a user into a field of a conversation-element of the model satisfies predefined criteria, and validating that the model does not include an impermissible overlap of an utterance with another conversation model. Such a person would have been motivated to make this combination as existing solutions that use argument mining can extract arguments from text and evaluate an extraction accuracy but cannot perform further analysis of extracted arguments. In another example, existing solutions that use logical artificial intelligence are able to validate simple arguments but cannot validate more complex arguments due to a reliance on an insufficiently robust dataset (GALITSKY, par. 0005).
Claims 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over YAO et al. (US20190166069A1) in view of WHITTEN et al. (US20210136008A1) and further in view of WANG et al. (US20180314689A1).
As to claim 27, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not teach wherein the instructions further cause the modeling system to: receive a versioning input from a user; and wherein storing generating and storing the model of the conversation comprises storing the model of the conversation with versioning information based on the versioning input.
In similar field of endeavor, WANG teaches wherein the instructions further cause the modeling system to: receive a versioning input from a user; and wherein storing generating and storing the model of the conversation comprises storing the model of the conversation with versioning information based on the versioning input (See par. 0436 where the dialog assistant 3010 may then be able to formulate a clarified version 3012B of the user's original dialog input 3012, either by combining the user's responses to the clarification questions with the original dialog input 3012 or formulating an entirely new version of the user's input; as taught by WANG).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of WANG wherein the instructions further cause the modeling system to: receive a versioning input from a user; and wherein storing generating and storing the model of the conversation comprises storing the model of the conversation with versioning information based on the versioning input. Such a person would have been motivated to make this combination as a multi-lingual person, or a multi-lingual group or family of users, cannot utilize the same virtual personal assistant device to converse in multiple different languages. Instead, the person or people may need, for example, a “Mandarin-speaking” device to speak in Mandarin Chinese and a separate “English-speaking” device to speak in English (WANG, par. 0076).
As to claim 28, YAO and WHITTEN teach the limitations of claim 1. YAO and WHITTEN do not teach wherein the instructions further cause the modeling system to enforce a business review process to ensure that the conversation model conforms with an enterprise requirement.
In similar field of endeavor, WANG teaches wherein the instructions further cause the modeling system to enforce a business review process to ensure that the conversation model conforms with an enterprise requirement (See par. 0086 where the reasoning 154 system may be provided an intelligent set of rules and/or models, which can be referred to as business rules 164, that help the reasoning 154 system to come to reasonable conclusions. The business rules 164 can include rules, models, templates, work flows, task flows, or some other method of expressing possible operations that the virtual personal assistant 150 is capable of; as taught by WANG).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the YAO and WHITTEN system to include the teachings of WANG wherein the instructions further cause the modeling system to enforce a business review process to ensure that the conversation model conforms with an enterprise requirement. Such a person would have been motivated to make this combination as the best course of action may include considering not only what the person 100 has said or typed, but also the person's 100 apparent emotional or cognitive state (WANG, par. 0086).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Publication Number
Filing Date
Title
US9325739B1
2013-04-29
Dynamic security policy generation
US11210593B1
2017-12-15
Storage and execution of operation sequences
US9971766B2
2017-02-17
Conversational agent
US20190207876A1
2018-12-20
Systems and methods for using natural language instructions with an ai assistant associated with machine learning conversations
US20180107461A1
2017-04-07
Bot creation with workflow development system
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOOROSH NEHCHIRI whose telephone number is (408)918-7643. The examiner can normally be reached M-F, 11-7 PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, William L. Bashore can be reached at 571-272-4088. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KOOROSH NEHCHIRI/Examiner, Art Unit 2174
/WILLIAM L BASHORE/ Supervisory Patent Examiner, Art Unit 2174
Prosecution Insights