DETAILED ACTION
This action is in response to an amendment filed on October 2, 2025 for the application of Kumar et al., for a “Metrics, events, alert extractions from system logs” filed on August 14, 2023. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in the application.
Claims 1-9, 12-15, and 20 have been amended.
Claims 1-20 are rejected under 35 USC § 101.
Claims 1, 4-8, 11-15, and 18-20 are rejected under 35 USC § 103.
Claims 2-3, 9-10, and 16-17 are objected to while containing allowable matter.
Claim Rejections - 35 USC § 112
In view of the applicant’s amendments, the previous rejections have been withdrawn.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) mental processes-concepts performed in human mind.
Claim 1 recites abstract ideas:
generate contextual meta tags associated with the data blocks, wherein each contextual meta tag corresponds to an event detected at a corresponding network-connected device corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses labeling data ([0018]).
execute at least one machine learning model configured based at least in part on entity-specific parameters received from a meta store to identify one or more entities for a given network-connected device amount to mere instructions to implement a mental process (i.e., a human mind can analyze data and perform data pattern matching/recognizing) on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f))).
create a taxonomy for a given entity of the one or more entities, the taxonomy comprising a plurality of categories each indicative of at least one contextual meta tag corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses organizing data into a plurality of categories based on the meta tag labels ([0019]).
Claim 1 does not recite additional limitations that integrate the judicial exceptions into practical application.
A system comprising: a processing unit configured to amounts to mere instructions to implement the abstract ideas on a computer, which is mere instructions to apply an exception. See MPEP 2106.05(f).
entity-specific parameters received from a meta store amounts to mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity. These limitation amount to receiving or transmitting data over a network and are well-understood, routine, conventional activity (MPEP 2106.05(d)).
generate output data for presenting one or more dashboards on a user device based at least in part on the taxonomy and a user request amount to mere data output, which is insignificant extra-solution activity (MPEP 2106.05(g).
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exceptions because the additional elements amount to generally linking the use of a judicial exception to a particular technological environment or field of use, insignificant extra-solution activity and mere instructions to apply an exception. See MPEP 2106.05(f), MPEP 2106.05(g), and MPEP 2106.05(h).
As for the limitations recited in claims 2-7, when considering each of the claims as a whole these additional elements do not integrate the exception into a practical application, using one or more of the considerations laid out by the Supreme Court and the Federal Circuit. The additional elements do not reflect an improvement in the functioning of a computer, or an improvement to other technology or technical field. The additional elements do not implement a judicial exception with, or use a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim. The additional element do not apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
As per claims 8 and 15, please refer to the analysis section of claim 1.
As per claims 9-14 and 16-20 please refer to the analysis section of claims 2-7.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-8, 11-15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Haggie et al. (U.S. PGPUB 20180089287) in view of Hassan et al. (U.S. PGPUB 20210117838).
As per claims 1 and 8, Haggie discloses a system/method comprising:
a processing unit ([0107]) configured to:
receiving, by an operations management system (OMS) ([0081], “data intake and query system 12”) via a network interface ([0233], “network interface 192”), a plurality of data blocks indicative of log data generated by a plurality of network-connected devices during operation ([0081], “computing resources that can generate data (e.g., log data)”);
generating, by the OMS, first data indicative of one or more contextual meta tags ([0406]-[0407]) extracted from one or more data blocks corresponding to a given network-connected device, wherein each contextual meta tag at least in part corresponds to an event detected at the given network-connected device (Fig. 5 and [0135]-[0137]);
executing, by the OMS on the first data correlated with the one or more data blocks, at least one machine learning model to identify one or more entities for the given network-connected device ([0251]-[0258] and [0290]);
creating, by the OMS for a given entity, a taxonomy comprising a plurality of categories, wherein each category is indicative of at least one contextual meta tag ([0369]-[0377]); and
generating, by the OMS, based at least in part on the taxonomy, output data to present one or more dashboards as a graphical user interface ([0418], “user dashboard”) of a user device (Figs. 29-31), responsive to one or more user requests received in plain text form from the user device ([0370], “The user inputs may include queries submitted by a user as text input in a search field or by selecting controls or options displayed on metrics-aware UI 258.”), each request soliciting real-time operational performance of the given network-connected device ([0412], “a user can adjust the predetermined time period, for example, to increase/decrease a historical time period and/or view a metric in real-time.”).
Haggie discloses using machine learning methods ([0290]). However, Haggie fails to explicitly disclose machine learning model configured based at least in part on entity-specific parameters.
Hassan of analogous art teaches:
executing, by the OMS on the first data correlated with the one or more data blocks, at least one machine learning model configured based at least in part on entity-specific parameters received from a meta store ([0031], “Log 115”) to identify one or more entities ([0045], “a machine learning model is used to extract an exception entity... named entity recognition (NER) is a natural language processing (NLP) technique used to identify entities from text and classify them into the defined categories.”) and (Fig. 1).
All of the claimed elements were known in Haggie and Hassan and could have been combined by known methods with no change in their respective functions. It therefore would have been obvious to a person of ordinary skill in the art before the time of effective filing language to combine their methods. One would be motivated to make this combination since Hassan’s NER model is a mere example of Haggie’s machine learning model.
As per claims 4, 11, and 18, Haggie discloses receive entity-specific parameters from a meta store associated with the given network-connected device; and configure the at least one machine learning model to identify the given entity associated with the given network-connected device ([0251]-[0258] and [0290]). Hassan discloses configure the at least one machine learning model based at least in part on the entity-specific parameters to identify the given entity associated with the given network-connected device ([0045], “a machine learning model is used to extract an exception entity... named entity recognition (NER) is a natural language processing (NLP) technique used to identify entities from text and classify them into the defined categories.”).
As per claims 5 and 12, Hassan discloses at least one machine learning model at least comprises a Named Entity Recognition (NER) model configured to identify mentions of the given entity ([0045], “a machine learning model is used to extract an exception entity... named entity recognition (NER) is a natural language processing (NLP) technique used to identify entities from text and classify them into the defined categories.”) in the log data ([0031], “Log 115”).
As per claims 6, 13, and 20, Haggie discloses the processing unit is further configured to: generate data for presenting the one or more dashboards based at least in part on a priority level of each category of the plurality of categories ([0210], “which is indicated in the incident review dashboard. The urgency value for a detected event can be determined based on the severity of the event and the priority of the system component associated with the event.”) and ([0458], “FIG. 50 illustrates the user dashboard 378 having a metric sorted by application. In some embodiment, sorting the metric by application (or other dimension) allows a user to quickly understand whether the anomaly is consistent across an entire platform (e.g., across all servers) or is an instance specific problem.”).
As per claims 7 and 14, Haggie discloses the processing unit is further configured to: responsive to presentation of the one or more dashboards, receive, from the user device, one or more modifications to a given contextual meta tag ([0395], “metadata is user specified and can indicate conditions causing the metrics catalog to automatically retrieve metrics data from the metrics store”) and regenerate the data for presenting the one or more dashboards at least in part based on the one or more modifications ([0472]-[0473]) and ([0478], “Additional metrics can be added to the user dashboard 378 by the user to further refine and/or analyze performance trends. In some embodiments, a user can generate a new dashboard 378 based on an investigation and/or modification of an existing technology selection.”).
As per claim 15, refer to the analysis section of claim 8. Haggie further discloses access a storage device to retrieve log data received ([0213]), via a network interface ([0233], “a network interface 192”), from one or more remote data sources associated with a plurality of computing devices ([0266] and [0294]);
generate first data indicative of data patterns identified in the log data ([0210], “To facilitate identifying patterns among the notable events, each notable event can be associated with an urgency value (e.g., low, medium, high, critical), which is indicated in the incident review dashboard”).
As per claim 19, Haggie discloses the operations management unit is further configured to: correlate at least one data pattern indicated by the first data with an event detected at the given computing device to generate third data ([0151] and [0210]) and create the taxonomy at least in part based on the third data ([0369]-[0377]).
Allowable Subject Matter
Claims 2-3, 9-10, and 16-17 are objected to as being dependent upon a rejected base claim. Claims 2-3, 9-10, and 16-17 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 101 as set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s amendments filed on October 2, 2025 necessitated a new ground(s) of rejection in this Office action. Accordingly, applicant’s arguments regarding claims 1, 8, and 15 have been fully considered but are moot in view of the new ground(s) of 35 U.S.C. 101/103 rejections, as set forth in this office action.
35 U.S.C. 101 rejections
With respect to the 35 USC § 101 rejections, applicant's arguments, see pages 9-11, filed on October 2, 2025 have been fully considered but they are not persuasive.
On pages 9-10, applicant argues:
“Regarding Step 2A - Prong One
As amended, claim 1 as a whole recites concrete, computer-implemented operations that are not mental steps, including the features:
“receive, via a network interface ... log data generated by a plurality of network- connected devices;”
“execute at least one machine learning model configured using entity-specific
parameters received from a meta store to identify one or more entities;”
“create a taxonomy for a given entity ... categories each indicative of at least one
contextual meta tag;” and
“generate data for presenting one or more dashboards on a user device based at least in part on the taxonomy and a user request.”
These limitations, taken together, do not “recite” a mental process: they require network I/O, ML model execution that is configured via parameters “received from a meta store,” construction of an entity-specific taxonomy tied to contextual meta tags, and rendering dashboard data based on that taxonomy. The OA identifies no portion of the record showing that these specific operations are performable “in the human mind” as recited.
Accordingly, for at least the above reasons claim 1 does not recites a judicial exception.”
The Examiner respectfully disagrees and would like to point out that Claim 1 recites the following abstract ideas:
generate contextual meta tags associated with the data blocks, wherein each contextual meta tag corresponds to an event detected at a corresponding network-connected device corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses labeling data ([0018]).
execute at least one machine learning model configured based at least in part on entity-specific parameters received from a meta store to identify one or more entities for a given network-connected device amount to mere instructions to implement a mental process (i.e., a human mind can analyze data and perform data pattern matching/recognizing) on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f))).
create a taxonomy for a given entity of the one or more entities, the taxonomy comprising a plurality of categories each indicative of at least one contextual meta tag corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses organizing data into a plurality of categories based on the meta tag labels ([0019]).
On pages 10-11, applicant argues:
“Regarding Step 2A -Prong Two
Even assuming arguendo that some portion of the claim could be characterized as an “abstract idea,” the claim is integrated into a practical application. The claim recites executing “at least one machine learning model configured using entity-specific parameters received from a meta store” (claim 1). The Office Action does not identify any evidence in the record that such meta-store parameterization is a mere field-of-use limitation or insignificant extra-solution activity. This is a specific configuration step in which machine behavior is altered using parameters received from a defined source (a meta store).
Further, the claim requires creating “a taxonomy for a given entity ... categories each indicative of at least one contextual meta tag,” and then generating dashboard data “based at least in part on the taxonomy.” This is a specific structural organization of data (e.g., entity to taxonomy to categories indicative of contextual meta tags) that drives the output. Consequently, it is not a result-only statement.
Accordingly, the claim integrates any alleged abstract idea into a specific practical application (meta-store-configured ML for entity identification; entity-specific taxonomy tied to contextual meta tags; dashboards generated based on that taxonomy).”
The Examiner respectfully disagrees and would like to point out that “execute at least one machine learning model configured based at least in part on entity-specific parameters received from a meta store to identify one or more entities for a given network-connected device” amount to mere instructions to implement a mental process (i.e., a human mind can analyze data and perform data pattern matching/recognizing) on a computer, or merely uses a computer as a tool to perform an abstract idea (MPEP 2106.05(f))).
“entity-specific parameters received from a meta store” amounts to mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity (MPEP 2106.05(g).
“create a taxonomy for a given entity of the one or more entities, the taxonomy comprising a plurality of categories each indicative of at least one contextual meta tag” corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses organizing data into a plurality of categories based on the meta tag labels ([0019]).
On page 11, applicant argues:
“Regarding Step 2B
In the Office Action, it is suggested that the claim “can be performed by a human mind or with the aid of pen and paper” and is applied on “generic computer components,” but does not cite record evidence that the specific recited limitations are “well-understood, routine, conventional” However, there is no evidence cited that it was WURC to:
(1) configure a machine learning model using entity-specific parameters received
from a meta store to identify one or more entities for a given network-connected device; and
(2) create an entity-specific taxonomy with categories each indicative of at least
one contextual meta tag and generate dashboard data “based at least in part
on the taxonomy.”
The Examiner respectfully disagrees and would like to point out that “entity-specific parameters received from a meta store” amounts to mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity. These limitation amount to receiving or transmitting data over a network and are well-understood, routine, conventional activity (MPEP 2106.05(d)). “Storing and retrieving information in memory” is well-understood, routine, conventional function when it is claimed in a merely generic manner (i.e., a meta store) (MPEP 2106.05(d)(II)) and Berkheimer).
create a taxonomy for a given entity of the one or more entities, the taxonomy comprising a plurality of categories each indicative of at least one contextual meta tag corresponds to data organization steps recited at high level generality such that they could be performed in the human/with the aid of pen/paper. The broadest reasonable interpretation of the limitation in light of the specification encompasses organizing data into a plurality of categories based on the meta tag labels ([0019]). Organizing/dividing data into categories based on data labels is well-understood, routine, conventional function (see Berkheimer).
generate output data for presenting one or more dashboards on a user device based at least in part on the taxonomy amount to mere data output, which is insignificant extra-solution activity (MPEP 2106.05(g). Please refer to the 35 USC § 101 rejection section for further details/analysis.
35 U.S.C. 102/103 rejections
Applicant’s amendments filed on October 2, 2025 necessitated a new ground(s) of rejection in this Office action. Accordingly, applicant’s arguments regarding claims 1, 8, and 15 have been fully considered but are moot in view of the new ground(s) of 35 U.S.C. 103 rejections.
Applicant’s arguments with respect to the rejection(s) of dependent claim(s) 2-3, 9-10, and 16-17 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
Applicant's arguments with respect to the rejection(s) of dependent claim(s) 6-7 have been fully considered but they are not persuasive.
As per claim 6 applicant argues that Haggie fails to teach the claimed limitation of generating data based at least in part on a priority level of each category of the plurality of categories.
The Examiner respectfully disagrees and would like to point out to paragraphs [0210], [0252], and [0256], wherein Haggie discloses specifying severity/priority levels to be displayed to user.
Further note paragraph [0458], wherein Haggie discloses:
“FIG. 50 illustrates the user dashboard 378 having a metric sorted by application. In some embodiment, sorting the metric by application (or other dimension) allows a user to quickly understand whether the anomaly is consistent across an entire platform (e.g., across all servers) or is an instance specific problem.”
Specifying severity/priority levels and sorting metrics to present to a user as disclosed by Haggie reads on the above limitation as recited in claim 6.
As per claim 7 applicant argues that Haggie fails to teach the claimed limitation of meta-tag modification and regeneration of dashboard data.
The Examiner respectfully disagrees and would like to point out to paragraph [0395], wherein Haggie discloses:
“metadata is user specified and can indicate conditions causing the metrics catalog to automatically retrieve metrics data from the metrics store”
Further note paragraphs [0472]-[0473] and [0478], wherein Haggie discloses:
“Additional metrics can be added to the user dashboard 378 by the user to further refine and/or analyze performance trends. In some embodiments, a user can generate a new dashboard 378 based on an investigation and/or modification of an existing technology selection.”.
Modifying metadata of the metrics catalog and generating new dashboards based on user modifications as disclosed by Haggie reads on the above limitation as recited in claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Elmira Mehrmanesh whose telephone number is (571)272-5531. The examiner can normally be reached on M-F from 10-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bryce Bonzo, can be reached at telephone number (571) 272-3655. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Elmira Mehrmanesh/
Primary Examiner, Art Unit 2113