DETAILED ACTION
Notice to Applicant
The following is a NON-FINAL Office action upon examination of application number 18/836,019 filed on 09/15/2023, in response to Applicant’s Request for Continued Examination (RCE) filed on March 13, 2026. Claims 1-4, 6-12, and 14-17 are pending in this application, and have been examined on the merits discussed below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
3. In the response filed March 13, 2026, Applicant amended claims 1 and 9, and did not cancel any claims. New claim 17 was presented for examination.
4. Applicant's amendments to the claims are hereby acknowledged. The amendments are not sufficient to overcome the previously issued claim rejection under 35 U.S.C. 101; accordingly, this rejection has been maintained.
Response to Arguments
5. Applicant's arguments filed March 13, 2026, have been fully considered.
6. Applicant submits “The features of the present disclosure make clear that the claimed invention is tied to a particular technological solution in a technological environment, namely, improved computer processing where a computing device programmatically and dynamically generate prompts as inputs for a large language model (LLM) from exception records that are generated in response to detected events in one or more subsystems deployed for a facility, where the LLM of the task generator is adapted to generate outputs that are tailored, field-specific responses to the prompts.” [Applicant’s Remarks, 03/13/2026, page 6]
The Examiner respectfully disagrees. In response to Applicant’s argument that “the features of the present disclosure make clear that the claimed invention is tied to a particular technological solution in a technological environment,” it is noted that the claim language does not recite any specific technological improvement to computer functionality. The steps related to generating exception records, generating prompts, and providing these prompts to a large language model merely describe collecting, evaluating, and using information to produce task outputs. These operations fall within abstract ideas implemented on generic computer components. The alleged “dynamic prompt generation” and “field-specific responses” are recited at a high level of generality and reflect only the use of a large language model as a tool, rather than any improvement to the operation of the LLM or the computer itself.
Moreover, the additional elements including the LLM and the electronic device do not integrate the abstract idea into a practical application. Thes element are recited in a generic manner, without any specific technical details describing how they are implemented or how they operate in a distinct way. For the reasons above, this argument is found unpersuasive.
7. Applicant submits “the claimed invention provides improved system for monitoring and responding to events detected by one or more subsystems deployed for a facility using programmatically generated prompts that are input to an LLM, which has been adapted to output tailored responses to the prompts within a specific field. This transforms the general-purpose LLM into a specialized task generator. This is not simply "applying an abstract idea on a generic computer." It is a specific technological improvement to the computer system itself. The process improves the quality and accuracy of the LLM's output by providing it with the necessary context to reason about the field-specific problem of disruptions that are detected as events by one or more subsystems associated with a facility. Therefore, the claims of the present application are patent eligible because the claims are not directed to a judicial exception and recite elements that result in a practical application.” [Applicant’s Remarks, 03/13/2026, page 7]
In response to Applicant’s argument that “the claims of the present application are patent eligible because the claims are not directed to a judicial exception and recite elements that result in a practical application,” the Examiner respectfully disagrees. Under Step 2A Prong Two of the eligibility inquiry, any additional elements are evaluated individually and in combination to determine whether they integrate the judicial exception into a practical application, with consideration of the following exemplary considerations that may be indicative of a practical application: an additional element that reflects an improvement to the functioning of a computer or to any other technology or technical field, applying the exception with a particular machine, applying the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, effecting a transformation of a particular article to a different state or thing, and applying or using the judicial exception some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
In this instance, the additional elements recited in exemplary claim 1 include: a large language model (LLM) of a task generator and an electronic device from a plurality of electronic devices. These elements have been considered individually and in combination, however these computing elements amount to using a generic computer programmed with computer-executable instructions/software to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment, which is not sufficient to amount to a practical application, as noted in MPEP 2106. See also MPEP 2106.05(f) and 2106.05(h). Furthermore, these additional elements fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Instead, the task generator amounts to using generic computing devices as tools to implement the abstract idea, which does not amount to a technological improvement or otherwise indicate a practical application. See MPEP 2106.05(f).
The Examiner emphasizes that nowhere in Applicant’s Specification is there any discussion or suggestion that the problem or solution is a technical one, nor is there even a hint of any contemplated improvement to technology. It is not clear how the claimed limitations provide an actual improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment evident in the claims. The Applicant’s claims do not adequately explain how the additional elements of the claim integrate to add any meaningful limits on the abstract idea. At the most, the claimed invention seems to provide improvement beneficial to the end users. The focus of the claims of the instant application is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. Even reviewing the Applicant’s Specification (which describes the hardware and software), it is not made clear how the hardware and software result in an improvement to the technology or hardware itself, etc. The claimed invention does not provide an improvement to another technology/technical field or the functioning of the computer itself. Applicant's invention is directed towards providing business solutions to business problems rather than providing technical solutions to technical problems; thus, the claimed invention does not provide an improvement to another technology/technical field or the functioning of the computer itself. The Examiner further points out there is no actual improvement to another technology or technical field, no improvement to the functioning of the computer itself, and no meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment evident in the claims.
It is also noted that Applicant’s claims are devoid of any discernible change, transformation, or improvement to a computer (software or hardware) or any existing technology. Applicant has not shown that any specific technological improvement is achieved within the scope of the claims. It bears emphasis that no task generator or technological elements are modified or improved upon in any discernible manner. Instead, the result produced by the claims is simply information including exception records, which is not a technical result or improvement thereof. The resulting output provided in the form of at least one task for responding to the operational disruptions, at most, represents an insignificant interaction with a generic computer, though without causing any form of change, modification, enhancement, or improvement to the processor, memory, or any technological element. For the reasons above, this argument is found unpersuasive.
Last, in response to Applicant’s argument that “This is not simply "applying an abstract idea on a generic computer,” it is noted that although the claim recites the use of an LLM and programmatically generated prompts, these elements are invoked at a high level of generality and perform their expected functions of receiving and producing output. The claim does not recite any specific technical implementation or modification that changes how the LLM operates, nor does it impose meaningful limits on how the prompts are generates beyond their use with the model. Therefore, the additional elements implement the abstract idea using generic computing components, rather than providing a technological improvement. Accordingly, the claim still amounts to applying the abstract idea in a computer environment.
For the reasons above, in addition to the reasons provided in the updated §101 rejection below, Applicant’s amendment and supporting arguments rejection are not sufficient to overcome the §101 rejection.
8. Applicant submits “Bober, Michael, and Parisa, when considered alone or in combination, fail to disclose, teach or suggest, inter alia, "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1.” [Applicant’s Remarks, 03/13/2026, page 7]
In response to the Applicant’s argument that “Bober, Michael, and Parisa, when considered alone or in combination, fail to disclose, teach or suggest, inter alia, "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions; wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1,” it is noted that this argument is a mere allegation of patentability by the Applicant with no supporting rationale or explanation. Merely stating that the claims do not teach a feature does not offer any insight as to why the specific sections of the prior art relied upon by the Examiner fail to disclose the claimed features. Applicant's arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Moreover, the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 03/13/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the new ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim 1 and supports a conclusion of obviousness of the amended claims.
9. Applicant submits “Bober fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1.” [Applicant’s Remarks, 03/13/2026, pages 8-9]
In response to Applicant’s argument that “Bober fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 03/13/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the new ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim 1 and supports a conclusion of obviousness of the amended claims.
In response to Applicant’s argument that “Bober fails to disclose, teach, or suggest "wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph,” it is noted that Bober was not asserted as teaching the disputed limitation. Accordingly, this argument is deemed moot.
10. Applicant submits “Michael fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1.” [Applicant’s Remarks, 03/13/2026, page 9]
In response to Applicant’s argument that “Michael fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 03/13/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the new ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim 1 and supports a conclusion of obviousness of the amended claims.
In response to Applicant’s argument that “Michael fails to disclose, teach, or suggest “wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph,” it is first noted that Michael was only relied upon as teaching wherein the set of attributes includes a priority level and an event frequency. Next, as discussed in paragraphs 0126 and 0127, the Michael reference teaches calculating a critic laity score using factors such as part cost, labor cost, cost of lost production, and the frequency of failure events. The frequency of failure events Is derived from work order data and asset history, which under the broasted reasonable interpretation correspond to the claimed event frequency. Similarly, Michael teaches assigning relative importance to parts based on these calculated scores, which corresponds to a priority level. Thus, given the broadest reasonable interpretation consistent with the specification in construing the claimed invention, it is Examiner’s position that the disclosure of Michael teaches and at least suggests the disputed limitation. Accordingly, this argument is found unpersuasive.
11. Applicant submits “Parisa fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1.” [Applicant’s Remarks, 03/13/2026, pages 9-10]
In response to Applicant’s argument that “Parisa fails to disclose, teach, or suggest "programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions; and selecting an electronic device from a plurality of electronic devices for association with the at least one task," as recited by claim 1,” the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 03/13/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claim 1 that are believed to be addressed via the new ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim 1 and supports a conclusion of obviousness of the amended claims.
In response to Applicant’s argument that “Parisa fails to disclose, teach, or suggest “wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph,” it is first noted that Parisa was only relied upon as teaching wherein the set of attributes includes a dependency count, the dependency count being updated by monitoring changes of a dependency graph. Next, as discussed in paragraphs 0009 and 0055 of Parisa, the reference teaches parsing incident tickets to identify dependent application using a dependency graph and updating the dependency graph based on whether related applications are affected by a disruption. This process suggests monitoring changes in the dependency graph and tracking the number of dependent applications, which corresponds to the claimed dependency count being updated by monitoring changes of a dependency graph. Thus, given the broadest reasonable interpretation consistent with the specification in construing the claimed invention, it is Examiner’s position that the disclosure of Parisa teaches and at least suggests the disputed limitation. Accordingly, this argument is found unpersuasive.
12. Applicant submits “that new claim 17 recite additional subject matter that further patentably distinguishes over the art-of-record at least because Bober, Michael, Parisa, Bishnoi, Adams, and Alcorn, when considered alone or in combination fail to disclose, teach, or suggest that "the selected set of the exception records utilized for programmatic generation of the prompt are grouped based on a temporal proximity between the plurality of events," as recited by claim 17.” [Applicant’s Remarks, 03/13/2026, pages 10-11]
In response to the Applicant’s argument that “Bober, Michael, Parisa, Bishnoi, Adams, and Alcorn, when considered alone or in combination fail to disclose, teach, or suggest that "the selected set of the exception records utilized for programmatic generation of the prompt are grouped based on a temporal proximity between the plurality of events," as recited by claim 17,” it is noted that this argument is a mere allegation of patentability by the Applicant with no supporting rationale or explanation. Merely stating that the claims do not teach a feature does not offer any insight as to why the specific sections of the prior art relied upon by the Examiner fail to disclose the claimed features. Applicant's arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Moreover, the Examiner notes the limitations being argued by Applicant as being newly added in the response filed 03/13/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to newly presented claim 17 that are believed to be addressed via the new ground of rejection under §103 set forth in the instant Office action.
13. Applicant’s remaining arguments either logically depend from the above-rejected arguments, in which case they too are unpersuasive for the reasons set forth above, or they are directed to features which have been newly added via amendment. Therefore, this is now the Examiner's first opportunity to consider these limitations and as such any arguments regarding these limitations would be inappropriate since they have not yet been examined. A full rejection of these limitations will be presented later in this Office Action.
Claim Rejections - 35 USC § 112
14. The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
15. Claims 1-4, 6-12, and 14-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
16. Claim 1 was amended to recite “inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records.” The meaning of the phrase “output responses to exception the exception records” is unclear. As written, the phrase is grammatically and syntactically ambiguous, and it is not clear whether the limitation ss intended to mean: output responses to the exception records, output responses to exceptions in the exception records, or some other operation involving the exception records, thus rendering the scope of the claim indefinite. Independent claim 9 recites similar limitations as those discussed above and are therefore found to be indefinite for the same reasons as claim 1. Appropriate correction is required.
17. All claims dependent from above rejected claims are also rejected due to dependency.
Claim Rejections - 35 USC § 101
18. 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.
19. Claims 1-4, 6-12, and 14-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the method (claims 1-4, 6-8, and 17) and computing device (claims 9-12 and 14-16), and is directed to at least one potentially eligible category of subject matter (i.e., process and machine, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-4, 6-12, and 14-17 is satisfied.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls into the “Certain Methods of Organizing Human Activity” abstract idea set forth in MPEP 2106 because the claims recite steps for managing events at a facility, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), and steps that can be performed in the human mind (including observation, evaluation, judgment, opinion), and therefore fall under the “Mental Processes” abstract idea grouping. With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: detecting a plurality of events corresponding to operational disruptions for a facility, each event including one of a predetermined set of identifiers; retrieving configuration data defining, for each identifier, a description of each disruption type and a set of attributes; determining, for each event, a score based on the set of attributes; generating, for each event, an exception record encoding the identifier and the score; sorting the exception records according to the scores; programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task. These steps are organizing human activity by managing interactions between people by following rules, or instructions, and may also be accomplished mentally such as via human observation and perhaps with the aid of pen and paper.
Therefore, because the limitations above set forth activities falling within the “Certain methods of organizing human activity” and “Mental Processes” abstract idea grouping described in MPEP 2106, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below. Independent claim 9 recites similar limitations as those discussed above and are therefore found to recite the same or substantially the same abstract idea as claim 1.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. With respect to independent claims 1/9, the additional elements are: programmatically, a large language model (LLM) of a task generator and an electronic device from a plurality of electronic devices (claim 1); a communications interface, a processor, a large language model (LLM) of a task generator, and an electronic device from a plurality of electronic devices (claim 9). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Even if the step for output is not deemed part of the abstract idea, this step is at most directed to insignificant extra-solution activity, which is not sufficient to amount to a practical application. See MPEP 2106.05(g). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. With respect to independent claims 1/9, the additional elements are: programmatically, a large language model (LLM) of a task generator and an electronic device from a plurality of electronic devices (claim 1); a communications interface, a processor, a large language model (LLM) of a task generator, and an electronic device from a plurality of electronic devices (claim 9). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment and does not amount to significantly more than the abstract idea itself. Notably, Applicant’s Specification suggests that virtually any type of computing device under the sun can be used to implement the claimed invention (Specification at paragraph [0022]). Accordingly, the generic computer involvement in performing the claim steps merely serves to generally link the use of the judicial exception to a particular technological environment, which does not add significantly more to the claim. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.). Next, the step for output is considered insignificant extra-solution output activity (transmitting data), which has been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d).
Even if the large language model (LLM) weas evaluated as an element beyond software/code for a generic computer to execute, it is noted that that the claimed use of a large language model (LLM) is recited at a high level of generality these elements amount to well-understood, routine, and conventional activity in the art, which fails to add significantly more to the claims. See, e.g., Georgescu et al., US 2025/0046434 A1 (paragraph 0002: “generative abilities are a strength of conventional LLMs”). See also, Radmilac et al., US 2024/0411751 A1 (paragraph 0004: “Conventional LLMs, as well as model networks that further process and analyze outputs from LLMs including interconnected sets of machine learning models, often serve a large and diverse group of users across different enterprises”).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent claims 2-4, 6-8, 10-12, and 14-17 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above. In particular, dependent claims 2-4, 6-8, and 17 recite “obtaining the at least one task; and transmitting the at least one task,” “wherein detecting the events includes: maintaining configuration data defining the predetermined set of identifiers; and monitoring event data for events having one of the predetermined set of identifiers,” “storing the exception records upon generation; and sorting the exception records according to the scores in response to expiry of a predetermined time period,” “wherein determining the score is based on the set of attributes and the sets of attributes corresponding to each of the plurality of events,” “wherein determining the score for a first one of the events includes determining a ratio of a first value based on the set of attributes corresponding to the first event, and a second value based on a combination of the sets of attributes for each of the events,” “wherein the exception records are one-dimensional arrays; and wherein providing the exception records includes concatenating the one-dimensional arrays in descending order of scores,” “wherein the selected set of the exception records utilized for programmatic generation of the prompt are grouped based on a temporal proximity between the plurality of events,” however these limitations cover activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), which is part of the same abstract idea as addressed in the independent claims that falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping and also recite steps that may also be accomplished mentally such as via human observation and perhaps with the aid of pen and paper. The other dependent claims have been evaluated as well, but similar to claims 2-4 and 6-8, these claims also recite details of the abstract ideas themselves accompanied by, at most, generic computer implementation, which is not enough to transform the claims into a practical application of the abstract idea or amount to significantly more than the abstract idea itself. See MPEP 2106.05(f),(h). See also, Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976. Dependent claims 2-3, 10-11, and 17 recite additional elements of: a client computing device, at least one operational subsystem, programmatic. However, when evaluated under Step 2A Prong Two and Step 2B, these additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself.
For more information, see MPEP 2106.
Claim Rejections - 35 USC § 103
20. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
21. 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 of this title, 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.
22. 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.
23. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
24. Claims 1-3, 6, 9-11, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bober et al., Pub. No.: US 2025/0036516 A1, [hereinafter Bober], in view of Michael et al., Pub. No.: US 2022/0147952 A1, [hereinafter Michael], in view of Parisa et al., Pub. No.: US 2021/0357284 A1, [hereinafter Parisa], in further view of Anthony et al., Pub. No.: US 2025/0004450 A1, [hereinafter Anthony].
As per claim 1, Bober teaches a method (paragraph 0012), comprising:
detecting a plurality of events corresponding to operational disruptions for a facility, each event including one of a predetermined set of identifiers (paragraph 0016, discussing automated methods that function in real-time and perform an analysis of prepared log data by automatically referencing a repository of known log sequences. When a known log sequence is identified in the log data, a corresponding operational condition (e.g., operational issue) and/or response may be automatically identified; paragraph 0019, discussing that the method may include: obtaining log data for a data processing system of the data processing systems, the log data including log messages that indicate activity of the data processing system during a period of time, the activity indicating a disruption in the computer-implemented services; paragraph 0034, discussing that a log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages (e.g., portions of the log) that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as conditions encountered by a component, a time when the condition was encountered, an identifier associated with a condition and/or a generator of the log (e.g., the device), an indication of a relative level of importance or severity of the encountered conditions, and/or other types of information; paragraph 0037, discussing that in order to identify operational issues, for example, of IoT devices, the logs of IoT devices may be monitored and/or analyzed; paragraph 0039, discussing that in order to identify and/or address operational issues of one or more devices in an efficient and cost-effective manner, the large volumes of log data collected from the one or more devices may be analyzed using automated methods of operational issue detection; paragraph 0043, discussing that through automated log analysis, operational issue(s) may be identified; paragraph 0053, discussing a process for managing a disruption in computer-implemented services provided by data processing systems. To do so, the disruption may be identified using a log data preparation process and/or an analysis process; paragraphs 0057, 0107);
retrieving configuration data defining, for each identifier, a set of attributes (paragraph 0034, discussing that a log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages (e.g., portions of the log) that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as conditions encountered by a component, a time when the condition was encountered, an identifier associated with a condition and/or a generator of the log (e.g., the device), an indication of a relative level of importance or severity of the encountered conditions, and/or other types of information; paragraph 0055, discussing that the log data collected by log data preparation process may be implemented with structured or unstructured data; therefore, the collected log data may be processed through a data pipeline which may include data normalization (e.g., standardizing collected log data based on a schema compatible for storage in a relational database) and/or other data processing. For example, unstructured log data may be cleaned and/or transformed to produce structured log data and/or different formats of collected structured log data may be transformed in order to produce standardized log data (e.g., based on the predetermined schema). The standardized log data may include tabular data with columns and rows that define attributes of the log data (e.g., extracted during the normalization and/or processing of the collected log data); paragraph 0057, discussing that log data attributes may include, for example, (i) portions of log messages of the log data (e.g., key words and/or numeric identifiers extracted from the log messages), (ii) time stamps of the portions of the log messages, (iii) information regarding the source of the log data (e.g., IoT device identifiers), (iv) information regarding data processing systems that may have forwarded the log data from the source (e.g., gateway and/or edge device identifiers), and/or (v) information from data tags (e.g., added by users and/or inference models; paragraph 0061, discussing that the historical log data may be prepared for analysis using a process similar to log data preparation process, where the historical log data may be normalized, and/or log data attributes may be generated (e.g., extracted and/or added) before the historical log data is analyzed; paragraphs 0058, 0059);
determining, for each event, a score (paragraph 0034, discussing that when operating, device and/or their components may generate log data (e.g., one or more operational logs). A log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as (i) conditions encountered by a component (e.g., of a device), (ii) a time when the condition was encountered, (iii) an identifier associated with a condition and/or a generator of the log (e.g., the device), (iv) an indication of a relative level of importance or severity of the encountered conditions, and/or (v) other types of information);
generating, for each event, an exception record encoding the identifier and the score (paragraph 0034, discussing that when operating, device and/or their components may generate log data (e.g., one or more operational logs). A log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as (i) conditions encountered by a component (e.g., of a device), (ii) a time when the condition was encountered, (iii) an identifier associated with a condition and/or a generator of the log (e.g., the device), (iv) an indication of a relative level of importance or severity of the encountered conditions, and/or (v) other types of information; paragraph 0042, discussing that the device manager may (i) obtain log data for hardware and/or software components of data processing systems and/or devices operably connected to data processing systems, (ii) prepare the log data (e.g., based on a predetermined schema) for storage and/or analysis, (iii) initiate analysis of and/or analyze the prepared log data to identify an operational condition (e.g., using a repository of modeled log data and corresponding remedial responses), (iv) generate an action set based on the analysis (e.g., a corresponding remedial response to an operational issue), and/or (v) generate and/or provide a notification regarding the operational issue and/or instructions for mitigating (e.g., correcting or compensating for) the operational issue; paragraph 0056, discussing that as part of log data preparation process, the collected log data may be classified and/or enriched, for example, by adding attributes and/or data tags to the collected log data and/or other methods of data enrichment that may improve the future usability of the log data);
sorting the exception records according to the scores (paragraph 0071, discussing that the dashboard may obtain notifications from the action set generation process and/or may be adapted to present status information regarding the devices to an administrator. The dashboard may include, for example, filtering functionality, which may allow the administrator to filter information displayed by the dashboard based on a level of risk and/or response type so that only critical operational issues requiring human intervention may be displayed. By doing so, the user may prioritize resources (e.g., human resources and/or computing resources) for critical operational issues, which may increase the likelihood of maintaining the provision of computer-implemented services provide by the devices); and
outputting, from the task generator, at least one task for responding to the operational disruptions (paragraph 0016, discussing that to improve the efficiency of the identification of operational issues in large numbers of devices, automated methods of log data analysis may be implemented. The automated methods may function in real-time and may perform an analysis of prepared log data by automatically referencing a repository of known log sequences (e.g., one or more log messages). When a known log sequence is identified in the log data, a corresponding operational condition (e.g., operational issue) and/or response may be automatically identified. The response may be used to generate timely and/or appropriate remedial responses that, when performed, may reduce negative outcomes of the operational conditions (e.g., that may negatively affect the computer-implemented services provided by the far edge devices). The action sets may include corrective action and/or compensatory action; paragraph 0039, discussing that in order to identify and/or address operational issues of one or more devices in an efficient and cost-effective manner, the large volumes of log data collected from the one or more devices may be analyzed using automated methods of operational issue detection. Additionally, automated methods of remediation may be implemented, for example, via automatic generation of instructions for corrective and/or compensatory action that may prevent and/or mitigate the operational issues and/or outcomes of the operational issues; paragraph 0042, discussing generating an action set based on the analysis (e.g., a corresponding remedial response to an operational issue), and/or (v) generate and/or provide a notification regarding the operational issue and/or instructions for mitigating (e.g., correcting or compensating for) the operational issue; paragraph 0071, discussing that the dashboard may obtain notifications from the action set generation process and/or may be adapted to present status information regarding the devices to an administrator. The dashboard may include, for example, filtering functionality, which may allow the administrator to filter information displayed by the dashboard based on a level of risk and/or response type so that only critical operational issues requiring human intervention may be displayed. By doing so, the user may prioritize resources (e.g., human resources and/or computing resources) for critical operational issues, which may increase the likelihood of maintaining the provision of computer-implemented services provide by the device; paragraph 0017).
Bober does not explicitly teach retrieving configuration data defining, for each identifier, a description of each disruption type; determining, for each event, a score based on the set of attributes; programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a priority level, an event frequency, and a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task. Michael in the analogous art of disruption management systems teaches:
determining, for each event, a score based on the set of attributes (paragraph 0126, discussing a system for calculating part criticality scores. Although the system identifies functionally significant components, part criticality provides more information that may be used to prioritise remedial action. Criticality utilises one or more of the Weibull distribution, work order frequency, part cost, labor cost, and cost of lost production and disruption to calculate a criticality score. Several factors impact the criticality score. The impact of failure may be characterised by a mix of material cost, labour cost for corrective work and the cost equivalent for lost production time while the asset is unavailable. The frequency of the failure events may be a combination of a B-20 age from the Weibull distribution and the number of preventative or corrective work orders per unit time. The detectability of the failure occurring may be derived from the asset history work orders and notifications, with a range of severity from the ‘failure was sudden, with no prior warning to operators or maintainers’ down to ‘the failure showed many different symptoms of failure as the condition slowly deteriorated over time where the symptoms were apparent to the operations or maintenance staff, with enough time before final failure, to plan, schedule and undertake corrective maintenance minimising operational disruption’; paragraph 0127, discussing that a part criticality score may be generated using a critical score function from the part's work order frequency, Weibull statistics generated using the Weibull fitter, the part's costs, the labour cost to service the work orders, and the cost of lost production and disruption in the event of a failure. The work order frequency is determined from the processed work order data and asset history);
wherein the set of attributes includes a priority level and an event frequency (paragraph 0126, discussing a system for calculating part criticality scores. Although the system identifies functionally significant components, part criticality provides more information that may be used to prioritise remedial action. Criticality utilises one or more of the Weibull distribution, work order frequency, part cost, labor cost, and cost of lost production and disruption to calculate a criticality score. Several factors impact the criticality score. The impact of failure may be characterised by a mix of material cost, labour cost for corrective work and the cost equivalent for lost production time while the asset is unavailable. The frequency of the failure events may be a combination of a B-20 age from the Weibull distribution and the number of preventative or corrective work orders per unit time. The detectability of the failure occurring may be derived from the asset history work orders and notifications, with a range of severity from the ‘failure was sudden, with no prior warning to operators or maintainers’ down to ‘the failure showed many different symptoms of failure as the condition slowly deteriorated over time where the symptoms were apparent to the operations or maintenance staff, with enough time before final failure, to plan, schedule and undertake corrective maintenance minimising operational disruption’; paragraph 0127, discussing that a part criticality score may be generated using a critical score function from the part's work order frequency, Weibull statistics generated using the Weibull fitter, the part's costs, the labour cost to service the work orders, and the cost of lost production and disruption in the event of a failure. The work order frequency is determined from the processed work order data and asset history).
Bober is directed to computer-implemented services performed by using artificial intelligence models. Michael is directed to optimization systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for task management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bober with Michael because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying Bober to include Michael’s features for including determining, for each event, a score based on the set of attributes and including wherein the set of attributes includes a priority level and an event frequency, in the manner claimed, would serve the motivation of increasing asset availability for profitable utilization, and increasing reliability to reduce disruption (Michael at paragraph 0099); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The Bober-Michael combination does not explicitly teach retrieving configuration data defining, for each identifier, a description of each disruption type; programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, wherein the set of attributes includes a dependency count, the dependency count being updated by monitoring changes of a dependency graph; and selecting an electronic device from a plurality of electronic devices for association with the at least one task. Parisa in the analogous art of incident management systems teaches:
retrieving configuration data defining, for each identifier, a description of each disruption type (paragraph 0009, discussing a method, system, and computer program product for incident management; paragraph 0053, discussing a service application interface incident reporting component that transmits incident data of a service disruption to an incident management system. The incident data may include information, for example, an area of the service application interface effected, the date of the disruption, the type of the disruption, or the length of the disruption; paragraph 0061); and
wherein the set of attributes includes a dependency count, the dependency count being updated by monitoring changes of a dependency graph (paragraph 0009, discussing that an embodiment includes a method for incident management. The embodiment parses, responsive to an incident ticket being opened relative to a first application, to identify a set of incident data. The embodiment identifies, using a dependency graph, a set of applications, wherein each application in the set of applications is dependent on the first application through at least one dependency relationship; paragraph 0055, discussing that the application parses the ticket to identify and extract information from the ticket. The information extracted from the ticket is parsed, utilizing a dependency graph, to identify related or dependent applications. The related application depends on the first application because of a data flow occurring between the first application and the related application during a performance of the type of transaction in the related application. The application will determine if the related application is affected by the disruption. If the related application is determined to be affected by the disruption recoding in the incident data, the service provider for the related application will be notified of the disruption and the potential disruption it may cause to that related application. If the related application is determined to be unaffected by the disruption recoding, the service provider in the related application will not be notified and the dependency graph will be updated. Notification to the service provider of the related application prevents the service provider of the related application from opening an incident ticket for a related disruption in the second service. The notification alerts the service provider that the disruption is already being investigated; paragraph 0060, discussing an example configuration of updating the dependency graph; paragraph 0061, discussing that the relationship between the first application and the related application is dynamic. The extracted information can analyze the related application to locate the data flow occurring between the first application and the related application. The relationship between the first application and the related application is located during a performance of the type of transaction in the related application . If, for example, a change made in the second application, for example, performing a second type of transaction relative to the first application, may avoid the possibility of a disruption of service in the related application. The second type of transaction causes the related application to be omitted from the dependency relationship between the first application and the related application. In that case, the dependency graph is updated and the related application is omitted from the set of related applications to be notified).
The Bober-Michael combination describes features related to machine learning and task generation. Parisa is directed to incident management systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for data processing and task management systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael combination with Parisa because the references are analogous art because they are both directed to solutions for data processing, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael combination to include Parisa’s features for including retrieving configuration data defining, for each identifier, a description of each disruption type, and wherein the set of attributes includes a dependency count, the dependency count being updated by monitoring changes of a dependency graph, in the manner claimed, would serve the motivation of increasing the efficiency of incident management processes and triaging services disruptions (Parisa at paragraph 0020); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The Bober-Michael-Parisa combination does not explicitly teach programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records; inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records; outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions; and selecting an electronic device from a plurality of electronic devices for association with the at least one task. However, Anthony in the analogous art of event detection systems teaches these concepts. Anthony teaches:
programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records (paragraph 0005, discussing a prompt engineering interface service that integrates artificial intelligence with the programming systems of an industrial automation environment to troubleshoot the devices and systems of an industrial automation environment. The prompt engineering interface service leverages the capabilities of a large language model (LLM) trained on industrial automation workflows to provide accurate and relevant troubleshooting guidance. For example, the prompt engineering interface service may generate a natural language prompt that includes instructions (e.g., for the LLM, etc.) to identify or otherwise categorize a type of anomaly based on a context of an automation system design; paragraph 0006, discussing that the software application then directs the device to generate a first prompt requesting identification of an anomaly type associated with the context of the automation system design. The first prompt may be generated based at least in part on system information of the automation system design; paragraph 0022m discussing that the prompt engineering interface service utilizes past workflows of industrial automation environments to respond to anomalies (e.g., issues, errors, failures, etc.) with accurate and relevant troubleshooting information. The prompt engineering interface service may use a variety of techniques such as natural language processing, machine learning, and deep learning to develop accurate and effective prompts for use with large language models, chatbots, virtual assistants, and the like. For example, the prompt engineering interface service may generate natural language prompts to identify or otherwise categorize an anomaly associated with a device on a network of an industrial automation system. In the same or another example, the prompt engineering interface service may generate natural language prompts to obtain relevant and accurate responses from an LLM that include solutions to address or otherwise resolve the anomaly; paragraph 0028, discussing that the model is representative of an LLM capable of processing natural language requests to generate a desired output. Examples of the model include a Generative Pretrained Transformer (GPT) model, a Bidirectional Encoder Representations from Transformer (BERT) model, and the like…Accordingly, the model may be an LLM or an LMMM. While language throughout refers to an LLM, LMMMs may be interchanged. The model may be trained using content of an embeddings database and/or domain. An embedding database includes natural language content that is organized and accessed programmatically; paragraphs 0034, 0053);
inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records (paragraph 0005, discussing that the prompt may also include instructions to identify and/or generate a solution that addresses the type of anomaly. The prompt engineering interface service may transmit the prompt to an LLM or other machine learning (ML) model and then receive a response generated by the LLM (or ML model) based on the parameters of the prompt. After receiving a response, the prompt engineering interface service may incorporate the content of the response into a user interface message for display to a user. In the same or alternative embodiment, the prompt engineering interface service modifies the automation system design based on the content of the response and surfaces a graphical user interface (GUI) that includes the modified design; paragraph 0006, discussing that the software application further directs the device to transmit the first prompt to a large language model; paragraph 0007, discussing that the software application directs the device to generate, based on the system information and the anomaly type, a second prompt requesting a solution that addresses the anomaly type. The software application further directs the device to transmit the second prompt to the large language model and receive a second response to the second prompt that includes the solution. The software application then directs the device to display the second response via the GUI. The software application may further direct the device to change the automation system design in accordance with the solution; paragraph 0025, discussing that the interface service then transmits the prompt to an LLM and receives a response based on the parameters of the prompt. The response includes the anomaly type and may further include a solution that addresses the anomaly type; paragraph 0046, discussing that the engine generates a prompt. The prompt includes a natural language query requesting troubleshooting information (e.g., identification of an anomaly type, a solution that addresses the anomaly type, a request for a user interface message to surface based on input, etc.). The engine then transmits the prompt to API 205. API 205 transmits the prompt to an LLM and receives response from the LLM; paragraph 0063);
outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions (paragraph 0005, discussing that the prompt may also include instructions to identify and/or generate a solution that addresses the type of anomaly. The prompt engineering interface service may transmit the prompt to an LLM or other machine learning (ML) model and then receive a response generated by the LLM (or ML model) based on the parameters of the prompt. After receiving a response, the prompt engineering interface service may incorporate the content of the response into a user interface message for display to a user. In the same or alternative embodiment, the prompt engineering interface service modifies the automation system design based on the content of the response and surfaces a graphical user interface (GUI) that includes the modified design; paragraph 0006, discussing that the software application further directs the device to transmit the first prompt to a large language model and receive a first response to the first prompt from the large language model; paragraph 0007, discussing that the software application directs the device to generate, based on the system information and the anomaly type, a second prompt requesting a solution that addresses the anomaly type. The software application further directs the device to transmit the second prompt to the large language model and receive a second response to the second prompt that includes the solution. The software application then directs the device to display the second response via the GUI; paragraphs 0046, 0058); and
selecting an electronic device from a plurality of electronic devices for association with the at least one task (paragraph 0007, discussing that the software application directs the device to generate, based on the system information and the anomaly type, a second prompt requesting a solution that addresses the anomaly type. The software application further directs the device to transmit the second prompt to the large language model and receive a second response to the second prompt that includes the solution. The software application then directs the device to display the second response via the GUI. The software application may further direct the device to change the automation system design in accordance with the solution; paragraph 0025, discussing that the response includes the anomaly type and may further include a solution that addresses the anomaly type. Example solutions include proposals to change the automation system design by modifying device hardware, software, controller code, layout, timing, inputs, outputs, etc. Example solutions may further include insights to supply chain issues and suggest alternatives that may avoid the supply chain issues (e.g., suggest alternative devices that have improved lead times, etc.; paragraph 0059, discussing that the computing system may receive, via the GUI, a user input that indicates an acceptance of the troubleshooting assistance and may transmit the input to the application. Subsequent to receiving the input, the application may employ the solution, for example, by completing the connection between a device and a controller, amending controller code, amending a ladder logic, amending a graphical representation of a device or system, updating the automation system design, altering a data model (e.g., create a new system model, modify an existing system model, modify a draft of the system model, etc.), etc. The application may then generate an updated GUI that includes a representation of the changes made. The updated GUI may also include a message requesting user feedback; paragraph 0072, discussing that the application may employ the solution that addresses the anomaly type, such as a solution to overcome the process failure noted in the message (e.g., altering an input of the process, updating a data model of the process, changing the power supply to a device of the process, etc.).
The Bober-Michael-Parisa combination describes features related to machine learning and task generation. Anthony is directed to artificial intelligence assisted device troubleshooting. Therefore, they are deemed to be analogous as they both are directed towards solutions for event detection. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael-Parisa combination with Bishnoi because the references are analogous art because they are both directed to solutions for data processing and event detection, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael-Parisa combination to include Anthony’s features for including programmatically generating a prompt as an input for a large language model (LLM) of a task generator based on a selected set of the exception records, inputting the prompt to the LLM of the task generator, the LLM of the task generator being adapted to output responses to exception the exception records, outputting, from the LLM of the task generator, at least one task for responding to the operational disruptions, and selecting an electronic device from a plurality of electronic devices for association with the at least one task, in the manner claimed, would serve the motivation of identifying anomalies and their respective solutions to maintain or improve the efficiency, safety, reliability, and other key performance factors of an industrial automation environment (Anthony at paragraph 0026); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 2, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Bober further teaches further comprising: obtaining, from the task generator, the at least one task (paragraph 0039, discussing that automated methods of remediation may be implemented, for example, via automatic generation of instructions for corrective and/or compensatory action that may prevent and/or mitigate the operational issues and/or outcomes of the operational issues; paragraph 0042, discussing generating an action set based on the analysis (e.g., a corresponding remedial response to an operational issue); paragraph 0051, discussing an action set which may include (i) notifying a user of the identified operational issue, and/or generating instructions for remediating the operational issue, such as instructions for corrective action and/or compensatory action); and
transmitting the at least one task to a client computing device (paragraph 0022, discussing that the additional instructions may include corrective action or compensatory action. The corrective action may modify operation of the data processing system to mitigate the disruption in the computer-implemented services. The compensatory action may modify operation of a second data processing system to mitigate the disruption in the computer-implemented services; paragraph 0042, discussing generating and/or providing a notification (e.g., to an administrator via a dashboard accessible to the administrator) regarding the operational issue and/or instructions for mitigating (e.g., correcting or compensating for) the operational issue; paragraph 0044, discussing that the generated action set may include providing a notification to a dashboard that may be monitored by one or more users (e.g., administrators); paragraph 0067).
As per claim 3, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Bober further teaches wherein detecting the events includes: maintaining configuration data defining the predetermined set of identifiers (paragraph 0034, discussing that a log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as conditions encountered by a component, a time when the condition was encountered, an identifier associated with a condition and/or a generator of the log (e.g., the device), an indication of a relative level of importance or severity of the encountered conditions, and/or other types of information; paragraph 0039, discussing that in order to identify and/or address operational issues of one or more devices in an efficient and cost-effective manner, the large volumes of log data collected from the one or more devices may be analyzed using automated methods of operational issue detection; paragraphs 0057, discussing that log data attributes may include, for example, portions of log messages of the log data (e.g., key words and/or numeric identifiers extracted from the log messages), time stamps of the portions of the log messages, information regarding the source of the log data (e.g., IoT device identifiers), (iv) information regarding data processing systems that may have forwarded the log data from the source (e.g., gateway and/or edge device identifiers), and/or (v) information from data tags; paragraphs 0094, 0099); and
monitoring event data from at least one operational subsystem for events having one of the predetermined set of identifiers (paragraph 0037, discussing that in order to identify operational issues, for example, of IoT devices, the logs of IoT devices may be monitored and/or analyzed; paragraph 0055, discussing that the log data collected by log data preparation process may be implemented with structured or unstructured data; therefore, the collected log data may be processed through a data pipeline which may include data normalization (e.g., standardizing collected log data based on a schema compatible for storage in a relational database) and/or other data processing. For example, unstructured log data may be cleaned and/or transformed to produce structured log data and/or different formats of collected structured log data may be transformed in order to produce standardized log data (e.g., based on the predetermined schema). The standardized log data may include tabular data with columns and rows that define attributes of the log data (e.g., extracted during the normalization and/or processing of the collected log data; paragraph 0059, discussing that analysis process may obtain prepared log data from log data preparation process. The prepared log data may include one or more log sequences describing the operation of one or more devices, along with log data attributes (e.g., log data attributes extracted from and/or added to the prepared log data during log data preparation process). The analysis process may attempt to identify one or more log sequence models (e.g., using a log sequence model repository) that correspond with the one or more log sequences of the prepared log data; paragraph 0061, discussing that the log sequence model and associated operational attributes may be based on a previous analysis of historical log data of devices and their corresponding historical operational attributes. The historical log data may be prepared for analysis using a process similar to log data preparation process, where the historical log data may be normalized, and/or log data attributes may be generated (e.g., extracted and/or added) before the historical log data is analyzed; paragraph 0082, discussing that the log data may also be prepared by performing a data tagging process, which may include extracting and/or adding log data attributes to metadata of the log data; paragraphs 0058, 0108).
As per claim 6, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Although not explicitly taught by Bober, Michael in the analogous art of disruption management systems teaches wherein determining the score is based on the set of attributes and the sets of attributes corresponding to each of the plurality of events (paragraph 0126, discussing a system for calculating part criticality scores. Although the system identifies functionally significant components, part criticality provides more information that may be used to prioritise remedial action. Criticality utilises one or more of the Weibull distribution, work order frequency, part cost, labor cost, and cost of lost production and disruption to calculate a criticality score. Several factors impact the criticality score. The impact of failure may be characterised by a mix of material cost, labour cost for corrective work and the cost equivalent for lost production time while the asset is unavailable. The frequency of the failure events may be a combination of a B-20 age from the Weibull distribution and the number of preventative or corrective work orders per unit time. The detectability of the failure occurring may be derived from the asset history work orders and notifications, with a range of severity from the ‘failure was sudden, with no prior warning to operators or maintainers’ down to ‘the failure showed many different symptoms of failure as the condition slowly deteriorated over time where the symptoms were apparent to the operations or maintenance staff, with enough time before final failure, to plan, schedule and undertake corrective maintenance minimising operational disruption’; paragraph 0127, discussing that a part criticality score may be generated using a critical score function from the part's work order frequency, Weibull statistics generated using the Weibull fitter, the part's costs, the labour cost to service the work orders, and the cost of lost production and disruption in the event of a failure. The work order frequency is determined from the processed work order data and asset history).
Bober is directed to computer-implemented services performed by using artificial intelligence models. Michael is directed to optimization systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for task management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Bober with Michael because the references are analogous art because they are both directed to solutions for task management, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying Bober to include Michael’s feature for including wherein determining the score is based on the set of attributes and the sets of attributes corresponding to each of the plurality of events, in the manner claimed, would serve the motivation of increasing asset availability for profitable utilization, and increasing reliability to reduce disruption (Michael at paragraph 0099); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 9 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 1, as discussed above. Further, as per claim 9 the Bober-Michael-Parisa-Anthony combination teaches a computing device, comprising: a communications interface; and a processor (Bober, paragraphs 0074, 0111, 0113, 0114, 0117).
Claim 10 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 2, as discussed above.
Claim 11 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 3, as discussed above.
Claim 14 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 6, as discussed above.
25. Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bober in view of Michael, in view of Parisa, in view of Anthony, in further view of Bishnoi, Pub. No.: US 2014/0201355 A1, [hereinafter Bishnoi].
As per claim 4, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Bober further teaches further comprising: storing the exception records upon generation (paragraph 0055, discussing that the collected log data may be processed through a data pipeline which may include data normalization (e.g., standardizing collected log data based on a schema compatible for storage in a relational database) and/or other data processing…; paragraph 0058, discussing that once the collected log has been normalized, processed, enriched, etc., log data preparation process may provide the prepared log data to a prepared log data repository where it may be stored. The prepared log data repository may be managed using a database, which may be queried using key words that may match one or more log data attributes, metadata tags, etc. The prepared log data may also be provided to the analysis process; paragraph 0063, discussing that the log sequences models (with associated log data attributes and/or operational attributes) may be stored in a repository such as log sequence model repository. The log sequence model repository may be managed using a relational database (e.g., which may be queried based on key words corresponding to log data attributes). The log sequence model repository may be accessible to the analysis process. The analysis process may use key words (e.g., based on log data attributes) of the prepared log data to identify a corresponding log sequence model stored in log sequence model repository; paragraph 0094).
The Bober-Michael-Parisa-Anthony combination does not explicitly teach sorting the exception records according to the scores in response to expiry of a predetermined time period. However, Bishnoi in the analogous art of event management systems teaches this concept. Bishnoi teaches:
sorting the exception records according to the scores in response to expiry of a predetermined time period (paragraph 0100, discussing that various data structures may be used to implement a variable duration time-based window. In one embodiment, a priority queue is used, where the priority is dictated by the expiration time computed for the events in the window. Newly received events are added to the queue and expired events are deleted from the queue. The events in the queue may be sorted based upon their associated expiration times. In one embodiment, the events are sorted such that events having earlier expiration times are closer to the head of the queue and events having later expiration times are towards the tail of the queue. At any time instance, the priority queue may comprise zero or more events representing the zero or more events in the time-based window at that time instance; paragraph 0104, discussing that the event at the head of the priority queue is accessed. Since event elements in the priority queue are always sorted based upon the expiration times associated with the events, with events having earlier expiration times being closer to the head of the queue and events having later expiration times being towards the tail of the queue, the event at the head of the queue represents an event in the window with the earliest expiration time; paragraph 0106, discussing that the event is inserted in a manner that maintains the sorted nature of the queue (i.e., sorted based upon the expiration times); paragraph 0157, discussing that within a queue for a partition, the events in the queue may be sorted based upon their associated expiration times. In one embodiment, the events are sorted such that events having earlier expiration times are closer to the head of the queue and events having later expiration times are towards the tail of the queue…; paragraph 0161, discussing that the event at the head of the priority queue for the partition being processed is accessed. Since event elements in the priority queue for the partition are always sorted based upon the expiration times associated with the events, with events having earlier expiration times being closer to the head of the queue and events having later expiration times being towards the tail of the queue, the event at the head of the queue represents an event in that partition window with the earliest expiration time; paragraph 0164).
The Bober-Michael-Parisa-Anthony combination describes features related to machine learning and task generation. Bishnoi is directed to data processing systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for data processing. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael-Parisa-Anthony combination with Bishnoi because the references are analogous art because they are both directed to solutions for data processing, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael-Parisa-Anthony combination to include Bishnoi’s feature for including sorting the exception records according to the scores in response to expiry of a predetermined time period, in the manner claimed, would serve the motivation of providing improved techniques for processing streams of data (Bishnoi at paragraph 0025); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 12 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 4, as discussed above.
26. Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bober in view of Michael, in view of Parisa, in view of Anthony, in further view of Adams et al., Pub. No.: US 2021/0185075 A1, [hereinafter Adams].
As per claim 7, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 6. Although not explicitly taught by the Bober-Michael-Parisa-Anthony combination, Adams in the analogous art of data processing system teaches wherein determining the score for a first one of the events includes determining a ratio of a first value based on the set of attributes corresponding to the first event, and a second value based on a combination of the sets of attributes for each of the events (paragraph 0008, discussing that the computing platform may compute the initial set of rank-ordered external domains by: for each external domain of the plurality of external domains selected for the conversation detection process: 1) identifying a first number of messages sent from one or more enterprise domains to the external domain; 2) identifying a second number of messages received at the one or more enterprise domains from the external domain; 3) computing a first ratio and a second ratio, where: the first ratio is the first number divided by the second number, and the second ratio is the second number divided by the first number; 4) identifying a difference between the first ratio and the second ratio; and 5) applying a weight value to the difference based on a quantity of messages corresponding to the first number and the second number, resulting in a weighted difference value for the external domain; paragraph 0014, discussing that he computing platform may compute an initial set of rank-ordered external domains by: 1) for each external domain of the plurality of external domains selected for the conversation detection process: a) identifying a first number of messages sent from an enterprise domain of the one or more enterprise domains to the external domain; b) identifying a second number of messages received at the one or more enterprise domains from the external domain; c) computing a first ratio and a second ratio, where: the first ratio is the first number divided by the second number, and the second ratio is the second number divided by the first number; d) identifying a difference between the first ratio and the second ratio; and e) applying a weight value to the difference based on a quantity of messages corresponding to the first number and the second number, resulting in a weighted difference value for the external domain; and 2) ranking the plurality of external domains selected for the conversation detection process based on each external domain's corresponding weighted difference value; paragraph 0049, discussing that after identifying the first number of messages and the second number of messages, the message security platform may compute a first ratio of the first number of messages divided by the second number of messages and a second ratio of the second number of messages divided by the first number of messages. After computing the first ratio and the second ratio, the message security platform 110 may identify a difference between the first ratio and the second ratio, and may apply a weight value to the difference based on a quantity of messages corresponding to the first number of messages and the second number of messages, which may result in a weighted difference value for the external domain (e.g., if the first number of messages and the second number of messages exceed a predetermined threshold, the external domain may correspond to a member of the supply chain that is frequently contacted or otherwise dealt with, and thus the difference value may be weighted higher than if the first number of messages and the second number of messages do not exceed the predetermined threshold).
The Bober-Michael-Parisa-Anthony combination describes features related to machine learning and task generation. Adams is directed to data processing methods and machine learning systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for data processing. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael-Parisa-Anthony combination with Adams because the references are analogous art because they are both directed to solutions for data processing, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael-Parisa-Anthony combination to include Adam’s feature for including wherein determining the score for a first one of the events includes determining a ratio of a first value based on the set of attributes corresponding to the first event, and a second value based on a combination of the sets of attributes for each of the events, in the manner claimed, would serve the motivation of providing efficient and effective monitoring processes (Adam at paragraph 0003); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 15 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 7, as discussed above.
27. Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bober in view of Michael, in view of Parisa, in view of Anthony, in further view of Alcorn et al., Pub. No.: US 2021/0133054 A1, [hereinafter Alcorn].
As per claim 8, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Bober further teaches wherein the exception records are one-dimensional arrays (paragraph 0034, discussing that when operating, devices and/or their components may generate log data (e.g., one or more operational logs). A log may refer to a data structure that includes a representation of current and/or past operation of all or a portion of a data processing system or device. For example, log data generated by and/or collected from IoT devices may include log messages (e.g., portions of the log) that indicate activity of the IoT devices during a period of time. The log data may include descriptions of device and/or device component functionality such as (i) conditions encountered by a component (e.g., of a device), (ii) a time when the condition was encountered, (iii) an identifier associated with a condition and/or a generator of the log (e.g., the device), (iv) an indication of a relative level of importance or severity of the encountered conditions, and/or (v) other types of information).
The Bober-Michael-Parisa-Anthony combination does not explicitly teach wherein providing the exception records to the task generator includes concatenating the one-dimensional arrays in descending order of scores. However, Alcorn in the analogous art of event management systems teaches this concept. Alcorn teaches:
wherein providing the exception records to the task generator includes concatenating the one-dimensional arrays in descending order of scores (paragraph 0031, discussing that the selected subset of the data may be transferred in a time-ordered series of files or file segments in a descending order of importance. In other words, the most important files or file segments may be transferred first before proceeding to transfer the next most important files or file segments. Furthermore, data in a given log file among the plurality of log files may include data segments with different priority. Such data segments may be identified, such as with a tag or filename, so that the data segments that are included in the given log file can later be concatenated for storage on the data storage device...Some embodiments may identify the filenames of each log file on the host node that includes any data segment of the selected subset of data, wherein, for each data segment of the selected subset of data, the data segment is stored on the data storage device in a file having the same filename as the log file on the host node from which the data segment was collected; paragraph 0036, discussing that the operations may comprise receiving a request for failure event log data stored by a host node that includes the processor, wherein the host node locally stores a plurality of log files during operation of the host node. The operations may further comprise prioritizing data from the plurality of log files to be included in the failure event log data. Still further, the operations may comprise transferring, in response to receiving the request, the data in order of descending priority until the plurality of log files have been transferred or until the data can no longer be transferred. Optionally, the operation of transferring the data may include transferring the data in order of descending priority until a power outage, a network disruption, and/or storage capacity of a receiving node is depleted. The operation of receiving the request for failure event log data may include receiving the request via a web interface, a command interface, and/or a remote command interface. For example, the request may originate from various sources, such as a user operating a remote system management application, a user interfacing with a front panel of the host node, or a user operating a mobile computing device).
The Bober-Michael-Parisa-Anthony combination describes features related to machine learning and task generation. Alcorn is directed to data processing methods and machine learning systems. Therefore, they are deemed to be analogous as they both are directed towards solutions for data processing. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael-Parisa-Anthony combination with Alcorn because the references are analogous art because they are both directed to solutions for data processing, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael-Parisa-Anthony combination to include Alcorn’s feature for including wherein providing the exception records to the task generator includes concatenating the one-dimensional arrays in descending order of scores, in the manner claimed, would serve the motivation of transferring data that is useful (Alcorn at paragraph 0001); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 16 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 8, as discussed above.
28. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Bober in view of Michael, in view of Parisa, in view of Anthony, in further view of Wu et al., Patent No.: US 11,960,254 B1, [hereinafter Wu].
As per claim 17, the Bober-Michael-Parisa-Anthony combination teaches the method of claim 1. Although not taught by the Bober-Michael-Parisa-Anthony combination, Wu in the analogous art of event management systems teaches wherein the selected set of the exception records utilized for programmatic generation of the prompt are grouped based on a temporal proximity between the plurality of events (col. 2, lines 63-67 & col. 3, lines 1-3, discussing classifying anomaly events by clustering a plurality of sensor events in temporal proximity, and determining a quantitative score for each of the detected anomaly events that indicates a level of significance or importance).
The Bober-Michael-Parisa-Anthony combination describes features related to machine learning and task generation. Wu describes a system and method for anomaly detection. Therefore, they are deemed to be analogous as they both are directed towards solutions for event detection and management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Bober-Michael-Parisa-Anthony combination with Wu because the references are analogous art because they are both directed to solutions for event management, which falls within applicant’s field of endeavor (automated input processing for machine learning-based task generation), and because modifying the Bober-Michael-Parisa-Anthony combination to include Wu’s feature for including wherein the selected set of the exception records utilized for programmatic generation of the prompt are grouped based on a temporal proximity between the plurality of events, in the manner claimed, would serve the motivation of rendering eventual anomaly detection more reliable, and providing effective quantitative evaluation to enable maintenance and repair personnel to be effectively deployed (Wu, col. 3, lines 13-17); and further obvious because the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lawler et al., Pub. No.: US 2025/0028626 A1 – describes an AI system that may tune a prompt to help ensure a valid solution is returned and may further validate the response prior to providing the solution to the user.
Carre et al., Patent No.: US 12,518,740 B1 – describes that a prompt may be input into an LLM that may generate action plan data comprising multiple API calls.
Bonageri et al., Pub. No.: US 2025/0087372 A1 – describes an AI-system that generates natural language processing (NLP) models that detect an event likely to have occurred among entities in the source data of the source documents.
Travalini et al., Pub. No.: US 2023/0376847 A1 – describes that the intelligent routing and assignment engine may transmit the work order to the technicians selected by the regression model. Technicians may receive the work order using a computing device with an I/O interface.
Dell’Amico et al., Patent No.: US 10,574,700 B1 – describes that each set within sets of events may be grouped by temporal proximity for client computing devices within a local network or organization.
Bradley et al., Pub. No.: US 2024/0378391 A1 – describes that problem management is drawn to identifying and addressing the root causes of recurring incidents or issues. It helps teams identify underlying problems that lead to multiple incidents, analyze their impact, and initiate appropriate actions for resolution. The problem management application provides tools for problem identification, investigation, prioritization, and tracking.
Sivaraman, Hariprasad. "INTELLIGENT AUTOMATION FOR SERVICE DEGRADATION PREDICTION USING LLMS AND OBSERVABILITY DATA." International Journal of Engineering Management 6.10.5281 (2021) –describes an observable framework that uses Large Language Models (LLMs) to predict service degradation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARLENE GARCIA-GUERRA whose telephone number is (571) 270-3339. The examiner can normally be reached M-F 7:30a.m.-5:00p.m. EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian M. Epstein can be reached on (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.
/Darlene Garcia-Guerra/
Primary Examiner, Art Unit 3625
Prosecution Insights