Prosecution Insights
Last updated: May 29, 2026
Application No. 18/893,857

SYSTEM AND METHOD FOR PROVIDING ORDER SUPPORT ASSISTANCE

Non-Final OA §101§103§112
Filed
Sep 23, 2024
Priority
Sep 25, 2023 — SG 10202302709T
Examiner
GOODMAN, MATTHEW PARKER
Art Unit
3628
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Shopee Ip Singapore Private Limited
OA Round
1 (Non-Final)
21%
Grant Probability
At Risk
1-2
OA Rounds
1y 2m
Est. Remaining
50%
With Interview

Examiner Intelligence

Grants only 21% of cases
21%
Career Allowance Rate
16 granted / 75 resolved
-30.7% vs TC avg
Strong +28% interview lift
Without
With
+28.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 10m
Avg Prosecution
16 currently pending
Career history
101
Total Applications
across all art units

Statute-Specific Performance

§101
15.6%
-24.4% vs TC avg
§103
75.6%
+35.6% vs TC avg
§102
8.0%
-32.0% vs TC avg
§112
0.8%
-39.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 75 resolved cases

Office Action

§101 §103 §112
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 . Priority Acknowledgment is made of applicant’s claim for Foreign Priority to SG10202302709T, originally filed 09/25/2023. The certified copy of the parent application has been filed with the USPTO on 10/22/2024. Claim Interpretation Claim 1 recites “receiving a request for assistance corresponding to a customer account of a customer, the customer account being associated with at least one order, . . . predicting with a prediction engine implementing a machine learning model, whether the request for assistance relates to the at least one order, . . . in response to predicting that the request for assistance relates to the at least one order, determining with the prediction engine, an intended order from the at least one order, wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance; . . .” (Emphasis added) at the second through fourth paragraphs. Because the request, definitionally, corresponds to a “customer account,” which is associated with “at least one order” the scope of “predicting . . . whether the request for assistance relates to the at least one order,” in situations where “the at least one order” associated with the “customer account” is two or more orders, is interpreted as analogous to “predicting . . . whether the request for assistance relates to each of the at least one order,” distinguishing from interpreting the limitation as analogous to “predicting . . . whether or not the request for assistance relates to the group of the at least one order.” This interpretation is in line with the subsequent limitations. Additionally, the limitation of “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance” (emphasis added) is being similar to “wherein the intended order represents a single order of the at least one order with a highest probability of being related to the purpose for having initiated the request for assistance.” This limitation is not interpreted as predicting the probabilities that the order initiated (i.e. created, submitted, or transmitted) the received request for assistance itself. The interpretation of Claim 1 discussed above extends to dependent Claims 2-18, and the similar limitations of independent Claims 19-20. 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. Claims 6-9 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. Claim 6 recites the limitation "The method of claim 2, further comprising the steps of: ranking the at least one order based on the score of the at least one order; and determining with the prediction engine, at least one other order from the at least one order, wherein the at least one other order has an inferior score compared to the intended order.” The plain meaning of the “at least one order” includes “one order” or “two (or more) orders.” However, the “ranking” and identification of “at least one other order” indicates that the scope of “the at least one order” is limited to two or more orders. Alternatively, these limitations could be conditioned on situations when “the at least one order” is two or more orders (i.e. enabling the ranking and identification of another order), but not intended to limit the scope of “the at least one order.” The scope of this limitation is unclear, and therefore indefinite, because there are multiple interpretations as to the scope of the claim. Thus, Claim 6 is rejected under 35 U.S.C. 112(b). In support of compact prosecution, and solely for examination purposes herein, further examination herein will interpret this claim as limiting “the at least one order” to two or more orders. Claims 7-9 are rejected via dependency. 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 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-18 recite a method (i.e. a process), Claim 19 recites a system (i.e. a machine or manufacture), and Claim 20 recites non-transitory computer storage media (i.e. a machine or manufacture). Therefore, Claims 1-20 all fall within the one of the four statutory categories of invention of 35 U.S.C. 101. Step 2A, Prong One Independent Claim 1 recites the abstract idea of: “. . . receiving a request for assistance corresponding to a customer account of a customer, the customer account being associated with at least one order, wherein the customer account comprises customer account information, and wherein the at least one order comprises order attributes; predicting [by] implementing a . . . model, whether the request for assistance relates to the at least one order, wherein the predicting is based on one of, or both of, the customer account information and the order attributes of the at least one order; in response to predicting that the request for assistance relates to the at least one order, determining . . . , an intended order from the at least one order, wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance; and causing the intended order to be displayed . . . .” The limitations stated above are processes/ functions that under broadest reasonable interpretation covers (1) receiving an assistance request corresponding to a customer account, which is associated with an order, order attributes, and customer information, (2) implementing a model to predict if the request relates to the order based on certain customer information, (3) determine the intended order based on the predicted highest probability, (4) displaying the intended order, all of which are: mathematical calculations (i.e. calculating probability to predict the order), which are mathematical concepts, an abstract idea, under MPEP 2106.04(a)(2)I, and managing personal behavior or relationships or interaction between people (i.e. providing assistance is at least a “social activity”) and commercial or legal interactions (i.e. customer account information, providing customer assistance, and predicting order related to customer assistance are at least “marketing or sales activities or behaviors” or “business relations”), which are certain methods of organizing human activity, an abstract idea, under MPEP 2106.04(a)(2)II. The mere the recitation of generic computer components (i.e., the “prediction engine,” “machine learning model,” “customer support interface,” and “customer device.”) implementing the identified abstract idea does not take the claim out of the organizing human activity grouping. MPEP 2106.04(d). If a claim limitation, under its broadest reasonable interpretation, covers “managing personal behavior or relationships or interactions between people” and “commercial or legal interactions” but for the recitation of generic computer components, then it falls in the organizing human activity grouping of abstract ideas. MPEP 2106.04. Therefore, Claim 1 recites an abstract idea. Step 2A, Prong Two The judicial exception is not integrated into a practical application. Claim 1 as a whole amounts to: (i) merely invoking generic components as a tool to perform the abstract idea or “apply it” (or an equivalent) and (ii) generally links the use of a judicial exception to a particular technological environment or field of use. The claim recites the additional elements of: (i) prediction engine, (ii) machine learning model, (iii) customer device, and (iv) customer support interface. The additional elements of (i) prediction engine (Fig. 1 and ¶74 shows “The prediction engine 150 can include a program or algorithm such as a machine learning model (e.g. neural network) that performs functions in accordance with the described embodiments.”), (ii) machine learning model (¶74 and ¶87 shows “machine learning model.”), (iii) customer device (Fig. 1 and ¶62 shows “customer device 120.”), and (iv) customer support interface (Fig. 1 and ¶63 shows “The customer support interface 122 represents the graphical user interface (GUI) to be displayed via a display screen on the customer device 120.”), are recited at a high-level of generality, such that, when viewed as whole/ordered combination (Fig. 1, ¶55, and ¶¶72-73 shows elements in combination.), they amount to no more than mere instruction to apply the judicial exception using generic computer components or “apply it” (See MPEP 2106.05(f)). The (i) prediction engine, (ii) machine learning model, (iii) customer device, and (iv) customer support interface, when viewed as whole/ordered combination (Fig. 1, ¶55, and ¶¶72-73 shows elements in combination.), does no more than generally link the use of the judicial exception to a particular technological environment or field of use (i.e. computer environment) (See MPEP 2106.05(h)). Accordingly, these additional elements, when viewed as a whole/ordered combination (Fig. 1, ¶55, and ¶¶72-73 shows elements in combination.), do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, the claim is directed to an abstract idea. Step 2B As discussed above with respect to Step 2A Prong Two, the additional elements amount to no more than: (i) “apply it” (or an equivalent) and (ii) generally link the use of a judicial exception to a particular technological environment or field of use, and are not a practical application of the abstract idea. The same analysis applies here in Step 2B, i.e., (i) merely invoking the generic components as a tool to perform the abstract idea or “apply it” (See MPEP 2106.05(f)) and (ii) generally linking the use of a judicial exception to a particular technological environment or field of use (See MPEP 2106.05(h)), does not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Therefore, the additional elements of the (i) prediction engine, (ii) machine learning model, (iii) customer device, and (iv) customer support interface, do not integrate the abstract idea into a practical application at Step 2A or provide an inventive concept at Step 2B. Thus, even when viewed as a whole/ordered combination (Fig. 1, ¶55, and ¶¶72-73 shows elements in combination.), nothing in the claims adds significantly more (i.e., an inventive concept) to the abstract idea. Thus, the claim is ineligible. Dependent Claims 2-18 recite the abstract idea of: wherein the step of determining the intended order from the at least one order comprises the steps of: calculating a score for each of the at least one order based on the order attributes of the at least one order, the score of the at least one order representing the probability of the at least one order having initiated the request for assistance; and identifying the at least one order with a highest score to be the intended order. (Claim 2) retrieving order attributes of the intended order; determining . . . , one or more prompts based on the order attributes of the intended order; and causing the one or more prompts to be displayed with the intended order . . . . (Claim 3) wherein the step of determining the one or more prompts comprises the steps of: retrieving a set of prompts . . . ; and selecting one or more prompts from the set of prompts according to a predefined rule. (Claim 4) wherein the one or more prompts is to be displayed with the intended order in a . . . session . . . (Claim 5) ranking the at least one order based on the score of the at least one order; and determining with the prediction engine, at least one other order from the at least one order, wherein the at least one other order has an inferior score compared to the intended order. (Claim 6) causing the intended order to be displayed more prominently . . . compared with the at least one other order. (Claim 7) wherein the step of causing the intended order to be displayed more prominently . . . compared with the at least one other order comprises the steps of: causing the intended order to be displayed . . . ; wherein the at least one other order is displayed . . . (Claim 8) wherein the at least one other order is displayed . . . based on the ranking of the at least one order. (Claim 9) receiving an input from the customer which affirms that the request for assistance was related to the intended order; and updating the . . . model . . . (Claim 10) wherein the input from the customer which affirms that the request for assistance was related to the intended order, comprises any one of: a query entered by the customer in the . . . session about the intended order, a customer selection of . . . the intended order, or a customer selection of . . . the one or more prompts. (Claim 11) receiving an input from the customer which affirms that the request for assistance was not related to the intended order; and updating the . . . model . . . (Claim 12) wherein the input from the customer which affirms that the request for assistance was not related to the intended order, comprises any one of: a query entered by the customer in the . . . session relating to an order which is not the intended order, a query entered by the customer in the . . . session that is not related to the intended order, a customer selection of . . . that is not related to the intended order, or the customer terminating the . . . session. (Claim 13) receiving an input from the customer that indicates relevance of the one or more prompts; and updating the . . . model . . . (Claim 14) wherein the input from the customer that indicates relevance of the one or more prompts, comprises a query entered by the customer in the . . . session that is related to the one or more prompts, or a customer selection of . . . the one or more prompts. (Claim 15) receiving an input from the customer that indicates non-relevance of the one or more prompts; and updating the . . . model . . . (Claim 16) wherein the input from the customer that indicates non-relevance of the one or more prompts, comprises any one of: a query entered in the . . . session that is not related to any of the one or more prompts, a customer selection . . . that is not any of the one or more prompts, and the customer terminating the . . . session. (Claim 17) wherein the customer account information comprises customer profile information, customer activity information, historical chat information, or a combination thereof. (Claim 18) Dependent Claims 2-18, have been given the full two-prong analysis including analyzing the further elements and limitations, both individually and in combination. When analyzed individually and in combination, these claims are also held to be patent ineligible under 35 U.S.C. 101. The further limitation of Claims 2-18 fail to establish claims that are not directed to an abstract idea because the further limitations of (1) calculating a probability score to determine the intended order (Claim 2) by ranking the orders (Claim 6), (1.a) displaying the intended order more prominently than an other order (Claim 7-8) based on the ranking (Claim 9), (2) displaying prompts based on the attributes of the intended order, with the intended order (Claims 3 and 5), (2.a) displaying prompts by selecting a prompt from a retrieved set of prompts (Claim 4), (2.b) receiving an affirmation from the customer that the request was, or was not related to the intended order based on certain inputs and updating the prediction model (Claims 10-13), (2.c) receiving an input of the relevance or non-relevance of the prompt based on certain types of inputs and updating the model (Claims 14-17), and (3) customer account information comprises certain information (Claim 18), merely further limit the recited abstract idea. The further elements of Claims 2-18 (i.e. “prediction engine” in Claims 3, 6, 10, 12, 14, and 16, “customer support interface” in Claims 3, 5, 7-8, “database” in Claim 4, “chatbot” in Claims 5, 11, 13, 15, and 17, “first interface” in Claim 8, “second interface” in Claims 8-9, “selectable link” in Claim 8, “machine learning model” in Claims 10, 12, 14, and 16, and “selectable element[s]” in Claim 11, 13, 15, and 17) fails to establish claims that are not directed to an abstract idea because the elements merely recite additional generic computer components similar to the generic computer components of Claim 1 and generally link the abstract idea to a particular technology or field of use (i.e. computer environment) just as in Claim 1. The organization of the further limitations of Claims 2-18 fail to integrate an abstract idea into a practical application just as discussed above for Claim 1. Additionally, performing the abstract idea of Claim 1 as recited in each of the further limitations of Claims 2-18, individually or in combination, does not (1) impose any meaningful limits on practicing the abstract ideas, or (2) provide improvements to the functioning of computing systems or to another technology or technical field, just as discussed above regarding Claim 1. Therefore, Claims 2-18 amount to mere instructions to implement the abstract idea (1) using generic computer components—using the computer, in its ordinary capacity, as a tool to perform the abstract idea, and (2) generally linked to a particular technology or field of use. Because the claims merely use a computer, in its ordinary capacity in a particular field of use, as a tool to perform the abstract idea cannot provide an inventive concept, the elements and limitations of Claims 2-18 fail to establish that the claims provide an inventive concept, just as in Claim 1. Therefore, Claims 2-18 fails the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101. Claims 19-20 recite elements and limitations that are substantially similar to Claim 1. Claims 19-20 recite generic computer components (i.e. “A system comprising one or more computers and one or more storage devices storing computer-readable instructions that, when executed by the one or more computers, cause the one or more computers to perform one or more operations” of Claim 19 and “One or more non-transitory computer storage media storing instructions that, when executed by one or more computers, cause the one or more computers to perform one or more operations” of Claim 20) that embody the method of Claim 1. Therefore, Claims 19-20 are rejected under 35 U.S.C. 101 just as Claim 1 is rejected under 35 U.S.C. 101 as discussed above. Claim Rejections - 35 USC § 103 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 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. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-6 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over US-10554817-B1 (“Sullivan”) in view of US-20180012231-A1 (“Sapoznik”). Regarding Claim 1, Sullivan teaches the “A method of implementing a customer support interface for order support assistance” (Fig. 4 and C24L58-62 shows “FIG. 4 illustrates an example intent constructor 400 processing activity data representing a recorded contact between a customer 410 and an agent 412, which may be a live or automated service agent, on a contact center as described herein.” (Emphasis added). Fig. 1 and C05L07-26 shows “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.”), the method comprising steps for:” “receiving a request for assistance corresponding to a customer account of a customer, the customer account being associated with at least one order, wherein the customer account comprises customer account information” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a request for assistance. Fig. 4 and C25L21-37 shows “The user data parser 406 may be configured to detect data returned to the contact center from one or more user data stores 414 in response to agent 412 actions. For example, the agent 412 may submit an API call or database query to a knowledge base storing information about the user's products, or to a user data store 414 (e.g., in the user's CRM) containing the user's customers' orders [(i.e. orders associated with customer account)] and other account data [(i.e. corresponding to a customer account of a customer)]. . . Similarly, the customer data parser 408 may be configured to collect data related to the customer, such as . . . a history of past contacts, . . .” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus at least “customer data 194” teaches “customer account information.”), and “wherein the at least one order comprises order attributes” (Fig. 4 and C27L09-20 shows “In some embodiments, where the intent constructor 400 had stored information indicating that the agent 412 expected that the customer ID and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) constituted sufficient information to identify one or more orders in the customer's order history, the intent constructor 400 may update the intent/action record with information confirming that queries with just these query terms can be successful (i.e., can cause the user CRM to return at least one order identifier for an order that matched the query terms).” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus, at least “orderDate,” “productKeyword,” “productCategory,” or “orderDetails,” in C27L09-20 teaches “order attributes.”); “predicting with a prediction engine implementing a machine learning model, whether the request for assistance relates to the at least one order, wherein the predicting is based on one of, or both of, the customer account information and the order attributes of the at least one order” (Fig. 1 and C11L64-C12L01 shows “The automated service agent engine 128 may produce (e.g., as output of the machine learning engine or the corresponding data modeling algorithms) predictive data [(i.e. prediction engine implementing a chine learning model)] such as intent records and/or action records that may be stored as intents and actions 126.” Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. For example, the action monitor 404 may detect that the agent 412 called a. “selectOrder” API with the customer identifier, the order date, and a keyword associated with ordered products as arguments. The intent constructor 400 may attempt to match the collected information to a known action, and may create an action record for the identified action and associate the action record with the intent record. In some embodiments, the intent constructor 400 may further store information (e.g., in the intent record or the action record) indicating that the agent 412 expected that the customer ID [(i.e. customer account information)] and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) [(i.e. order attributes)] constituted sufficient information to identify one or more orders in the customer's order history stored in the user data stores 414.” (Emphasis added). Thus, the determination of “sufficient information to identify one or more orders in the customer's order history” teaches predicting whether assistance relates to the at least one order.); “in response to predicting that the request for assistance relates to the at least one order, determining with the prediction engine, an intended order from the at least one order, . . .” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action should be performed in response to each of the three responses: if there are zero results [(i.e. assistance does not relate to the at least one order)], report this to the customer and ask the customer to re-enter values; if there is one result [(i.e. assistance does relate to the at least one order)], perform the next action associated with the intent using the returned result; and, if there are multiple results [(i.e. assistance does relate to the at least one order)], list the results [(i.e. each are determined to be “an intended order”)] for the customer and enable the customer to select the proper result.” Although C09L25-56, C12L36-62, and C19L50-C20L04 discuss the uses of metrics including rates of satisfaction and frequency thresholds to determine validity of a predicted action, Sullivan does not explicitly teach “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance”); and “causing the intended order to be displayed on the customer support interface on a customer device” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action [(i.e. one or more prompts)] should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). Thus, Fig. 5 and C28L01-12 teaches that the “intended order” in the list is “displayed on the customer support interface on a customer device.” See also Fig. 1 and C05L07-26 showing “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.”). Sullivan does not explicitly teach, but Sapoznik teaches “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance” (¶44 shows “determin[ing] an appropriate action to take in response to the customer's request. . . [T]he possible actions may be organized using an action graph, where a graph is a number of nodes connected by edges or links.” Fig. 4 and ¶¶46-47 shows that the nodes of the action graph can represent different items, such as “Phone, Internet, and TV.” ¶28, ¶83, and ¶473 shows that the request can be related to delivery of a “package.” Thus, each node teaches an “order.” Fig. 4 and ¶48 shows a “node selector component 320 may select a node from the action graph using the NLP features” and an “action selector component 330, may then select an action from the one or more actions associated with the selected node.” ¶49 shows “each node of the action graph may be associated with a node selector classifier, where a node selector classifier is configured to determine a score (e.g., a likelihood or probability) indicating a match between the node and the customer's request.” (Emphasis added). Fig. 5 and ¶52 shows that “At step 530, a node of the action graph is selected using the features [by] computing a score for every node of the action graph and selecting a node with a highest score . . .” (Emphasis added). Fig. 5 and ¶54 shows that “Step 530 may be implemented using other data in addition to the NLP features. For example, step 530 may be implemented using customer data, such as customer data retrieved from customer data data store 342 and other data, such as other data retrieved from other data data store 343. When receiving a request from the customer, the request may include a customer identifier (such as a customer identification number, customer user name, or device identifier) that may be used to obtain information about the customer from customer data data store 343. The customer data may include any information about the customer, such as a customer profile, a customer location, billing and payment data, and services provided to the customer [(i.e. orders associated with the customer)].” Thus, the selected node with the highest score in Sapoznik teaches “the intended order represents the at least one order with a highest probability of having initiated the request for assistance.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the use of rates/metrics to determine a sufficient workstate (C09L25-56, C12L36-62, C19L50-C20L04, and C26L43-59, and C27L09-20) without the specific algorithm and Sapoznik teaches the use of a score representing probability to select the next node (¶49 and ¶52), i.e. workstate, which further improves automation of customer assistance (¶¶3-4 and ¶¶27-28). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 2, Sullivan and Sapoznik teach “The method of claim 1,” as discussed above. Sullivan does not explicitly teach, but Sapoznik teaches “wherein the step of determining the intended order from the at least one order comprises the steps of:” “calculating a score for each of the at least one order based on the order attributes of the at least one order, the score of the at least one order representing the probability of the at least one order having initiated the request for assistance” (¶49 shows “each node of the action graph may be associated with a node selector classifier, where a node selector classifier is configured to determine a score (e.g., a likelihood or probability) indicating a match between the node and the customer's request.” (Emphasis added). Fig. 5 and ¶52 shows that “At step 530, a node of the action graph is selected using the features [by] computing a score for every node of the action graph and selecting a node with a highest score . . .” (Emphasis added). Fig. 5 and ¶54 shows that “Step 530 may be implemented using other data in addition to the NLP features. For example, step 530 may be implemented using customer data, such as customer data retrieved from customer data data store 342 and other data, such as other data retrieved from other data data store 343. When receiving a request from the customer, the request may include a customer identifier (such as a customer identification number, customer user name, or device identifier) that may be used to obtain information about the customer from customer data data store 343. The customer data may include any information about the customer, such as a customer profile, a customer location, billing and payment data, and services provided to the customer [(i.e. the order attributes of the at least one order)].” See also ¶¶55-57 further discussing the use of customer related data in the score calculation.); and “identifying the at least one order with a highest score to be the intended order” (Fig. 5 and ¶52 shows that “At step 530, a node of the action graph is selected using the features [by] computing a score for every node of the action graph and selecting [(i.e. identifying)] a node with a highest score . . .” (Emphasis added).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the use of rates/metrics to determine a sufficient workstate (C09L25-56, C12L36-62, C19L50-C20L04, and C26L43-59, and C27L09-20) without the specific algorithm and Sapoznik teaches the use of a score representing probability to select the next node (¶49 and ¶52), i.e. workstate, which further improves automation of customer assistance (¶¶3-4 and ¶¶27-28). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 3, Sullivan and Sapoznik teach “The method of claim 1,” as discussed above. Sullivan further teaches: “retrieving order attributes of the intended order” (Fig. 4 and C26L18-42 shows “In response to this prompt, at reference 444 the customer 410 communicates a natural language input of “The shoes I ordered yesterday” to the agent 412, which identifies entities “Shoes” and “Yesterday.” The speech sampler 402 detects this input as one or more values for intent attributes. In some embodiments, at this point the intent attributes are unknown; the intent constructor 400 may at reference 447 apply automated logical reasoning to determine the context of the values. For example, the intent constructor 400 may determine that an order must be identified to be canceled, and the user data store 414 maintains a set of parameters [(i.e. attributes)] for each order including the order number; order date, products in the order, etc.; the user data store 414 may also maintain a set of parameters for each product, including product identifier, category, manufacturer, model number, price, etc. Based on the available parameters, the intent constructor 400 may determine that the values are associated with certain intent attributes. For example, the intent constructor 400 may access [(i.e. retrieve)] a knowledge base associated with the user or with a business category that the user's business belongs to, and may determine that “shoes” are a product category, the intent constructor 400 may use semantic reasoning or context data to determine that “yesterday” is associated with a specific date and is likely an order date associated with the order to be canceled.” (Emphasis added).); “determining by the prediction engine, one or more prompts based on the order attributes of the intended order” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action [(i.e. one or more prompts)] should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added).); and “causing the one or more prompts to be displayed with the intended order on the customer support interface” (Fig. 5 and C28L01-12 shows “. . . list the results for the customer and enable the customer to select the proper result,” which teaches causing one or more prompts to be displayed on the customer support interface with the intended order.). Regarding Claim 4, Sullivan and Sapoznik teach “The method of claim 3,” as discussed above. Sullivan further teaches “wherein the step of determining the one or more prompts comprises the steps of:” “retrieving a set of prompts from a database” (Fig. 1 and C08L36-41 shows “Workflow library 152 [(i.e. database)] may include a stored library of previously created workflows (e.g., IVR workflows, chat workflows, SMS workflows, etc.) that may be loaded [(i.e. retrieved)] into the interactive contact run-time environment of a contact center service 102 executing the contact center 103.” C13L14-21 shows that the “segments of scripted speech” (i.e. prompts) used by the “automated service agent 104” are “associated with the workflow states.”); and “selecting one or more prompts from the set of prompts according to a predefined rule” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action [(i.e. one or more prompts)] should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results [(i.e. predefined rule)], list the results for the customer [(i.e. selecting a prompt)] and enable the customer to select the proper result.” See also Fig. 6 showing a flowchart of rule-logic guiding workflow states and adjoining prompts.). Regarding Claim 5, Sullivan and Sapoznik teach “The method of claim 3,” as discussed above. Sullivan further teaches “wherein the one or more prompts is to be displayed with the intended order in a chatbot session on the customer support interface” (Fig. 5 and C28L01-12 shows “. . . list the results for the customer and enable the customer to select the proper result,” which teaches causing one or more prompts to be displayed on the customer support interface with the intended order.). Regarding Claim 6, Sullivan and Sapoznik teach “The method of claim 2,” as discussed above. Sullivan further teaches “determining with the prediction engine, at least one other order from the at least one order” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results [(i.e. at least one other order from the at least one order)], list the results for the customer and enable the customer to select the proper result.”). Sullivan does not explicitly teach, but Sapoznik teaches: “ranking the at least one order based on the score of the at least one order” (Fig. 5 and ¶52 shows “Scores may be generated for some or all of the nodes of the action graph, and a node may be selected using the scores. Some example implementations of selecting a node include (i) computing a score for every node of the action graph and selecting a node with a highest score; . . .” (Emphasis added). Because the “highest” score is selected Sapoznik teaches “ranking” the orders (i.e. nodes) based on the score. See also Fig. 6-8 and ¶¶61-162 showing more detail to the score calculation and node selection algorithms.); and “determining with the prediction engine, at least one other order from the at least one order, wherein the at least one other order has an inferior score compared to the intended order” (Fig. 5 and ¶52 shows “Scores may be generated for some or all of the nodes of the action graph, and a node may be selected using the scores. Some example implementations of selecting a node include (i) computing a score for every node of the action graph and selecting a node with a highest score; . . .” (Emphasis added). Because a score is calculated for each, i.e. “all,” of the nodes (i.e. orders), Sapoznik teaches determining at least one other order with an inferior score (i.e. the other orders that are not the “highest”). See also Fig. 6-8 and ¶¶61-162 showing more detail to the score calculation and node selection algorithms.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the use of rates/metrics to determine a sufficient workstate (C09L25-56, C12L36-62, C19L50-C20L04, and C26L43-59, and C27L09-20) without the specific algorithm and Sapoznik teaches the use of a score representing probability to select the next node (¶49 and ¶52), i.e. workstate, which further improves automation of customer assistance (¶¶3-4 and ¶¶27-28). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 10, Sullivan and Sapoznik teach “The method of claim 5,” as discussed above. Sullivan further teaches: “receiving an input from the customer which affirms that the request for assistance was related to the intended order” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.); and “updating the machine learning model of the prediction engine” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.). Regarding Claim 11, Sullivan and Sapoznik teach “The method of claim 10,” as discussed above. Sullivan further teaches “wherein the input from the customer which affirms that the request for assistance was related to the intended order, comprises any one of:” “a query entered by the customer in the chatbot session about the intended order” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a query entered by the customer because the customer input results in a query. For example, Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. . .” ), “a customer selection of a selectable element representing the intended order” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. . . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). See also C19L42-49 showing use of a “selectable element” and C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent.), or “a customer selection of a selectable element representing the one or more prompts” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. . . . if there are multiple results, list the results [(i.e. one or more prompts)] for the customer and enable the customer to select the proper result.” (Emphasis added). See also C19L42-49 showing use of a “selectable element” and C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent.). Regarding Claim 12, Sullivan and Sapoznik teach “The method of claim 5,” as discussed above. Sullivan further teaches: “receiving an input from the customer which affirms that the request for assistance was not related to the intended order” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.); and “updating the machine learning model of the prediction engine” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.). Regarding Claim 13, Sullivan and Sapoznik teach “The method of claim 12,” as discussed above. Sullivan further teaches “wherein the input from the customer which affirms that the request for assistance was not related to the intended order, comprises any one of:” “a query entered by the customer in the chatbot session relating to an order which is not the intended order” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a query entered by the customer because the customer input results in a query. For example, Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. . .” ). See also C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent, i.e. session relating to an order which is not the intended order.), “a query entered by the customer in the chatbot session that is not related to the intended order” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a query entered by the customer because the customer input results in a query. For example, Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. . .” ). See also C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent, i.e. session relating to an order which is not the intended order.), “a customer selection of a selectable element that is not related to the intended order” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. . . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). See also C19L42-49 showing use of a “selectable element” and C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent.), or “the customer terminating the chatbot session” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. . .” (Emphasis added).). Regarding Claim 14, Sullivan and Sapoznik teach “The method of claim 5,” as discussed above. Sullivan further teaches: “receiving an input from the customer that indicates relevance of the one or more prompts” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8. C13L14-21 shows that the “segments of scripted speech” (i.e. prompts) used by the “automated service agent 104” are “associated with the workflow states.” Thus, the feedback teaches an indication of the relevance of the one or more prompts.); and “updating the machine learning model of the prediction engine” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.). Regarding Claim 15, Sullivan and Sapoznik teach “The method of claim 14,” as discussed above. Sullivan further teaches “wherein the input from the customer that indicates relevance of the one or more prompts, comprises:” “a query entered by the customer in the chatbot session that is related to the one or more prompts” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a query entered by the customer because the customer input results in a query. For example, Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. . .”), or “a customer selection of a selectable element that represents the one or more prompts” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. . . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). See also C19L42-49 showing use of a “selectable element” and C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent.). Regarding Claim 16, Sullivan and Sapoznik teach “The method of claim 5,” as discussed above. Sullivan further teaches: “receiving an input from the customer that indicates non-relevance of the one or more prompts” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8. C13L14-21 shows that the “segments of scripted speech” (i.e. prompts) used by the “automated service agent 104” are “associated with the workflow states.” Thus, the negative feedback teaches an indication of non-relevance of the one or more prompts.); and “updating the machine learning model of the prediction engine” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. The feedback may be stored as contact center data 150, or may be sent directly to the automated service agent engine 128, which may incorporate the feedback into the data model(s) using the machine learning engine/data modeling algorithms. For example, the machine learning engine may be retrained using the feedback to improve the thresholds or other aspects of the data model. The system 114 may make automated service agents and generated contact workflows available to the users, such as by providing an API to the automated service agent system 128.” (Emphasis added). See also Fig. 7-8.). Regarding Claim 17, Sullivan and Sapoznik teach “The method of claim 16,” as discussed above. Sullivan further teaches “wherein the input from the customer that indicates non-relevance of the one or more prompts, comprises any one of:” “a query entered in the chatbot session that is not related to any of the one or more prompts” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a query entered by the customer because the customer input results in a query. For example, Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. . .” ). See also C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent, i.e. session not related to the prompt.), “a customer selection of a selectable element that is not any of the one or more prompts” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. . . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). See also C19L42-49 showing use of a “selectable element” and C33L17-33 showing an example chat exchange where the automated service agent lists options to clarify the customer’s intent.), and “the customer terminating the chatbot session” (C13L46-67 shows “The contact center service 102 may produce feedback, automatically and/or based on user input, that indicates whether the automated service agent 104 and/or the generated contact workflow that the agent 104 executes are fulfilling customer expectations. Feedback validating the workflow states may be generated in response to the performance of an automated action, as well as in response to favorable responsive input from the customer after the action is performed. In contrast, if an automated action fails or is aborted or canceled, or if the customer invokes a transition to a human agent or exhibits certain sentiment in the natural language input, negative feedback may be generated. . .” (Emphasis added).). Regarding Claim 18, Sullivan and Sapoznik teach “The method of claim 1,” as discussed above. Sullivan further teaches “wherein the customer account information comprises customer profile information, customer activity information, historical chat information, or a combination thereof” (Fig. 4 and C25L21-37 shows “The user data parser 406 may be configured to detect data returned to the contact center from one or more user data stores 414 in response to agent 412 actions. For example, the agent 412 may submit an API call or database query to a knowledge base storing information about the user's products, or to a user data store 414 (e.g., in the user's CRM) containing the user's customers' orders and other account data . . . Similarly, the customer data parser 408 may be configured to collect data related to the customer [(i.e. customer profile information)], such as the method of contacting the contact center (e.g., phone call, live chat on website, click-through from website, emailed service request) [(i.e. customer activity information)], a history of past contacts [(i.e. historical chat information)], . . .” (Emphasis added). Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108 [(i.e. customer activity information)]) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added).). Regarding Claim 19, Sullivan teaches the “A system comprising one or more computers and one or more storage devices storing computer-readable instructions that, when executed by the one or more computers, cause the one or more computers to perform one or more operations” (Fig. 4 and C24L58-62 shows “FIG. 4 illustrates an example intent constructor 400 processing activity data representing a recorded contact between a customer 410 and an agent 412, which may be a live or automated service agent, on a contact center as described herein.” (Emphasis added). Fig. 1 and C05L07-26 shows “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.” Fig. 10 and C33L62-C34L44 shows the use of “general-purpose computing device 1000” including “processor 110” and “memory 1020.”), “comprising:” “receiving a request for assistance corresponding to a customer account of a customer, the customer account being associated with at least one order, wherein the customer account comprises customer account information” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a request for assistance. Fig. 4 and C25L21-37 shows “The user data parser 406 may be configured to detect data returned to the contact center from one or more user data stores 414 in response to agent 412 actions. For example, the agent 412 may submit an API call or database query to a knowledge base storing information about the user's products, or to a user data store 414 (e.g., in the user's CRM) containing the user's customers' orders [(i.e. orders associated with customer account)] and other account data [(i.e. corresponding to a customer account of a customer)]. . . Similarly, the customer data parser 408 may be configured to collect data related to the customer, such as . . . a history of past contacts, . . .” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus at least “customer data 194” teaches “customer account information.”), and “wherein the at least one order comprises order attributes” (Fig. 4 and C27L09-20 shows “In some embodiments, where the intent constructor 400 had stored information indicating that the agent 412 expected that the customer ID and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) constituted sufficient information to identify one or more orders in the customer's order history, the intent constructor 400 may update the intent/action record with information confirming that queries with just these query terms can be successful (i.e., can cause the user CRM to return at least one order identifier for an order that matched the query terms).” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus, at least “orderDate,” “productKeyword,” “productCategory,” or “orderDetails,” in C27L09-20 teaches “order attributes.”); “predicting with a prediction engine implementing a machine learning model, whether the request for assistance relates to the at least one order, wherein the predicting is based on one of, or both of, the customer account information and the order attributes of the at least one order” (Fig. 1 and C11L64-C12L01 shows “The automated service agent engine 128 may produce (e.g., as output of the machine learning engine or the corresponding data modeling algorithms) predictive data [(i.e. prediction engine implementing a chine learning model)] such as intent records and/or action records that may be stored as intents and actions 126.” Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. For example, the action monitor 404 may detect that the agent 412 called a. “selectOrder” API with the customer identifier, the order date, and a keyword associated with ordered products as arguments. The intent constructor 400 may attempt to match the collected information to a known action, and may create an action record for the identified action and associate the action record with the intent record. In some embodiments, the intent constructor 400 may further store information (e.g., in the intent record or the action record) indicating that the agent 412 expected that the customer ID [(i.e. customer account information)] and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) [(i.e. order attributes)] constituted sufficient information to identify one or more orders in the customer's order history stored in the user data stores 414.” (Emphasis added). Thus, the determination of “sufficient information to identify one or more orders in the customer's order history” teaches predicting whether assistance relates to the at least one order.); “in response to predicting that the request for assistance relates to the at least one order, determining with the prediction engine, an intended order from the at least one order, . . .” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action should be performed in response to each of the three responses: if there are zero results [(i.e. assistance does not relate to the at least one order)], report this to the customer and ask the customer to re-enter values; if there is one result [(i.e. assistance does relate to the at least one order)], perform the next action associated with the intent using the returned result; and, if there are multiple results [(i.e. assistance does relate to the at least one order)], list the results [(i.e. each are determined to be “an intended order”)] for the customer and enable the customer to select the proper result.” Although C09L25-56, C12L36-62, and C19L50-C20L04 discuss the uses of metrics including rates of satisfaction and frequency thresholds to determine validity of a predicted action, Sullivan does not explicitly teach “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance”); and “causing the intended order to be displayed on the customer support interface on a customer device” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action [(i.e. one or more prompts)] should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). Thus, Fig. 5 and C28L01-12 teaches that the “intended order” in the list is “displayed on the customer support interface on a customer device.” See also Fig. 1 and C05L07-26 showing “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.”). Sullivan does not explicitly teach, but Sapoznik teaches “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance” (¶44 shows “determin[ing] an appropriate action to take in response to the customer's request. . . [T]he possible actions may be organized using an action graph, where a graph is a number of nodes connected by edges or links.” Fig. 4 and ¶¶46-47 shows that the nodes of the action graph can represent different items, such as “Phone, Internet, and TV.” ¶28, ¶83, and ¶473 shows that the request can be related to delivery of a “package.” Thus, each node teaches an “order.” Fig. 4 and ¶48 shows a “node selector component 320 may select a node from the action graph using the NLP features” and an “action selector component 330, may then select an action from the one or more actions associated with the selected node.” ¶49 shows “each node of the action graph may be associated with a node selector classifier, where a node selector classifier is configured to determine a score (e.g., a likelihood or probability) indicating a match between the node and the customer's request.” (Emphasis added). Fig. 5 and ¶52 shows that “At step 530, a node of the action graph is selected using the features [by] computing a score for every node of the action graph and selecting a node with a highest score . . .” (Emphasis added). Fig. 5 and ¶54 shows that “Step 530 may be implemented using other data in addition to the NLP features. For example, step 530 may be implemented using customer data, such as customer data retrieved from customer data data store 342 and other data, such as other data retrieved from other data data store 343. When receiving a request from the customer, the request may include a customer identifier (such as a customer identification number, customer user name, or device identifier) that may be used to obtain information about the customer from customer data data store 343. The customer data may include any information about the customer, such as a customer profile, a customer location, billing and payment data, and services provided to the customer [(i.e. orders associated with the customer)].” Thus, the selected node with the highest score in Sapoznik teaches “the intended order represents the at least one order with a highest probability of having initiated the request for assistance.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the use of rates/metrics to determine a sufficient workstate (C09L25-56, C12L36-62, C19L50-C20L04, and C26L43-59, and C27L09-20) without the specific algorithm and Sapoznik teaches the use of a score representing probability to select the next node (¶49 and ¶52), i.e. workstate, which further improves automation of customer assistance (¶¶3-4 and ¶¶27-28). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 20, Sullivan teaches the “One or more non-transitory computer storage media storing instructions that, when executed by one or more computers, cause the one or more computers to perform one or more operations” (Fig. 4 and C24L58-62 shows “FIG. 4 illustrates an example intent constructor 400 processing activity data representing a recorded contact between a customer 410 and an agent 412, which may be a live or automated service agent, on a contact center as described herein.” (Emphasis added). Fig. 1 and C05L07-26 shows “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.” Fig. 10 and C33L62-C34L44 shows the use of “general-purpose computing device 1000” including “processor 110” and “memory 1020.”), “for:” “receiving a request for assistance corresponding to a customer account of a customer, the customer account being associated with at least one order, wherein the customer account comprises customer account information” (Fig. 4 and C25L20-C26L42 shows reference “417,” “427,” and “444” are received from “customer 410,” each of which teach receiving a request for assistance. Fig. 4 and C25L21-37 shows “The user data parser 406 may be configured to detect data returned to the contact center from one or more user data stores 414 in response to agent 412 actions. For example, the agent 412 may submit an API call or database query to a knowledge base storing information about the user's products, or to a user data store 414 (e.g., in the user's CRM) containing the user's customers' orders [(i.e. orders associated with customer account)] and other account data [(i.e. corresponding to a customer account of a customer)]. . . Similarly, the customer data parser 408 may be configured to collect data related to the customer, such as . . . a history of past contacts, . . .” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus at least “customer data 194” teaches “customer account information.”), and “wherein the at least one order comprises order attributes” (Fig. 4 and C27L09-20 shows “In some embodiments, where the intent constructor 400 had stored information indicating that the agent 412 expected that the customer ID and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) constituted sufficient information to identify one or more orders in the customer's order history, the intent constructor 400 may update the intent/action record with information confirming that queries with just these query terms can be successful (i.e., can cause the user CRM to return at least one order identifier for an order that matched the query terms).” Fig. 1 and C15L25-28 shows “user customer relationship management (CRM) system 192” includes “customer data 194 (e.g., a purchase history of a customer 108) and/or business data 195 (e.g., a product catalog, inventory, or purchase order database).” (Emphasis added). Thus, at least “orderDate,” “productKeyword,” “productCategory,” or “orderDetails,” in C27L09-20 teaches “order attributes.”); “predicting with a prediction engine implementing a machine learning model, whether the request for assistance relates to the at least one order, wherein the predicting is based on one of, or both of, the customer account information and the order attributes of the at least one order” (Fig. 1 and C11L64-C12L01 shows “The automated service agent engine 128 may produce (e.g., as output of the machine learning engine or the corresponding data modeling algorithms) predictive data [(i.e. prediction engine implementing a chine learning model)] such as intent records and/or action records that may be stored as intents and actions 126.” Fig. 4 C26L43-59 shows “The action monitor 404 determines that the agent 412 queries the data store 414 for a corresponding order at reference 451. For example, the action monitor 404 may detect that the agent 412 called a. “selectOrder” API with the customer identifier, the order date, and a keyword associated with ordered products as arguments. The intent constructor 400 may attempt to match the collected information to a known action, and may create an action record for the identified action and associate the action record with the intent record. In some embodiments, the intent constructor 400 may further store information (e.g., in the intent record or the action record) indicating that the agent 412 expected that the customer ID [(i.e. customer account information)] and the values for intent attributes “orderDate” and “productKeyword” (or “productCategory” or “orderDetails,” etc.) [(i.e. order attributes)] constituted sufficient information to identify one or more orders in the customer's order history stored in the user data stores 414.” (Emphasis added). Thus, the determination of “sufficient information to identify one or more orders in the customer's order history” teaches predicting whether assistance relates to the at least one order.); “in response to predicting that the request for assistance relates to the at least one order, determining with the prediction engine, an intended order from the at least one order, . . .” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action should be performed in response to each of the three responses: if there are zero results [(i.e. assistance does not relate to the at least one order)], report this to the customer and ask the customer to re-enter values; if there is one result [(i.e. assistance does relate to the at least one order)], perform the next action associated with the intent using the returned result; and, if there are multiple results [(i.e. assistance does relate to the at least one order)], list the results [(i.e. each are determined to be “an intended order”)] for the customer and enable the customer to select the proper result.” Although C09L25-56, C12L36-62, and C19L50-C20L04 discuss the uses of metrics including rates of satisfaction and frequency thresholds to determine validity of a predicted action, Sullivan does not explicitly teach “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance”); and “causing the intended order to be displayed on the customer support interface on a customer device” (Fig. 5 and C28L01-12 shows “For example, where the current action is a database query, the system may determine, based on the activity data, that there are three possible responses to the query: zero results, one result, and multiple results. The system may further determine that a different action [(i.e. one or more prompts)] should be performed in response to each of the three responses: if there are zero results, report this to the customer and ask the customer to re-enter values; if there is one result, perform the next action associated with the intent using the returned result; and, if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). Thus, Fig. 5 and C28L01-12 teaches that the “intended order” in the list is “displayed on the customer support interface on a customer device.” See also Fig. 1 and C05L07-26 showing “contact center 103” includes “an online chat platform, with an interface presented to the customer in a software application or on a website.”). Sullivan does not explicitly teach, but Sapoznik teaches “wherein the intended order represents the at least one order with a highest probability of having initiated the request for assistance” (¶44 shows “determin[ing] an appropriate action to take in response to the customer's request. . . [T]he possible actions may be organized using an action graph, where a graph is a number of nodes connected by edges or links.” Fig. 4 and ¶¶46-47 shows that the nodes of the action graph can represent different items, such as “Phone, Internet, and TV.” ¶28, ¶83, and ¶473 shows that the request can be related to delivery of a “package.” Thus, each node teaches an “order.” Fig. 4 and ¶48 shows a “node selector component 320 may select a node from the action graph using the NLP features” and an “action selector component 330, may then select an action from the one or more actions associated with the selected node.” ¶49 shows “each node of the action graph may be associated with a node selector classifier, where a node selector classifier is configured to determine a score (e.g., a likelihood or probability) indicating a match between the node and the customer's request.” (Emphasis added). Fig. 5 and ¶52 shows that “At step 530, a node of the action graph is selected using the features [by] computing a score for every node of the action graph and selecting a node with a highest score . . .” (Emphasis added). Fig. 5 and ¶54 shows that “Step 530 may be implemented using other data in addition to the NLP features. For example, step 530 may be implemented using customer data, such as customer data retrieved from customer data data store 342 and other data, such as other data retrieved from other data data store 343. When receiving a request from the customer, the request may include a customer identifier (such as a customer identification number, customer user name, or device identifier) that may be used to obtain information about the customer from customer data data store 343. The customer data may include any information about the customer, such as a customer profile, a customer location, billing and payment data, and services provided to the customer [(i.e. orders associated with the customer)].” Thus, the selected node with the highest score in Sapoznik teaches “the intended order represents the at least one order with a highest probability of having initiated the request for assistance.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the use of rates/metrics to determine a sufficient workstate (C09L25-56, C12L36-62, C19L50-C20L04, and C26L43-59, and C27L09-20) without the specific algorithm and Sapoznik teaches the use of a score representing probability to select the next node (¶49 and ¶52), i.e. workstate, which further improves automation of customer assistance (¶¶3-4 and ¶¶27-28). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over US-10554817-B1 (“Sullivan”) in view of US-20180012231-A1 (“Sapoznik”) and US-20220261817-A1 (“Ferrucci”). Regarding Claim 7, Sullivan and Sapoznik teach “The method of claim 6,” as discussed above. Sullivan further teaches “causing the intended order to be displayed . . . with the at least one other order” (Fig. 5 and C28L01-12 shows “. . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added).). Sullivan and Sapoznik do not explicitly teach, but Ferrucci teaches “causing the intended order to be displayed more prominently on the customer support interface compared with the at least one other order” (¶93 shows “In some examples, the multimodal dialog engine 216 may configure user interface elements to guide the user input to explore suggested remedies and/or relevant articles found in a large body of knowledge (“data sources”), including natural language text (e.g., journals, literature, documents, knowledge base, market research documents, and/or structured databases). The multimodal dialog engine 216 may present the one or more suggestions with one or more interactable links to technical documents. The knowledge sources may include any print media or electronic sources and any unstructured, semi-structured, and structured knowledge. Non-limiting examples of knowledge sources may include manuscripts, letters, interviews, records, textbooks, magazine articles, book reviews, commentaries, encyclopedias, almanacs, books, brochures, journals, magazines, newspapers, medical ontologies, research articles, clinical reports, case studies, dissertations, peer-reviewed articles, knowledge graphs, research papers, clinical studies, music, video, photos, and the like. As described herein, the multimodal dialog engine 216 may generate suggestions (e.g., suggested remedies and/or relevant articles) and the NLU engine 212 may determine a. ranking for the suggestions. The user portal 208 may present the suggestions in ranked order [(i.e. some suggestions are displayed “more prominently” than others)]. The user portal 208 may also present prompts for user feedback for each suggestion.” (Emphasis added). See also ¶98-101 further discussing the ranking to better assist the goal of the user and Fig. 4-11 showing example graphic user interfaces.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ferrucci with Sullivan and Sapoznik because Sullivan teaches providing a list of orders for the user to select (Fig. 5 and C28L01-12) and Ferrucci teaches ranking customer service suggestions to better resolve the user’s goal (¶¶98-101). Thus, combining Ferrucci with Sullivan and Sapoznik furthers the interest taught in Ferrucci, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 8, Sullivan, Sapoznik, and Ferrucci teach “The method of claim 7,” as discussed above. Sullivan further teaches “wherein the step of causing the intended order to be displayed . . . with the at least one other order comprises the steps of:” “causing the intended order to be displayed on a first interface of the customer support interface” (Fig. 5 and C28L01-12 shows “. . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). C13L14-21 shows “The automated service agent 104 may then operate using suitable interfaces for receiving a request for customer service, initiating the contact with the corresponding customer, communicating with the customer via segments of scripted speech associated with the workflow states, processing natural language inputs in real-time to determine customer responses, and calling the associated API(s) to perform indicated actions.” Fig. 2 and C15L44-C16L09 shows “user interface service 224” shows a variety of “graphical elements and interactive elements” are displayed on “screens of user computing devices.”); and “wherein the at least one other order is displayed on a second interface of the customer support interface . . .” (Fig. 5 and C28L01-12 shows “. . . if there are multiple results, list the results for the customer and enable the customer to select the proper result.” (Emphasis added). C13L14-21 shows “The automated service agent 104 may then operate using suitable interfaces for receiving a request for customer service, initiating the contact with the corresponding customer, communicating with the customer via segments of scripted speech associated with the workflow states, processing natural language inputs in real-time to determine customer responses, and calling the associated API(s) to perform indicated actions.” Fig. 2 and C15L44-C16L09 shows “user interface service 224” shows a variety of “graphical elements and interactive elements” are displayed on “screens of user computing devices.”). Sullivan does not explicitly teach, but Sapoznik teaches “wherein the step of causing the intended order to be displayed . . . with the at least one other order comprises the steps of: . . . causing a selectable link to be presented on the first interface” (¶89 shows “Application interface component 220 may communicate with customer device 210 using any appropriate techniques. For example, application interface component 220 may transmit any of the following to customer device 210: HTML to be presented by a display; audio to be played by a speaker (or text to be used to generate audio at the customer device); a link to a page of an app or a website (e.g., a “deep link”).” (Emphasis added).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the presenting the user with a list of choices (C28L01-12) and Sapoznik teaches the use of a threshold to determine the list of choices presented to the user (¶70 and ¶177). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Sullivan and Sapoznik do not explicitly teach, but Ferrucci further teaches “wherein the step of causing the intended order to be displayed more prominently on the customer support interface compared with the at least one other order comprises the steps of: . . . wherein the at least one other order is displayed on a second interface of the customer support interface in response to a customer selection of the selectable link” (¶93 shows “In some examples, the multimodal dialog engine 216 may configure user interface elements to guide the user input to explore suggested remedies and/or relevant articles found in a large body of knowledge (“data sources”), including natural language text (e.g., journals, literature, documents, knowledge base, market research documents, and/or structured databases). The multimodal dialog engine 216 may present the one or more suggestions with one or more interactable links to technical documents [i.e. each suggestion includes an selectable link to a subsequent interface providing more information]. The knowledge sources may include any print media or electronic sources and any unstructured, semi-structured, and structured knowledge. Non-limiting examples of knowledge sources may include manuscripts, letters, interviews, records, textbooks, magazine articles, book reviews, commentaries, encyclopedias, almanacs, books, brochures, journals, magazines, newspapers, medical ontologies, research articles, clinical reports, case studies, dissertations, peer-reviewed articles, knowledge graphs, research papers, clinical studies, music, video, photos, and the like. As described herein, the multimodal dialog engine 216 may generate suggestions (e.g., suggested remedies and/or relevant articles) and the NLU engine 212 may determine a. ranking for the suggestions. The user portal 208 may present the suggestions in ranked order [(i.e. some suggestions are displayed “more prominently” than others)]. The user portal 208 may also present prompts for user feedback for each suggestion.” (Emphasis added). See also ¶98-101 further discussing the ranking to better assist the goal of the user and Fig. 4-11 showing example graphic user interfaces.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ferrucci with Sullivan and Sapoznik because Sullivan teaches providing a list of orders for the user to select (Fig. 5 and C28L01-12) and Ferrucci teaches ranking customer service suggestions to better resolve the user’s goal (¶¶98-101). Thus, combining Ferrucci with Sullivan and Sapoznik furthers the interest taught in Ferrucci, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Regarding Claim 9, Sullivan, Sapoznik, and Ferrucci teach “The method of claim 8,” as discussed above. Sullivan does not explicitly teach, but Sapoznik further teaches “wherein the at least one other order is displayed on the second interface based on the ranking of the at least one order” (¶177 shows “For example, the top scoring suggestion, a top number of scoring suggestions, or all suggestions with a score above a threshold may be presented.” Fig. 6 and ¶70 shows “Instead of selecting a node (which may be an incorrect node), it may provide a better experience for the customer to obtain additional information and to have greater certainty in finding an appropriate node to respond to the customer's request. For example, the customer may be asked to select one of several possible choices or to provide additional text to clarify his or her request.” (Emphasis added). Thus, Sapoznik teaches that the “other” order is displayed based on its ranking (i.e. score relative to other scores).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Sapoznik with Sullivan because Sullivan teaches the presenting the user with a list of choices (C28L01-12) and Sapoznik teaches the use of a threshold to determine the list of choices presented to the user (¶70 and ¶177). Thus, combining Sapoznik with Sullivan furthers the interest taught in Sullivan, and therefore, would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is as follows: US-20210224306-A1 (“Choudhary”) shows a machine learning model that is used to determine intent of a customer service interaction. US-20250086647-A1 (“Gao”) shows an AI chatbot used as a customer service agent, which can retrieve and provide relevant documents to the user. WO-2023210846-A1 (“Park”) shows an automated chatbot that can help a customer, by reviewing transaction data, perform tasks like look up order details or cancel an order. “The evolution of conversational support starts now – with our new Resolution Bot” (“Andom” 02/25/2020, https://www.intercom.com/blog/announcing-resolution-bot/) shows a machine learning Resolution Bot that can resolve complex customer support problems directly with the customer. For Example, the Resolution Bot can pull up a customer’s Shopify order by providing customer specific bots. “Introducing Order Bot! Check Out Re:amaze’s Newst Chatbot!” (“Lam” 05/06/2019, https://www.reamaze.com/blog/introducing-order-bot-check-out-reamazes-newest-chatbot/) shows an order bot that can provide status of an order. “The User Experience of Chatbots” (“Budiu” 11/25/2018, https://www.nngroup.com/articles/chatbots/) shows Converse, Walmart’s in-house conversational AI platform, which uses proactive assistance to predict the intent of the user. “AI for Customer Care- Building smart conversational assistants” (“Bhatt” 04/07/2022, https://medium.com/walmartglobaltech/ai-for-customer-care-building-smart-conversational-assistants-f0f527169bbb) shows the advantages of using selectable links with chatbots to provide more information because space on screen is limited. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW PARKER GOODMAN whose telephone number is (571) 272-5698. The examiner can normally be reached on Monday-Thursday from 9:30 AM ET to 6:00 PM ET. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Zimmerman, can be reached at telephone number (571) 272-4602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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. /MATTHEW PARKER GOODMAN/Examiner, Art Unit 3628 /JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
Read full office action

Prosecution Timeline

Sep 23, 2024
Application Filed
Apr 23, 2026
Non-Final Rejection mailed — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12462298
COMPUTER-IMPLEMENTED SYSTEMS AND METHODS FOR REAL-TIME RISK-INFORMED RETURN ITEM COLLECTION USING AN AUTOMATED KIOSK
4y 5m to grant Granted Nov 04, 2025
Patent 12437312
UTILIZING MACHINE LEARNING AND TRANSACTION DATA TO DETERMINE FUEL PRICES AT FUEL STATIONS
1y 10m to grant Granted Oct 07, 2025
Patent 12400171
RETURNABLE PACKAGING AND FRESH PRODUCT DELIVERY SYSTEM USING PACKAGING STATE INFORMATION
2y 5m to grant Granted Aug 26, 2025
Patent 12380366
AUTO-GENERATED FULFILLMENT ATTRIBUTES
3y 7m to grant Granted Aug 05, 2025
Patent 12367509
MARKUP OPTIMIZATION
2y 9m to grant Granted Jul 22, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
21%
Grant Probability
50%
With Interview (+28.4%)
2y 10m (~1y 2m remaining)
Median Time to Grant
Low
PTA Risk
Based on 75 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month