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 .
Claims 1-20 are presented for examination.
Claim Objections
Claims 5, 15 and 19 are objected to because of the following informalities: The claims include subject-verb disagreement in "whether the initial natural language text input and the additional natural language text input is valid" (plural subjects with singular verb "is"), potentially making the limitation ambiguous. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 10 recites the limitation " the data for the incident workflow " in second line of the claim. There is insufficient antecedent basis for this limitation in the claim. Claim 1 which claim 10 is dependent on does not introduce “data for the incident workflow,” through claim 4 does (but claim 10 does not depend on claim 4).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 17 is directed to a computer-readable storage medium. However, it is noted that the specification does not provide an explicit definition of what constitute a computer-readable medium as intended by the Applicant to cover. The broadest reasonable interpretation of a claim drawn to a computer-readable storage medium typically covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of a computer-readable medium, particularly when the specification is silent. See MPEP § 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 US.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. Therefore, the claimed computer-readable storage medium is ineligible subject matter under § 101. Applicant is advised to amend the claim to recite “a non-transitory computer-readable storage medium” in order to overcome the 35 U.S.C. § 101 rejection.
Claims 18-20 depend on Claim 17 and do not cure the deficiency of Claim 17. Therefore, Claims 18-20 are rejected for the same reason set forth in the rejection of Claim 17.
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(s) 1-4, 10-14 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nahamoo (US 11,056,107 B2) in view of Saxena (US 20230140918) further in view of Ghosh (US 10938678).
Regarding claim 1, Nahamoo (US 11,056,107 B2) teaches
A method comprising:
receiving, by a computing system, and from a user computing device, an initial natural language text input [associated with an incident] (Col 5: ln 52-67, The present disclosure collectively refers to NLU as components that are responsible to analyze natural human language input and extract features/parameters that can then be mapped to a semantic representation—e.g., assign a known meaning along with related parameters to the entire human language input, and parts thereof that originated in the Client Request (105) and further enhanced in the Application Request (115)) Examiner Comments: Nahamoo teaches receiving initial NL text input from a client/user device as part of the client request to initiate dialog processing
generating, by the computing system and based on the initial natural language text input, a set of prompts including one or more prompts (Col 3: ln 53-67, The Conversation Application Orchestration (175) provides orchestration of one or more Conversation Systems (120) by sending an Application Request (115) that triggers the Conversation Workflow Orchestration (170) in the Conversation System (120). The Conversation Workflow Orchestration (170) processes the Application Request (115) and may call one or more Micro-Service Proxies (340.x, FIG. 3) with a Conversation Request (330.x, FIG. 3)) Examiner Comments: Nahamoo teaches generating application/conversation requests (prompts) based on the initial NL input to orchestrate further processing
providing, by the computing system, the set of prompts as input to a machine learning model (Col 5: ln 1-17, The Conversation Workflow Orchestration (170) may also engage a Hypothesis Search (220) to search Dialog Context (165) to decide upon the best predicted dialog path from the available options provided by the Conversation Workflow Orchestration (170) and/or the Inference Engines (210.x) towards the completion of the goal of the dialog; Col 5: ln 17-39, Inference Engines can be viewed as specialized engines used to help break-up (decompose) the Conversation Workflow Orchestration (170) tasks (dialog flow management tasks) to a finite set of specialized Examiner Comments/deciding engines whose results can be combined to provide an eventual Client Response (180)) Examiner Comments: Nahamoo teaches providing the requests/prompts to ML-based inference engines (machine learning models) for processing;
receiving, by the computing system and from the machine learning model, text output for each prompt from the set of prompts, wherein the text output includes one or more of a clarifying question and a clarifying instruction (Col 4: ln 1-34, In cases where the state of Dialog Context (165) is sufficient to provide an Application Response (145), one is generated and returned to the Conversation Application Orchestration (175). There may be other intermediate cases that require additional data or disambiguation from, or further analysis by Business Applications (150) such as a plugin application. In this case Conversation Workflow Orchestration (170) is suspended and a “call back” is returned in an Application Response (145) for the Conversation Application Orchestrator (175) to act upon) Examiner Comments: Nahamoo teaches receiving text output from the model, including callbacks for disambiguation (clarifying questions/instructions) when additional data is needed
sending, by the computing system and to the user computing device, the text output (Col 4: ln 1-34, The Conversation Application may engage the Client Application (100) for disambiguation by returning a Client Response (180), and/or may re-engage the Conversation System (120) to resume Conversation Workflow Orchestration (170)) Examiner Comments: Nahamoo teaches sending the clarifying output back to the user/client device for further input
receiving, by the computing system, and from the user computing device, additional natural language text input (Col 4: ln 1-34, The Conversation Application's (110) Application Workflow Orchestration (175) may trigger a Business Request (148) to be sent to a Business Application (150) for processing. When done processing, the Business Application (150) responds with a Business Response (155)) Note: This includes receiving additional NL input after clarification. Examiner Comments: Nahamoo teaches receiving additional NL text input from the user in response to the clarifying output to resume the workflow
applying, by the computing system, the machine learning model to the initial natural language text input and the additional natural language text input [to generate respective initial structured text data for each prompt from the set of prompts] (Col 3: ln1-23, Both the Conversation Application and Conversation System use and develop Dialog Context (165) by leveraging Conversation Micro-Services (130) and Business Applications (150) as directed by the Application and Conversation Workflow Orchestrations (175, 170) until a Client Response (180) can be returned to the Client Application (100)) Examiner Comments: Nahamoo teaches applying the ML model to initial and additional inputs to generate and update structured dialog context (initial structured text data) for each request/prompt.
applying, by the computing system, the machine learning model to the respective initial structured text data for each prompt from the set of prompts [to generate updated structured text data] (Col 1: ln 55 – Col 2: ln 3, The conversation application and the conversation system develop dialog context and store the dialog context in a memory device, the conversation application and the conversation system developing the dialog context by invoking at least one micro-service. The conversation application generates a response to the client request based on the developed dialog context) Examiner Comments: Nahamoo teaches applying the model to initial structured data to generate updated dialog context, which includes instructions for task/workflow completion.
Nahamoo did not specifically teach
the association with an incident
wherein the updated structured text data includes instructions for creating an incident workflow for the incident
to generate respective initial structured text data for each prompt from the set of prompts
to generate updated structured text data, wherein the updated structured text data includes instructions for creating an incident workflow for the incident
However, Saxena (US 20230140918) teaches
to generate respective initial structured text data for each prompt from the set of prompts (Para 0005, In some embodiments, the automated incident response workflows may be obtained using machine learning and other artificial intelligence (AI) techniques; Para 0006, predicting, based on at least one of the event identifier, or keyphrases in the event description, at least one of: one or more actions in a workflow to respond to the event; a workflow based on a corresponding input event descriptor; or a combination thereof; Para 0009, the one or more actions in the workflow to respond to the event may be associated with one or more corresponding action risk-scores, and the workflow is associated with a corresponding workflow risk-score. For example, the corresponding action risk score may be based on one or more of: a corresponding action type, or a corresponding action environment, or a corresponding user profile associated with a user executing the action, or a combination thereof) Examiner Comments: This passage from Saxena specifies generating structured data for prompts via ML
to generate updated structured text data (Para 0013, a workflow-prediction model using machine learning techniques based on input workflows and event descriptors, wherein the workflow-prediction model is trained to predict a workflow based on a corresponding input event descriptor; Para 0042, IR interaction 116 may include an updated workflow and/or list of actions 106 based on current user selections and/or modifications in UI 104. Accordingly, in some embodiments, based on current user selection and/or modification information (e.g. in IR interaction 116), execution environment service 130-B may recommend an updated likely workflow 126-l and/or suggest other actions 122-l based on input from recommendation engine 136 and/or rules service 138) Examiner Comments: This passage from Saxena describes ML-generated updated structured instructions for workflows.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo with Saxena in order to enhance the workflow generation with predictive ML models that infer structured instructions from incident-related NL inputs, enabling more accurate and automated incident response plans as the invention automates incident management using ML to predict workflows from event descriptors, incorporating NLP for keyphrase extraction to provide recommended workflows (Saxeta [Summary]).
Nahamoo and Saxena did not specifically teach
the association with an incident
wherein the updated structured text data includes instructions for creating an incident workflow for the incident.
However, Ghosh (US 10938678) teaches
the association with an incident (Col 1: ln24-46, Ticket data is obtained and processed using a clustering-based natural language analysis model of ticket descriptions associated with incidents) Examiner Comments: This passage from Ghosh specifies that the NL input is associated with incidents/tickets
wherein the updated structured text data includes instructions for creating an incident workflow for the incident (Abstract , Determine an automation plan for at least one class of tickets, and implement it to configure automatic ticket resolution or ticket generation mitigation; Col 1: ln 47-67, an automation plan for resolving incoming tickets, and obtaining, by the device, ticket data based on receiving the request) Examiner Comments: These passages from Ghosh specify instructions for incident workflows in the structured data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo and Saxena with Ghosh in order to apply the conversational AI framework to the specific domain of incident management, allowing users to create incident workflows through natural language interactions without manual coding, thereby improving efficiency and user experience in IT operations as the system automates ticket resolution by classifying incidents using NLP and ML, reducing manual effort and resource utilization (Ghosh [Background/Summary]).
Regarding Claim 2, Nahamoo, Saxena and Ghosh teach
The method of claim 1, further comprising: receiving, by the computing system, the updated structured text data (Nahamoo [Col 2: ln 1-4, The conversation application generates a response to the client request based on the developed dialog context]) Examiner Comments: This passage from Nahamoo describes receiving and creating based on updated data.
Nahamoo and Saxena did not specifically teach
and creating, by the computing system, and based on the updated structured text data, the incident workflow.
However, Ghosh teaches
and creating, by the computing system, and based on the updated structured text data, the incident workflow (Abstract, Determine an automation plan for at least one class of tickets …, and may implement the automation plan to configure an automatic ticket resolution or ticket generation mitigation procedure for the at least one class of ticket) Examiner Comments: This passage from Ghosh specifies creating incident workflows.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo and Saxena with Ghosh in order to apply the conversational AI framework to the specific domain of incident management, allowing users to create incident workflows through natural language interactions without manual coding, thereby improving efficiency and user experience in IT operations as the system automates ticket resolution by classifying incidents using NLP and ML, reducing manual effort and resource utilization (Ghosh [Background/Summary]).
Regarding Claim 3, Nahamoo, Saxena and Ghosh teach
The method of claim 1, wherein the computing system generates data for [a user interface] including the initial natural language text input, the additional natural language text input, and the text output (Nahamoo [Col 4: ln 6-34, The Conversation Application may engage the Client Application (100) for disambiguation by returning a Client Response (180), and/or may re-engage the Conversation System (120) to resume Conversation Workflow Orchestration (170)]) Examiner Comments: This passage from Nahamoo describes UI data generation including inputs and outputs.
Nahamoo did not specifically teach
A user interface.
However, Saxena teaches
A user interface (Para 0035, provides a user interface 104 to facilitate user interaction with the system and to monitor, track, and respond to events / tickets 110) Examiner Comments: This passage from Saxena specifies UI for inputs/outputs.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo with Saxena in order to enhance the workflow generation with predictive ML models that infer structured instructions from incident-related NL inputs, enabling more accurate and automated incident response plans as the invention automates incident management using ML to predict workflows from event descriptors, incorporating NLP for keyphrase extraction to provide recommended workflows (Saxeta [Summary]).
Regarding Claim 4, Nahamoo, Saxena and Ghosh teach
The method of claim 1, wherein the initial natural language text input and the additional natural language text input are indicative of data for the incident workflow (Nahamoo [ Col 5: 53-67, The present disclosure collectively refers to NLU as components that are responsible to analyze natural human language input and extract features/parameters that can then be mapped to a semantic representation]) Examiner Comments: This passage from Nahamoo describes inputs (initial and additional) are indicative of parameters/data for the workflow.
Regarding Claim 10, Nahamoo, Saxena, and Ghosh teach
The method of claim 1, wherein the computing system is further configured to receive user input to further configure the data for the incident workflow (Nahamoo [Col 4: 6-33, The Conversation Application may engage the Client Application (100) for disambiguation by returning a Client Response (180)) Examiner Comments: This passage from Nahamoo describes receiving additional user input to configure the workflow data.
Regarding Claim 11, is a system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 12, is a system claim corresponding to the method claim above (Claim 2) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 2.
Regarding Claim 13, is a system claim corresponding to the method claim above (Claim 3) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 3.
Regarding Claim 14, is a system claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 4.
Regarding Claim 17, Nahamoo (US 11,056,107 B2) teaches
A computer-readable storage medium encoded with instructions that, when executed, cause at least one processor of a computing system to:
receive, from a user computing device, an initial natural language text input [associated with an incident] (Col 5: ln 52-67, The present disclosure collectively refers to NLU as components that are responsible to analyze natural human language input and extract features/parameters that can then be mapped to a semantic representation—e.g., assign a known meaning along with related parameters to the entire human language input, and parts thereof that originated in the Client Request (105) and further enhanced in the Application Request (115)) Examiner Comments: Nahamoo teaches receiving initial NL text input from a client/user device as part of the client request to initiate dialog processing
generate, based on the initial natural language text input, a set of prompts including one or more prompts (Col 3: ln 53-67, The Conversation Application Orchestration (175) provides orchestration of one or more Conversation Systems (120) by sending an Application Request (115) that triggers the Conversation Workflow Orchestration (170) in the Conversation System (120). The Conversation Workflow Orchestration (170) processes the Application Request (115) and may call one or more Micro-Service Proxies (340.x, FIG. 3) with a Conversation Request (330.x, FIG. 3)) Examiner Comments: Nahamoo teaches generating application/conversation requests (prompts) based on the initial NL input to orchestrate further processing
provide the set of prompts as input to a machine learning model (Col 5: ln 1-17, The Conversation Workflow Orchestration (170) may also engage a Hypothesis Search (220) to search Dialog Context (165) to decide upon the best predicted dialog path from the available options provided by the Conversation Workflow Orchestration (170) and/or the Inference Engines (210.x) towards the completion of the goal of the dialog; Col 5: ln 17-39, Inference Engines can be viewed as specialized engines used to help break-up (decompose) the Conversation Workflow Orchestration (170) tasks (dialog flow management tasks) to a finite set of specialized Examiner Comments/deciding engines whose results can be combined to provide an eventual Client Response (180)) Examiner Comments: Nahamoo teaches providing the requests/prompts to ML-based inference engines (machine learning models) for processing;
receive, from the machine learning model, text output for each prompt from the set of prompts, wherein the text output includes one or more of a clarifying question and a clarifying instruction (Col 4: ln 1-34, In cases where the state of Dialog Context (165) is sufficient to provide an Application Response (145), one is generated and returned to the Conversation Application Orchestration (175). There may be other intermediate cases that require additional data or disambiguation from, or further analysis by Business Applications (150) such as a plugin application. In this case Conversation Workflow Orchestration (170) is suspended and a “call back” is returned in an Application Response (145) for the Conversation Application Orchestrator (175) to act upon) Examiner Comments: Nahamoo teaches receiving text output from the model, including callbacks for disambiguation (clarifying questions/instructions) when additional data is needed
send, to the user computing device, the text output (Col 4: ln 1-34, The Conversation Application may engage the Client Application (100) for disambiguation by returning a Client Response (180), and/or may re-engage the Conversation System (120) to resume Conversation Workflow Orchestration (170)) Examiner Comments: Nahamoo teaches sending the clarifying output back to the user/client device for further input
receive, from the user computing device, additional natural language text input (Col 4: ln 1-34, The Conversation Application's (110) Application Workflow Orchestration (175) may trigger a Business Request (148) to be sent to a Business Application (150) for processing. When done processing, the Business Application (150) responds with a Business Response (155)) Note: This includes receiving additional NL input after clarification. Examiner Comments: Nahamoo teaches receiving additional NL text input from the user in response to the clarifying output to resume the workflow
apply the machine learning model to the initial natural language text input and the additional natural language text input [to generate respective initial structured text data for each prompt from the set of prompts] (Col 3: ln1-23, Both the Conversation Application and Conversation System use and develop Dialog Context (165) by leveraging Conversation Micro-Services (130) and Business Applications (150) as directed by the Application and Conversation Workflow Orchestrations (175, 170) until a Client Response (180) can be returned to the Client Application (100)) Examiner Comments: Nahamoo teaches applying the ML model to initial and additional inputs to generate and update structured dialog context (initial structured text data) for each request/prompt.
apply the machine learning model to the respective initial structured text data for each prompt from the set of prompts [to generate updated structured text data] (Col 1: ln 55 – Col 2: ln 3, The conversation application and the conversation system develop dialog context and store the dialog context in a memory device, the conversation application and the conversation system developing the dialog context by invoking at least one micro-service. The conversation application generates a response to the client request based on the developed dialog context) Examiner Comments: Nahamoo teaches applying the model to initial structured data to generate updated dialog context, which includes instructions for task/workflow completion
receive the updated structured text data (Col 2: ln 1-4, The conversation application generates a response to the client request based on the developed dialog context) Examiner Comments: This passage from Nahamoo describes receiving and creating based on updated data
Nahamoo did not specifically teach
the association with an incident
wherein the updated structured text data includes instructions for creating an incident workflow for the incident
to generate respective initial structured text data for each prompt from the set of prompts
to generate updated structured text data, wherein the updated structured text data includes instructions for creating an incident workflow for the incident
and create based on the updated structured text data, the incident workflow.
However, Saxena (US 20230140918) teaches
to generate respective initial structured text data for each prompt from the set of prompts (Para 0005, In some embodiments, the automated incident response workflows may be obtained using machine learning and other artificial intelligence (AI) techniques; Para 0006, predicting, based on at least one of the event identifier, or keyphrases in the event description, at least one of: one or more actions in a workflow to respond to the event; a workflow based on a corresponding input event descriptor; or a combination thereof; Para 0009, the one or more actions in the workflow to respond to the event may be associated with one or more corresponding action risk-scores, and the workflow is associated with a corresponding workflow risk-score. For example, the corresponding action risk score may be based on one or more of: a corresponding action type, or a corresponding action environment, or a corresponding user profile associated with a user executing the action, or a combination thereof) Examiner Comments: This passage from Saxena specifies generating structured data for prompts via ML
to generate updated structured text data (Para 0013, a workflow-prediction model using machine learning techniques based on input workflows and event descriptors, wherein the workflow-prediction model is trained to predict a workflow based on a corresponding input event descriptor; Para 0042, IR interaction 116 may include an updated workflow and/or list of actions 106 based on current user selections and/or modifications in UI 104. Accordingly, in some embodiments, based on current user selection and/or modification information (e.g. in IR interaction 116), execution environment service 130-B may recommend an updated likely workflow 126-l and/or suggest other actions 122-l based on input from recommendation engine 136 and/or rules service 138) Examiner Comments: This passage from Saxena describes ML-generated updated structured instructions for workflows.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo with Saxena in order to enhance the workflow generation with predictive ML models that infer structured instructions from incident-related NL inputs, enabling more accurate and automated incident response plans as the invention automates incident management using ML to predict workflows from event descriptors, incorporating NLP for keyphrase extraction to provide recommended workflows (Saxeta [Summary]).
Nahamoo and Saxena did not specifically teach
the association with an incident
wherein the updated structured text data includes instructions for creating an incident workflow for the incident
and create based on the updated structured text data, the incident workflow.
However, Ghosh (US 10938678) teaches
the association with an incident (Col 1: ln24-46, Ticket data is obtained and processed using a clustering-based natural language analysis model of ticket descriptions associated with incidents) Examiner Comments: This passage from Ghosh specifies that the NL input is associated with incidents/tickets
wherein the updated structured text data includes instructions for creating an incident workflow for the incident (Abstract , Determine an automation plan for at least one class of tickets, and implement it to configure automatic ticket resolution or ticket generation mitigation; Col 1: ln 47-67, an automation plan for resolving incoming tickets, and obtaining, by the device, ticket data based on receiving the request) Examiner Comments: These passages from Ghosh specify instructions for incident workflows in the structured data
and create based on the updated structured text data, the incident workflow (Abstract, Determine an automation plan for at least one class of tickets …, and may implement the automation plan to configure an automatic ticket resolution or ticket generation mitigation procedure for the at least one class of ticket) Examiner Comments: This passage from Ghosh specifies creating incident workflows
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo and Saxena with Ghosh in order to apply the conversational AI framework to the specific domain of incident management, allowing users to create incident workflows through natural language interactions without manual coding, thereby improving efficiency and user experience in IT operations as the system automates ticket resolution by classifying incidents using NLP and ML, reducing manual effort and resource utilization (Ghosh [Background/Summary]).
Regarding Claim 18, Nahamoo, Saxena and Ghosh teach
The computer-readable storage medium of claim 17, wherein the at least one processor is further configured to generate data for [a user interface] including the initial natural language text input, the additional natural language text input, and the text output (Nahamoo [Col 4: ln 6-34, The Conversation Application may engage the Client Application (100) for disambiguation by returning a Client Response (180), and/or may re-engage the Conversation System (120) to resume Conversation Workflow Orchestration (170)]) Examiner Comments: This passage from Nahamoo describes UI data generation including inputs and outputs.
Nahamoo did not specifically teach
A user interface.
However, Saxena teaches
A user interface (Para 0035, provides a user interface 104 to facilitate user interaction with the system and to monitor, track, and respond to events / tickets 110) Examiner Comments: This passage from Saxena specifies UI for inputs/outputs.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Nahamoo with Saxena in order to enhance the workflow generation with predictive ML models that infer structured instructions from incident-related NL inputs, enabling more accurate and automated incident response plans as the invention automates incident management using ML to predict workflows from event descriptors, incorporating NLP for keyphrase extraction to provide recommended workflows (Saxeta [Summary]).
Claim(s) 5-9, 15-16 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nahamoo (US 11,056,107 B2) in view of Saxena (US 20230140918) and Ghosh (US 10938678) further in view of Eggebraaten (US 8639497).
Regarding Claim 5, Nahamoo, Saxena and Ghosh teach
The method of claim 1.
Nahamoo, Saxena and Ghosh did not teach
further comprising: determining, by the computing system and based on stored data, whether the initial natural language text input and the additional natural language text input is valid, wherein the stored data includes one or more of valid user data, valid computing system data, and valid workflow parameters data.
However, Eggebraaten (US 8639497) teaches
further comprising: determining, by the computing system and based on stored data, whether the initial natural language text input and the additional natural language text input is valid, wherein the stored data includes one or more of valid user data, valid computing system data, and valid workflow parameters data (Abstract, evaluating each identified condition in accordance with the predetermined evidence and predefined condition evaluation rules; evaluating each coarse grained text fragment in dependence upon the condition evaluations and the logical operators) Examiner Comments: This passage from Eggebraaten specifies the computing system evaluating/validating NL inputs against stored predefined rules and evidence (workflow parameters data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combined Nahamoo, Saxena and Ghosh’s teaching to Eggebraaten’s in order to incorporate automated evaluation and validation of NL inputs using predefined rules and evidence, enabling disambiguation and accurate processing of complex text passages in workflows, by calculating truth value indicating degree to which evidence meets criteria of text passage by natural language processing module in dependence upon evaluations of fragment (Eggebraaten [Summary]).
Regarding Claim 6, Nahamoo, Saxena, Ghosh and Eggebraaten teach
The method of claim 5.
Nahamoo teaches valid inputs include requests that trigger actions and fields in the workflow: (Col 3: ln 53-67, The Conversation Workflow Orchestration (170) processes the Application Request (115) and may call one or more Micro-Service Proxies (340.x, FIG. 3) with a Conversation Request (330.x, FIG. 3)).
Ghosh teaches incident-specific triggers/actions/fields: (Abstract, The automation plan includes instructions for resolving the incident workflow).
Nahamoo, Saxena, and Ghosh did not specifically teach
wherein the initial natural language text input and the additional natural language text input determined to be valid includes one or more of a trigger, an action, and a field for the incident workflow.
However, Eggebraaten (US 8639497) teaches
wherein the initial natural language text input and the additional natural language text input determined to be valid includes one or more of a trigger, an action, and a field for the incident workflow (Abstract, decomposing the text passage into coarse grained text fragments, including grouping text segments in dependence upon the logical operators; analyzing each coarse grained text fragment to identify conditions) Examiner Comments: This passage from Eggebratten specifies valid evaluated inputs include conditions (fields), logical operators (triggers/actions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combined Nahamoo, Saxena and Ghosh’s teaching to Eggebraaten’s in order to incorporate automated evaluation and validation of NL inputs using predefined rules and evidence, enabling disambiguation and accurate processing of complex text passages in workflows, by calculating truth value indicating degree to which evidence meets criteria of text passage by natural language processing module in dependence upon evaluations of fragment (Eggebraaten [Summary]).
Regrading Claim 7, Nahamoo, Saxena, Ghosh and Eggebraaten teach
The method of claim 6, wherein the trigger includes one or more of a manual trigger, an automatic trigger, a scheduled trigger, and an event-based trigger (Nahamoo [Col 3: ln 53-67, The Conversation Application Orchestration (175) provides orchestration of one or more Conversation Systems (120) by sending an Application Request (115) that triggers the Conversation Workflow Orchestration (170) in the Conversation System (120)." (col. 4, lines 25-30]). Examiner Comments: This passage from Nahamoo describes manual/event triggers.
Regarding Claim 8, Nahamoo, Saxena, Ghosh and Eggebraaten teach
The method of claim 6, wherein the action includes one or more of an addition of stakeholders, a sending of a status update, a creation of a message thread, a sending of a message thread link, an addition of responders, and a starting of a virtual meeting (Nahamoo [ Abstract , The conversation application and the conversation system develop dialog context and store the dialog context in a memory device, the conversation application and the conversation system developing the dialog context by invoking at least one micro-service) Examiner Comments: This passage from Nahamoo describes actions like invoking micro-services, which can include sending updates or adding responders in a conversational context.
Regarding Claim 9, Nahamoo, Saxena, Ghosh and Eggebraaten teach
The method of claim 6.
Nahamoo, Saxena, and Ghosh did not specifically teach
wherein the field for the incident workflow includes one or more of an identifier, a title, a description, a timestamp, an incident type, an incident source, a severity level, one or more assigned users, an urgency level, a priority level, a current incident status, incident resolution data, one or more associated support tickets, and an action log.
However, Eggebraaten (US 8639497) teaches
wherein the field for the incident workflow includes one or more of an identifier, a title, a description, a timestamp, an incident type, an incident source, a severity level, one or more assigned users, an urgency level, a priority level, a current incident status, incident resolution data, one or more associated support tickets, and an action log (Abstract, receiving a text passage to process, the text passage including conditions and logical operators, the text passage comprising criteria for evidence) Examiner Comments: This passage from Eggebraaten specifies fields like conditions (type/description), logical operators (priority/urgency), truth values (status/resolution).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combined Nahamoo, Saxena and Ghosh’s teaching to Eggebraaten’s in order to incorporate automated evaluation and validation of NL inputs using predefined rules and evidence, enabling disambiguation and accurate processing of complex text passages in workflows, by calculating truth value indicating degree to which evidence meets criteria of text passage by natural language processing module in dependence upon evaluations of fragment (Eggebraaten [Summary]).
Regarding Claim 15, is a system claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 5.
Regarding Claim 16, is a system claim corresponding to the method claim above (Claim 6-9) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 6-9.
Regarding Claim 19, Nahamoo, Saxena and Ghosh teach
The computer-readable storage medium of claim 17, wherein the initial natural language text input and the additional natural language text input are indicative of data for the incident workflow (Nahamoo [ Col 5: 53-67, The present disclosure collectively refers to NLU as components that are responsible to analyze natural human language input and extract features/parameters that can then be mapped to a semantic representation]) Examiner Comments: This passage from Nahamoo describes inputs (initial and additional) are indicative of parameters/data for the workflow.
Nahamoo, Saxena and Ghosh did not teach
wherein the at least one processor is further configured to: determine, based on stored data, whether the initial natural language text input and the additional natural language text input is valid, wherein the stored data includes one or more of valid user data, valid computing system data, and valid workflow parameters data.
However, Eggebraaten (US 8639497) teaches
wherein the at least one processor is further configured to:determine, based on stored data, whether the initial natural language text input and the additional natural language text input is valid, wherein the stored data includes one or more of valid user data, valid computing system data, and valid workflow parameters data (Abstract, evaluating each identified condition in accordance with the predetermined evidence and predefined condition evaluation rules; evaluating each coarse grained text fragment in dependence upon the condition evaluations and the logical operators) Examiner Comments: This passage from Eggebraaten specifies the computing system evaluating/validating NL inputs against stored predefined rules and evidence (workflow parameters data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combined Nahamoo, Saxena and Ghosh’s teaching to Eggebraaten’s in order to incorporate automated evaluation and validation of NL inputs using predefined rules and evidence, enabling disambiguation and accurate processing of complex text passages in workflows, by calculating truth value indicating degree to which evidence meets criteria of text passage by natural language processing module in dependence upon evaluations of fragment (Eggebraaten [Summary]).
Regarding Claim 20, is a computer-readable storage medium claim corresponding to the method claim above (Claim 6-9) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 6-9.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
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, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191