DETAILED ACTION
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 .
Notice to Applicant
The following is a Non-Final Office action. Claims 1-20 are pending in this application and are rejected below.
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 a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“A method, comprising:
configuring a first response model at a first …;
configuring a second response model at a second …, the second response model being different than the first response model; receiving a target customer incident;
obtaining, from at least one of the first … or the second …, at least one output comprising a target candidate action for the target customer incident;
displaying the output comprising the target candidate action for the target customer incident …; and
responsive to an interaction with the target candidate action, performing the target candidate action...”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” (“managing personal behavior (including social activities, teaching, and following rules or instructions for customer service)), as here we a first response model, which [0032, 0038] as published explains takes customer incident and attributes and outputs candidate actions. This is consistent with claim 1 which receives target customer incident, then outputs target candidate actions. The “response model” is a further narrowing of a mathematical relationship of what actions are helpful in resolving the customer incident [0031]. For “performing” the target candidate action, this can be any of a number of alternatives including “pasting text”, posting question/statement to customer, giving a coupon, issuing a refund, or providing a discount (See [0070] as published - Example types of actions include, but are not limited to, delete, copy, paste, following a link, speaking or writing a statement to a customer, speaking or writing a question for the customer to gather more information, issue a coupon, remotely control the customer's system, transmit data and/or an application to the customer, issue a refund to the customer, provide a discount to the customer, etc. … Examples of different content that may be included in the candidate action include, but are not limited to, a text description, instructions, user manual, instruction manual, compatibility information, an image, a video, audio, etc. Accordingly, claim 1 is directed to an abstract idea because it has a model of response to an incident, obtains a target candidate action for a person to select/approve, and performs the candidate action (e.g. give information to a customer, issue a coupon, or provide a discount) to handle the incident.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements that are:
configuring a first response model at a first endpoint;
configuring a second response model at a second endpoint…
obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident;
displaying the output comprising the target candidate action for the target customer incident in a graphical user interface (GUI) ;
responsive to an interaction with the target candidate action, performing the target candidate action;
wherein the method is performed by at least one device including a hardware processor.
“responsive to an interaction with the target candidate action” target candidate action – [0026] - Each interface element may have an associated action that the service agent may execute by selecting an area on the card (e.g., a button).
The additional elements of “endpoint” is interpreted as a computer, that possibly includes an address or location information [see applicant’s [0037] as published;
Endpoints are defined in the “Authoritative Dictionary of IEEE Standard Terms”, 7th edition, 2000 for “identify the sources and destinations of data” [see (2) below, which is consistent with how Applicant has used the term]
PNG
media_image1.png
171
384
media_image1.png
Greyscale
The claim has steps “performed by a hardware processor” where there is a response model for different endpoints representing “different locations” [0037] as published, and having a “display and GUI” for a customer service agent.
(MPEP 2106.05f – each limitation in claim involves a computer and is considered “apply it” – applying the abstract idea on a computer – merely uses a computer as a tool to perform an abstract idea; also MPEP 2106.05h field of use for GUI and person “interaction” with GUI)).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a hardware processor, and response model at different endpoints (i.e. locations), and a GUI for a person, are MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235) and “field of use” (MPEP 2106.05h). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. In addition, “storing” data is a conventional computer function – See MPEP 2106.05d(II) - iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334.
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. The claim is not patent eligible. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent claim 17 is directed to an article of manufacture at step 1, which is a statutory category. Claim 17 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2 and step 2b.
Independent claim 19 is directed to a system at step 1, which is a statutory category. Claim 19 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2 and step 2b.
Claim 2, 18 narrow the abstract idea by having “logic” for generating candidate actions based on attributes of the incident. The attributes can just be date or time of incident amongst many other alternatives (See [0036] as published - Moreover, attributes associated with the customer incident 116 may include date of incident, time of incident, user input (text, images, logs, etc.) describing the problem that the customer is experiencing, service agent input (text, images, logs, etc.) describing the problem that the customer is experiencing, operating system (OS) version of customer device, application(s) currently running on customer device, application(s) version, customer name, customer organization, support plan level (for customers who subscribe to a particular service plan designed to address software/hardware issues at a customer site), tabs or windows open on browser of customer device, etc.)
Claim 3 narrows the abstract idea by having different candidate actions from different response models, like alternative candidate actions for a customer service agent to review; and then receiving a “response model parameter” and configuring the response model based on the parameter, where the model parameter can just be “purpose” of the response. The examples of the “parameters” include [0105] as published “the parameters specific to the user-selected response model may include any of the following: a name associated with the user-selected response model, a description of a purpose of the user-selected response model, selection of one or more profiles having access to the user-selected response model, authentication information for access to the user-selected response model, etc.”
Claim 4, 20 narrows the abstract idea as it also receives attributes, like claim 2, which can be the date or time, or even description of problem, customer name, customer organization, or particular service plan, and then similarly outputting candidate actions for the 1st endpoint. The additional element of “selecting the first endpoint based on the attribute” can be for purpose of selecting the most appropriate customer incident, since the attributes can even just be description of problem or customer name/organization.
Claims 5 narrows the abstract idea in of location and metadata of “type” of action (e.g. refund/discount/coupon) is considered narrowing the abstract idea. Claim 5 also recites additional elements that the first response model is by “machine learning model”, and there is a “reference pointer” referencing a location (in [0104] as published example, the pointer is a URL), and metadata parameter ([0069[ as published gives examples “metadata may be included with the candidate actions that indicates characteristics of the candidate actions, such as type of action, display format, content, etc”), and an additional element that the endpoints are representational state transfer (REST) endpoints. Accordingly, the “REST endpoints” are considered just specifying which “sources” of data the incidents/actions come from which is considered “field of use” MPEP 2106.05h at this time; the REST protocol is also considered “field of use” MPEP 2106.05h at this time. At step 2B, this is also considered conventional – see Govindan 2015/0285398 Abstract “architecture can exchange data in the JSON format between a first layer and a second layer. This architecture is configured to be lightweight as compared to the SOAP/HTTP architecture found in conventional techniques, typically deploying a Representational State Transfer (REST) structure”; Tolksdorf (US 20160189164 – see par 76 – server 320 queries customer database to resolve customer issues; see par 83 – server interacts with modules and contact center resources (par 69, e.g. computers) via REST protocol as is conventional). Claim 5, individually or in combination, is viewed as “apply it [abstract idea] on a computer” (MPEP 2106.05f – “by machine learning”) and field of use (MPEP 2106.05h – use of REST endpoint terminology), where a location and metadata of “type” of action of refund/coupon/discount can be metadata.
Claim 6 narrows the abstract idea by having two different candidate actions from output from 1st and 2nd endpoints. To extent these are “from” different models and endpoints/computers, this is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f) and “field of use” (MPEP 2106.05h) for similar reasons as claim 1 above.
Claim 7 includes consideration of attributes and parameters and a machine learning model and is narrowing the abstract idea and has additional elements (machine learning model by a computer), and is rejected for similar reasons as claim 1 and 5 above.
Claim 8 narrows the abstract idea by considering metadata parameters (0069[ as published gives examples “metadata may be included with the candidate actions that indicates characteristics of the candidate actions, such as type of action, display format, content, etc”), which the type of action can be discount, coupon, refund or other business actions for customer service. A “reference pointer” referencing a location (in [0104] as published example, the pointer is a URL).
Claim 9 narrows the abstract idea by stating the metadata parameters are either name, location, description, profile.
Claim 10 narrows the abstract idea by stating there is a ranked list of actions based on characteristics for a display format. Display format could just be an “ordered list” (See [0041, 0064]), and a description is then also displayed to the customer service agent. [0062-0064] also give examples of display format based on characteristics where display format is “text description that describes what the candidate action will do” including “contact someone, generate a report… issue a coupon, issue a refund.
Claim 11 narrows the abstract idea by receiving positive/success feedback from a person, and then subsequently selecting such a candidate action for an incident.
Claim 12 narrows the abstract idea by having customer service agent make “a selection.” To extent this is clicking/selecting in GUI, this is an additional element and is rejected under step 2a, prong 2 and step 2B for same reasons as claim 1 - “apply it [abstract idea] on a computer” (MPEP 2106.05f) and “field of use” (MPEP 2106.05h).
Claim 13 has response model as “rules-based” OR “artificial intelligence”. “Rules-based” model is considered narrowing the abstract idea in the determination of rules to follow and/or mathematical relationship, based on [0113] as published example is “set of rules indirectly specify a mathematical model”. Even if amended to require “artificial intelligence,” this is considered at this high level to be [abstract idea] on a computer (MPEP 2106.05f – “by machine learning”) and field of use (MPEP 2106.05h).
Claim 14-15 has selecting an endpoint based on alternative considerations. This encompasses narrowing the abstract idea to extent selection based on “historical performance” (resolving customer incident), or “type of incident, identity of customer,” or “previous characteristic of action retrieved”; claim 15 alternatives are date, time, problem description, customer name, customer organization, support plan level.
Claim 16 narrows abstract idea by updating incident management by removing an interface element corresponding to a target action, as example [0098] is for duplicate actions; [0101] just removes any a person (customer service agent) chooses to remove. To extent this is on a display of a computer, this is considered to be “apply it [abstract idea] on a computer” (MPEP 2106.05f) and “field of use” (MPEP 2106.05h).
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
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-3, 6-7, 10-12, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Jain (US 2019/0108470) and further in view of Sachan (US 2020/0293946).
Concerning claim 1, Jain discloses:
A method, comprising: (Jain – See par 123 – computing device 1300 includes one or more processors; Processor circuit 1302 may execute program code stored in a computer readable medium, such as program code of operating system 1330, application programs 1332, other programs 1334, etc; see par 130 - computer programs and modules (including application programs 1332 and other programs 1334) may be stored on the hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Computer programs, when executed or loaded by an application, enable computing device 1300 to implement features of embodiments discussed herein.), cause:
configuring a first response model at a first endpoint (Jain – see par 43 - In system 200, server(s) 230 execute an automated incident handler 232 for managing incidents generated or received by server(s) 230, according to an example embodiment. Server(s) 230 may represent a processor-based electronic device capable of executing computer programs installed thereon, and automated incident handler 232 may comprise such a computer program that is executed by server(s) 230. see par 50 - Automated incident handler 432 of FIG. 4 may be substantially similar to automated incident handler 132 described above with reference to FIG. 1 or automated incident handler 232 described above with reference to FIG. 2. par 58 – incident handler 432 includes …model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports));
configuring a second response model at a second endpoint, the second response model being different than the first response model (Jain see par 43 - In system 200, server(s) 230 execute an automated incident handler 232 for managing incidents generated or received by server(s) 230, according to an example embodiment. Server(s) 230 may represent a processor-based electronic device capable of executing computer programs installed thereon, and automated incident handler 232 may comprise such a computer program that is executed by server(s) 230. see par 47 - an incident handler user interface (UI) 242 may be provided on computing device(s) 240 that provides a user with the ability to select any of the one or more suggested actions received from automated incident handler 232 of server(s) 230, including a subset thereof, to execute on server(s) 230 to respond to an incident. see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions corresponding to more than one priority determination, confidence value, or ranking. For instance, as an illustrative example, model 444 may output three separate sets of suggested actions based on the three highest confidence values or rankings. In another embodiment, model 444 may be configured to output one or more suggested actions only model 444 has been trained by model generator 440 with a predetermined threshold of learned behaviors for the incident report corresponding to the feature vector.
Jain discloses multiple servers and computing devices and a cloud server network (See par 35 and 40-43). Jain discloses computing devices 120, 130 communicate via one or more application programming interfaces (API) (See par 34). To any extent Jain does not disclose, Sachan discloses “endpoint”
first “endpoint”… configuring a second response model at a second “endpoint,” the second response model being different than the first response model (Sachan see par 163 - machine learning based incident nature model 130) may be retrained with the latest information on a regular schedule. In this regard, FIG. 12 illustrates a machine learning based predictive model retraining flow to illustrate operation of the apparatus 100 ; see par 166 - At block 1204, when a machine learning based predictive model is deployed as a web service, this may result in the generation of a “default endpoint”, which may represent a uniform resource locator address; see par 169 – can use “new scoring endpoint” with retraining).
Jain and Sachan disclose:
receiving a target customer incident (Jain see par 38, 40 - computing device(s) 130 include an automated incident handler 132 for managing incidents generated or received by computing device(s) 130, according to an example embodiment. see par 49 - Flowchart 300 begins with step 302. In step 302, an incident report is received);
obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident (Jain –
see par 50 - Automated incident handler 432 of FIG. 4 may be substantially similar to automated incident handler 132; As shown in FIG. 4, automated incident handler 432 comprises a response logger 434, an incident generator 436, a featurizer 438, a model generator 440, an action recommender 442 comprising a model 444; see par 54 – feature vector provided to machine-learning based model; featurizer 438 provided 456 as input to model 444 used by action recommender; Action recommender 442 uses a machine-learning-based model 444 to recommend a set of actions for a given incident report. incident.);
displaying the output comprising the target candidate action for the target customer incident in a graphical user interface (GUI) (Jain – see par 58 - model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports); par 61 - In embodiments, action recommender 442 may take into account additional factors in determining the one or more suggested actions to output, and/or how the one or more suggested actions are prioritized or ranked); see par 69 - model 444 may make a priority determination, determine a confidence value, or determine a ranking regarding the suggested actions based on the prior actions executed in response to the same feature vector corresponding to the incident report; see par 73 - Incident handler UI 242 and incident handler UI 446 may comprise any suitable interface by which a user may view, manage, select, or otherwise interact 460 with the one or more suggested actions outputted by action recommender 442.)
responsive to an interaction with the target candidate action, performing the target candidate action (Jain – see par 72 - a user may remotely select one or more suggested actions output by server(s) 230 through interaction with incident handler UI 242.see par 73 - Incident handler UI 242 and incident handler UI 446 may comprise any suitable interface by which a user may view, manage, select, or otherwise interact 460 with the one or more suggested actions outputted by action recommender 442. see par 79 - With reference to FIG. 4, upon receiving a user's selection of one or more of the suggested actions through a user interface, action executor 448 automatically executes the one or more suggested actions selected by the user.);
wherein the method is performed by at least one device including a hardware processor. (Jain – see par 130 - computer programs, when executed or loaded by an application, enable computing device 1300 to implement features of embodiments discussed herein).
Both Jain and Sachan are analogous art as they are directed to recommending actions/steps to resolving incidents (see Jain Abstract, par 59; Sachan Abstract). Jain discloses multiple servers and computing devices and a cloud server network (See par 35 and 40-43). Jain discloses computing devices 120, 130 communicate via one or more application programming interfaces (API) (See par 34). Sachan improves upon Jain by disclosing explicitly having “endpoints” for various computing and a predictive model where it makes a variety of incident recommendations for resolution from trained machine learning models (See e.g. FIG. 1, par 35-36, 47-48). One of ordinary skill in the art would be motivated to further include using endpoints in incident resolution to efficiently improve upon the recommended actions for handling incidents using server(s) and computing device(s) where communications is over APIs in Jain.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to recommend actions for resolving incidents in Jain to further have endpoints in the formation of a machine learning models for recommending incident resolution as disclosed in Sachan, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 17, Jain and Sachan disclose:
One or more non-transitory computer readable media comprising instructions which, when executed by one or more hardware processors, cause performance of operations comprising (Jain – see par 119 - one or more of the components of computing devices 120A-120N or computing device(s) 130 described above in reference to FIG. 1, computing devices 220A-220N, server(s) 230, or computing device(s) 240 described above with reference to FIG. 2, or computing device 430 described above with reference to FIG. 4, and one or more steps of flowcharts 300, 500, 600, 700, 800, 900, 1000, and 1100 may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium.).
receiving a first response model parameter entered into a configuration GUI (The examples of the “parameters” include [0105] as published “the parameters specific to the user-selected response model may include any of the following: a name associated with the user-selected response model, a description of a purpose of the user-selected response model, selection of one or more profiles having access to the user-selected response model, authentication information for access to the user-selected response model, etc.”
Jain – see par 63 - For example, incident handler UI 446 may provide an interface for a user to specify one or more preferences or settings that affect a type and/or ordering of suggested actions output by action recommender 442. see par 64 - In yet another embodiment, a user may configure action recommender 442 to output suggested actions based on the type of actions preferred by a user. For example, where a user prefers only certain types of actions in responding to a given incident report, action recommender 442 may be configured, through incident handler UI 446, to output or prioritize the types of actions consistent with the user's preferences; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible.
see also Sachan – see par 120 - the incident 110 may include limited information such as description and short description that may be in textual form; see par 159 - automated resolution represents a configurable process that lets the automated incident resolver 106 know if a process or a component may be implemented with a correct set of parameters to resolve the underlying issue. These set of parameters may represent the inputs (e.g., server name, job name, error number, error description, etc.) needed by a function to perform automated resolution. If the underlying issue can be resolved by the automated incident resolver 106, the automated incident resolver 106 may further determine whether the incident is resolved, and close any related incident ticket. If the underlying issue is not an appropriate candidate for automated resolution, further processing may proceed to determine recommendations by the incident recommender 122, user sentiment score, and Level-3 ticket prediction.);
receiving a second response model parameter entered into the configuration GUI (Jain – see par 63 - For example, incident handler UI 446 may provide an interface for a user to specify one or more preferences or settings that affect a type and/or ordering of suggested actions output by action recommender 442. see par 64 - In yet another embodiment, a user may configure action recommender 442 to output suggested actions based on the type of actions preferred by a user. For example, where a user prefers only certain types of actions in responding to a given incident report, action recommender 442 may be configured, through incident handler UI 446, to output or prioritize the types of actions consistent with the user's preferences; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible.
see also Sachan – see par 120 - the incident 110 may include limited information such as description and short description that may be in textual form; see par 159 - automated resolution represents a configurable process that lets the automated incident resolver 106 know if a process or a component may be implemented with a correct set of parameters to resolve the underlying issue. These set of parameters may represent the inputs (e.g., server name, job name, error number, error description, etc.) needed by a function to perform automated resolution);
configuring a first response model at a first endpoint based on the first response model parameter (Jain – see par 43 - In system 200, server(s) 230 execute an automated incident handler 232 for managing incidents generated or received by server(s) 230, according to an example embodiment. Server(s) 230 may represent a processor-based electronic device capable of executing computer programs installed thereon, and automated incident handler 232 may comprise such a computer program that is executed by server(s) 230. see par 50 - Automated incident handler 432 of FIG. 4 may be substantially similar to automated incident handler 132 described above with reference to FIG. 1 or automated incident handler 232 described above with reference to FIG. 2. par 58 – incident handler 432 includes …model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports; see par 63-66 as above – actions recommended based on preferences, settings, type, and other factors).
The remaining limitations are the same as claim 1 and are rejected for the same reasons. It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above.
Concerning independent claim 19, Jain and Sachan disclose:
A system comprising:
one or more hardware processors;
one or more non-transitory computer-readable media; and
program instructions stored on the one or more non-transitory computer-readable media which, when executed by one or more hardware processors, cause the system to perform operations comprising: (Jain – see par 119 - one or more of the components of computing devices 120A-120N or computing device(s) 130 described above in reference to FIG. 1, computing devices 220A-220N, server(s) 230, or computing device(s) 240 described above with reference to FIG. 2, or computing device 430 described above with reference to FIG. 4, and one or more steps of flowcharts 300, 500, 600, 700, 800, 900, 1000, and 1100 may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer readable storage medium.).
…
wherein the first response model (a) includes a first logic for generating one or more candidate actions and (b) is configured to generate a first output by applying the first logic to a first one or more attributes of the target customer incident (Applicant’s [0036] as published - Moreover, attributes associated with the customer incident 116 may include date of incident, time of incident, user input (text, images, logs, etc.) describing the problem that the customer is experiencing, service agent input (text, images, logs, etc.) describing the problem that the customer is experiencing, operating system (OS) version of customer device, application(s) currently running on customer device, application(s) version, customer name, customer organization, support plan level (for customers who subscribe to a particular service plan designed to address software/hardware issues at a customer site), tabs or windows open on browser of customer device, etc) (Jain – see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436. ); and
the second response model (a) includes a second logic for generating one or more candidate actions and (b) is configured to generate a second output by applying the second logic to a second one or more attributes of the target customer incident (Jain see par 47 - an incident handler user interface (UI) 242 may be provided on computing device(s) 240 that provides a user with the ability to select any of the one or more suggested actions received from automated incident handler 232 of server(s) 230, including a subset thereof, to execute on server(s) 230 to respond to an incident. see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions ; see also Sachan par 163-169 – endpoints; new scoring endpoint).
The remaining limitations are the same as claim 1 and are rejected for the same reasons. It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above.
Concerning claims 2 and 18, Jain and Sachan disclose:
The method of claim 1:
wherein the first response model (a) includes a first logic for generating one or more candidate actions and (b) is configured to generate a first output by applying the first logic to a first one or more attributes of the target customer incident (Jain – see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436); and
the second response model (a) includes a second logic for generating one or more candidate actions and (b) is configured to generate a second output by applying the second logic to a second one or more attributes of the target customer incident (Jain see par 47 - an incident handler user interface (UI) 242 may be provided on computing device(s) 240 that provides a user with the ability to select any of the one or more suggested actions received from automated incident handler 232 of server(s) 230, including a subset thereof, to execute on server(s) 230 to respond to an incident. see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions ; see also Sachan par 163-169 – endpoints; new scoring endpoint).
It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above.
Concerning claim 3, Jain discloses:
The method of claim 1:
wherein the GUI is a candidate action GUI configured to display candidate actions from different response models (Jain -see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions corresponding to more than one priority determination, confidence value, or ranking. For instance, as an illustrative example, model 444 may output three separate sets of suggested actions based on the three highest confidence values or rankings. In another embodiment, model 444 may be configured to output one or more suggested actions only model 444 has been trained by model generator 440 with a predetermined threshold of learned behaviors for the incident report corresponding to the feature vector); and
the method further comprises:
receiving a first response model parameter entered into a configuration GUI (The examples of the “parameters” include [0105] as published “the parameters specific to the user-selected response model may include any of the following: a name associated with the user-selected response model, a description of a purpose of the user-selected response model, selection of one or more profiles having access to the user-selected response model, authentication information for access to the user-selected response model, etc.”
Jain – see par 63 - For example, incident handler UI 446 may provide an interface for a user to specify one or more preferences or settings that affect a type and/or ordering of suggested actions output by action recommender 442. see par 64 - In yet another embodiment, a user may configure action recommender 442 to output suggested actions based on the type of actions preferred by a user. For example, where a user prefers only certain types of actions in responding to a given incident report, action recommender 442 may be configured, through incident handler UI 446, to output or prioritize the types of actions consistent with the user's preferences; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible.
see also Sachan – see par 120 - the incident 110 may include limited information such as description and short description that may be in textual form; see par 159 - automated resolution represents a configurable process that lets the automated incident resolver 106 know if a process or a component may be implemented with a correct set of parameters to resolve the underlying issue. These set of parameters may represent the inputs (e.g., server name, job name, error number, error description, etc.) needed by a function to perform automated resolution. If the underlying issue can be resolved by the automated incident resolver 106, the automated incident resolver 106 may further determine whether the incident is resolved, and close any related incident ticket. If the underlying issue is not an appropriate candidate for automated resolution, further processing may proceed to determine recommendations by the incident recommender 122, user sentiment score, and Level-3 ticket prediction);
configuring the first response model based on the first response model parameter (Jain – see par 43 - In system 200, server(s) 230 execute an automated incident handler 232 for managing incidents generated or received by server(s) 230, according to an example embodiment. Server(s) 230 may represent a processor-based electronic device capable of executing computer programs installed thereon, and automated incident handler 232 may comprise such a computer program that is executed by server(s) 230. see par 50 - Automated incident handler 432 of FIG. 4 may be substantially similar to automated incident handler 132 described above with reference to FIG. 1 or automated incident handler 232 described above with reference to FIG. 2. par 58 – incident handler 432 includes …model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports; see par 63-66 as above – actions recommended based on preferences, settings, type, and other factors);
receiving a second response model parameter entered into the configuration GU (Jain – see par 63 - For example, incident handler UI 446 may provide an interface for a user to specify one or more preferences or settings that affect a type and/or ordering of suggested actions output by action recommender 442. see par 64 - In yet another embodiment, a user may configure action recommender 442 to output suggested actions based on the type of actions preferred by a user. For example, where a user prefers only certain types of actions in responding to a given incident report, action recommender 442 may be configured, through incident handler UI 446, to output or prioritize the types of actions consistent with the user's preferences; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible.
see also Sachan – see par 120 - the incident 110 may include limited information such as description and short description that may be in textual form; see par 159 - automated resolution represents a configurable process that lets the automated incident resolver 106 know if a process or a component may be implemented with a correct set of parameters to resolve the underlying issue. These set of parameters may represent the inputs (e.g., server name, job name, error number, error description, etc.) needed by a function to perform automated resolution)I; and
configuring the second response model based on the second response model parameter (Jain – see par 43 - In system 200, server(s) 230 execute an automated incident handler 232 for managing incidents generated or received by server(s) 230, according to an example embodiment. Server(s) 230 may represent a processor-based electronic device capable of executing computer programs installed thereon, and automated incident handler 232 may comprise such a computer program that is executed by server(s) 230. see par 50 - Automated incident handler 432 of FIG. 4 may be substantially similar to automated incident handler 132 described above with reference to FIG. 1 or automated incident handler 232 described above with reference to FIG. 2. par 58 – incident handler 432 includes …model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports; see par 63-66 as above – actions recommended based on preferences, settings, type, and other factors).
It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above.
Concerning claim 6, Jain and Sachan disclose:
The method of claim 1:
wherein obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident comprises:
obtaining a first output from the first endpoint (Jain – see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions corresponding to more than one priority determination, confidence value, or ranking. For instance, as an illustrative example, model 444 may output three separate sets of suggested actions based on the three highest confidence values or rankings.);
obtaining a second output from the second endpoint (Jain – see par 40 - An information technology incident may also include any type of report relating to a customer-impacting issue, where a customer relies on, operates, or otherwise utilizes any of computing devices 120A-120N. see par 62 - In yet another scenario, action recommender 442 may consider that certain actions resolved an incident report with relatively little to no customer impact compared to alternative actions that resulted in a greater customer impact during resolution.
Sachan – see par 49 - The incident recommender 122 may determine, based on the incident metadata, key phrases associated with the incident 110. The incident recommender 122 may determine, based on the key phrases associated with the incident 110, a historical incident, from a plurality of historical incidents, which includes a high confidence score based on a match to the incident 110. Further, the incident recommender 122 may determine, based on the historical incident, the incident resolution recommendation 126. see par 167 - machine learning based predictive model may be deployed as a web service. The web service endpoints that are thus generated may be treated as a common endpoint for all subsequent retraining calls. see par 168 - At block 1208, in order to retrain the machine learning based predictive model with new data, the web service endpoint created at block 1206 may be utilized); and
displaying the first output and the second output in the GUI (Jain – see par 69 - In another embodiment, model 444 may output a plurality of sets of suggested actions corresponding to more than one priority determination, confidence value, or ranking. For instance, as an illustrative example, model 444 may output three separate sets of suggested actions based on the three highest confidence values or rankings.).
Concerning claim 7, Jain and Sachan disclose:
The method of claim 1:
wherein the first response model comprises a machine learning model (Jain – see par 54 - . Action recommender 442 uses a machine-learning-based model 444 to recommend a set of actions for a given incident report, wherein the model is generated by model generator 440 and is trained 458 on the behaviors of one or more users in responding to incident reports as logged by response logger 434.) configured to select one or more candidate actions to display in the GUI based on detection of a particular set of attributes associated with a particular customer incident (Jain –see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436.. ); and
wherein configuring the first response model at the first endpoint comprises:
obtaining a plurality of parameters that associate the target candidate action with a type of customer incident having a same attribute as the target candidate action, the target candidate action comprising content relevant to the type of customer incident (Jain - see par 63 - For example, incident handler UI 446 may provide an interface for a user to specify one or more preferences or settings that affect a type and/or ordering of suggested actions output by action recommender 442; see par 70 - In another embodiment, which will be discussed in greater detail below with reference to FIG. 11, action recommender 442 may output one or more suggested actions based one or more feature vectors that are determined to be similar to the input feature vector and that correspond to other incident reports. see par 107 - In step 1106, one or more suggested actions are automatically determined based on a similarity between the feature vector corresponding to the generated incident report and one or more feature vectors associated with previous incident reports.)
Concerning claim 10, Jain and Sachan disclose:
The method of claim 1, further comprising:
generating a ranked list of one or more candidate actions including the target candidate action (Jain – see par 58 - model 444 used by action recommender 442 to recommend actions may be trained based on previous actions executed in relation to previous incident reports); par 61 - In embodiments, action recommender 442 may take into account additional factors in determining the one or more suggested actions to output, and/or how the one or more suggested actions are prioritized or ranked); see par 69 - model 444 may make a priority determination, determine a confidence value, or determine a ranking regarding the suggested actions based on the prior actions executed in response to the same feature vector corresponding to the incident report); and
selecting a display format for displaying the ranked list of candidate actions based on characteristics of the one or more candidate actions (Applicant’s [0041, 0062-0064 as published states “. Any suitable format for a candidate action may be selected, such as an ordered list, an audio playback element, a video playback element, a thumbnail image, a frame, and a grid”; display format may include a text description that describes what the candidate action will do if selected by the service agent, such as a function that will be performed, e.g., copy, paste, contact someone (via email, phone, etc.), generate a report with attributes 302 of the customer incident 116, issue a coupon, issue a refund, refer customer incident 116 to another service or support agent, retrieve additional documentation regarding the customer incident 116 (user manual, installation manual, operating system requirements, etc.), display a set of ordered steps to resolve the customer incident 116, etc.)
Jain see par 67 - ] The techniques in which action recommender 442 may consider additional personalized factors in outputting one or more suggested actions are not, however, limited to the above examples. Action recommender 442 may consider any combination of the above factors, or any other facts as may be understood and appreciated by one skilled in the relevant art, in outputting, prioritizing, and/or ranking suggested actions. see par 69 - model 444 may make a priority determination, determine a confidence value, or determine a ranking regarding the suggested actions based on the prior actions executed in response to the same feature vector corresponding to the incident report. In this embodiment, model 444 may output one or more suggested actions based on the highest priority determination, confidence value or ranking indicative of how a user is likely to respond to the incident report. ); and
displaying a description of the target candidate action in accordance with the display format (Jain – see par 100 - action recommender 442 may be configured to output a series of suggested actions for closing an incident. For instance, FIG. 9 shows a flowchart 900 for permitting a user to select a subset of a series of suggested actions, according to an example embodiment. see par 101-102 - FIG. 4, action recommender 442 may output a series of suggested actions, through model 444, such as a set of actions or an entire orchestrated sequence of actions to be performed in a specified order based on a feature vector extracted by featurizer 438 corresponding to an incident report generated by incident generator 436.).
Concerning claim 11, Jain and Sachan disclose:
The method of claim 1, further comprising:
receiving feedback for a first candidate action selected in association with a particular customer incident, the feedback for the first candidate action indicating a selection or success of the first candidate action (Jain – see par 60 - action recommender 442 may output a single suggested action, a set of suggested actions, or an entire orchestrated sequence of suggested actions to be performed in a particular order based on previously learned behaviors in model 444 generated by model generator 440.
Sachan –see par 48 - The incident recommender 122 may analyze the incident data by a trained machine learning based incident nature model 130. Further, the incident recommender 122 may determine, based on the analysis of the incident data by the trained machine learning based incident nature model 130, the incident nature recommendation 124. see par 141 - The proactive Bot may also collect feedback data from a user, and use the feedback data to determine the relevance percentage of recommendations in order to better train and/or retrain the machine learning based models as disclosed herein. ); and
selecting a subsequent candidate action for a subsequent customer incident based on the feedback (Jain – see par 96 - As the number of logged incident reports and actions taken in response to logged incidents continues to increase in response logger 434, model generator 440 may continuously train model 444, thereby rendering model 444 increasingly accurate in suggesting one or more actions to execute in response to an input feature vector corresponding to an incident report generated by incident generator 436.).
It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above.
Concerning claim 12, Jain and Sachan disclose:
The method of claim 1: wherein the interaction comprises a selection from a ranked list of a plurality of candidate actions displayed in the GUI, the ranked list of the plurality of candidate actions including the target candidate action (Jain – see par 73 - ] Incident handler UI 242 and incident handler UI 446 may comprise any suitable interface by which a user may view, manage, select, or otherwise interact 460 with the one or more suggested actions outputted by action recommender 442. For instance, incident handler UI 242 and incident handler UI 446 may be any one of a graphical user interface; see par 77 - in this manner, a user may utilize the displayed priority determination, confidence value or ranking in determining whether to select one or more of the suggested actions provided by model 444.).
Concerning claim 16, Jain and Sachan disclose:
The method of claim 1, further comprising:
responsive to the interaction with the target candidate action in the GUI, updating an incident management interface by:
removing an interface element of the GUI corresponding to the target candidate action from a plurality of interface elements respectively representing a plurality of possible candidate actions of a ranked list of candidate actions for addressing the target customer incident (Jain – see par 31 - The automated incident handler may provide an interface by which a user may accept the suggested actions, modify the suggested actions, reject the suggested actions, or select only a subset of actions to execute. see par 76 - Incident handler UI 242 and incident handler UI 446 may also be configured to permit a user to add, modify, or remove a text-based input in addition to selecting one or more suggested actions).
Claims 4-5, 8-9, 13-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jain (US 2019/0108470) and further in view of Sachan (US 2020/0293946), as applied to claims 1-3, 6-7, 10-12, and 16 above, and further in view of Masood et al., “Cognitive Computing Recipes: Artificial Intelligence Solutions Using Microsoft Cognitive Services and TensorFlow,” 2019, Apress, Chapter 6, pages 289-310.
Concerning claims 4 and 20, Jain and Sachan disclose:
The method of claim 1:
wherein receiving the target customer incident comprises receiving a target customer incident and an attribute of the target customer incident (See [0036] as published - Moreover, attributes associated with the customer incident 116 may include date of incident, time of incident, user input (text, images, logs, etc.) describing the problem that the customer is experiencing, service agent input (text, images, logs, etc.) describing the problem that the customer is experiencing, operating system (OS) version of customer device, application(s) currently running on customer device, application(s) version, customer name, customer organization, support plan level (for customers who subscribe to a particular service plan designed to address software/hardware issues at a customer site), tabs or windows open on browser of customer device, etc –
Jain discloses the limitations based on broadest reasonable interpretation in light of the specification– see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436;
see also Sachan par 196 - At block 1406, the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. all incident attributes in the repository may be compared to find common patterns. The top three most occurring common behaviors may be considered as the dominant patterns;
wherein obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident comprises:
selecting the first endpoint based on the attribute (Jain – see par 70 - action recommender 442 may output one or more suggested actions based one or more feature vectors that are determined to be similar to the input feature vector and that correspond to other incident reports; see par 105 - In an embodiment, automated incident handler 132, automated incident handler 232, and/or automated incident handler 432 may orchestrate a set of suggested actions based on a similarity between a generated feature vector and feature vector(s) of previous incident reports;
see also Sachan – see par 167 - At block 1206, in order to enable retraining of the machine learning based predictive model, a web service output may be added to the trained machine learning based predictive model created at block 1200, and the machine learning based predictive model may be deployed as a web service. The web service endpoints that are thus generated may be treated as a common endpoint for all subsequent retraining calls; At block 1210, the application programming interface may be called to replace the machine learning based predictive model for the “new scoring endpoint” (initially saved as part of the training experiment), with the one retrained above passing in its uniform resource locator generated at block 1208. The “new scoring endpoint” may include a new uniform resource locator similar to the sample endpoint; The “new scoring endpoint” may now use the retrained machine learning based predictive model. Using the “new scoring endpoint”, the machine learning based predictive model may be retrained on a regular schedule with the latest data.)
To any extent Jain and Sachan do not disclose, Masood discloses:
wherein obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident comprises:
selecting the first endpoint based on the attribute (Masood – see page 289, 1st paragraph – knowledge management deals with identifying, capturing, storing, retrieving… information; imagine working as a helpdesk representative and receiving a ticket to address a certain issue within an application; consider getting all the information associated with this ticket, such as similar tickets and their fixes,… standard operating procedures, and other knowledge-base items associated with the application, such as wiki articles; the knowledge graph associated with this application even recommends a potential fix and provides information; see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence. page 292, last paragraph – Building cognitive knowledge-base systems requires a variety of AI and machine learning components to come together).
Jain, Sachan, and Masood disclose:
inputting the attribute into the first endpoint to cause the first response model to output the target candidate action based on the attribute (Jain – see par 105 - In an embodiment, automated incident handler 132, automated incident handler 232, and/or automated incident handler 432 may orchestrate a set of suggested actions based on a similarity between a generated feature vector and feature vector(s) of previous incident reports; see par 107 - In step 1106, one or more suggested actions are automatically determined based on a similarity between the feature vector corresponding to the generated incident report and one or more feature vectors associated with previous incident reports;
see also Masood - see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence).
It would have been obvious to combine Jain and Sachan for the same reasons as claim 1 above. In addition, Jain, Sachan, and Masood are analogous art as they are directed to recommending actions/steps to resolving incidents (see Jain Abstract, par 59; Sachan Abstract; Masood page 289-290). Jain discloses suggesting actions based on feature vectors and similarity (See par 70, 105). Sachan discloses having machine learning predictive model for incidents using web service endpoints (see par 159, 163-166). Masood improves upon Jain and Sachan by disclosing knowledge graphs can recommend potential fixes along with geotargeted search results by cognitive services (See page 289-290) and intelligent search of endpoints used in knowledge repository to provide relevant answers. One of ordinary skill in the art would be motivated to further include intelligent search of endpoints for relevant answers to efficiently improve upon the recommended actions for handling incidents using server(s) and computing device(s) where communications is over APIs in Jain and the web service endpoints for incident information in Sachan.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to recommend actions for resolving incidents in Jain to further have endpoints in the formation of a machine learning models for recommending incident resolution as disclosed in Sachan, and to further have intelligent search of endpoints by cognitive systems to provide relevant answers to problems as disclosed in Masood, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning claim 5, Jain discloses having “computing devices 120A-120N and computing device(s) 130 may communicate via one or more application programming interfaces (API)” and computing devices executing services (See par 34-36). Jain also discloses that semantic-based features of an incident include “domain-specific information”, global unique identifiers (GUIDs), universal resource locators (URLs), error codes, geography, customer/user identities (See par 91).
Sachan discloses:
The method of claim 1, wherein:
the first endpoint comprises a representational state transfer (REST) endpoint (Sachan – see par 165 - At block 1202, the trained machine learning based predictive model may be deployed, for example, as a web service. In this regard, the trained machine learning based predictive model may be implemented in a Cloud space, and the trained machine learning based predictive model may be utilized in real time prediction, for example, through REST application programming interfaces. see par 166 - At block 1204, when a machine learning based predictive model is deployed as a web service, this may result in the generation of a “default endpoint”, which may represent a uniform resource locator address..)
Jain and Sachan disclose:
the first response model is machine learning model (Jain – see par 54 – feature vector provided to machine-learning based model; featurizer 438 provided 456 as input to model 444 used by action recommender; Action recommender 442 uses a machine-learning-based model 444 to recommend a set of actions for a given incident report, wherein the model is generated by model generator 440 and is trained 458 on the behaviors of one or more users in responding to incident reports as logged by response logger 434. For example, response logger 434 may be configured to log each action a user, such as an administrator responsible for responding for handling incident reports, performs to in response to a given incident report. In an embodiment, response logger 434 may log an entire sequence of actions a user performs in response to a given incident report. see par 96 - As the number of logged incident reports and actions taken in response to logged incidents continues to increase in response logger 434;
Sachan – see par 165 - At block 1202, the trained machine learning based predictive model may be deployed, for example, as a web service); and
configuring the first response model at the first endpoint comprises:
accessing (a) a reference pointer referencing a location (Sachan – see par 166 - At block 1204, when a machine learning based predictive model is deployed as a web service, this may result in the generation of a “default endpoint”, An example of an endpoint may include “https://<<endpoint>>.services.azureml.net/workspaces/<<workspaceid>>/services/<<servicesid>>/execute?api-version=2.0&details=true”. The web service uniform resource locator, as well as the web service application programming interface may be obtained, and using these endpoints, the machine learning based predictive model may be utilized; see par 169 – at 1210 can use “new scoring endpoint”;
see also Masood see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence) and (b) a metadata parameter associated with the first response model (0069] as published gives examples “metadata may be included with the candidate actions that indicates characteristics of the candidate actions, such as type of action, display format, content, etc
Jain - see par 65 - In yet another embodiment, action recommender 442 may consider the attributes of a user (e.g., a user of computing device 430). For example, computing device 430 may contain metadata regarding its user; Action recommender may take any of these attributes into account in tailoring which suggested actions to output, the prioritization of the actions, and/or ranking of the actions; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible. see par 105 - a set of suggested actions based on a similarity between a generated feature vector and feature vector(s) of previous incident reports. For instance, FIG. 11 shows a flowchart 1100 for enabling an automated handling of an information technology incident report based on a determined similarity to previous incident reports
see also Sachan – see par 174 - The machine learning based incident classification model 114 may be trained as a two class machine learning model with input parameters as short description, description of the incident ticket, and other technical parameters such as the severity, email alias, etc. ); and
configuring the REST endpoint at the location referenced by the reference pointer by (Jain – see par 91 - Featurizer 438 may featurize an incident report in any other suitable manner… Context- and semantic-based featurization may also be performed by featurizer 210 to provide structure to unstructured information that is received. For example, semantic-based feature sets may be extracted by featurizer 438 for technical phrases from the incident report. Sematic-based features sets may comprise, without limitation, domain-specific information and terms such as global unique identifiers (GUIDs), universal resource locators (URLs), emails, error codes, customer/user identities, geography, times/timestamps, and/or the like. Count- and/or correlation-based feature selection as featurization may also be performed by featurizer 438 on text associated with the normalized incident report to determine if system/service features are present and designate such system/service features in the feature vector.
Sachan – see par 167 - machine learning based predictive model may be deployed as a web service. The web service endpoints that are thus generated may be treated as a common endpoint for all subsequent retraining calls. see par 168 - At block 1208, in order to retrain the machine learning based predictive model with new data, the web service endpoint created at block 1206 may be utilized… When the retraining operation is complete, the uniform resource locator of the retrained machine learning based predictive model may be returned;
see also Masood see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence):
hosting the machine learning model at the REST endpoint (Jain – see par 29 – servers may include web server; Each server and user computer may have various applications installed that are needed to support the function of the computer. Incident management systems may continuously and automatically monitor any of these servers and/or computers connected to the network for proper operation, and generate an incident report upon detecting a potential issue on one or more devices or the network itself. see par 36 - A “supporting service” is a cloud computing service/application configured to manage a set of servers (e.g., a cluster of servers in servers) to operate as network-accessible (e.g., cloud-based) computing resources for users. Examples of supporting services include Microsoft® Azure®, Amazon Web Services™, Google Cloud Platform™, IBM® Smart Cloud, etc. A supporting service may be configured to build, deploy, and manage applications and services on the corresponding set of servers), the machine learning model being configured to select a selected candidate action to display in the GUI based on a particular attribute being input into the machine learning model (Jain – see par 61 - For instance, in one embodiment, action recommender 442 may take into account training data across a plurality of users, such as a plurality of users, groups, or teams within a larger organization. In other embodiments, action recommender 442 may consider one or more factors that are personalized to a user in outputting suggested actions. see par 65 - action recommender 442 may consider the attributes of a user (e.g., a user of computing device 430). see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible; see par 54, 91 – Featurizer 438 extracts…Sematic-based features sets may comprise, without limitation, domain-specific information and terms such as global unique identifiers (GUIDs), universal resource locators (URLs), emails, error codes, customer/user identities, geography, times/timestamps, and/or the like; features given to action recommender 442 that uses machine-learning based model 444 to recommend actions); and
configuring the REST endpoint to output the selected candidate action in accordance with the metadata parameter in response to detecting that the target customer incident is associated with the particular attribute (Jain – see par 64 - where a user prefers only certain types of actions in responding to a given incident report, action recommender 442 may be configured, through incident handler UI 446, to output or prioritize the types of actions consistent with the user's preferences. see par 65 - action recommender 442 may consider the attributes of a user (e.g., a user of computing device 430). For example, computing device 430 may contain metadata regarding its user, such as the user's domain expertise, job type/description (e.g., a developer versus a service engineer), level (e.g., based on years of employment or managerial status), geographic location, responsibility/ownership of certain services, products, and/or components; see par 66 - action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible. In another example, action recommender 442 may take into account the types of incident reports assigned to a particular team in the past, and/or the types of actions one or more members of the team recently executed. In another embodiment, action recommender 442 may consider a dependency graph of a particular team's services relative to one or more other teams' services;
see also Sachan – par 163 - In this regard, FIG. 12 illustrates a machine learning based predictive model retraining flow to illustrate operation of the apparatus 100 in accordance with an example of the present disclosure; see par 48 -the incident recommender 122 may analyze the incident data by a trained machine learning based incident nature model 130. Further, the incident recommender 122 may determine, based on the analysis of the incident data by the trained machine learning based incident nature model 130, the incident nature recommendation 124. see par 49 - the incident recommender 122 may generate, for the selected support personnel 120, the incident resolution recommendation 126 by generating incident metadata for the incident 110. The incident recommender 122 may determine, based on the incident metadata, key phrases associated with the incident 110;
see also Masood see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence)
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and 4 above.
Concerning claim 8, Jain and Sachan disclose:
The method of claim 1:
wherein configuring the first response model at the first endpoint comprises:
accessing (a) at least a first metadata parameter for the first response model and (0069] as published gives examples “metadata may be included with the candidate actions that indicates characteristics of the candidate actions, such as type of action, display format, content, etc
Jain - see par 65 - In yet another embodiment, action recommender 442 may consider the attributes of a user (e.g., a user of computing device 430). For example, computing device 430 may contain metadata regarding its user; Action recommender may take any of these attributes into account in tailoring which suggested actions to output, the prioritization of the actions, and/or ranking of the actions; see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible. see par 105 - a set of suggested actions based on a similarity between a generated feature vector and feature vector(s) of previous incident reports. For instance, FIG. 11 shows a flowchart 1100 for enabling an automated handling of an information technology incident report based on a determined similarity to previous incident reports) (b) a first reference pointer referencing a first address (Sachan – see par 166 - At block 1204, when a machine learning based predictive model is deployed as a web service, this may result in the generation of a “default endpoint”, An example of an endpoint may include “https://<<endpoint>>.services.azureml.net/workspaces/<<workspaceid>>/services/<<servicesid>>/execute?api-version=2.0&details=true”. The web service uniform resource locator, as well as the web service application programming interface may be obtained;
see also Masood page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence); and
configuring the first endpoint, at the first address, to output, in accordance with the first metadata parameter, one or more candidate actions selected by the first response model (Jain – see par 105 - In an embodiment, automated incident handler 132, automated incident handler 232, and/or automated incident handler 432 may orchestrate a set of suggested actions based on a similarity between a generated feature vector and feature vector(s) of previous incident reports; see par 107 - In step 1106, one or more suggested actions are automatically determined based on a similarity between the feature vector corresponding to the generated incident report and one or more feature vectors associated with previous incident reports;
Sachan – see par 31 - In this regard, metadata with respect to an incident may be analyzed to determine key words. For example, the MICROSOFT prebuilt Cognitive application programming interface specified as Text Analytics Key Phrase may be utilized to determine key phrases and keywords. The incident nature recommendation may be determined, for example, by using a machine learning based incident nature model to predict various incident features such as incident category, subcategory, assignment group, application name, severity, etc; see par 49 - The incident recommender 122 may determine, based on the incident metadata, key phrases associated with the incident 110. The incident recommender 122 may determine, based on the key phrases associated with the incident 110, a historical incident, from a plurality of historical incidents, which includes a high confidence score based on a match to the incident 110; see par 166-169 – endpoints and uniform resource locators for machine learning based predictive model;); and
wherein configuring the second response model at the second endpoint comprises:
accessing (a) at least a second metadata parameter for the second response model and (b) a second reference pointer referencing a second address (Sachan see par 166-169 – endpoints and uniform resource locators for machine learning based predictive model;
see also Masood page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence); and
configuring the second endpoint, at the second address, to output, in accordance with the second metadata parameter, one or more candidate actions selected by the second response model (Jain - see par 66 - action recommender 442 may consider other factors, such as the team, service, or group for which a user of an organization belongs. For example, by considering information regarding a user's role in an organization, action recommender 442 may automatically determine which features of a service, product, or component the user may be responsible. see par 105 - a set of suggested actions; see Sachan par 49 - the incident recommender 122 may determine, based on the historical incident, the incident resolution recommendation 126;
see also Masood - see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence).
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and 4 above.
Concerning claim 9, Jain and Sachan disclose:
The method of claim 8: wherein the first metadata parameter and the second metadata parameter are selected from: a name, a location, a description, a profile selection, a display format; or authentication information (Jain – see par 65 – action recommender 442 may consider attributes of a user, including geographic location; see par 113 - Example data can include web pages, text, images, sound files, video data, or other data to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory 1220 can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.
Sachan – see par 31, 50 – metadata with respect an incident analyzed to determine key words and phrases; see par 34 – incident description; see FIG. 8, par 121 – block 808 - entity recognition- includes names, locations, organizations; FIG. 8, par 132-133 – incident recommendation based on FIG. 8 (which includes 808);
see also Masood – see page 289, 1st paragraph – knowledge management deals with identifying, capturing, storing, retrieving… information; imagine working as a helpdesk representative and receiving a ticket to address a certain issue within an application; consider getting all the information associated with this ticket, such as similar tickets and their fixes, application telemetry data and logs, standard operating procedures, and other knowledge-base items associated with the application, such as wiki articles; the knowledge graph associated with this application even recommends a potential fix and provides information; see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence. page 292, last paragraph – Building cognitive knowledge-base systems requires a variety of AI and machine learning components to come together).
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and 4 above.
Concerning claim 13, Jain and Sachan disclose:
The method of claim 1: wherein the first response model comprises a… model that selects one or more candidate actions to display based on a particular set of attributes associated with a particular customer incident (See [0036] as published - Moreover, attributes associated with the customer incident 116 may include date of incident, time of incident, user input (text, images, logs, etc.) describing the problem that the customer is experiencing, service agent input (text, images, logs, etc.) describing the problem that the customer is experiencing, operating system (OS) version of customer device, application(s) currently running on customer device, application(s) version, customer name, customer organization, support plan level (for customers who subscribe to a particular service plan designed to address software/hardware issues at a customer site), tabs or windows open on browser of customer device, etc
Jain – see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436;
see also Sachan par 196 - At block 1406, the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. all incident attributes in the repository may be compared to find common patterns. The top three most occurring common behaviors may be considered as the dominant patterns.)
Jain discloses having a machine learning based model to recommend actions to respond to incidents (See par 41). Sachan disclose having a “Cognitive” application programming interface for text analysis along with machine learning (See par 31).
Masood discloses:
The method of claim 1: wherein the first response model comprises "a rules-based model or artificial intelligence” model that selects one or more candidate actions to display based on a particular set of attributes associated with a particular customer incident (Masood - see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence. page 292, last paragraph – Building cognitive knowledge-base systems requires a variety of AI and machine learning components to come together; see page 293, 3rd paragraph – introduction to knowledge management… individual components link to build an intelligent knowledge engine).
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and claim 4 above.
Concerning claim 14, Jain and Sachan disclose:
The method of claim 1, wherein:
obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprises:
selecting the first endpoint based on at least one of: a historical performance of a plurality of endpoints including the first endpoint, a type of the target customer incident, an identity of a customer associated with the target customer incident, an availability of the plurality of endpoints, a speed of candidate action acquisition for the plurality of endpoints, or a previous characteristic of a previous candidate action retrieved from the plurality of endpoints (claim is in the alternative;
Jain see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436;
see also Sachan par 196 - At block 1406, the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. all incident attributes in the repository may be compared to find common patterns. The top three most occurring common behaviors may be considered as the dominant patterns;
Masood – see page 289, 1st paragraph – knowledge management deals with identifying, capturing, storing, retrieving… information; imagine working as a helpdesk representative and receiving a ticket to address a certain issue within an application; consider getting all the information associated with this ticket, such as similar tickets and their fixes, application telemetry data and logs, standard operating procedures, and other knowledge-base items associated with the application, such as wiki articles; the knowledge graph associated with this application even recommends a potential fix and provides information; see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence. page 292, last paragraph – Building cognitive knowledge-base systems requires a variety of AI and machine learning components to come together
; and
obtaining the at least one output from the first endpoint (Jain – see par 50, 54 - Action recommender 442 uses a machine-learning-based model 444 to recommend a set of actions for a given incident report. incident; see also Sachan – FIG. 1, incident recommender).
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and 4 above.
Concerning claim 15, Jain and Sachan disclose:
The method of claim 1:
wherein obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprises:
selecting the first endpoint based on one or more attributes of the target customer incident comprising at least one of: a date of the target customer incident, a time of the target customer incident, a user input associated with the target customer incident, a problem description associated with the target customer incident, a service agent input associated with the target customer incident, an operating system version of a customer device associated with the target customer incident, an application run on the customer device associated with the target customer incident, an application version of the application run on the customer device associated with the target customer incident, a customer name associated with the target customer incident, a customer organization associated with the target customer incident, or a support plan level associated with the target customer incident (claim is in the alternative
Jain see par 52- Once the incident report is received, action recommender 442 may provide 456 the incident report to featurizer 438 to generate a feature vector based on the incident report as input to model 444 in determining one or more suggested actions to execute in response to the incident report. Featurizer 438 may extract information from the incident report to generate a feature vector for the incident report. see par 53 - Featurizer 438 may operate in a number of ways to featurize, or generate a feature vector for, an incident report. For example and without limitation, featurizer 438 may featurize an incident report through keyword featurization, semantic-based featurization; Each of these manners of featurization will be discussed in more detail with respect to FIG. 5. See par 54-55 - In this manner, model 444 may be trained based on the actions a user has taken in response to a feature vector corresponding to a previous incident report. action recommender 442 may output a set of suggested actions to execute external to the incident management system based on a feature vector corresponding to an incident report generated by incident generator 436;
see also Sachan par 196 - At block 1406, the incident ticket router 112 may identify a similar behavior or pattern that exists between the new incident identified in the new incident ticket and historical incidents (that are member of the clusters identified at block 1404). The pattern may include a set of one or more features of an incident, such as name, severity, application, issue type, etc. all incident attributes in the repository may be compared to find common patterns. The top three most occurring common behaviors may be considered as the dominant patterns;
Masood – see page 289, 1st paragraph – knowledge management deals with identifying, capturing, storing, retrieving… information; imagine working as a helpdesk representative and receiving a ticket to address a certain issue within an application; consider getting all the information associated with this ticket, such as similar tickets and their fixes, application telemetry data and logs, standard operating procedures, and other knowledge-base items associated with the application, such as wiki articles; the knowledge graph associated with this application even recommends a potential fix and provides information; see page 290, last paragraph – Cognitive services also rely on modern ecosystem of digital assistants and contextual, geotargeted search results; see page 292, 2nd to last paragraph – organization can publish intelligent search endpoints to be utilized by cognitive digital assistants, which can then use the knowledge repository to query the problem description and provide the relevant answer with a higher degree of confidence. page 292, last paragraph – Building cognitive knowledge-base systems requires a variety of AI and machine learning components to come together
; and
obtaining the at least one output from the first endpoint (Jain – see par 50, 54 - Action recommender 442 uses a machine-learning-based model 444 to recommend a set of actions for a given incident report. incident; see also Sachan – FIG. 1, incident recommender; see also Masood page 292 – search endpoints by cognitive digital assistants to query problem description and provide relevant answer).
It would have been obvious to combine Jain and Sachan and Masood for the same reasons as claim 1 and 4 above.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,387,222 in view of Jain (US 2019/0108470) and further in view of Sachan (US 2020/0293946), and Masood, “Cognitive Computing Recipes: Artificial Intelligence Solutions Using Microsoft Cognitive Services and TensorFlow, 2019, Apress, Chapter 6, pages 289-310.
Claims 1-20 are rejected on the ground of nonstatutory double patenting over claims 1-20 of U.S. Patent No. 12,387,222 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows:
App. No. 19/245,739
US 12,387,222 claim 1
A method, comprising: ; wherein the method is performed by at least one device including a hardware processor.
One or more non-transitory machine-readable media storing instructions which, when executed by one or more processors, cause:
configuring a first response model at a first endpoint; configuring a second response model at a second endpoint, the second response model being different than the first response model;
Claim 2 - pull a first set of candidate actions from the first user-defined representational state transfer (REST) endpoint and pull a second set of candidate actions from a second user-defined representational state transfer (REST) endpoint, wherein the plurality of candidate actions includes the first set of candidate actions and the second set of candidate actions
OR claim 5 - inputting the set of attributes into a first response model hosted at a first user-defined representational state transfer (REST) endpoint to obtain a first selection of one or more candidate actions; inputting the set of attributes into a second response model hosted at a second user-defined representational state transfer (REST) endpoint to obtain a second selection of one or more candidate actions;
receiving a target customer incident;
receiving a target customer incident and an associated set of attributes;
Claim 2, 4-5, 7, 13, 15, 18-19 consider “attributes”
based on receiving the target customer incident and the associated set of attributes, obtaining a plurality of candidate actions to address the target customer incident;
obtaining, from at least one of the first endpoint or the second endpoint, at least one output comprising a target candidate action for the target customer incident;
wherein obtaining the plurality of candidate actions to address the target customer incident comprises: identifying, using a trained machine learning model, one or more endpoints of a plurality of endpoints; obtaining the plurality of candidate actions from the one or more endpoints of the plurality of endpoints;
displaying the output comprising the target candidate action for the target customer incident in a graphical user interface (GUI);
obtaining feedback corresponding to the plurality of candidate actions, wherein the feedback includes an indication of a selected candidate action from the plurality of candidate actions;
and responsive to an interaction with the target candidate action, performing the target candidate action
and updating the trained machine learning model using the feedback corresponding to the plurality of candidate actions as training data;
Claim 11 - The method of claim 1, further comprising: receiving feedback for a first candidate action selected in association with a particular customer incident, the feedback for the first candidate action indicating a selection or success of the first candidate action; and selecting a subsequent candidate action for a subsequent customer incident based on the feedback.
wherein updating the trained machine learning model using the feedback corresponding to the plurality of candidate actions comprises retraining the trained machine learning model to select endpoints for obtaining candidate actions using the indication of the selected candidate action as training data.
The claim limitations here are almost all present in claim 1 and 2 or 5 of the ‘222 patent. The claim here is broader as it does not require feedback or training as in last step of ‘222 claim, but claim 11 in 19/245,739 has similar limitations, already mapped to Jain and Sachan. In addition, Sachan discloses training of various machine learning based predictive models (See par 64). The differences in claim limitations are obvious based on the art citations in the 103 rejections above; and Jain, Sachan, and Masood would be obvious to combine for the same reasons as in the 103 rejection above. The other dependent claims are similar to claims in the ‘222 patent and any further differences are obvious for the reasons given in the 103 rejection above.
Furthermore, there is no apparent reason why applicant was prevented from presenting claims corresponding to those of the instant application during prosecution of the application which matured into a patent. See In re Schneller, 397 F.2d 350, 158 USPQ 210 (CCPA 1968). See also MPEP § 804.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
El-Nakib US 10,410,219 – directed to identifying suggested solutions to problem descriptions (See Abstract)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at 571-270-3614. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/IVAN R GOLDBERG/ Primary Examiner, Art Unit 3619
Prosecution Insights