DETAILED ACTION
This communication is a first Office Action Non-Final rejection on the merits. Claims 1-20 as originally filed are currently pending and considered below.
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 .
Status of Claims
This Non-Final Office action is in response to the application filed on 08/10/2023. Claims 1-20 are pending.
Priority
Application 18/447,923 was filed 08/10/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/10/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-7 are directed to a method (process), Claims 8-13 are directed to a system (machine/apparatus), and Claims 14-20 are directed to a computer program product comprising one or more computer-readable storage media (Specification [0061 “a computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se”) (machine). Thus, these claims fall within one of the four statutory categories of invention. (Step 1: YES).
For step 2A, the Examiner has identified independent method Claim 1 as the claim that represents the claimed invention for analysis. Claim 1, as exemplary example for Claims 8 and 14 is recited below, isolating the abstract idea from the additional elements, wherein the abstract idea is set in bold:
A computer-implemented method, comprising: generating groups of action executions that execute on a collaboration platform, wherein the groups of action executions are generated by natural language processing of contextual information extracted from one or more Chat Operations conversations; generating recommendation candidates corresponding to the action executions by clustering action executions contained in each of the groups, wherein the clustering is based on times of past executions of the action executions; and generating a learned schedule by ranking the recommendation candidates based on the contextual information, wherein the learned schedule indicates one or more recommendations to execute a specific action within a specific time.
The above bolded limitations recite the abstract idea of analyzing past activities and contextual information to recommend when an action should be performed. These limitations under its broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior or relationships or interactions between people and following rules or instructions) but for the recitation of generic computer components. That is, other than reciting a method implemented by a collaboration platform (computer) the claimed invention amounts to the abstract idea stated above. For example, for the related computer components, this claim encompasses activities involving analyzing communications between users, identifying actions associated with those communications, organizing prior actions based on when they were performed, and recommending when prior based on when they were performed, and recommending when particular actions should subsequently be performed. Such activities can be carried out by individuals reviewing prior conversations and activities, identifying recuring actions and their timing, and using that information to determine or recommend when an action should be performed. Additionally, extracting contextual information from conversations and using past activities to generate and rank recommendations constitutes a method of organizing human activity in the form of managing relationships or interactions between people, as it involves using communications between participants of a collaboration platform to organize and coordinate their subsequent activities. The claimed natural language processing, clustering, and ranking are ultimately used to facilitate the coordination of actions arising from interactions between users by recommending a particular action to be performed at a particular time and therefore amount to managing interactions between people. If a claim limitation, under its broadest reasonable interpretation, covers interactions between parties, but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. The mere nominal recitation of a “computer” and “a collaboration platform”, do not take the claim out of the methods of organizing human interactions grouping. Thus, claims 1, 8, and 14 recites an abstract idea. (Step 2A- Prong 1: YES. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application (2nd prong of eligibility test for step 2A). Claim 1 recites the additional elements of a “computer” and “a collaboration platform”. Claim 8 recites the same additional elements of Claim 1 with the addition of “one or more processors”. Claim 14 recites the same additional elements of Claim 1 with the addition of “a computer program product”, “one or more computer-readable storage media”, and “a processor”. These additional elements are all considered nothing more than generic computing devices to perform generic communicating functions. These elements are recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component in technological environment. The additional elements are considered nothing more than a general link to implementation by the claimed processor because there is no recitation of specifics of how this additional element is being used. See MPEP 2106.05(f) and (h). Accordingly, these additional elements (combination of computer and the use of models) do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are recited at a high level of generality when considered both individually and as a whole. Thus, Claims 1, 8, and 14 are directed to an abstract idea without integration into a practical application. (Step 2A-Prong 2: NO: the additional claimed elements are not integrated into a practical application).
For step 2B, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they do not amount to more than simply instructing one to practice the abstract idea by using generic computer components to carry out the steps that define the abstract idea, as discussed above. This does not render the claims as being eligible. See MPEP 2106.05(f). The additional elements of using a processor and platform when considered both individually and as an ordered combination did not add significantly more to the abstract idea because they were simply applying the abstract idea using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (See MPEP 2106.05(f)). Accordingly, these additional elements, do not change the outcome of the analysis, and claims 1, 8, and 14 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more).
Claim 2 and 9 recites limitations that further define the same abstract idea of independent claims to include wherein the learned schedule is one of multiple learned schedules, and wherein the action executions execute, and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules. In addition, the claims recite the additional element of “multiple channels of the collaboration platform” which is considered nothing more than a general link to technology because there is no recitation of specifics of how this additional element is being used. See MPEP 2106.05(f) and (h) indicate that merely “generally linking” the abstract idea to a particular technological environment or field of use cannot provide a practical application or significantly more. Therefore, the claims are patent ineligible.
Claim 3 and 10 recites limitations that further define the same abstract idea of independent claims to include wherein the learned schedule is one of multiple learned schedules, wherein the contextual information is determined by processing Chat Operations conversations of multiple users, and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to one or more of the multiple users. In addition, the claims recite the additional element of “the collaboration platform” which is considered nothing more than a general link to technology because there is no recitation of specifics of how this additional element is being used. See MPEP 2106.05(f) and (h) indicate that merely “generally linking” the abstract idea to a particular technological environment or field of use cannot provide a practical application or significantly more. Therefore, the claims are patent ineligible.
Claim 4 and 17 recites limitations that further define the same abstract idea of independent claims to include wherein the action executions are tail executions, wherein the learned schedule is a schedule of service level agreement (SLA) alerts, and further comprising: generating an SLA alert in response to detecting a failure to perform a corresponding action. The claimed elements are considered part of the abstract idea because they merely define analyzing past activities and contextual information to recommend when an action should be performed, without adding any concrete technological implementation or improvement. Additionally, the dependent claims do not include any new additional elements and therefore are considered patent ineligible for the reasons given above.
Claim 5, 11, and 18 recites limitations that further define the same abstract idea of independent claims to include wherein the action executions execute, and wherein the clustering comprises: generating a dependency graph based on Chat Operations contextual information for each action execution; determining a dependency order for each of the action executions in accordance with the clustering based on times of past executions; and ranking the recommendation candidates based on the dependency order of each action. In addition, the claims recite the additional element of “multiple channels of the collaboration platform” which is considered nothing more than a general link to technology because there is no recitation of specifics of how this additional element is being used. See MPEP 2106.05(f) and (h) indicate that merely “generally linking” the abstract idea to a particular technological environment or field of use cannot provide a practical application or significantly more. Therefore, the claims are patent ineligible.
Claims 6-7, 12-13, and 19-20 recites limitations that further define the same abstract idea of independent claims to include monitoring whether action executions occur at times corresponding to the learned schedule; and automatically initiating execution of an action in response to determining that a user failed to execute the action in accordance with the learned schedule and wherein the generating groups of action executions correlates the one or more Chat Operations conversations with each of the action executions based on identifying a user intent through natural language processing of the one or more Chat Operations conversations. The claimed elements are considered part of the abstract idea because they merely define analyzing past activities and contextual information to recommend when an action should be performed, without adding any concrete technological implementation or improvement. Additionally, the dependent claims do not include any new additional elements and therefore are considered patent ineligible for the reasons given above.
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.
Claims 1, 6-8, 12-14 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 20220308943) in view of Muthusami et al. (US 20220393992).
Srinivasan et al. is directed to an approach for building a machine learning model that predicts the appropriate action to resolve a malfunction or system error, a processor receives an alert that a malfunction or a system error has occurred.
With regards to Claim 1, Srinivasan et al. teaches a computer-implemented method, comprising: (See Abstract & FIG 1)
generating groups of action executions that execute on a collaboration platform, wherein the groups of action executions are generated by natural language processing of contextual information extracted from one or more Chat Operations conversations; (See Claim 1, Also See [0002] The term ChatOps refers to a collaboration model that creates a workspace where people, tools, processes, and automation are connected in a seamless and transparent way. The workspace is managed by other IT personnel and consumers of IT business applications (hereinafter referred to as “support service agents”). In the workspace, the support service agents collaborate on the work that needs to be done, the work that is currently happening, and the work that has been done in one persistent location. Also See [0006]-As the team evolves, the ChatOps platform provides two-way communications between the support service agents and the affected system or systems that the support service agents are managing. Also See [0007]-A processor creates a workspace on a ChatOps platform integrated with a chatbot and one or more tools. A processor inputs data relating to the alert that a malfunction or a system error has occurred in a natural language format. A processor processes the data using a natural language processing algorithm of the chatbot. A processor extracts one or more sequential patterns of events from the data. A processor records an occurrence of one or more sequential patterns of events from the data. Also See [0058]- actionable alert generation program 122 analyzes the transcript of the conversation using text analytics. Text analytics uses advanced linguistic technologies and natural language processing to rapidly process a large variety of unstructured and semi-structured text data and, from this text data, extract and organize the key concepts into categories…actionable alert generation program 122 analyzes the transcript of the conversation using pattern matching. Pattern matching is an algorithmic task that finds pre-determined patterns among sequences of raw data or processed tokens…responsive to actionable alert generation program 122 monitoring the conversation, actionable alert generation program 122 analyzes the transcript of the conversation.)
generating recommendation candidates corresponding to the action executions (See [0007]- A processor creates an analytic and predictive machine learning model to predict the actionable alert in future iterations. A processor trains the analytic and predictive machine learning model using one or more system generated events and one or more human generated events. Also See [0013]- subsequent to training the analytic and predictive machine learning model using one or more system generated events and one or more human generated events, a processor tunes the analytic and predictive machine learning model using reinforcement learning. A processor stores the analytic and predictive machine learning model in a database. Also See [0029]-Actionable alert generation program 122 operates to build a model that predicts the appropriate action the chatbot should perform automatically to resolve the malfunction or system error. Actionable alert generation program 122 operates to train the model to learn the correlations between the malfunction or system error and the actions performed by the support service agent to resolve the malfunction or system error using machine learning based on natural language processing. )
ranking the recommendation candidates based on the contextual information (See [0052]-actionable alert generation program 122 determines whether pre-set threshold for outputting an actionable alert has been met. In an embodiment, actionable alert generation program 122 compares the one or more sequential pattern of events to control data. Chat data 128 is used as control data. In an embodiment, actionable alert generation program 122 ranks the one or more sequential pattern of events according to how similar the one or more sequential pattern of events is to the control data. The highest ranked sequential pattern of events recorded the highest number of occurrences and is the most similar to the control data, whereas the lowest ranked sequential pattern of events recorded the lowest number of occurrences and is the least similar to the control data. In an embodiment, actionable alert generation program 122 generates an actionable alert directing that the highest ranked sequential pattern of events be executed at the end point of the IT system.)
Srinivasan et al. teaches generating recommendation candidates corresponding to the action executions but does not teach doing so by clustering action executions contained in each of the groups, wherein the clustering is based on times of past executions of the action executions. Srinivasan et al. also teaches ranking the recommendation candidates based on the contextual information but does not teach generating a learned schedule by ranking the recommendation candidates based on the contextual information, wherein the learned schedule indicates one or more recommendations to execute a specific action within a specific time.
Muthusami et al. is directed to properties associated with computing resources are received. At least a portion of the received properties is used to cluster the computing resources into one or more operating groups. At least a portion of the received properties is used to determine a recommendation of an operation schedule for at least one of the one or more operating groups. The recommendation is provided. A feedback is received in response to the recommendation.
Muthusami et al. teaches:
clustering action executions contained in each of the groups, wherein the clustering is based on times of past executions of the action executions; (See Claim 6, Also See [0013]- similar pattern computing resources (e.g., physical machines, virtual machines, or other computing resources) may be found based on their usage and tags and can be clustered. Clustering of computing resources based on usage to refine up and down times of computing resources saves costs. Clustering based on tags can group computing resources owned by similar groups or business units or operated in similar time zones. In some embodiments, a time window of operation (e.g., hours or operation) for computing resources is suggested based at least in part on past usage data. [0015]- the computing resources are clustered based on the learned usage patterns, and scheduling recommendations are generated. In various embodiments, the hours of idle time for computing resources for one day of the week, several days of the week, or all days of the week are forecasted based on idle times learned based on usage patterns. In various embodiments, computing resources are clustered based on hours of usage and business hours (hours of operation) are determined for each cluster. In some embodiments, machine learning models are utilized to output computing resource clusters and hours of operation for the clusters. In various embodiments, hours of operation (also referred to as on times/hours, up times/hours, active times/hours, etc.) for determined clusters are recommended to a user. Also See [0018]- resource scheduling recommendation system 110 includes tools configured to cluster computing resources into multiple operating groups based on received metrics (e.g., CPU, memory, network data transfer utilization) and forecast start and stop schedules for each of the multiple operating groups based on the received metrics. Also See [0029]- framework 300 is utilized to train a machine learning model to forecast periods of time (e.g., hours of the day) that computing resources are active and/or to cluster computing resources.)
generating a learned schedule [by ranking the recommendation candidates based on the contextual information], wherein the learned schedule indicates one or more recommendations to execute a specific action within a specific time (See [0025]- outputs of forecasting analysis comprise forecasted levels of activity (e.g., CPU utilization) for specified periods of the day (e.g., specified hours or portions thereof) for each computing resource (e.g., virtual machine) to be scheduled. In various embodiments, the computing resources (e.g., all the virtual machines to be scheduled) are clustered based on one or more data metrics (e.g., CPU utilization) associated with computing resource activity. Also See [0028]- fter forecasting and clustering or clustering and forecasting, recommendation framework 206 provides recommendations for operating times (also referred to as business hours) for analyzed computing resources. In various embodiments, a recommended schedule is provided for each determined cluster of computing resources. For example, when the computing resources are virtual machines, clustering analysis would determine various groups of virtual machines and forecasting analysis would determine when the virtual machines are likely to be active. For each group of virtual machines (or other computing resources), a recommendation is made as to time periods (e.g., specific hours) that the virtual machines (or other computing resources) should be active (e.g., started, left on, powered on, etc.) because they are forecasted to be well-utilized according to historical utilization metrics. In some embodiments, the forecasted periods of activity (e.g., forecasted hours of high utilization) of computing resources are the recommended periods for activating/keeping on (e.g., business hours) for the computing resources. Also See [0036]- the recommendation of the start and stop schedule indicates periods of the day (e.g., hours) that each cluster of computing resources is on versus off, activated versus deactivated, etc. It is also possible to based start and stop schedules on multiple metrics (e.g., an average of when CPU utilization and memory utilization exceed corresponding specified thresholds).).
Srinivasan et al. and Muthusami et al. are both considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan et al. reference to further include clustering action executions contained in each of the groups, wherein the clustering is based on times of past executions of the action executions and generating a learned schedule [by ranking the recommendation candidates based on the contextual information], wherein the learned schedule indicates one or more recommendations to execute a specific action within a specific time as taught by Muthusami et al. This is desirable such it that it allows for activating and deactivating clusters of computing resources for efficiency of management and instead of managing numerous computing resources, dimensionality of management is reduced to a smaller number of operating groups. Start and stop schedules are useful because resources (e.g., money, electrical power, etc.) are conserved by stopping computing resources when they are unlikely to be active (e.g., virtual machines that are unlikely to perform computing tasks because it is the middle of the night for users that typically assign tasks to those virtual machines). . (See Muthusami, [0036]).
With regards to Claim 8, it is rejected on a similar basis to Claim 1, with the following additions:
Srinivasan et al. teaches:
A system, comprising: one or more processors configured to initiate operations including: (See [0080] Computer system 400 includes processor(s) 401, memory 402. See [0083] Program instructions and data (e.g., software and data 410) used to practice embodiments of the present invention may be stored in persistent storage 405 and in memory 402 for execution by one or more of the respective processor(s) 401 via cache 403.)
With regards to Claim 14, it is rejected on a similar basis to Claim 1, with the following additions:
Srinivasan et al. teaches:
A computer program product, the computer program product comprising: one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media, the program instructions executable by a processor to cause the processor to initiate operations including: (See [0080]-Computer system 400 includes processor(s) 401, memory 402. Also See [0083] Program instructions and data (e.g., software and data 410) used to practice embodiments of the present invention may be stored in persistent storage 405 and in memory 402 for execution by one or more of the respective processor(s) 401 via cache 403. Also See [0089]-The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.)
With regards to Claim 6, 12, and 19 the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
automatically initiating execution of an action in response to determining that a user failed to execute the action in accordance with the learned schedule (See [0045]-application 134 is an online banking application. In application 134, a user can set up an automatic monthly transfer of money from the user's checking account to the user's money market account. Application 134 monitors the automatic monthly transfers and detects for malfunctions or system errors. A threshold is pre-set by application 134. When the threshold is met, application 134 sends an alert to actionable alert generation program 122. In the middle of an automatic monthly transfer, the workflow malfunctions and the user's money is not transferred from the user's checking account to the user's money market account. This failure meets the threshold for application 134 to send an alert to actionable alert generation program 122, notifying actionable alert generation program 122 of the workflow malfunction. Also See [0054]- In an embodiment, actionable alert generation program 122 outputs the actionable alert directing the chatbot to automatically execute the highest ranked sequential pattern of events at the end point of the IT system. In an embodiment, responsive to actionable alert generation program 122 determining a pre-set threshold has been met (decision 225, YES branch), actionable alert generation program 122 outputs an actionable alert. Also See [0064]- In an embodiment, actionable alert generation program 122 operates to build an analytic and predictive machine learning model that predicts the appropriate action the chatbot should perform automatically to resolve the malfunction or system error.)
However, the Srinivasan et al. references does not teach monitoring whether action executions occur at times corresponding to the learned schedule.
Muthusami et al. teaches:
monitoring whether action executions occur at times corresponding to the learned schedule; (See [0034]-the computing resources are accessible over a network. Network monitoring software may collect properties associated with the computing resources over time (e.g., continuously or periodically). In various embodiments, each computing resource is individually identifiable (e.g., an individually identifiable virtual machine) and properties are tracked for each individual computing resource frequently enough and over a sufficiently lengthy period of time to generate a profile of level of activity of the computing resource during the 24 hours in a day. For example, CPU utilization can be measured every 5 minutes over the course of a week, month, etc. to determine specific hours of the day during which CPU utilization is higher relative to other hours of the day.)
Srinivasan et al. and Muthusami et al. are both considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan-Muthusami combination to further include monitoring whether action executions occur at times corresponding to the learned schedule as taught by Muthusami et al. This is desirable such it that it allows for activating and deactivating clusters of computing resources for efficiency of management and instead of managing numerous computing resources, dimensionality of management is reduced to a smaller number of operating groups. Start and stop schedules are useful because resources (e.g., money, electrical power, etc.) are conserved by stopping computing resources when they are unlikely to be active (e.g., virtual machines that are unlikely to perform computing tasks because it is the middle of the night for users that typically assign tasks to those virtual machines). . (See Muthusami, [0036]).
With regards to Claim 7, 13, and 20 the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
wherein the generating groups of action executions correlates the one or more Chat Operations conversations with each of the action executions based on identifying a user intent through natural language processing of the one or more Chat Operations conversations (See [0043]- actionable alert generation program 122 operates to monitor and document the conversation that occurs between two or more support service agents in the workspace on the ChatOps platform to identify and to resolve a malfunction or system error. In an embodiment, actionable alert generation program 122 operates to provide the appropriate action to resolve the malfunction or system error. In an embodiment, actionable alert generation program 122 operates to use data inputted into a natural language processing algorithm of the chatbot to predict the appropriate action. Also See [0058] In step 240, actionable alert generation program 122 analyzes the transcript of the conversation. In an embodiment, actionable alert generation program 122 analyzes the transcript of the conversation to infer what the malfunction or system error is and what actions need to be executed in order to resolve the malfunction or system error. Also See [0064]-In an embodiment, actionable alert generation program 122 operates to train the model to learn the correlations between the malfunction or system error and the actions performed by the support service agent to resolve the malfunction or system error using machine learning based on natural language processing.).
Claims 2-3 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 20220308943) in view of Muthusami et al. (US 20220393992), further in view of Rajan et al. (US20150220871).
With regards to Claim 2 and 9, the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
multiple channels on the collaboration platform (See [0006] When a major incident occurs, some ChatOps platforms are prepared to automatically create a channel and invite support service agents from a pre-selected assignment list to join the conversation. As the team evolves, the ChatOps platform provides two-way communications between the support service agents and the affected system or systems that the support service agents are managing. Also See [0067]-Critical chat type content includes, but is not limited to, sessions on messaging platforms (e.g., on Slack® channels),)
However, the Srinivasan-Muthusami combination does not teach wherein the learned schedule is one of multiple learned schedules, and wherein the action executions execute on [multiple channels of the collaboration platform], and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to[ one or more of the multiple channels].
Rajan et al. is directed to methods and systems for scheduling a batch of tasks on one or more crowdsourcing platforms. The method includes generating one or more forecast models for each of the one or more crowdsourcing platforms based on historical data associated with each of the one or more crowdsourcing platforms and a robustness parameter.
Rajan et al. teaches:
wherein the learned schedule is one of multiple learned schedules (See [0067]-[0068]- Post generating the one or more forecast models, the processor 202 generates one or more schedules from the one or more forecast models. The generation of the one or more schedules is explained next. At step 308, a schedule is generated for each forecast model, associated with each of the one or more crowdsourcing platforms. In an embodiment, the processor 202 is operable to generate the schedule. In an embodiment, the processor 202 generates the schedule based on the forecast model and the one or more requirement parameters (i.e., the one or more parameters associated with the batch of tasks).) and wherein the action executions execute on multiple [channels] of the collaboration platform, and further comprising (See [0027]- In an embodiment, the forecast model may be utilized to generate a schedule for scheduling the batch of tasks on the one or more crowdsourcing platforms.): generating an aggregate ranking of the multiple learned schedules; (See [0011] FIG. 4 is a flowchart that illustrates a method for ranking a one or more schedules, in accordance with at least one embodiment. Also See [0040]- Additionally, in an embodiment, the application server 106 may also rank the schedule with respect to other schedules, which are generated for other forecast models from the one or more forecast models. )
determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to one or more of the multiple channels (See [0040]- Additionally, in an embodiment, the application server 106 may also rank the schedule with respect to other schedules, which are generated for other forecast models from the one or more forecast models. In an embodiment, the application server 106 may recommend the schedule to the requestor based on at least one of the confidence score or the ranking of the schedule. Also See [0101]-At step 316, the schedule is recommended to the requestor based on at least one of the ranking or the confidence score of the schedule. In an embodiment, the processor 202 is operable to recommend the schedule to the requestor on the requestor-computing device 108. In an embodiment, the requestor may be displayed a sorted list of the one or more schedules with the corresponding ranks and confidence scores of each schedule. In addition, in an embodiment, the requestor may also be displayed the maximum and the minimum performance scores corresponding to each schedule. Using these recommendations, the requestor may provide an input indicative of a selection of one of the one or more recommended schedules for processing of the batch of tasks.)
Srinivasan et al., Muthusami et al., and Rajan et al. are all considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan-Muthusami combination to further include wherein the learned schedule is one of multiple learned schedules, and wherein the action executions execute on [multiple channels of the collaboration platform], and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to[ one or more of the multiple channels] as taught by Rajan et al. This is desirable such it that it allows for lead to efficient scheduling of large batches of tasks on multiple crowdsourcing platforms over an extended period of time. (See Rajan [0131]).
With regards to Claim 3 and 10, the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
Chat Operations conversations of multiple users of the collaboration platform (See [0006] When a major incident occurs, some ChatOps platforms are prepared to automatically create a channel and invite support service agents from a pre-selected assignment list to join the conversation. As the team evolves, the ChatOps platform provides two-way communications between the support service agents and the affected system or systems that the support service agents are managing. Also See [0067]-Critical chat type content includes, but is not limited to, sessions on messaging platforms (e.g., on Slack® channels),)
However, the Srinivasan-Muthusami combination does not teach wherein the learned schedule is one of multiple learned schedules, wherein the contextual information is determined, and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to one or more of the multiple users.
Rajan et al. teaches:
wherein the learned schedule is one of multiple learned schedules (See [0067]-[0068]- Post generating the one or more forecast models, the processor 202 generates one or more schedules from the one or more forecast models. The generation of the one or more schedules is explained next. At step 308, a schedule is generated for each forecast model, associated with each of the one or more crowdsourcing platforms. In an embodiment, the processor 202 is operable to generate the schedule. In an embodiment, the processor 202 generates the schedule based on the forecast model and the one or more requirement parameters (i.e., the one or more parameters associated with the batch of tasks)., wherein the contextual information is determined by processing [Chat Operations conversations of multiple users of the collaboration platform], and further comprising (See [0027]- In an embodiment, the forecast model may be utilized to generate a schedule for scheduling the batch of tasks on the one or more crowdsourcing platforms.): generating an aggregate ranking of the multiple learned schedules; (See [0011] FIG. 4 is a flowchart that illustrates a method for ranking a one or more schedules, in accordance with at least one embodiment. Also See [0040]- Additionally, in an embodiment, the application server 106 may also rank the schedule with respect to other schedules, which are generated for other forecast models from the one or more forecast models. )
determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to one or more of the multiple users (See [0040]- Additionally, in an embodiment, the application server 106 may also rank the schedule with respect to other schedules, which are generated for other forecast models from the one or more forecast models. In an embodiment, the application server 106 may recommend the schedule to the requestor based on at least one of the confidence score or the ranking of the schedule. Post recommending the schedule to the requestor, in an embodiment, the application server 106 may receive an input from the requestor indicative of a selection of the schedule for processing of the batch of tasks. In response to receiving such input from the requestor, in an embodiment, the application server 106 may upload the batch of tasks on the one or more crowdsourcing platforms as per the schedule. Also See [0101]-At step 316, the schedule is recommended to the requestor based on at least one of the ranking or the confidence score of the schedule. In an embodiment, the processor 202 is operable to recommend the schedule to the requestor on the requestor-computing device 108. In an embodiment, the requestor may be displayed a sorted list of the one or more schedules with the corresponding ranks and confidence scores of each schedule. In addition, in an embodiment, the requestor may also be displayed the maximum and the minimum performance scores corresponding to each schedule. Using these recommendations, the requestor may provide an input indicative of a selection of one of the one or more recommended schedules for processing of the batch of tasks.).
Srinivasan et al., Muthusami et al., and Rajan et al. are all considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan-Muthusami combination to further include wherein the learned schedule is one of multiple learned schedules, wherein the contextual information is determined, and further comprising: generating an aggregate ranking of the multiple learned schedules; and determining, based on the aggregate ranking, an assignment of one or more of the multiple learned schedules to one or more of the multiple users as taught by Rajan et al. This is desirable such it that it allows for lead to efficient scheduling of large batches of tasks on multiple crowdsourcing platforms over an extended period of time. (See Rajan [0131]).
Claims 4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 20220308943) in view of Muthusami et al. (US 20220393992), further in view of Cohen et al.(US20170031943).
With regards to Claim 4 and 17, the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
further comprising: generating an [SLA]alert in response to detecting a failure to perform a corresponding action (See [0007]- A processor receives an alert that a malfunction or a system error has occurred. A processor creates a workspace on a ChatOps platform integrated with a chatbot and one or more tools. A processor inputs data relating to the alert that a malfunction or a system error has occurred in a natural language format. Also See [0010]- A processor generates an actionable alert directing that the highest of the one or more sequential patterns of events be executed at the end point of the IT system. A processor outputs the actionable alert to the conversation occurring in the workspace on the ChatOps platform. Also See [0030]-[0031]-Actionable alert generation program 122 operates to provide the appropriate action to resolve the malfunction or system error. Actionable alert generation program 122 operates to use data inputted into a natural language processing algorithm of the chatbot to predict the appropriate action. Actionable alert generation program 122 operates to generate and output an actionable alert to the conversation in the workspace on the ChatOps platform for the chatbot to perform automatically…actionable alert generation program 122 is initiated after receiving an alert from an application (e.g., application 134) running on a user computing device that a malfunction or system error has occurred. For example, responsive to application 134 on user computing device 130 sending actionable alert generation program 122 an alert that a malfunction or system error has occurred, actionable alert generation program 122 begins.).
However, the Srinivasan-Muthusami combination does not teach wherein the action executions are tail executions, wherein the learned schedule is a schedule of service level agreement (SLA) alerts.
Cohen et al. is directed to information technology service management records in a service level target database table may include aggregating, at a predetermined elapsed time, a plurality of actions performed on each of a plurality of ITSM records since a prior update of an SLT database.
Cohen et al. teaches:
wherein the action executions are tail executions, wherein the learned schedule is a schedule of service level agreement (SLA) alerts (See [0059]-Compressing the portion of the plurality of aggregated actions may further include identifying actions of a plurality of actions performed over a single ITSM record during the same time unit that do not affect that SLT database table entry corresponding to the ITSM record except for the elapsed-duration calculation. For example, if an ITSM record has start, suspend, and unsuspend actions performed on it, the final SLT state for the update should be active since the final action prior to the update was an unsuspend action which rendered the ITSM record active. Also See [0094]-if an ITSM record had many actions performed over it during a predetermined elapsed time period that would have modified the SLT state back and forth between active and inactive, but a final action occurring before the update was an unsuspend action rendering the ITSM record active then the SLT state may be modified to active according to that most recent action. Also See [0042]-The status may include a designation of whether the ITSM record is breached. An ITSM record may be breached when the ITSM record is currently open and being worked on, but the elapsed duration has already exceeded the target-duration and/or a time specified in a commitment such as an SLA limiting the maximum amount of time that may be spent on the ITSM record before the milestone should be achieved. Also See [0051]- The target-date may be based on the elapsed-duration of activity on the ITSM record, the working schedule of ITSM resources to which the ITSM record is assigned, and/or the target-duration terms specified in an SLA.)
*Examiner interprets the claimed “tail execution” as the final or most recent action in a sequence of related actions performed in carrying out a a process task, consistent with the specification [0053], which defines a tail execution as the last of a sequence of related action executed in performing an identifiable processing task.
Srinivasan et al., Muthusami et al., and Cohen et al. are all considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan-Muthusami combination to further include wherein the action executions are tail executions, wherein the learned schedule is a schedule of service level agreement (SLA) alerts as taught by Cohen et al. This is desirable such it that it allows for modifying an ITSM record property which may cause a target-definition to be changed (e.g., increasing a priority of an ITSM record will decrease the maximum response time of an ITSM resource) (See Cohen, [0012]).
Claims 5, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. (US 20220308943) in view of Muthusami et al. (US 20220393992), further in view of Curino et al. (US 20200133726).
With regards to Claim 5, 11, and 18, the Srinivasan-Muthusami combination teaches the claimed invention as recited in the independent claim above.
Srinivasan et al. teaches:
wherein the action executions execute on multiple channels of the collaboration platform, and wherein the clustering comprises: (See [0006] When a major incident occurs, some ChatOps platforms are prepared to automatically create a channel and invite support service agents from a pre-selected assignment list to join the conversation. As the team evolves, the ChatOps platform provides two-way communications between the support service agents and the affected system or systems that the support service agents are managing. Also See [0067]-Critical chat type content includes, but is not limited to, sessions on messaging platforms (e.g., on Slack® channels),)
Chat operations (See [0006] When a major incident occurs, some ChatOps platforms are prepared to automatically create a channel and invite support service agents from a pre-selected assignment list to join the conversation. As the team evolves, the ChatOps platform provides two-way communications between the support service agents and the affected system or systems that the support service agents are managing.)
However, the Srinivasan-Muthusami combination does not teach generating a dependency graph based on [Chat Operations] contextual information for each action execution [on each of the multiple channels]; determining a dependency order for each of the action executions in accordance with the clustering based on times of past executions; and ranking the recommendation candidates based on the dependency order of each action.
Curino et al. is directed to a system and method for ranking and/or taking an action regarding execution of jobs of a shared computing cluster based upon predicted user impact.
Curino et al. teaches:
generating a dependency graph based on [Chat Operations] contextual information for each action execution [on each of the multiple channels]; (See [0022]-[0023]- The system 100 can utilize this observation in order to open up the opportunity to leverage observations from past runs to inform decisions made for future runs. The system 100 provides a mechanism that leverages historical traces of job executions, and tracks their provenance (i.e., the lineage of data dependencies among jobs) and their telemetry (e.g., statistics about a job execution, such as time in which the job was started/completed, CPU hours spend by the jobs, total data read/written) to automatically derive a notion of “relevance/importance” of a job, and correlate it to time of the job execution to arrive at job-impact based utility function(s)… The system 100 further includes a data dependencies component 130 that determine data dependencies between the plurality of jobs. In some embodiments, the data dependencies can be represented by a DAG. )
determining a dependency order for each of the action executions in accordance with the clustering based on times of past executions; (See [0025]- In some embodiments, job-impact can be expressed in terms of how much downstream work a job is able to unblock once it is completed, or how much work cannot proceed due to the job failing or being delayed. Also See [0022] The system 100 can utilize this observation in order to open up the opportunity to leverage observations from past runs to inform decisions made for future runs. The system 100 provides a mechanism that leverages historical traces of job executions, and tracks their provenance (i.e., the lineage of data dependencies among jobs) and their telemetry (e.g., statistics about a job execution, such as time in which the job was started/completed, CPU hours spend by the jobs, total data read/written) to automatically derive a notion of “relevance/importance” of a job, and correlate it to time of the job execution to arrive at job-impact based utility function(s).)
ranking the recommendation candidates based on the dependency order of each action (See [0034]-The system 100 also includes a job ranking component 160 that ranks the plurality of jobs based upon the calculated user impact. The system 100 further includes a job action component 170 that takes an action in accordance with the ranking of the plurality of jobs. In some embodiments, the action can include automatically scheduling the jobs in accordance with the ranking of the plurality of jobs. Also [0064] -a method of ranking and/or taking an action regarding execution of jobs of a shared computing cluster based upon predicted user impact, comprising: obtaining information regarding previous executions of a plurality of jobs; determining data dependencies of the plurality of jobs; calculating job impact of each of the plurality of jobs as a function of the determined data dependencies; calculating user impact of each of the plurality of jobs as a function of the determined data dependencies, the calculated job impact and time; ranking the plurality of jobs in accordance with the calculated user impact; and taking an action in accordance with the ranking of the plurality of jobs.).
Srinivasan et al., Muthusami et al., and Curino et al. are all considered to be analogous to the claimed invention because they are in the same field of analyzing operational information and using learned patterns to recommend, schedule, and execute actions. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Srinivasan-Muthusami combination to further include generating a dependency graph based on [Chat Operations] contextual information for each action execution [on each of the multiple channels]; determining a dependency order for each of the action executions in accordance with the clustering based on times of past executions; and ranking the recommendation candidates based on the dependency order of each action as taught by Curino et al. This is desirable such it that it allows for a system for ranking and/or taking an action regarding execution of jobs of a shared computing cluster based upon predicted user impact. (See Curino, [0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
VINAYAKA et al. (US20250232260) discloses systems and methods for enhanced software development lifecycle management using a pipeline of machine learning and adaptive models for anomaly detection and termination. In some aspects, the system may generate a system data stream for an SDLC management platform that stitches together source data from multiple sources.
Kikuchi et al. (US20220067053) discloses a method for a multi-channel search includes receiving a specific post selection submitted in a first channel and query text associated with the specific post in the first channel, where the query text includes one or more words for performing a query evaluation.
All sources listed above are relevant to the disclosed and claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAA WADIE HUSSEIN whose telephone number is 571-270-1748. The examiner can normally be reached M-F: 8:00-5:00.
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, Jessica Lemieux can be reached on 571-270-3445. 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.
/A.W.H./
Examiner, Art Unit 3626
/SANGEETA BAHL/Primary Examiner, Art Unit 3626
Prosecution Insights