DETAILED ACTION
This communication is a Non-Final Rejection Office Action in response to the 1/27/2025 submission filled in Application17/195,890 .
Claims 1-20 were subject to a restriction requirement. The Applicant elected Claims 1, 9, 10, 16 and 20 and claim 2-8, 17-19. Claims 11-15 are withdrawn. Applicant’s election without traverse of these claims in the reply filed on 1/27/2025 is acknowledged.
Claims 1-10, 16-20 are now presented.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-10, 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
When considering subject matter eligibility under 35 U.S.C. 101, in step 1 it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, in step 2A prong 1 it must then be determined whether the claim is recite a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). If the claim recites a judicial exception, under step 2A prong 2 it must additionally be determined whether the recites additional elements that integrate the judicial exception into a practical application. If a claim does not integrate the Abstract idea into a practical application, under step 2B it must then be determined if the claim provides an inventive concept.
In the Instant case Claims 1-9, 10 are directed toward a method for calculating a support service score for the IT support service ticket based on metric scores, system-defined weights, and user-defined weights. Claims 16-20 are directed toward a system for calculating a support service score for the IT support service ticket based on metric scores, system-defined weights, and user-defined weights. As such, each of the Claims is directed to one of the four statutory categories of invention.
MPEP 2106.04 II. A. explains that in step 2A prong 1 Examiners are to determine whether a claim recites a judicial exception. MPEP 2106.04(a) explains that:
To facilitate examination, the Office has set forth an approach to identifying abstract ideas that distills the relevant case law into enumerated groupings of abstract ideas. The enumerated groupings are firmly rooted in Supreme Court precedent as well as Federal Circuit decisions interpreting that precedent, as is explained in MPEP § 2106.04(a)(2). This approach represents a shift from the former case-comparison approach that required examiners to rely on individual judicial cases when determining whether a claim recites an abstract idea. By grouping the abstract ideas, the examiners’ focus has been shifted from relying on individual cases to generally applying the wide body of case law spanning all technologies and claim types.
The enumerated groupings of abstract ideas are defined as:
1) Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations (see MPEP § 2106.04(a)(2), subsection I);
2) Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP § 2106.04(a)(2), subsection II); and
3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).
As per step 2A prong 1 of the eligibility analysis, claim 1 is directed to the abstract idea of predicting with the processor metric scores of a plurality of IT support service metrics for the IT support service ticket based on the field data by executing the multi score prediction engine; obtaining system-defined weights and user-defined weights for the plurality of IT support service metrics; calculating a support service score for the IT support service ticket based on the metric scores, the system-defined weights, and the user-defined weights; and evaluating user experience on the support service ticket based on the support service score which falls into the abstract idea categories of certain methods of organizing human activity and mental processes.
The elements of Claim 1 that represent the Abstract idea include:
A method comprising:
applying a decision rule to the first field data and the second field data to obtain metric scores of a plurality of IT support service metrics for the historical IT support service ticket; and
training a model based on the first field data, the second field data, and the metric scores to generate the multi-score prediction engine;
predicting metric scores of a plurality of IT support service metrics for the IT support service ticket based on the field data by executing the multi score prediction engine;
calculating a support service score for the IT support service ticket based on the metric scores, the system-defined weights, and the user-defined weights; and
evaluating user experience on the support service ticket based on the support service score.
MPEP 2106.04(a)(2) II. states:
The phrase "methods of organizing human activity" is used to describe concepts relating to:
fundamental economic principles or practices (including hedging, insurance, mitigating risk);
commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and
managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions).
The Supreme Court has identified a number of concepts falling within the "certain methods of organizing human activity" grouping as abstract ideas. In particular, in Alice, the Court concluded that the use of a third party to mediate settlement risk is a ‘‘fundamental economic practice’’ and thus an abstract idea. 573 U.S. at 219–20, 110 USPQ2d at 1982. In addition, the Court in Alice described the concept of risk hedging identified as an abstract idea in Bilski as ‘‘a method of organizing human activity’’. Id. Previously, in Bilski, the Court concluded that hedging is a ‘‘fundamental economic practice’’ and therefore an abstract idea. 561 U.S. at 611–612, 95 USPQ2d at 1010.
In the instant case, the limitations of applying a decision rule; training a model based data; predicting metric scores; calculating a support service score for the IT support service ticket; and evaluating user experience on the support service ticket based on the support service score are directed to commercial or legal interactions including business relations. For example, evaluating user experience regarding a support service is directed to commercial interactions including business relations and sales activities.
MPEP 2106.04(a)(2) states:
The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 (2012) ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions
In the instant case, the limitations of applying a decision rule; training a model based data; predicting metric scores; calculating a support service score for the IT support service ticket; and evaluating user experience on the support service ticket based on the support service score cover the performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting “a processor” nothing in the claim precludes the steps from being performed in the human mind.
Under step 2A prong 2 the examiner must then determine if the recited abstract idea is integrated into a practical application. MPEP 2106.04 states:
Limitations the courts have found indicative that an additional element (or combination of elements) may have integrated the exception into a practical application include:
• An improvement in the functioning of a computer, or an improvement to other technology or technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a);
• Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2);
• Implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b);
• Effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and
• Applying or using 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, as discussed in MPEP § 2106.05(e)
The courts have also identified limitations that did not integrate a judicial exception into a practical application:
• Merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f);
• Adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g); and
• Generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).
In the instant case, this judicial exception is not integrated into a practical application. In particular, Claim 1 recites the additional elements of:
A method comprising:
obtaining a field data of an information technology (IT) support service ticket via a communications interface and storing the field data in a database;
obtaining with a processor a multi-score prediction engine by:obtaining a training data set of a plurality of historical IT support service tickets, the training data set comprising a first field data for each of the plurality of historical IT support service tickets;
extracting a second field data from the first field data for the historical IT support service ticket;
training a machine learning model;
obtaining system-defined weights and user-defined weights for the plurality of IT support service metrics;
using a processor to perform the predicting
However, the computer elements (the processor to perform the abstract idea) are recited at a high level of generality and given the broadest reasonable interpretation are simply generic computers performing generic computer functions. Generic computers performing generic computer functions, alone, do not amount to significantly more than the abstract idea and mere instructions to implement an abstract idea on a computer.
Further, the obtaining of data, and the extracting of data under the broadest reasonable interpretation, amount to mere data gathering which the MPEP says is insignificant extra solution activity (see MPEP 2106.05(g).
Further, the training of a machine learning model is indicative of adding the words “apply it” (or an equivalent) with the judicial exception. MPEP 2106.05(f) states:
When determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following:
(1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it". See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015). In contrast, claiming a particular solution to a problem or a particular way to achieve a desired outcome may integrate the judicial exception into a practical application or provide significantly more. See Electric Power, 830 F.3d at 1356, 119 USPQ2d at 1743.
By way of example, in Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words "apply it". 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44 (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem")).
In the instant case, the additional elements of the broadly recited machine learning attempt to cover any solution to the identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it”. For example, the claims do not state how the machine learning model is trained. As such, the broadly recited ML model does not integrate a judicial exception into a practical application or provide significantly more.
Viewing the generic processor in combination with the data gathering and the training of the machine learning model does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea.
In step 2B, the Examiner must determine whether the claim adds a specific limitation other than what is well-understood, routine, conventional activity in the field - see MPEP 2106.05(d).
As discussed with respect to Step 2A Prong Two, the additional element the processor amounts to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Further, nothing in the claim indicates that the obtaining and extracting of information is anything other than conventional. See MPEP 2106.05(d) that states “Receiving or transmitting data over a network, e.g., using the Internet to gather data is conventional when claimed in a merely generic manner (see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Further, similar to the analysis with respect to step 2A prong 2 recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished (i.e. the broadly recited machine learning) cannot provide an inventive concept under step 2B of the eligibility analysis.
Further Claims 2-9 further limit the abstract idea of an analysis that can be performed mentally or certain methods of human activity that were already rejected in claim 1, but fail to remedy the deficiencies of the parent claim as they do not impose any limitations that amount to significantly more than the abstract idea itself.
Accordingly, the Examiner concludes that there are no meaningful limitations in claims 2-9 that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
The analysis above applies to all statutory categories of invention. As such, the presentment of claim 1 otherwise styled as a method or computer program product, for example, would be subject to the same analysis. Therefore, Claims 10, 16-20 are rejected for the same rational that applied to claims 1-7.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 1, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 2017/0169438 A1 in view of Kumar US 9313332 B1.
As per Claim 1 Maynard teaches a method comprising:
obtaining a field data of an information technology (IT) support service ticket via a communications interface and storing the field data in a database; (Maynard para. 35 teaches next, prediction worker 148 processes the enqueued job. During this process, the system first retrieves ticket details from various endpoints 152 within ticketing platform 132. The retrieved ticket details 150 comprise a feature set that comprises various signals to be evaluated by one or more models 162. Para. 33 teaches when the ticket update 133 occurs, a binary log associated with the update is written to a local database 135.)
obtaining with a processor a multi-score prediction engine by:
obtaining a training data set of a plurality of historical IT support service tickets, the training data set comprising a first field data for each of the plurality of historical IT support service tickets; (Maynard para. 10 teaches prior to determining the probability that the customer will be satisfied, the system trains the machine-learning model based on information related to previous customer-service interactions along with feedback information indicating whether customers were satisfied with the previous customer-service interactions. Further, para. 52 teaches FIG. 4 presents a flow chart illustrating how the satisfaction-prediction model can be periodically trained and updated in accordance with the disclosed embodiments. First, the system trains a new model based on information related to a set of most recent customer-service interactions along with feedback information indicating whether customers were satisfied with the customer-service interactions (step 402). Next, the system updates the working model with the new model (step 404). Note that this updating process is repeated at periodic intervals, for example once a day or once a week.)
extracting a second field data from the first field data for the historical IT support service ticket; (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. The Examiner considers generating all of the features for the model from the retrieved ticket details to be extracting a second field data.
applying a decision rule to the first field data and the second field data to obtain metric scores of a plurality of IT support service metrics for the historical IT support service ticket; and (Para. 40 teaches In some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction. Para. 41 teaches when a prediction 164 is finally returned, modeler 158 updates a corresponding ticket 168 maintained in ticketing platform 132 with this prediction 164. This update facilitates subsequent interactions with the customer as is described in more detail below with reference to the flow chart that appears in FIG. 2.)
training a machine learning model based on the first field data, the second field data, and the metric scores to generate the multi-score prediction engine; (Maynard paras. 9-10 teaches in some embodiments, while using the obtained information to determine the probability that the customer will be satisfied, the system uses a machine-learning model that operates on signals derived from the obtained information to determine the probability that the customer will be satisfied. In some embodiments, prior to determining the probability that the customer will be satisfied, the system trains the machine-learning model based on information related to previous customer-service interactions along with feedback information indicating whether customers were satisfied with the previous customer-service interactions.)
predicting with the processor metric scores of a plurality of IT support service metrics for the IT support service ticket based on the field data by executing the multi score prediction engine; (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. For example, this process can involve breaking textual information contained in various communications related to the customer-service interaction into n-grams, such as unigrams, bigrams and trigrams. This facilitates correlating the occurrence of specific n-grams in the customer communications with positive or negative outcomes. For example, if a customer uses any of the n-grams “frustrated,” “really tired” or “out to lunch” in a communication, the customer-satisfaction model may predict that the customer is likely to be unsatisfied. Para. 40 teaches in some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction.)
calculating a support service score for the IT support service ticket based on the metric scores; and (Maynard para. 36 teaches FIG. 2 presents a flow chart illustrating the process of using a satisfaction-prediction model to facilitate a customer-service interaction in accordance with the disclosed embodiments. As mentioned above, this process is triggered when a ticket is updated or created or when a periodic timer expires (step 202). In response to this triggering event, the system obtains information related to an ongoing customer-service interaction involving the customer (step 204). Next, the system generates features (also referred to as “signals”) from the obtained information (step 206). The system then evaluates the features against a model to determine a probability that the customer associated with the ticket will be satisfied with the customer-service interaction (step 208). Note the system can use different models for different businesses, and for different subsets of customers for each business. Finally, the system uses the determined probability that the customer will be satisfied to facilitate subsequent interactions with the customer in furtherance of the customer-service interaction (step 210). These subsequent actions are described in more detail below with reference to the flow chart that appears in FIG. 3. Para. 51 teaches 51 the system can also identify which signals derived from the ticket information are most predictive of customer satisfaction or dissatisfaction (step 308). This information about predictive signals can be used to prioritize various aspects of interactions with customers. For one set of customers, such as purchasers of a software product, reply time may be extremely important for customer satisfaction. In this case, customer-service agents dealing with this set of customers should be very sensitive about reply time. On the other hand, for another set of customers associated with an internal help desk within a company, reply time may be somewhat less important, so agents dealing with this set of customers can be less sensitive about reply time. Para. 54 teaches The working model can also produce a number of different types of outputs and is not limited to simply predicting a probability that a customer will be satisfied. For example, in cases where the feedback information includes numerical ratings, the model can predict an average rating for the customer-service interaction. The Examiner considers an average rating for the customer-service interaction to be metric scores of a plurality of IT support service metrics.
evaluating user experience on the support service ticket based on the support service score. Para. 42 teaches the system also maintains a set of “new models” 170 that are periodically trained based on information related to the most recently completed customer-service interactions along with feedback information indicating whether customers were satisfied with the customer-service interactions. During normal system operation, the working models 162 are periodically synchronized with the new models 170. For example, this synchronization can take place once a day. This ensures that the working models 162 are consistent with more recent customer-service interactions.
Maynard does not teach obtaining system-defined weights and user-defined weights for the plurality of IT support service metrics; calculating score based on the system-defined weights, and the user-defined weights
However, Kumar column 27 lines 65-column 28 line 10 teaches in some implementations, the content provider may configure specific weights for agent parameters corresponding to different skills, which are used in computing agent scores. For example, sales skills may be given a 5% weightage, technical support skills may be given a 7% weightage, and expertise in handling customers with accents may be given a 10% weightage. (113) In some implementations, the weights 208a and the units 208b are pre-determined by the contact handling platform 130, and provided to the content provider when the corresponding parameters are selected by the content provider. In some implementations, the content provider may be allowed to set its own weights and/or units, or change the values of the weights and/or units provided by the contact handling platform. This may be useful in situations where the content provider wants to customize the response of its interaction site to suit the perceived needs of its customers, which may differ from content provider to content provider, or from interaction site to interaction site, or both. Both Maynard and Kumar are directed to a service environment. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard to include obtaining system-defined weights and user-defined weights for the plurality of IT support service metrics; calculating score based on the system-defined weights, and the user-defined weights as taught by Kumar to allow the content provider wants to customize the response of its interaction site to suit the perceived needs of its customers, which may differ from content provider to content provider, or from interaction site to interaction site, or both (see column 27 lines 65-column 28 line 10).
As per Claim 16 Maynard teaches a system, comprising:
a memory having stored thereon executable instructions;
a processor in communication with the memory, the processor when executing the instructions configured to: (see para. 27)
obtain a field data of an information technology (IT) support service ticket;obtain a multi-score prediction engine by: (Maynard para. 35 teaches next, prediction worker 148 processes the enqueued job. During this process, the system first retrieves ticket details from various endpoints 152 within ticketing platform 132. The retrieved ticket details 150 comprise a feature set that comprises various signals to be evaluated by one or more models 162. Para. 33 teaches when the ticket update 133 occurs, a binary log associated with the update is written to a local database 135.)
obtaining a training data set of a plurality of historical IT support service tickets, the training data set comprising a first field data for each of the plurality of historical IT support service tickets; (Maynard para. 10 teaches prior to determining the probability that the customer will be satisfied, the system trains the machine-learning model based on information related to previous customer-service interactions along with feedback information indicating whether customers were satisfied with the previous customer-service interactions. Further, para. 52 teaches FIG. 4 presents a flow chart illustrating how the satisfaction-prediction model can be periodically trained and updated in accordance with the disclosed embodiments. First, the system trains a new model based on information related to a set of most recent customer-service interactions along with feedback information indicating whether customers were satisfied with the customer-service interactions (step 402). Next, the system updates the working model with the new model (step 404). Note that this updating process is repeated at periodic intervals, for example once a day or once a week.)
extracting a second field data from the first field data for the historical IT support service ticket; (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. The Examiner considers generating all of the features for the model from the retrieved ticket details to be extracting a second field data.)
applying a decision rule to the first field data and the second field data to obtain metric scores of a plurality of IT support service metrics for the historical IT support service ticket; and (Para. 40 teaches In some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction. Para. 41 teaches when a prediction 164 is finally returned, modeler 158 updates a corresponding ticket 168 maintained in ticketing platform 132 with this prediction 164. This update facilitates subsequent interactions with the customer as is described in more detail below with reference to the flow chart that appears in FIG. 2.)
training a machine learning model based on the first field data, the second field data, and the metric scores to generate the multi-score prediction engine; (Maynard paras. 9-10 teaches in some embodiments, while using the obtained information to determine the probability that the customer will be satisfied, the system uses a machine-learning model that operates on signals derived from the obtained information to determine the probability that the customer will be satisfied. In some embodiments, prior to determining the probability that the customer will be satisfied, the system trains the machine-learning model based on information related to previous customer-service interactions along with feedback information indicating whether customers were satisfied with the previous customer-service interactions.
predict metric scores of a plurality of IT support service metrics for the IT support service ticket based on the field data by executing the multi-score prediction engine; (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. For example, this process can involve breaking textual information contained in various communications related to the customer-service interaction into n-grams, such as unigrams, bigrams and trigrams. This facilitates correlating the occurrence of specific n-grams in the customer communications with positive or negative outcomes. For example, if a customer uses any of the n-grams “frustrated,” “really tired” or “out to lunch” in a communication, the customer-satisfaction model may predict that the customer is likely to be unsatisfied. Para. 40 teaches in some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction.)
calculate a support service score based on the metric scores,; and (Maynard para. 36 teaches FIG. 2 presents a flow chart illustrating the process of using a satisfaction-prediction model to facilitate a customer-service interaction in accordance with the disclosed embodiments. As mentioned above, this process is triggered when a ticket is updated or created or when a periodic timer expires (step 202). In response to this triggering event, the system obtains information related to an ongoing customer-service interaction involving the customer (step 204). Next, the system generates features (also referred to as “signals”) from the obtained information (step 206). The system then evaluates the features against a model to determine a probability that the customer associated with the ticket will be satisfied with the customer-service interaction (step 208). Note the system can use different models for different businesses, and for different subsets of customers for each business. Finally, the system uses the determined probability that the customer will be satisfied to facilitate subsequent interactions with the customer in furtherance of the customer-service interaction (step 210). These subsequent actions are described in more detail below with reference to the flow chart that appears in FIG. 3. Para. 51 teaches 51 the system can also identify which signals derived from the ticket information are most predictive of customer satisfaction or dissatisfaction (step 308). This information about predictive signals can be used to prioritize various aspects of interactions with customers. For one set of customers, such as purchasers of a software product, reply time may be extremely important for customer satisfaction. In this case, customer-service agents dealing with this set of customers should be very sensitive about reply time. On the other hand, for another set of customers associated with an internal help desk within a company, reply time may be somewhat less important, so agents dealing with this set of customers can be less sensitive about reply time. Para. 54 teaches The working model can also produce a number of different types of outputs and is not limited to simply predicting a probability that a customer will be satisfied. For example, in cases where the feedback information includes numerical ratings, the model can predict an average rating for the customer-service interaction. The Examiner considers an average rating for the customer-service interaction to be metric scores of a plurality of IT support service metrics.
evaluate user experience on the support service ticket based on the support service score. Para. 42 teaches the system also maintains a set of “new models” 170 that are periodically trained based on information related to the most recently completed customer-service interactions along with feedback information indicating whether customers were satisfied with the customer-service interactions. During normal system operation, the working models 162 are periodically synchronized with the new models 170. For example, this synchronization can take place once a day. This ensures that the working models 162 are consistent with more recent customer-service interactions.
Maynard does not teach obtain system-defined weights and user-defined weights for the plurality of IT support service metrics; and calculate score based on the system-defined weights, and the user-defined weights However, Kumar column 27 lines 65-column 28 line 10 teaches in some implementations, the content provider may configure specific weights for agent parameters corresponding to different skills, which are used in computing agent scores. For example, sales skills may be given a 5% weightage, technical support skills may be given a 7% weightage, and expertise in handling customers with accents may be given a 10% weightage. (113) In some implementations, the weights 208a and the units 208b are pre-determined by the contact handling platform 130, and provided to the content provider when the corresponding parameters are selected by the content provider. In some implementations, the content provider may be allowed to set its own weights and/or units, or change the values of the weights and/or units provided by the contact handling platform. This may be useful in situations where the content provider wants to customize the response of its interaction site to suit the perceived needs of its customers, which may differ from content provider to content provider, or from interaction site to interaction site, or both. Both Maynard and Kumar are directed to a service environment. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard to include obtaining system-defined weights and user-defined weights for the plurality of IT support service metrics; calculating score based on the system-defined weights, and the user-defined weights as taught by Kumar to allow the content provider wants to customize the response of its interaction site to suit the perceived needs of its customers, which may differ from content provider to content provider, or from interaction site to interaction site, or both (see column 27 lines 65-column 28 line 10).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 20170169438 A1 in view of Kumar US 9313332 B1 as applied to claim 1 and in further view of Boss US 2019/0012167 A1.
As per Claim 2 Maynard does not teach the method of claim 1, wherein obtaining the system-defined weights for the plurality of IT support service metrics comprises:
obtaining system-defined priorities of the plurality of IT support service metrics; and
generating the system-defined weights based on the system-defined priorities, an IT support service metric with a higher system-defined priority having a higher system-defined weight. Boss para. 52-55 teach continuing from 110, FIG. 1, at 115, a determination is made as to whether specific system determined weights or user determined weights for use in developing a productivity model that can be used to determine recommendations for increasing a development team's productivity (in the aggregate). In one embodiment, a user-specified or system-specified weight(s) represents a priority set for a particular business objective(s) or business parameter(s) of a product being developed by the development team.
If, at 115, it is determined that system determined weights are to be used, then the process proceeds to step 120 where model weights are automatically generated for input to the machine learning algorithms employed based on the current business cycle and competitive market landscape. In one embodiment, the system generates default model weights based on the analysis of structured and unstructured data items obtained from the reservoir 250, the cognitive analysis performed for classifying the activities, and the current business cycle and competitive offering performance. That is, without setting a parameter goal, the system will implement machine learning algorithms that automatically learn from how the product performed over a past time period (e.g., from operations, revenues, product financials, etc.), and make the best recommendations for the development team the economic environment, market landscape and market conditions, etc. That is, using a learning model based on linear modeling function and applied across all parameters, and given the prior product behavior and product financials, the model learns what would be the best goal(s) and optimal levels to achieve.
Otherwise, at 115, if it is determined that user determined weights are to be used, the process proceeds to step 116 that involves further steps of receiving/taking user inputs and providing interactive feedback from the weighting. In one example implementation, interactive feedback is enabled via an input device, in which a user may provide a priority for given business parameter.
For example, a product manager of a software development entity may set a bias to achieve a particular goal and, through a device interface, may input and set parameters relating to a product performance goal for a product in the market place. For example, one product may be old and generate moderate income, but has steady sales, while a second product is up and coming but is presently losing money for the entity. In this example, a user can bias and give more weight to parameters like market share growth or brand perception that bias productivity measurements toward a new market.
In one embodiment, a user, via an interface to the system described herein with respect to FIG. 3, may input desirous objective(s), e.g., maximize revenue or grow revenue by 5% points over next 12 months, and assign it a higher weight. In one embodiment, example KPI's may be listed and objective function parameters that may be user-selected.
Both Maynard in view of Kumar and Boss are directed to a optimizing business objectives. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include obtaining system-defined priorities of the plurality of IT support service metrics; and generating the system-defined weights based on the system-defined priorities, an IT support service metric with a higher system-defined priority having a higher system-defined weight as taught by Boss to set objectives that optimize performance (as suggested y para. 4).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 20170169438 A1 in view of Kumar US 9313332 B1 in view of Boss US 2019/0012167 A1 as applied to claim 2 and in further view of Ratakonda US 20170208487 A1.
As per Claim 3 Maynard does not teach the method of claim 2, wherein the system-defined weights follow a Fibonacci sequence pattern. Ratakonda para. 51 teaches the second step of the scoring mechanism involves calculation of KPI scores based on a number of detected failures exceeding a predefined threshold (threshold excess score) in the wireless communication system for each of the one or more identified root causes. As shown in table 2, KPI root cause analyzer 225 assigns a weight value to each threshold excess score as the depth of KPI records used for correlation increases. In other words, KPI root cause analyzer 225 multiplies each threshold excess score by an integer number such that the integer increases follow a portion of a Fibonacci number series. In a Fibonacci series, the kth number (with the exception of the first and second numbers which both equal one) in the series will equal the sum of the (k−1) and (k−2) numbers. Thus, a Fibonacci series is as follows: 1, 1, 2, 3, 5, 8, 13, 21, etc. In alternative embodiment, weight values for threshold excess score may increase linearly. According to an embodiment of the present invention, the third and final step of the scoring mechanism involves generation of probability score as a ratio of each KPI score to the sum of all KPI scores, as shown in table 2. Advantageously, the probability score is indicative of likelihood that each potential cause actually caused the reported network problems. For example, in table 2 above, the third listed potential cause (inter MME handover failure) has approximately 60% likelihood of causing users' inability to connect to an LTE network. Both Maynard, Kumar and Boss are directed to a optimizing business objectives. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard to include the system-defined weights follow a Fibonacci sequence pattern as taught by Kumar to allow implement an objective framework for prioritization which ensures that valuable resources are allocated where they are most needed.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 20170169438 A1 in view of Kumar US 9313332 B1 as applied to claim 1 and in further view of Boss US 2019/0012167 A1 in view of Mohamed US 2011/0295754 A1.
As per Claim 4 Maynard in view of Kumar does not teach the method of claim 1, wherein obtaining the user-defined weights for the plurality of IT support service metrics comprises:
obtaining user-defined priorities of the plurality of IT support service metrics; and
generating the user-defined weights based on the user-defined priorities, . However, Boss para. 52 teaches continuing from 110, FIG. 1, at 115, a determination is made as to whether specific system determined weights or user determined weights for use in developing a productivity model that can be used to determine recommendations for increasing a development team's productivity (in the aggregate). In one embodiment, a user-specified or system-specified weight(s) represents a priority set for a particular business objective(s) or business parameter(s) of a product being developed by the development team. Both Maynard in view of Kumar and Boss are directed to a optimizing business objectives. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include obtaining system-defined priorities of the plurality of IT support service metrics; and generating the system-defined weights based on the system-defined priorities, an IT support service metric with a higher system-defined priority having a higher system-defined weight as taught by Boss to set objectives that optimize performance (as suggested by para. 4).
Maynard in view of Kumar in view of Boss does not explicitly disclose the IT support service metrics with a same user-defined priority having a same user-defined weight However, Mohamed para. 100 teaches the components are prioritized with respect to each expert based on his familiarity and experience with each component. Since, values for all components from the historical metrics have the same importance, the values can be assigned the same weights for the metric vector of the components. One of ordinary skill in the art before the effective filing date of the Applicant’s invention would have recognized that applying the known technique of Mohamed would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Mohamed to the teachings of Maynard in view of Kumar in view of Boss would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate using the same weight for elements that have the same priority into similar systems. Further, incorporating the use of the same weight for elements that have the same priority taught by Mohamed to the system taught by Maynard in view of Kumar in view of Boss would result in an improved system that provides a more accurate evaluation of user experience.
Claim(s) 5, 6, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 20170169438 A1 in view of Kumar US 9313332 B1 as applied to claim 1 and in further view of Chrapko US 9721296 B1.
As per Claim 5 Maynard does not teach the method of claim 1, wherein calculating the support service score based on the metric scores, the system-defined weights, and the user-defined weights comprises: for each of the plurality of IT support service metrics, determining a coefficient of the system-defined weight and a coefficient of the user-defined weight for the IT support service metric based on a difference between the system-defined weight and the user-defined weight, and calculating a metric weight of the IT support service metric based on the system- defined weight, the user-defined weight, the coefficient of the system-defined weight, and the coefficient the user-defined weight; and calculating the support service score based on the metric scores and metric weights of the IT support service metrics. However, Carpko column 49, lies 24-55 teaches at 1706, the processing circuitry may optionally determine whether the inputs are within a threshold difference of the weighting profile. If the inputs are not within a threshold difference, then the processing circuitry may return to 1704. For example, large changes to weights may be ignored by the processing circuitry as outliers when updating a default weighting profile. At 1708, if the inputs are within a threshold difference of the weighting profile, the processing circuitry may update the weighting profile based on the received inputs. In some embodiments, updating the weighting profile comprises calculating an average set of weights based on the received inputs. At 1710, the processing circuitry may transmit the updated weighting profile to at least one of the plurality of user accounts. In some embodiments, the user accounts may be associated with user devices. Accounts may be accounts requiring the user to log in, internet accounts, accounts on a mobile device, user profiles; or accounts may refer to information stored about a user on local or remote storage devices. Both Maynard in view of Kumar and Chrapko are directed to a using weighting to reflect priority. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include calculating the support service score based on the metric scores, the system-defined weights, and the user-defined weights comprises: for each of the plurality of IT support service metrics, determining a coefficient of the system-defined weight and a coefficient of the user-defined weight for the IT support service metric based on a difference between the system-defined weight and the user-defined weight, and calculating a metric weight of the IT support service metric based on the system- defined weight, the user-defined weight, the coefficient of the system-defined weight, and the coefficient the user-defined weight; and calculating the support service score based on the metric scores and metric weights of the IT support service metrics as taught by Carpko to provide a more accurate set of weights to provide a more reliable result (see column 5 lines 10-15).
As per Claim 6 Maynard does not teach the method of claim 5, wherein determining the coefficient of the system defined weight and the coefficient of the user-defined weight for the IT support service metric comprises:in response to a difference between the system-defined weight and the user defined weight is less than a predefined threshold, assigning a same value to the coefficient of the system-defined weight and the coefficient of the user-defined weight. However, Carpko column 49, lies 24-55 teaches at 1706, the processing circuitry may optionally determine whether the inputs are within a threshold difference of the weighting profile. If the inputs are not within a threshold difference, then the processing circuitry may return to 1704. For example, large changes to weights may be ignored by the processing circuitry as outliers when updating a default weighting profile. At 1708, if the inputs are within a threshold difference of the weighting profile, the processing circuitry may update the weighting profile based on the received inputs. In some embodiments, updating the weighting profile comprises calculating an average set of weights based on the received inputs. At 1710, the processing circuitry may transmit the updated weighting profile to at least one of the plurality of user accounts. In some embodiments, the user accounts may be associated with user devices. Accounts may be accounts requiring the user to log in, internet accounts, accounts on a mobile device, user profiles; or accounts may refer to information stored about a user on local or remote storage devices. Both Maynard in view of Kumar and Carpko are directed to a using weighting to reflect priority. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include wherein determining the coefficient of the system defined weight and the coefficient of the user-defined weight for the IT support service metric comprises:in response to a difference between the system-defined weight and the user defined weight is less than a predefined threshold, assigning a same value to the coefficient of the system-defined weight and the coefficient of the user-defined weight as taught by Carpko to provide a more accurate set of weights to provide a more reliable result (see column 5 lines 10-15).
As per Claim 17 Maynard does not teach The system of claim 16, wherein the system is configured to: for each of the plurality of IT support service metrics, determine a coefficient of the system-defined weight and a coefficient of the user- defined weight for the IT support service metric based on a difference between the system-defined weight and the user-defined weight, and calculate a metric weight of the IT support service metric based on the system- defined weight, the user-defined weight, the coefficient of the system-defined weight, and the coefficient the user-defined weight; and calculate the support service score based on the metric scores and metric weights of the IT support service metrics. However, Carpko column 49, lies 24-55 teaches at 1706, the processing circuitry may optionally determine whether the inputs are within a threshold difference of the weighting profile. If the inputs are not within a threshold difference, then the processing circuitry may return to 1704. For example, large changes to weights may be ignored by the processing circuitry as outliers when updating a default weighting profile. At 1708, if the inputs are within a threshold difference of the weighting profile, the processing circuitry may update the weighting profile based on the received inputs. In some embodiments, updating the weighting profile comprises calculating an average set of weights based on the received inputs. At 1710, the processing circuitry may transmit the updated weighting profile to at least one of the plurality of user accounts. In some embodiments, the user accounts may be associated with user devices. Accounts may be accounts requiring the user to log in, internet accounts, accounts on a mobile device, user profiles; or accounts may refer to information stored about a user on local or remote storage devices. Both Maynard in view of Kumar and Carpko are directed to a using weighting to reflect priority. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include wherein the system is configured to: for each of the plurality of IT support service metrics, determine a coefficient of the system-defined weight and a coefficient of the user- defined weight for the IT support service metric based on a difference between the system-defined weight and the user-defined weight, and calculate a metric weight of the IT support service metric based on the system- defined weight, the user-defined weight, the coefficient of the system-defined weight, and the coefficient the user-defined weight; and calculate the support service score based on the metric scores and metric weights of the IT support service metrics as taught by Carpko to provide a more accurate set of weights to provide a more reliable result (see column 5 lines 10-15).
As per Claim 18 Maynard does not teach 18. (Original) The system of claim 17, wherein the system is configured to: in response to a difference between the system-defined weight and the user defined weight is less than a predefined threshold, assign a same value to the coefficient of the system-defined weight and the coefficient of the user-defined weight. However, Carpko column 49, lies 24-55 teaches at 1706, the processing circuitry may optionally determine whether the inputs are within a threshold difference of the weighting profile. If the inputs are not within a threshold difference, then the processing circuitry may return to 1704. For example, large changes to weights may be ignored by the processing circuitry as outliers when updating a default weighting profile. At 1708, if the inputs are within a threshold difference of the weighting profile, the processing circuitry may update the weighting profile based on the received inputs. In some embodiments, updating the weighting profile comprises calculating an average set of weights based on the received inputs. At 1710, the processing circuitry may transmit the updated weighting profile to at least one of the plurality of user accounts. In some embodiments, the user accounts may be associated with user devices. Accounts may be accounts requiring the user to log in, internet accounts, accounts on a mobile device, user profiles; or accounts may refer to information stored about a user on local or remote storage devices. Both Maynard in view of Kumar and Carpko are directed to a using weighting to reflect priority. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include wherein the system is configured to: in response to a difference between the system-defined weight and the user defined weight is less than a predefined threshold, assign a same value to the coefficient of the system-defined weight and the coefficient of the user-defined weight as taught by Carpko to provide a more accurate set of weights to provide a more reliable result (see column 5 lines 10-15).
Claim(s) 9, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 2017/0169438 A1 in view of Kumar US 9313332 B1 as applied to claim 1 and in further view Foster US 2018/0253677 A1.
As per Claim 9 Maynard does not teach the method of claim 1, wherein the decision rule comprises mappings between metric values of an IT support service metric and metric scores of the IT support service metric, applying the decision rule to the first field data and the second field data to obtain the metric scores of the plurality of IT support service metrics comprising:for each of the plurality of IT support service metrics,identifying one or more metric fields corresponding to the IT support service metric from the first field data and the second field data,deriving a metric value of the IT support service metric from values of the one or more metric fields, and determining a metric score of the IT support service metric by indexing the metric value of the IT support service metric in the mappings. However, Foster para. 26 teaches referring to FIG. 8, the method of the present invention is designed to summarize the information that is included in the raw datasets to give the user an understanding of the system's performance. To accomplish this the present invention provides a summarization template for each KPI that is stored on the remote server. The summarization template is a template that identifies the pieces of information that are pertinent to the analyzing each KPI. The sub-process begins by populating the summarization template with the initial raw dataset and the subsequent raw dataset for the corresponding KPI with the remote server. The sub-process pulls required information out of the initial raw dataset and the subsequent raw dataset and uses this information to populate data fields in the summarization template for the KPI to which the raw datasets are associated. The sub-process continues by correlating the corresponding KPI to a performance index with the remote server, in order to identify a performance score. The performance index is a user-defined metric that can be used to determine the performance of the system with respect to one or more KPIs. Both Maynard in view of Kumar and Foster are directed to a correlating metrics to performance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include wherein the decision rule comprises mappings between metric values of an IT support service metric and metric scores of the IT support service metric, applying the decision rule to the first field data and the second field data to obtain the metric scores of the plurality of IT support service metrics comprising:for each of the plurality of IT support service metrics,identifying one or more metric fields corresponding to the IT support service metric from the first field data and the second field data,deriving a metric value of the IT support service metric from values of the one or more metric fields, and determining a metric score of the IT support service metric by indexing the metric value of the IT support service metric in the mappings as taught by Foster to better analyze how individual parameters will affect system performance (see para. 160.
As per Claim 20 Maynard does not teach the system of claim 16, wherein the decision rule comprises mappings between metric values of an IT support service metric and metric scores of the IT support service metric, the system is configured to: for each of the plurality of IT support service metrics, identify one or more metric fields corresponding to the IT support service metric from the first field data and the second field data, derive a metric value of the IT support service metric from values of the one or more metric fields, and determine a metric score of the IT support service metric by indexing the metric value of the IT support service metric in the mappings.
However, Foster para. 26 teaches referring to FIG. 8, the method of the present invention is designed to summarize the information that is included in the raw datasets to give the user an understanding of the system's performance. To accomplish this the present invention provides a summarization template for each KPI that is stored on the remote server. The summarization template is a template that identifies the pieces of information that are pertinent to the analyzing each KPI. The sub-process begins by populating the summarization template with the initial raw dataset and the subsequent raw dataset for the corresponding KPI with the remote server. The sub-process pulls required information out of the initial raw dataset and the subsequent raw dataset and uses this information to populate data fields in the summarization template for the KPI to which the raw datasets are associated. The sub-process continues by correlating the corresponding KPI to a performance index with the remote server, in order to identify a performance score. The performance index is a user-defined metric that can be used to determine the performance of the system with respect to one or more KPIs. Both Maynard in view of Kumar and Foster are directed to a correlating metrics to performance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard in view of Kumar to include wherein the decision rule comprises mappings between metric values of an IT support service metric and metric scores of the IT support service metric, the system is configured to: for each of the plurality of IT support service metrics, identify one or more metric fields corresponding to the IT support service metric from the first field data and the second field data, derive a metric value of the IT support service metric from values of the one or more metric fields, and determine a metric score of the IT support service metric by indexing the metric value of the IT support service metric in the mappings as taught by Foster to better analyze how individual parameters will affect system performance (see para. 160).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Maynard US 20170169438 A1 in view Foster US 20180253677 A1.
As per Claim 10 Maynard a method comprising:
obtaining and storing in a database a training data set of a plurality of information technology (IT) support service tickets, the training data set comprising a first field data for each of the plurality of IT support service tickets; (Maynard para. 35 teaches next, prediction worker 148 processes the enqueued job. During this process, the system first retrieves ticket details from various endpoints 152 within ticketing platform 132. The retrieved ticket details 150 comprise a feature set that comprises various signals to be evaluated by one or more models 162. Para. 33 teaches when the ticket update 133 occurs, a binary log associated with the update is written to a local database 135.)
extracting with a processor a second field data from the first field data for the IT support service ticket; (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. The Examiner considers generating all of the features for the model from the retrieved ticket details to be extracting a second field data.)
applying with the processor the decision rule to the first field data and the second field data to obtain metric scores of a plurality of IT support service metrics for the IT support service ticket by: (Para. 40 teaches In some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction. Para. 41 teaches when a prediction 164 is finally returned, modeler 158 updates a corresponding ticket 168 maintained in ticketing platform 132 with this prediction 164. This update facilitates subsequent interactions with the customer as is described in more detail below with reference to the flow chart that appears in FIG. 2.)
training with the processor a machine learning model based on the first field data, the second field data, and the metric scores to generate a multi-score prediction engine, the multi- score prediction engine being for predicting metric scores of the plurality of IT support service metrics for an IT support service ticket. (Maynard paras. 9-10 teaches in some embodiments, while using the obtained information to determine the probability that the customer will be satisfied, the system uses a machine-learning model that operates on signals derived from the obtained information to determine the probability that the customer will be satisfied. In some embodiments, prior to determining the probability that the customer will be satisfied, the system trains the machine-learning model based on information related to previous customer-service interactions along with feedback information indicating whether customers were satisfied with the previous customer-service interactions.)
for each of the plurality of IT support service metrics,identifying metric fields corresponding to the IT support service metric from the first field data and the second field data,deriving a metric value of the IT support service metric from values of the metric fields, anddetermining a metric score of the IT support service metric by indexing the metric value of the IT support service metric in the mappings; and (Maynard para. 36 teaches next, prediction worker 148 sends the retrieved ticket details 154 to another endpoint 156. A worker called a modeler 158 subsequently generates all of the features for the model (which are also referred to as “signals”) from the retrieved ticket details 154. For example, this process can involve breaking textual information contained in various communications related to the customer-service interaction into n-grams, such as unigrams, bigrams and trigrams. This facilitates correlating the occurrence of specific n-grams in the customer communications with positive or negative outcomes. For example, if a customer uses any of the n-grams “frustrated,” “really tired” or “out to lunch” in a communication, the customer-satisfaction model may predict that the customer is likely to be unsatisfied. Para. 40 teaches in some embodiments, models 162 comprises three different models, including: (1) a model for words extracted from communications between the customer and a customer-service agent; (2) a model for performance metrics associated with the customer-service interaction; (3) customer data associated with the requester of the customer-service interaction; and (4) a model for configurable settings associated with the customer-service interaction. The output of these models can be combined (for example, through a voting operation) to generate a prediction.)
Maynard does not teach obtaining with the processor a decision rule comprising mappings between metric valuesof an IT support service metric and metric scores of the IT support service metric; However, Foster para. 26 teaches referring to FIG. 8, the method of the present invention is designed to summarize the information that is included in the raw datasets to give the user an understanding of the system's performance. To accomplish this the present invention provides a summarization template for each KPI that is stored on the remote server. The summarization template is a template that identifies the pieces of information that are pertinent to the analyzing each KPI. The sub-process begins by populating the summarization template with the initial raw dataset and the subsequent raw dataset for the corresponding KPI with the remote server. The sub-process pulls required information out of the initial raw dataset and the subsequent raw dataset and uses this information to populate data fields in the summarization template for the KPI to which the raw datasets are associated. The sub-process continues by correlating the corresponding KPI to a performance index with the remote server, in order to identify a performance score. The performance index is a user-defined metric that can be used to determine the performance of the system with respect to one or more KPIs. Both Maynard in view of Kumar and Foster are directed to a correlating metrics to performance. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Maynard to include obtaining with the processor a decision rule comprising mappings between metric valuesof an IT support service metric and metric scores of the IT support service metric as taught by Foster to better analyze how individual parameters will affect system performance (see para. 160).
Relevant Art Not Relied Upon in a Rejection
Newton US 20160012454 A1 Para. 216 teaches all defined entities have user weighted influence equation to calculate the topical online influence across various social media outlets. Because entities may wield more influence in one form of content then another, the weights can be applied on a per entity basis, e.g., the user may adjust the weights on Robert Scoble's Influence equation to one set of values that are different from the weights they apply to other entities in the system. In the absence of a user defined custom set of weights for an entity's influence, the system default influence equation weights will be used for that entity type. All entity types will have a default set of weights defined in the system that will be used in absence of user defined weights.
Vinnakota US 20160012360 A1 Para. 56 teaches after checking the compliance, the system 102 may employ the assigner 216 to assign weights to the plurality of governance focus areas 306, the plurality of governance control dimensions 308, and the sub-information security governances 304. The weights may be assigned to the sub-information security governances 304 based on a priority/significance defined by the users/employees. In one example, the effective information security governance 304-1 may be assigned more weight than the efficient information security governance 304-2. Similarly, the information security strategy may be assigned with more weight than the information security awareness in the plurality of governance focus areas 306. Similarly, the preventive dimension may be assigned more weight than the reactive dimension in the plurality of governance control dimensions 308. Further, assigning the weight with variation may help to assess orientation of the enterprise in at least one of—the effective information security governance 304-1, the efficient information security governance 304-2, the accountable information security governance 304-3, or/and the responsive information security governance 304-4 or a combination thereof. Further, assigning the weight and assessment may help to compare a state of the information security governance 302 of the enterprise with various other enterprises' information security governance scores.
Dubey US 20220230116 A1 Para. 12 The present disclosure solves the above-mentioned problems by bringing in an objective measure for a call interaction and associating a score with each call interaction. A “call interaction” as used herein means an oral communication between a customer and an employee of an organization or a company, irrespective of the mode of transmission (e.g., telephone, videoconference, web chat, or any other mode of voice exchange(s)). “Employee” is meant to encompass an individual hired by a company or organization to perform a set job. Examples of employees include customer service representatives, sales representatives, contractors, and consultants. Examples of call interactions include sales calls, client meetings, webinars, training and coaching calls, web conferences, and customer service and support calls. Multiple parameters based on what an employee spoke and how the employee spoke are taken into account while calculating the score of the call interaction. According to certain embodiments, each score is then compared to thresholds, standards, or targets defined by the company in guidance with industry standards and then a weighted average of the score of each parameter is taken into account in calculating the score of the call interaction. Based on the final score, subjective remarks are also provided for the call interaction to help get an understanding of whether the call interaction was good or not. For example, the final score can provide an indication of whether the employee is following protocol or company procedures, whether the employee provided satisfactory customer service, and/or whether a sale is a likely outcome of the call interaction. In some embodiments, whether the call interaction was good (e.g., acceptable) or not is determined relative to other call interactions so that leaders and managers can quickly pinpoint the employees that need training and coaching, and even rank those needing the most or specific types of training or coaching. Amongst the variety of call interactions that get recorded and scored, the present disclosure can be used across all types of calls, including sales calls and client meetings, and training and coaching interactions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEIRDRE D HATCHER whose telephone number is (571)270-5321. The examiner can normally be reached Monday-Friday 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached at 571-270-5389. 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.
/DEIRDRE D HATCHER/Primary Examiner, Art Unit 3625
Prosecution Insights