DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Application
2. Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Foreign Priority
3. The Examiner has noted the Applicants claiming Priority from Foreign Application AU2024202688 filed on 04/24/2024. Receipt is acknowledged of papers submitted under 35 U.S.C. § 119(a)-(d), which papers have been placed of record in the file. Therefore, Examiner notes the effective filing date of this application examined on the record is 04/24/2024.
IDS Statements
4. The 1 Information Disclosure Statement (IDS) filed on 09/09/2025 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and are considered by the Examiner.
Claim Objections
5. Claims 19-20 are objected to because of the following informalities:
(A). Claim 19 recites the following limitation: “A computer processing system including: a processing unit; a communication interface; and a non-transitory computer-readable storage medium storing instructions, which when executed by the processing unit, cause the processing unit to perform a method according to claim 1.” There appears to be minor claim informalities of the phrase “a method according to claim 1” if Claim 19 intends to refer back to Independent Claim 1. For the purposes of examination, Examiner suggests to amend Claim 19 as follows: “A computer processing system including: a processing unit; a communication interface; and a non-transitory computer-readable storage medium storing instructions, which when executed by the processing unit, cause the processing unit to perform [[ the computer implemented method according to claim 1.” It is not unclear if a method of claim 19 is the same method of claim 1.
(B). Claim 20 recites the following limitation: “A non-transitory storage medium storing instructions executable by processing unit to cause the processing unit to perform a method according to claim 1.” There appears to be minor claim informalities of the phrase “a method according to claim 1” if Claim 20 intends to refer back to Independent Claim 1. For the purposes of examination, Examiner suggests to amend Claim 20 as follows: “A non-transitory storage medium storing instructions executable by a processing unit to cause the processing unit to perform [[ the computer implemented method according to claim 1.” It is not unclear if a method of claim 20 is the same method of claim 1. Appropriate corrections are required.
Claim Rejections - 35 USC § 112
6. 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.
7. Claims 14-15 and 19-20 are 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.
(A). Dependent Claim 14 recites the following limitation: “The computer implemented method according to claim 1, wherein processing the input string to generate a support request, wherein the support request is based on the input string and additional query data, and the classifier input is based on the support request.” There appears to be a lack of antecedent basis with respect to the 1st phrase or 1st term of “the input string” when referring back to Independent Claim 1 which initially recites “input data”, which renders the result being indefinite. For the purposes of examination, Examiner suggests to Applicant to amend the claim limitation of Dependent Claim 14 to recite the following: “The computer implemented method according to claim 1, wherein processing [[ a input string to generate a support request, wherein the support request is based on the input string and additional query data, and the classifier input is based on the support request.” Furthermore, Dependent Claim 15 depend from Dependent Claim 14 and therefore inherit the 35 U.S.C. § 112 (b) deficiency of Dependent Claim 15 discussed above.
Claim Rejections - 35 USC § 101
8. 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.
9. Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-20 are each focused to a statutory category namely a “method” or a “process” (Claims 1-20).
We proceed onto analyzing the claims with respect to Step 2A Prong 1 shown below.
Step 2A Prong One: Independent Claim 1 recite limitations that set forth the abstract idea(s), namely (see in bold except via strikethrough):
“receiving input data defining a support query, the input data being in ” (see Independent Claim 1);
“processing the input data to generate a classifier input for a classifier based on the input data, wherein the classifier is a trained model and wherein the classifier input is a prompt including a context setting components and one or more of: ” (see Independent Claim 1);
“processing, by the classifier, the classifier input to identify a first workflow from a plurality of workflows, wherein the first workflow defines one or more workflow actions which can be executed in response to the support query” (see Independent Claim 1).
Here, for Independent Claim 1, the claim limitations recite an abstract idea directed to automated query classification and response mapping. The core concept is analyzing human language, categorizing it using mathematical models, and retrieving a corresponding instruction or rule. The first claim limitation step of “Receiving input data defining a support query (natural language)…” recites Mental Processes or Certain Methods of Organizing Human Activities Groupings. This claim limitation involves the receipt or gathering of information. Interpreting human communication is an act that can practically be performed in the human mind. The categorization of data received from a user into a query is a fundamental communicative step. The second claim limitation step of “Processing the input data to generate a classifier input…” recites Mental Processes or Mathematical Concept Groupings. The act of processing data to format it—via context setting, output setting, and rules—is essentially compiling and organizing information. This step represents abstract analytical thinking (i.e., organizing data into a specific format to assess relevance) which can be performed mentally or via pen and paper. The last claim limitation step of “Processing by the classifier to identify a first workflow” recites Mental Processes or Mathematical Concept Groupings. Classifiers, trained machine learning models, and rule engines inherently rely on algorithms, statistical analysis, and mathematical computations to make classifications. The task of matching an input to an output based on learned patterns is a mathematical correlation. Because the evaluation and judgment involved here can be performed by the human mind, it triggers the mental process exception.
Therefore, these abstract idea limitations (as identified above in bold), under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Certain Methods of Organizing Human Activities” which pertains to (1) managing personal behavior or relationships or interactions between people (including teachings or following rules or instructions) and additionally or alternatively as “Mathematical Concepts” which pertains to (2) mathematical relationships.
Additionally, or alternatively, these abstract idea limitations (as identified above in bold), under the broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Mental Processes” which pertains to (3) concepts performed in the human mind (including observations or evaluations or judgments) or (4) using pen and paper as a physical aid, in order to help perform these mental steps does not negate the mental nature of these limitations. The use of "physical aids" in implementing the abstract mental process, does not preclude these claims from reciting an abstract idea. See MPEP § 2106.04(a) III C.
That is, other than reciting the additional elements of (e.g., “information basis setting component” & “an output setting component” & “output rule component”, etc…), nothing in the claim elements precludes the steps from being performed as “Certain Methods of Organizing Human Activities” which pertains to (1) managing personal behavior or relationships or interactions between people (including teachings or following rules or instructions) and additionally or alternatively as “Mental Processes” which pertains to (2) concepts performed in the human mind (including observations or evaluations or judgments) or (3) using pen and paper as a physical aid and additionally or alternatively as “Mathematical Concepts” which pertains to (4) mathematical relationships.
Therefore, at step 2a prong 1, Yes, Claims 1-20 recite an abstract idea. We proceed onto analyzing the claims at step 2a prong 2.
Step 2A Prong Two: With respect to Step 2A Prong Two of the eligibility inquiry (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. Independent Claim 1 recites additional elements directed to: (e.g., “information basis setting component” & “an output setting component” & “output rule component”). These additional elements have been considered individually and in combination, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP § 2106.05(f) and MPEP § 2106.05(h).
Independent Claim 1: With respect to reliance on (e.g., “natural language” & “machine learning model”) as additional elements shown in Independent Claim 1 when considered individually and as an ordered combination (as a whole) in view of these claim limitations, these additional elements do not provide limitations that are indicative of integration into a practical application under step 2a prong 2 due to: (1) the claims as a whole are limited to a particular field of use or technological environment for automated query classification and response mapping using a computer in the field of identifying a workflow in a business management environment (see MPEP § 2106.05(h)) or (2) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)).
Furthermore, certain/particular limitations in Independent Claim 1 recites “mere data gathering” (e.g., “receiving input data defining a support query, the input data being in natural language” (see Independent Claim 1)), which when evaluated as additional elements, this activity at most amounts to insignificant extra-solution activities (see MPEP § 2106.05 (g)).
In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception. Therefore, at step 2a prong 2, Claims 1-20 are directed to the abstract idea and do not recite additional elements that integrate into a practical application.
Step 2B: (As explained in MPEP § 2106.05), it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Independent Claim 1 recites additional elements directed to: (e.g., “information basis setting component” & “an output setting component” & “output rule component”). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (computing environment) and does not amount to significantly more than the abstract idea itself. See MPEP § 2106.05 (h) and See MPEP § 2106.05 (f). Notably, Applicant’s Specification suggests that the claimed invention relies on nothing more than a general-purpose computer executing the instructions to implement the invention (see at least Applicant’s Specification ¶ [0033]: “Client application 132 may be a general web browser application which accesses server application 114, support application 116 and/or other applications provided by the server environment 110 via an appropriate uniform resource locator (URL) and communicates with server application 114 via general world-wide-web protocols (e.g. http, https, ftp).”. See also Applicant’s Specification ¶ [0043]: “System 200 is a general-purpose computer processing system.”).
Furthermore, certain/particular limitations in Independent Claim 1 recites “mere data gathering” (e.g., “receiving input data defining a support query, the input data being in natural language” (see Independent Claim 1)), which when evaluated as additional elements, this activity at most amounts to insignificant extra-solution activities (see MPEP § 2106.05 (g)), and have been recognized as Well-Understood, Routine and Conventional (WURC), and thus insufficient to add significantly more to the abstract idea. See MPEP § 2106.05(d) ii - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Lastly, the large language model (LLM) is recited at a high level of generality (black box recitation), is only recited in steps that may be considered insignificant extra-solution activities (inputting, receiving), and particular when recited at a high level of generality (as recited in the current claims), is considered well-understood, routine, and conventional in the art. See, for example, Shah et al., US 2024/0420161, noting for example in par. [0127] that “As is known in the art, an LLM is a machine learning model configured to achieve general-purpose language understanding and generation. LLMs are trained in advance.” See also, Mongeau, US 2025/0173999, noting for example in par. [0038] that “Examples of NLP and LLM algorithms are well known in the art and can be considered as black boxes, using a language model adapted to process the textual inputs to generate textual outputs.” Accordingly, the use of an LLM for implementing the inputting and receiving does not add significantly more to the claims.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent Claims 2-20 recite additional elements directed to: (e.g., “a communication interface” (see Claim 19) & “a non-transitory computer-readable storage medium” (see Claims 19-20) & “a processing unit” (see Claims 19-20), etc…), and when considered individually and as an ordered combination (as a whole) with the limitations recite the same abstract idea(s) as shown in Independent Claim 1 along with further steps/details that could be performed as “Certain Methods of Organizing Human Activities” which pertains to (1) managing personal behavior or relationships or interactions between people (including teachings or following rules or instructions) and additionally or alternatively as “Mental Processes” which pertains to (2) concepts performed in the human mind (including observations or evaluations or judgments) or (3) using pen and paper as a physical aid and additionally or alternatively as “Mathematical Concepts” which pertains to (4) mathematical relationships.
Dependent Claims 5-6, 9-12 and 14-18 further narrow the abstract ideas, and are therefore still ineligible for the reasons previously provided in Steps 2A Prong 2 and 2B for Independent Claim 1.
Dependent Claims 2-4: With respect to reliance on (e.g., “machine learning” (see Claim 2) & “natural language processing (NLP)” (see Claims 2-3) & “large language model (LLM)” (see Claim 3) & “LLM prompt” (see Claims 3-4)) as additional elements shown in Dependent Claims 2-4 when considered individually and as an ordered combination (as a whole) in view of these claim limitations, these additional elements do not provide limitations that are indicative of integration into a practical application under step 2a prong 2 and also do not recite additional elements that amount to significantly more than the recited judicial exceptions under step 2B due to: the claims as a whole are limited to a particular field of use or technological environment for automated query classification and response mapping using natural language processing using a computer in the field of identifying a workflow in a business management environment (see MPEP § 2106.05(h)) or (2) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)). Claim 2: The claim still fails. Limiting the classification step to an "NLP model" does not remove the fundamental abstract concept of classifying/routing support queries. Classifying text using an NLP model is still categorized under the abstract idea of mental processes or mathematical concepts. Claim 2 lacks an inventive concept. An NLP model is a generic, conventional mathematical tool for processing text. The addition of a conventional machine learning model, applied in its intended field without any specifically claimed improvement to the technology of the model itself, fails to provide an inventive concept. Claim 3: The claim is still directed to an abstract idea. Using a Large Language Model and formulating prompts is merely a highly advanced, modern mechanism for performing the same abstract classification and routing function as previous claims. Claim 3 lacks an inventive concept. Using an LLM to generate text or classifications is considered the use of a generic, conventional tool. Because the claim does not recite a new, non-conventional way of training or building the LLM itself, but simply uses an off-the-shelf LLM to perform the abstract task of query classification, it lacks an inventive concept. Claim 4: The claim remains directed to the abstract idea of processing a query to determine an output/action. Using a "zero-shot prompt" (which allows the LLM to make predictions on categories it hasn’t been explicitly trained on) is fundamentally just a method of organizing human activity and a mathematical/statistical concept. The claim lacks an inventive concept. A zero-shot prompt is an industry-standard method of operating an LLM. Using a known machine learning technique to perform the exact same abstract categorization goal without claiming any specific structural innovation to the prompt, the model, or the computing hardware, provides no inventive concept beyond applying a well-known AI technique to a generalized business method.
Dependent Claims 7-8 and 13: With respect to reliance on (e.g., “audio input” (see Claim 7) & “automatically” (see Claims 8 and 13)) as additional elements shown in Dependent Claims 2-4 when considered individually and as an ordered combination (as a whole) in view of these claim limitations, these additional elements do not provide limitations that are indicative of integration into a practical application under step 2a prong 2 and also do not recite additional elements that amount to significantly more than the recited judicial exceptions under step 2B due to: the claims as a whole are limited to a particular field of use or technological environment for automated query classification and response mapping using a computer in the field of identifying a workflow in a business management environment (see MPEP § 2106.05(h)) or (2) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)). Claim 7: Does it integrate the exception? No. This claim limitation describes data gathering or input selection—a conventional task. Merely stating that data is based on an "audio input" does not tie the abstract idea to a specific, technical implementation (e.g., a proprietary hardware microphone design or specialized acoustic noise-cancellation algorithm). Claim 7: Does it add "significantly more"? No. The step of basing input data on an audio signal amounts to "insignificant extra-solution activity". It only specifies the source of the data rather than providing a new way to process or use it. Thus, the claim as a whole lack an inventive concept. Claim 8: Does it integrate the exception? No. Directing a computer to "automatically perform" actions in a workflow is a restatement of the abstract idea itself (the automation of tasks). There are no specific mechanisms, technical rules, or structural transformations tying the workflow execution to an improvement in computer functionality (such as memory management, processing speed, or GUI interaction). Claim 8: Does it add "significantly more"? No. The recitation of "executing... a workflow" and "automatically performing... actions" uses generic, off-the-shelf computer terminology (like "a computer-implemented method") without reciting specific, non-routine technology to accomplish the automation. Claim 13: Does it integrate the exception? No. This claim merely broadens the automation of the workflow action in Claim 8 to all workflow actions. Executing a series of pre-programmed tasks sequentially or automatically is universally recognized as a basic organizational concept. It is implemented on a generic computer, meaning it does not recite a specific technical solution to a concrete problem. Claim 13: Does it add "significantly more"? No. Expanding automation to "all" workflow actions does not transform the abstract idea into a patent-eligible application. It utilizes generic computer capabilities (storing and executing instructions) to perform well-known business/organizational tasks without an inventive concept in the hardware or software design itself.
Dependent Claims 19-20: With respect to reliance on (e.g., “processing unit” & “communication interface” & “non-transitory computer-readable storage medium”) as additional elements shown in Dependent Claims 19-20 when considered individually and as an ordered combination (as a whole) in view of these claim limitations, these additional elements do not provide limitations that are indicative of integration into a practical application under step 2a prong 2 and also do not recite additional elements that amount to significantly more than the recited judicial exceptions under step 2B due to: the claims as a whole are limited to a particular field of use or technological environment for automated query classification and response mapping using a computer in the field of identifying a workflow in a business management environment (see MPEP § 2106.05(h)) or (2) reciting mere instructions to implement an abstract idea on a computer or using a computer as a tool to “apply” the recited judicial exceptions (see MPEP § 2106.05(f)).
Therefore, the ordered combination of elements in the Dependent Claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself. Therefore, under Step 2B, Claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the recited judicial exceptions. Thus, Claims 1-20 are ineligible with respect to the 35 U.S.C. § 101 analysis.
Claim Rejections - 35 USC § 102
10. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
11. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
12. Claims 1-4, 8-13 and 16-20 are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by US PG Pub (US 2024/0386214 A1) hereinafter Ghoche, et. al.
Regarding Independent Claim 1, Ghoche method for automatically identifying a workflow includes:
- receiving input data defining a support query (see at least Ghoche: ¶ [0069] & ¶ [0123] & ¶ [0193] & ¶ [0200]. Ghoche notes that the customer support application 130 may, for example, be responsible for receiving customer support queries from individual customer user devices. For example, customer service queries may enter an input queue for routing to individual customer support agents. Also, a customer question is received at an input queue in block 402. In block 405, an analysis is performed to determine if a ticket's question can be handled by a ML selection of a template answer. See also Ghoche at ¶ [0193]: Empathy customization may include, as inputs, the template answer, the customer question, and the detected topic. These inputs may be provided to a generative model train on empathic conversations and fine tuned to modify an answer to be more empathic in block 3220. Theoretically, other inputs could be provided (e.g., the location of the customer, information on previous interactions with the customer, sentiment/stress metrics based on voice analysis, use of language, or other metrics, etc.). See also Ghoche at ¶ [0200]: An individual customer email may be input by a customer to a webform (or is converted into a webform format) that provides space for the customer to input a longform query. This is unlike chat, which is typically single lines of text and which is input by the user in response to a prompt. An individual email from a customer may include several lines of text, even the equivalent of a long paragraph or paragraphs. For example, a customer requesting a refund could, in some cases, write several sentences into an email webform, even the equivalent of a long-form paragraph or paragraphs.), the input data being in natural language (see at least Ghoche: ¶ [0231-0232] & ¶ [0241] & Figs. 54-55. Ghoche notes that in block 4802 there may be optional training of a large language model to aid an autonomous AI chatbot agent to solve customer service tickets based on a natural language workflow policy. In block 4804, a natural language text input of an admin user is received describing a workflow policy for a particular customer intent. See also Ghoche at Figs. 50-51. See also Ghoche at ¶ [0241] & Fig. 55: “In block 5510, a large language model is used to infer a natural language workflow to answer a question for a particular topic/intent/issue.”).
- processing the input data to generate a classifier input for a classifier based on the input data (see at least Ghoche: ¶ [0076-0077]. Ghoche teaches that classifiers may be created to predict outcomes based on a feature dataset extracted from incoming tickets. For example, ML/AI techniques may be used to, for example, create a classifier 235 to classify incoming tickets into classes of questions that can be reliably mapped to a pre-approved answer. ML/AI techniques may be used to classify 240 tickets for routing to agents, including identifying a class of incoming tickets having a high likelihood of escalation. See Fig. 2B of Ghoche noting “classifiers 280”.), wherein the classifier is a trained machine learning model and wherein the classifier input (see at least Ghoche: ¶ [0131-0133] & ¶ [0138] & Figs. 10-12. Ghoche teaches that the generated dataset may be used to train a ML classifier to infer intent of a new question and select a macro template answer. That is, a ML classifier can be trained based on questions and answers in the tickets to infer (predict) the user's intention and identify template answers to automatically generate a response. See also Ghoche at ¶ [0138] & Fig. 10: “FIG. 10 is a high-level flow chart of a method of training a ML classifier model to identify a category/subcategory of a customer question to perform routing of tickets to agents.) is a prompt including a context setting components and one or more of: an information basis setting component; an output setting component; and an output rule component (see at least Ghoche: ¶ [0200] & ¶ [0213] & ¶ [0228] & ¶ [0233] & ¶ [0242]. Ghoche teaches that an individual customer email may be input by a customer to a webform (or is converted into a webform format) that provides space for the customer to input a longform query. This is unlike chat, which is typically single lines of text and which is input by the user in response to a prompt. An individual email from a customer may include several lines of text, even the equivalent of a long paragraph or paragraphs. For example, a customer requesting a refund could, in some cases, write several sentences into an email webform, even the equivalent of a long-form paragraph or paragraphs. See also Ghoche at ¶ [0213]: As illustrated in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow. See also Ghoche at ¶ [0228]: For example, a guard rail could include guard rail prompts to remind the large language model know it is an AI customer service chatbot, it must respond truthfully to customer questions, it must follow the workflow policy provided, etc. See also Ghoche at ¶ [0233]: Block 4912, the large language model is prompted, where the prompts may include information on the conversation, the workflow policy, and observations regarding the results of previous actions/use of tools. In block 4914, a determination is made of actions and response for the autonomous AI chatbot. See also Ghoche at ¶ [0242]: The output typically has couple of answer clusters per topic, generally 2-3, typically no more than 7, but sometimes 1. These answer clusters represent a percentage of the whole topic, which some of them contributing more than the others.)
- processing, by the classifier, the classifier input to identify a first workflow from a plurality of workflows (see at least Ghoche: ¶ [0092-0095] & Figs. 14-16 & Fig. 19. Ghoche teaches that a support manager may use an identification of a macro ID to configure specific workflows. For example, suppose that classification of an incoming question returns a macro ID for a refund (a refund macro). In this example, a workflow manager may include a confirmation email to confirm that a customer desires a refund. Or as another example, a macro may automatically generate a customer satisfaction survey to help identify why a refund was requested. More generally, a support manager may support a configurable set of options in response to receiving a macro ID. For example, in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc. See also Ghoche at [0095]: “Another way is to perform a form of classification on top of historical tickets to look for answers that contain links to knowledge articles. That is, a knowledge article link can be identified that corresponds to an answer for a question. In effect, an additional form of supervised learning is performed in which there is a data set with questions and corresponding answers with links to a knowledge article. This is a data set that can be used to train a classifier. Thus, in response to an incoming question, a knowledge article that's responsive to the question is identified.”), wherein the first workflow defines one or more workflow actions which can be executed in response to the support query (see at least Ghoche: ¶ [0137] & ¶ [0147] & ¶ [0197] & Fig. 9. Ghoche teaches that a macro code may correspond to a code for generating template text about a refund policy or a confirmation that a refund will be made. In this case, the template answer may be to provide details on requesting a refund or providing a response that refund will be granted. In some implementations, a workflow task building module 915 may use the macro code to trigger a workflow action, such as issuing a customer survey to solicit customer feedback, scheduling follow-up workflow actions, such as scheduling a refund, follow-up call, etc. See also Ghoche at ¶ [0147]: “Trends in the performance metrics of different topics may provide actionable clues and suggest actions. For example, a topic indicating a particular problem with a product release may emerge after the product release and an increase in the percentage or volume of such ticket may generate a customer support issue for which an action step could be performed, such as alerting product teams, training human agents on how to handle such tickets, generating recommended answers for agents, or automating responses to such tickets.” See also Ghoche at Fig. 25: FIG. 25 illustrates a UI having an actions section to build a custom workflow for solve, customizing triage, and generating suggested answers for assist. See also Ghoche at ¶ [0197] & Fig. 36: FIG. 36 illustrates a UI displaying suggested actions for the topic “cannot make payment.” Example actions in this example include ZendeskHandoff, Start ZendeskChat, hyperlinkRedirect, and SFDCaccessToken. That is, an administrator can be provided with options to create workflow steps for a particular topic. See also Ghoche at ¶ [0212-0213].)
Regarding Dependent Claim 2, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the trained machine learning model is a natural language processing (NLP) model (see at least Ghoche: ¶ [0072] & ¶ [0088] & ¶ [0139]. Ghoche teaches that a trained model may be based on BERT, XLNet (a BERT-like model), or other transformer-based machine learning techniques for natural language processing pre-training. See also Ghoche at ¶ [0072]: The AI augmented customer service module 140 may, for example, have individual AI/ML training modules, trained models and classifiers, and customer service analytical modules. The AI augmented customer service module 140 may, for example, use natural language understanding (NLU) to aid in interpreting customer issues in tickets.)
Regarding Dependent Claim 3, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1-2 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the natural language processing model (see at least Ghoche: ¶ [0072] & ¶ [0088] & ¶ [0139]. Ghoche teaches that a trained model may be based on BERT, XLNet (a BERT-like model), or other transformer-based machine learning techniques for natural language processing pre-training. See also Ghoche at ¶ [0072]: The AI augmented customer service module 140 may, for example, have individual AI/ML training modules, trained models and classifiers, and customer service analytical modules. The AI augmented customer service module 140 may, for example, use natural language understanding (NLU) to aid in interpreting customer issues in tickets.) is a large language model (LLM) and the classifier input is an LLM prompt (see at least Ghoche: ¶ [0213] & Figs. 14-16 & Fig. 19 & Fig. 40. Ghoche teaches that as illustrated in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow. See also Ghoche at ¶ [0146]: Implementation the discovery module includes a trained granular taxonomy classifier 1405. A classifier training engine 1410 may be provided to train/retrain the granular taxonomy classifier. In some implementations, the granular taxonomy classifier 1405 is frequently retrained to aid in identifying new emerging customer support issues. For example, the retraining could be done on a quarterly basis, a monthly basis, a weekly basis, a daily basis, or even on demand.)
Regarding Dependent Claim 4, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1-3 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the LLM prompt is a zero-shot prompt (see at least Ghoche: ¶ [0208-0213]. Ghoche teaches that a data set is built for zero-shot relation extraction. As an example, given a slot name and some context (e.g., for purchasing/changing tickets a ticket subject and description), a zero-shot extraction technique may extract an appropriate fill for that slot name. See also Ghoche at Figs. 14-16 & Fig. 19 & Fig. 40.).
Regarding Dependent Claim 8, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- further including executing the first workflow, wherein executing the first workflow includes automatically performing a first workflow action (see at least Ghoche: Fig. 9 & ¶ [0137] & ¶ [0147]. Ghoche teaches that a macro code may correspond to a code for generating template text about a refund policy or a confirmation that a refund will be made. In this case, the template answer may be to provide details on requesting a refund or providing a response that refund will be granted. In some implementations, a workflow task building module 915 may use the macro code to trigger a workflow action, such as issuing a customer survey to solicit customer feedback, scheduling follow-up workflow actions, such as scheduling a refund, follow-up call, etc. See also Ghoche at ¶ [0147]: “Trends in the performance metrics of different topics may provide actionable clues and suggest actions. For example, a topic indicating a particular problem with a product release may emerge after the product release and an increase in the percentage or volume of such ticket may generate a customer support issue for which an action step could be performed, such as alerting product teams, training human agents on how to handle such tickets, generating recommended answers for agents, or automating responses to such tickets.” See also Ghoche at Fig. 25.).
Regarding Dependent Claim 9, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1 and 8 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein executing the first workflow (see at least Ghoche: Fig. 9 & ¶ [0137] & ¶ [0147]. Ghoche teaches that a macro code may correspond to a code for generating template text about a refund policy or a confirmation that a refund will be made. In this case, the template answer may be to provide details on requesting a refund or providing a response that refund will be granted. In some implementations, a workflow task building module 915 may use the macro code to trigger a workflow action, such as issuing a customer survey to solicit customer feedback, scheduling follow-up workflow actions, such as scheduling a refund, follow-up call, etc. See also Ghoche at ¶ [0147]: “Trends in the performance metrics of different topics may provide actionable clues and suggest actions. For example, a topic indicating a particular problem with a product release may emerge after the product release and an increase in the percentage or volume of such ticket may generate a customer support issue for which an action step could be performed, such as alerting product teams, training human agents on how to handle such tickets, generating recommended answers for agents, or automating responses to such tickets.” See also Ghoche at Fig. 25.) includes:
- requesting first information from a user (see at least Ghoche: ¶ [0092] & ¶ [0137] & ¶ [0142] & ¶ [0188]. Ghoche teaches that a macro may automatically generate a customer satisfaction survey to help identify why a refund was requested. More generally, a support manager may support a configurable set of options in response to receiving a macro ID. For example, in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc. See also Ghoche at ¶ [0137], ¶ [0142], ¶ [0188] & Fig. 24: “FIG. 24 illustrates a UI showing metrics for a particular topic (e.g., “requesting refund”). Information on example tickets for particular topics may also be displayed.”.)
- receiving the first information from the user (see at least Ghoche: ¶ [0137] & ¶ [0142] & ¶ [0193-0195] & ¶ [0215]. Ghoche teaches that an example of an intent is a refund request, or a reset password request, or a very granular intent such as a very specific customer question. These intents can be defined by the support admin/manager, who also configures the steps that the Solve module should perform to handle each intent. The group of steps that handle a specific intent are called a workflow. When a customer query comes in, determine with a high degree of accuracy which intent (if any) this query corresponds to, and if there is one, triggers the corresponding workflow (i.e., a sequence of steps). See also Ghoche at ¶ [0123]: A customer question is received at an input queue in block 402. In block 405, an analysis is performed to determine if a ticket's question can be handled by a ML selection of a template answer. See also Ghoche at ¶ [0193]: “Theoretically, other inputs could be provided (e.g., the location of the customer, information on previous interactions with the customer, sentiment/stress metrics based on voice analysis, use of language, or other metrics, etc.). In block 3225 an empathic answer is provided to the customer that includes the substantive portion of the template answer and that has associated with the corresponding workflow.” See also Ghoche at ¶ [0215]: “The method may include other steps to resolve the issues in the ticket, such as issuing API calls, notifying the client various actions have been completed (e.g., a refund has been issued to and you will receive an email verifying the refund) and confirming with the client that all of their issues have been resolved in block 4120.”);
- performing a second workflow action based on the first information (see at least Ghoche: ¶ [0137] & ¶ [0142] & ¶ [0147] & ¶ [0198-0199]. Ghoche teaches that some customer emails are simple information requests that can be addressed once the intent of the customer's email is determined and their intent is verified. However, customers sometimes have issues in their query that require implementing a workflow to resolve their concerns, such as issuing a refund, cancelling an order, changing a reservation time, etc. See also Ghoche at ¶ [0137]: A macro code may correspond to a code for generating template text about a refund policy or a confirmation that a refund will be made. In this case, the template answer may be to provide details on requesting a refund or providing a response that refund will be granted. In some implementations, a workflow task building module 915 may use the macro code to trigger a workflow action, such as issuing a customer survey to solicit customer feedback, scheduling follow-up workflow actions, such as scheduling a refund, follow-up call, etc.)
Regarding Dependent Claim 10, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1 and 8-9 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the user is the user that submitted the user request (see at least Ghoche: ¶ [0003] & ¶ [0092] & ¶ [0142] & ¶ [0211]. Ghoche teaches that to address common support questions, the human agents may have available to them macros and templates in SalesForce® or templates in Zendesk® as examples. Macros and templates work well for generating information to respond to routine requests for information, such as if a customer asks, “Do you offer refunds?” However, there are some types of more complicated or non-routine questions for which there may be no macro or template. See also Ghoche at ¶ [0092]: A macro may automatically generate a customer satisfaction survey to help identify why a refund was requested. More generally, a support manager may support a configurable set of options in response to receiving a macro ID. For example, in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc. See also Ghoche at ¶ [0142]: A support manager may configure specific workflows. A support manager can configure workflows in Solve, where each workflow corresponds to a custom “intent.” An example of an intent is a refund request, or a reset password request, or a very granular intent such as a very specific customer question. These intents can be defined by the support admin/manager, who also configures the steps that the Solve module should perform to handle each intent. See also Ghoche at ¶ [0211]: For examples, suppose a customer sends a long and rambling email about changing their flight. The abstractive summarizer may summarize that to “Need to Change Airline Tickets”, the topic may be identified, and a workflow triggered for changing airline tickets with airlines. The handoff to the AI chat widget may ask the customer to confirm the customer wants to change their tickets.)
Regarding Dependent Claim 11, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1 and 8-9 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the user is a support technician (see at least Ghoche: ¶ [0069] & ¶ [0104-0105] & ¶ [0108]. Ghoche teaches that the customer support application 130 may, for example, be responsible for receiving customer support queries from individual customer user devices. For example, customer service queries may enter an input queue for routing to individual customer support agents. This may, for example, be implemented using a ticketing paradigm in which a ticket dealing with a customer support issue has at least one question, leading to at least one answer being generated in response during the lifecycle of a ticket. See also Ghoche at ¶ [0104-0105]: The ML model can also be trained to make predictions of escalation, where escalation is the process of passing on tickets from a support agent to more experienced and knowledgeable personnel in the company, such as managers and supervisors, to resolve issues of customers that the previous agent failed to address. See also Ghoche at ¶ [0108]: An answer from a past ticket is identified as a recommended answer to a new incoming ticket so that the support agent can use all or part of the recommended answer and/or revise the recommended answer. A one-click answer functionality is supported for an agent to select a recommended answer. See also Ghoche at ¶ [0143]: This typically results in a modest number of categories/categories, often no more than 15. Manually selecting more than about 20 categories also raises challenges training support agents to recognize and accurately label every incoming ticket.).
Regarding Dependent Claim 12, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1, 8-9 and 11 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein executing the first workflow includes causing a visual representation of the first workflow to be displayed to the support technician (see at least Ghoche: ¶ [0119] & ¶ [0141] & Figs. 21-25. Ghoche teaches that the analytics module may support a variety of analytical functions to look at data, filter data, and track performance. This may include generating visualizations on the data, such as metrics about tickets automatically solved, agents given assistance, triage routing performed, etc. Analytics helps to provide an insight into how the ML is helping to service tickets. See also Ghoche at ¶ [0141] & Fig. 13: Ghoche teaches in Fig. 13 that intent workflows are illustrated for order status, modify or cancer order, contact support, petal signature, question, and question about fabric printing. But more generally, custom intent workflows may be defined using the workflow builder, which is an extension of the Solve module. See also Ghoche depicting the “visual representation of first workflow” shown in Figs. 21-25.)
Regarding Dependent Claim 13, Ghoche method for automatically identifying a workflow teaches the limitations of Claims 1 and 8 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein executing the first workflow includes automatically performing all of the workflow actions (see at least Ghoche: ¶ [0073-0074] & ¶ [0137] & ¶ [0219-0225]. Ghoche teaches that the AI augmented customer support module 140 may support one or more functions, such as 1) automatically solving at least a portion of routine customer service support questions; 2) aiding in automatically routing customer service tickets to individual agents, which may include performing a form of triage in which customer tickets in danger of escalation are identified for special service (e.g., to a manager or someone with training in handling escalations). See also Ghoche at ¶ [0137]: Workflow task building module 915 may use the macro code to trigger a workflow action, such as issuing a customer survey to solicit customer feedback, scheduling follow-up workflow actions, such as scheduling a refund, follow-up call, etc. See also Ghoche at ¶ [0204]: A workflow response is identified and triggered based on intent. As previously discussed, a variety of tools may be included to aid administrators to build workflows to resolve customer tickets. This may include, for example, generating recommendations to automate resolving certain types of customer tickets and tools to aid in designing workflows. For example, if the customer's intent was to obtain a refund, then a refund workflow response may be selected. As another example, if the workflow response deals with changing travel tickets, the workflow response for changing travel tickets may be initiated. See also Ghoche at ¶ [0211], ¶ [0215], ¶ [0219], ¶ [0223]. “A workflow policy and available tools are selected. Thus, for example, if a customer's ticket/text message indicated that their intent is to cancel an order, the workflow for “cancel order” is triggered, a workflow policy and available tools for “cancel order” is accessed, and autonomous AI chatbot 4704 and large language model 4706 interact to implement the cancel order workflow.”.)
Regarding Dependent Claim 16, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the classifier input (see at least Ghoche: Figs. 14-16 & Fig. 19.) includes a plurality of descriptors each corresponding to one of the plurality of workflows (see at least Ghoche: Fig. 13 & Figs. 39-40 & ¶ [0203-0204]. Ghoche notes that the intent detection may include identifying which topics in the topic taxonomy the abstract most closely corresponds to. For example, “unable to run payroll” might in some cases map to a discovered topic corresponding to “payroll problem.” As previously discussed, the overall system may generate a granular taxonomy of discovered topics. In one implementation, the solve module has access to a classifier trained to identify a granular taxonomy of issues customers are concerned about. The granular taxonomy of topics may correspond, for example, to that previously described technique for the discovery of a granular taxonomy of topics based on an analysis of tickets in FIGS. 16, 17, and 18 , That is, the solve module may leverage off of the granular taxonomy of topics. However, in theory the solve module could employ a variation of the previously described techniques to generate a granular taxonomy of topics.)
Regarding Dependent Claim 17, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the classifier (see at least Ghoche: Figs. 14-16 & Fig. 19.) identifies the first workflow by returning a descriptor associated with the first workflow (see at least Ghoche: ¶ [0243-0245] & ¶ [0247] & ¶ [0250-0258]. Ghoche notes considering an issue about “returning an item.” In this example, it might be the case that there are two large clusters of answers corresponding to the following: 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” 2—essentially telling the customer “sorry, since you purchased this item longer than 30 days ago, you cannot return it anymore”. See also Ghoche at ¶ [0247]: The workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz. Otherwise, apologize because it's been longer than 30 days.” See also Ghoche at ¶ [0250-0258].)
Regarding Dependent Claim 18, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- wherein the classifier (see at least Ghoche: Figs. 14-16 & Fig. 19.) identifies the first workflow by returning an identifier associated with the first workflow (see at least Ghoche: ¶ [0092] & [0204] & Fig. 39. Ghoche teaches that a support manager may use an identification of a macro ID to configure specific workflows. For example, suppose that classification of an incoming question returns a macro ID for a refund (a refund macro). In this example, a workflow manager may include a confirmation email to confirm that a customer desires a refund. Or as another example, a macro may automatically generate a customer satisfaction survey to help identify why a refund was requested. More generally, a support manager may support a configurable set of options in response to receiving a macro ID. For example, in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc. See also Ghoche at ¶ [0204]: “A workflow response is identified and triggered based on intent. As previously discussed, a variety of tools may be included to aid administrators to build workflows to resolve customer tickets. This may include, for example, generating recommendations to automate resolving certain types of customer tickets and tools to aid in designing workflows. For example, if the customer's intent was to obtain a refund, then a refund workflow response may be selected. As another example, if the workflow response deals with changing travel tickets, the workflow response for changing travel tickets may be initiated.”).
Regarding Dependent Claim 19, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- a computer processing system including (see at least Ghoche: Fig. 2B & ¶ [0078] & ¶ [0263]. Ghoche teaches processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.);
- a processing unit (see at least Ghoche: Fig. 2B & ¶ [0078]. Ghoche teaches a processor 262 shown in Fig. 2B.);
- a communication interface (see at least Ghoche: Fig. 2B & ¶ [0078] & ¶ [0269]. Ghoche teaches a network adapter, graphics adapter 268, and display 270 may be communicatively coupled by a communication bus. See also Ghoche at ¶ [0269] noting “network adapters”.);
- a non-transitory computer-readable storage medium storing instructions (see at least Ghoche: Fig. 2B & ¶ [0078] & ¶ [0266]. Ghoche teaches that a computer program product accessible from a non-transitory computer-usable or computer-readable medium providing program code for use by, or in connection with, a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.), which when executed by the processing unit (see at least Ghoche: Fig. 2B & ¶ [0078]. Ghoche teaches a processor 262 shown in Fig. 2B.), cause the processing unit to perform a method according to claim 1 (see at least Ghoche details mapped for Independent Claim 1 above.)
Regarding Dependent Claim 20, Ghoche method for automatically identifying a workflow teaches the limitations of Independent Claim 1 above, and Ghoche further teaches the method for automatically identifying a workflow comprising:
- a non-transitory storage medium storing instructions (see at least Ghoche: Fig. 2B & ¶ [0078] & ¶ [0266]. Ghoche teaches that a computer program product accessible from a non-transitory computer-usable or computer-readable medium providing program code for use by, or in connection with, a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.) executable by processing unit to cause the processing unit (see at least Ghoche: Fig. 2B & ¶ [0078]. Ghoche teaches a processor 262 shown in Fig. 2B.) to perform a method according to claim 1 (see at least Ghoche details mapped for Independent Claim 1 above.)
Claim Rejections - 35 USC § 103
13. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
14. 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.
15. Claims 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub (US 2024/0386214 A1) hereinafter Ghoche, et. al., and in view of US PG Pub (US 2025/0328914 A1) hereinafter Opedal, et. al.
Regarding Dependent Claim 5, Ghoche method for automatically identifying a workflow does not explicitly disclose, but Opedal in the analogous art for automatically identifying a workflow does disclose the following:
- wherein the input data is an input string (see at least Opedal: ¶ [0032]. Opedal teaches that the processing unit 204 uses natural language processing (NPL) to extract natural language from the communication. For example, when the communication is in an oral form, the processing unit 204 uses NPL to convert the oral communication into a written form (e.g., as a string of text). The processing unit 204 is configured to process the communication to create an embedding vector that includes a numerical representation of the natural language extracted from the communication.)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have combined / modified the teachings of Ghoche method for automatically identifying a workflow with the aforementioned teachings of: wherein the input data is an input string, and in view of Opedal, in order to improve the accuracy and efficiency of communications during customer service sessions. Specifically, the disclosed methods and systems are directed to identifying customer's intent for reaching out to a company or an organization. The intent can include the type of problem the customer is trying to solve, a type of information the customer needs, or a type of service the customer would likely benefit from. The intent can be identified by using artificial intelligence-based models that classify a communication session to an intent classification based on the natural language expressed during a current and/or historical communication session. In particular, the present technology can classify the intent in real time such that the customer's intent is identified while the customer is interacting with a customer service representative or a chatbot and the intent can be used to assist the customer during the interaction (see at least Opedal: ¶ [0011]).
Further, the claimed invention is merely a combination of old elements in a similar field for automatically identifying a workflow and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Opedal, the results of the combination were predictable.
Regarding Dependent Claim 6, Ghoche / Opedal method for automatically identifying a workflow teaches the limitations of Claims 1 and 5 above, and Opedal further teaches the method for automatically identifying a workflow comprising:
- wherein the input data is processed to generate the input string (see at least Opedal: ¶ [0032]. Opedal teaches that when the communication is in an oral form, the processing unit 204 uses NPL to convert the oral communication into a written form (e.g., as a string of text). The processing unit 204 is configured to process the communication to create an embedding vector that includes a numerical representation of the natural language extracted from the communication. The processing unit 204 is then configured to compare the embedding vector to multiple embedding vectors, each of which is associated with an intent classification. The multiple embedding vectors can be stored at the vector database 206. For example, the processing unit 204 can retrieve vector data from the vector database 206 that includes the multiple embedding vectors. The processing unit 204 can identify an intent classification for the embedding vector representative of the communication while the communication session between the customer and the customer service representative and/or chatbot is ongoing (e.g., in real time or near real time).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have combined / modified the teachings of Ghoche / Opedal method for automatically identifying a workflow with the aforementioned teachings of: wherein the input data is processed to generate the input string, and in further view of Opedal, in order to improve the accuracy and efficiency of communications during customer service sessions. Specifically, the disclosed methods and systems are directed to identifying customer's intent for reaching out to a company or an organization. The intent can include the type of problem the customer is trying to solve, a type of information the customer needs, or a type of service the customer would likely benefit from. The intent can be identified by using artificial intelligence-based models that classify a communication session to an intent classification based on the natural language expressed during a current and/or historical communication session. In particular, the present technology can classify the intent in real time such that the customer's intent is identified while the customer is interacting with a customer service representative or a chatbot and the intent can be used to assist the customer during the interaction (see at least Opedal: ¶ [0011]).
Further, the claimed invention is merely a combination of old elements in a similar field for automatically identifying a workflow and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Opedal, the results of the combination were predictable.
Regarding Dependent Claim 7, Ghoche method for automatically identifying a workflow does not explicitly disclose, but Opedal in the analogous art for automatically identifying a workflow does disclose the following:
- wherein the input data is based on audio input (see at least Opedal: ¶ [0086].)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have combined / modified the teachings of Ghoche method for automatically identifying a workflow with the aforementioned teachings of: wherein the input data is based on an audio input, and in view of Opedal, in order to improve the accuracy and efficiency of communications during customer service sessions. Specifically, the disclosed methods and systems are directed to identifying customer's intent for reaching out to a company or an organization. The intent can include the type of problem the customer is trying to solve, a type of information the customer needs, or a type of service the customer would likely benefit from. The intent can be identified by using artificial intelligence-based models that classify a communication session to an intent classification based on the natural language expressed during a current and/or historical communication session. In particular, the present technology can classify the intent in real time such that the customer's intent is identified while the customer is interacting with a customer service representative or a chatbot and the intent can be used to assist the customer during the interaction (see at least Opedal: ¶ [0011]).
Further, the claimed invention is merely a combination of old elements in a similar field for automatically identifying a workflow and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Opedal, the results of the combination were predictable.
16. Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub (US 2024/0386214 A1) hereinafter Ghoche, et. al., and in view of US PG Pub (US 2025/0005263 A1) hereinafter Mansour, et. al.
Regarding Dependent Claim 14, Ghoche method for automatically identifying a workflow does not explicitly disclose, but Mansour in the analogous art for automatically identifying a workflow does disclose the following:
- wherein processing the input string to generate a support request (see at least Mansour: ¶ [0059-0063] & ¶ [0383]. Mansour teaches that the system may also provide a look-up service that returns project names, user names, and/or, other resources in response to a command character. In one specific example, a designated phrase “/whoowns” is used to initiate the use of a classification model that is adapted to return corresponding user names, teams, or project codes that correspond to an input string following the designated phrase. See also Mansour at ¶ [0062-0063]: “The user input may be in the form of interaction with a graphical user interface affordance (e.g., button or other UI element), or may be in the form of plain text. In some cases, the user input may be provided as typed string input provided to a command prompt triggered by a preceding user input.”), wherein the support request is based on the input string (see at least Mansour: ¶ [0078-0080].) and additional query data, and the classifier input is based on the support request (see at least Mansour: ¶ [0339] & ¶ [0371] & Figs. 31B-31C. Mansour teaches that the system generates the series of suggested questions or proposed queries 3120 regardless of the completeness score such that the user can review additional questions even when the initial request may be predicted to be sufficiently complete to obtain a successful resolution. Also, in some implementations, the completeness score may be computed but not displayed to the user. See also Mansour at ¶ [0317-0319]: The window 1520 also includes an entry type or word classifier 1523, which indicates whether the word is a “project,” “service,” “team,” “epic,” “initiative,” or other item managed by the directory platform, other type of platform, or used within an organization in accordance with the word classifier 1523. In some cases, the word classifier 1523 is also selectable to cause display of other uses of that word in the platform or organization in a similar context. See also Mansour at ¶ [0339]: The prompt may include an extracted portion of the structured query 2232 and additional context provided from the query 2232 or the current session. The explanations 2242 are prepared in advance and stored for recall in response to a user request. See also Mansour at Figs. 31A-31E: Initial user-generated request message including a natural language user input provided to a chat interface of a messaging platform and generative responses provided via the messaging platform.).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have combined / modified the teachings of Ghoche method for automatically identifying a workflow with the aforementioned teachings of: wherein processing the input string to generate a support request, wherein the support request is based on the input string and additional query data, and the classifier input is based on the support request, and in view of Mansour, in order for the analysis module may determine an intent metric for a given natural language user input. The intent metric may be determined using a semantic analysis of the user input and may indicate a conformity or a correlation of a natural language user input with respect to a request type of multiple request types handled by a particular automated chat service. For example, the automated chat service may be adapted to handle a predefined number of request types using a deterministic or predefined chat sequence that is designed to handle a particular type of issue or technical problem. For each request type, the system may define or obtain a classifying feature set or exemplar request (or set of requests) that can be used to determine a correlation between a particular natural language user input and a request type (see at least Mansour: ¶ [0359]).
Further, the claimed invention is merely a combination of old elements in a similar field for automatically identifying a workflow and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Mansour, the results of the combination were predictable.
Regarding Dependent Claim 15, Ghoche / Mansour method for automatically identifying a workflow teaches the limitations of Claims 1 and 14 above, and Mansour further teaches the method for automatically identifying a workflow comprising:
- wherein the additional query data includes one or more of: user identification data; and context data (see at least Mansour: ¶ [0065] & ¶ [0099] & ¶ [0339]. Mansour teaches that FIG. 22 , in response to a user input provided to a portion 2234 of a structured query 2232 displayed in a query region 2230, an explanation 2242 of a function or operation of the respective portion 2232 may be displayed in a window 2240. The user input may be a user selection input, a hover input, or a selection of an assistance control 2210. The explanation 2242 may be generated in response to a prompt provided to the generative output engine. The prompt may include an extracted portion of the structured query 2232 and additional context provided from the query 2232 or the current session. The explanations 2242 are prepared in advance and stored for recall in response to a user request. See also Mansour at Fig. 22.).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have combined / modified the teachings of Ghoche / Mansour method for automatically identifying a workflow with the aforementioned teachings of: wherein the additional query data includes one or more of: user identification data; and context data, and in further view of Mansour, in order for the analysis module may determine an intent metric for a given natural language user input. The intent metric may be determined using a semantic analysis of the user input and may indicate a conformity or a correlation of a natural language user input with respect to a request type of multiple request types handled by a particular automated chat service. For example, the automated chat service may be adapted to handle a predefined number of request types using a deterministic or predefined chat sequence that is designed to handle a particular type of issue or technical problem. For each request type, the system may define or obtain a classifying feature set or exemplar request (or set of requests) that can be used to determine a correlation between a particular natural language user input and a request type (see at least Mansour: ¶ [0359]).
Further, the claimed invention is merely a combination of old elements in a similar field for automatically identifying a workflow and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Mansour, the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Foreign Patent Documents
WO 2024/168300 A1 – “System and Method of Using Generative AI for Customer Support”, hereinafter Ghoche, et. al. Ghoche at ¶ [abstract] teaches a computer-implemented method is disclosed for using generative Al for customer support. An Al model may be fine-tuned on the task of generating a template workflow answer given a prompt of real answers.
WO 2025/010233 A2 – “System and Method of Automatically Generating a Natural Language Workflow Policy for a Workflow for Customer Support of Emails”, hereinafter Ghoche, et. al. Ghoche at ¶ [abstract] teaches a natural language workflow policy is generated for a workflow to solve customer support tickets is automatically generated from representative tickets. Tools, such as API calls, may also be automatically generated from representative tickets. The generated workflows may be used by a large language model to generate answers for customer questions for an autonomous Al chatbot agent.
NPL Documents
Liu, Yuchi, et al. "Towards hierarchical multi-agent workflows for zero-shot prompt optimization." arXiv preprint arXiv:2405.20252 (2024). Liu, et. al. teaches in ¶ [abstract] a hierarchy of LLMs, first constructing a prompt with precise instructions and accurate wording in a hierarchical manner, and then using this prompt to generate the final answer to the user query. We term this pipeline Hierarchical Multi-Agent Workflow, or HMAW. In contrast with prior works, HMAW imposes no human restriction and requires no training, and is completely task-agnostic while capable of adjusting to the nuances of the underlying task.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DERICK HOLZMACHER whose telephone number is (571) 270-7853. The examiner can normally be reached on Monday-Friday 9:00 AM – 6:30 PM EST.
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, Brian Epstein can be reached on 571-270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-270-8853.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DERICK J HOLZMACHER/Patent Examiner, Art Unit 3625A
/BRIAN M EPSTEIN/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights