DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to amendments filed February 11th, 2026, in which claims 1, 2, 14, 15 and 20 have been amended. No claims have been cancelled nor added. The amendments have been entered, and claims 1-20 are currently pending in the case. Claims 1 and 14 are independent claims.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-6, 10-12, 14-15, 17-18 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Patti et al. (US Patent No. 12271287).
As to claim 1, Patti et al. discloses a computer program product comprising a non-volatile computer readable medium and non-transitory program instructions embodied therein, the program instructions being configured to be executable by a processor to cause the processor to perform operations comprising:
receiving a particular event code from a monitored device, wherein the particular event code represents an event that occurred on the monitored device (col. 18, lines 51-65);
accessing a metadata file including a plurality of records, each record including an event code and a device parameter associated with the event code (col. 3, lines 41-52);
identifying, using the metadata file, the device parameter that is associated with the particular event code (col. 3, lines 41-52);
sending a knowledge base query to a server hosting a knowledge base, wherein the knowledge base query includes the particular event code received from the monitored device and a value of the device parameter that is specific to the monitored device (col. 9, lines 40-54), wherein the value of the device parameter for the monitored device enables the knowledge base to refine a determination of a service action to be included in a response to the knowledge base query (col. 11, lines 53-60, wherein “enables” reads on “feedback”); and
receiving the response from the server hosting the knowledge base, wherein the response identifies a service action to implement on the monitored device to remediate the event that occurred on the monitored device (Figure 6).
As to claim 2, Patti et al. discloses The computer program product of claim 1, wherein the metadata file includes a record for each event code that the knowledge base associates with more than one service action depending upon the value of the device parameter (col. 9, lines 40-54).
As to claim 3, Patti et al. discloses The computer program product of claim 1, wherein the value for the device parameter that is specific to the monitored device is automatically sent to the server in the knowledge base query (col. 7, lines 48-60).
As to claim 4, Patti et al. discloses The computer program product of claim 1, the operations further comprising:
receiving an update to the metadata file from the server (col. 3, lines 41-52, wherein it is inherent that any data including metadata is updated upon interaction).
As to claim 5, Patti et al. discloses The computer program product of claim 1, wherein the device parameter is an operating system version installed on the monitored device, a firmware version installed on the monitored device, and/or a model number of the monitored device (col. 25, lines 31-32).
As to claim 6, Patti et al. discloses The computer program product of claim 5, wherein the knowledge base uses the value of the device parameter that is specific to the monitored device and the particular event code to identify the service action (col. 33, lines 9-60).
As to claim 10, Patti et al. discloses The computer program product of claim 1, the operations further comprising:
receiving an event notification from the monitored device, wherein the event notification includes the event code (col. 33, lines 9-60);
displaying the event notification on a user interface (col. 33, lines 9-60); and
requesting the log data from the monitored device in response to user input requesting to investigate and/or remediate the event identified by the event notification (col. 33, lines 9-60).
As to claim 11, Patti et al. discloses The computer program product of claim 1, wherein the value of the device parameter associated with the particular event code is provided in a token, and wherein the token is sent to the knowledge base (col. 33, lines 9-60).
As to claim 12, Patti et al. discloses The computer program product of claim 1, the operations further comprising:
automatically causing the identified service action to be implemented on the monitored device (col. 33, lines 9-60).
As to claim 13, Patti et al. discloses The computer program product of claim 1, the operations further comprising:
prompting a user to physically implement the identified service action on the monitored device (col. 33, lines 9-60).
As to claim 14, Patti et al. discloses A computer program product comprising a non-volatile computer readable medium and non-transitory program instructions embodied therein, the program instructions being configured to be executable by a processor to cause the processor to perform operations comprising:
receiving a knowledge base query from a system management node, wherein the knowledge base query includes a particular event code that represents an event that occurred on a device monitored by the system management node (col. 18, lines 51-65);
accessing a metadata file including a plurality of records, each record including an event code and a device parameter associated with the event code (col. 3, lines 41-52);
identifying, using the metadata file, the device parameter that is associated with the particular event code (col. 3, lines 41-52);
sending a request to the system management node for a value of the identified device parameter that is specific to the monitored device (col. 7, lines 48-60);
receiving the value of the identified device parameter that is specific to the monitored device from the system management node (col. 9, lines 40-54);
identifying, using the knowledge base, a recommended service action associated with the particular event code and the received value of the identified device parameter (col. 11, lines 53-60, wherein “enables” reads on “feedback”); and
sending a response to the system management node, wherein the response identifies a recommended service action to remediate the event that occurred on the monitored device (Figure 6).
As to claim 15, Patti et al. discloses The computer program product of claim 14, wherein the metadata file is stored on a server hosting the knowledge base (col. 3, lines 41-52, wherein it is inherent that files are stored in a server).
As to claim 17, Patti et al. discloses The computer program product of claim 14, wherein the metadata file is automatically generated by identifying, for each event code in the knowledge base, the device parameter that is used to advance along a decision tree of the knowledge base to reach a service action that is more specific to the monitored device where the event occurred (col. 7, lines 48-60, wherein refining the system or selection suggests a decision tree, also noted “used to advance along” is non-functional descriptive material and does not carry patentable weight).
As to claim 18, Patti et al. discloses The computer program product of claim 17, wherein the knowledge base includes a plurality of records, wherein each record identifies an event code and one or more service actions associated with the event code, and wherein at least one of the records of the knowledge base identifies multiple service actions associated with the event code, wherein each of the multiple service actions is uniquely associated with a different value of the device parameter (col. 6, lines 3-35).
As to claim 20, Patti et al. discloses The computer program product of claim 14, wherein the device parameter is an operating system version installed on the monitored device, a firmware version installed on the monitored device and/or a model number of the monitored device (col. 25, lines 31-32).
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 7-9, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Patti et al. US Patent No. 12271287 in view of Kolluri Venkata Sesha et al. (US Patent No. 10650424).
As to claim 7, Patti et al. discloses the use of user interface displaying detected event, and selection of remedy action including the ability for the selection to be done by hyperlink (col. 12, lines 1-17, and it is well understood in the art that user interface display can easily by customizable). It is not specific to: The computer program product of claim 1, the operations further comprising:
displaying the event code in a user interface;
displaying a hyperlink to the knowledge base in the user interface adjacent to the event code, wherein the knowledge base query is sent to the server hosting the knowledge base in response to user selection of the hyperlink.
Kolluri Venkata Sesha et al. discloses:
displaying the event code in a user interface;
displaying a hyperlink to the knowledge base in the user interface adjacent to the event code, wherein the knowledge base query is sent to the server hosting the knowledge base in response to user selection of the hyperlink (col. 6, lines 25-47, Figure 6).
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 teaching of the cited references and modify the combined Patti et al.’s user interface include Kolluri Venkata Sesha et al.’s ability to present hyperlink with recommended remedy action because it allows for faster and more immediate ability to take action.
As to claim 8, Patti et al. as modified discloses. The computer program product of claim 7, the operations further comprising:
receiving user input selecting the hyperlink to the knowledge base, wherein the knowledge base query is sent to the server in response to receiving the user input selecting the hyperlink (col. 5, Lines 45-58).
As to claim 9, Patti et al. as modified discloses The computer program product of claim 7, the operations further comprising:
receiving and storing a plurality of links to the knowledge base, wherein each of the links is associated with one of the event codes and links to one or more service action associated with the event code, where the hyperlink displayed in the user interface adjacent to the event code is obtained from the stored plurality of links (Kolluri Venkata Sesha et al. Figure 6).
As to claim 16, Patti et al. discloses the use of user interface displaying detected event, and selection of remedy action including the ability for the selection to be done by hyperlink (col. 12, lines 1-17, and it is well understood in the art that user interface display can easily by customizable). It is not specific to:
The computer program product of claim 14, wherein the request sent to the system management node includes a query result page with a link that, in response to user selection of the link, will cause the system management node to send the value of the device parameter that is specific to the monitored device in a response to the request.
Kolluri Venkata Sesha et al. teaches:
wherein the request sent to the system management node includes a query result page with a link that, in response to user selection of the link, will cause the system management node to send the value of the device parameter that is specific to the monitored device in a response to the request (Figure 6).
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 teaching of the cited references and modify the combined Patti et al.’s user interface include Kolluri Venkata Sesha et al.’s ability to present hyperlink with recommended remedy action because it allows for faster and more immediate ability to take action.
As to claim 19, Patti et al. discloses the use of user interface displaying detected event, and selection of remedy action including the ability for the selection to be done by hyperlink (col. 12, lines 1-17, and it is well understood in the art that user interface display can easily by customizable). It is not specific to:
The computer program product of claim 14, wherein the log data from the monitored device has a deterministic filesystem structure, wherein the server hosting the knowledge base embeds a link into HTML output in the response from the knowledge base, and wherein the embedded link will pull data from the log data set to populate a dynamic field in the response.
Kolluri Venkata Sesha et al. discloses:
The computer program product of claim 14, wherein the log data from the monitored device has a deterministic filesystem structure, wherein the server hosting the knowledge base embeds a link into HTML output in the response from the knowledge base, and wherein the embedded link will pull data from the log data set to populate a dynamic field in the response (Figure 6).
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 teaching of the cited references and modify the combined Patti et al.’s user interface include Kolluri Venkata Sesha et al.’s ability to present hyperlink with recommended remedy action because it allows for faster and more immediate ability to take action.
Response to Arguments
Applicant's arguments filed February 11th, 2026 (hereinafter “Remarks”) have been fully considered but they are not persuasive.
Rejections under 35 U.S.C. § 102:
Regarding claim 1:
Argument 1:
“The rejection of claim 1 asserts that Patti et al. discloses "receiving a particular event code from a monitored device, wherein the particular event code represents an event that occurred on the monitored device (col. 18, lines 51-65)." (Office Action dated Nov. 13, 2025; page 3, lines 1-2). However, the cited portion of Patti actually states that "[t]he system detects, by the monitoring devices and/or applications, an event associated with a monitored system (Operation 502)." (Patti, col. 18, lines 52-55). The Applicant asserts that Patti's disclosure of a monitoring device detecting an event does not disclose any use of an "event code" that represents an event and does not disclose the monitoring device "receiving a particular event code from a monitored device."” (Remarks, page 8).
Examiners Response:
Examiner respectfully disagrees, the MPEP states “Because applicant has the opportunity to amend the claims during prosecution, giving a claim its broadest reasonable interpretation will reduce the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984); In re Zletz, 893 F.2d 319, 321, 13 USPQ2d 1320, 1322 (Fed. Cir. 1989) ("During patent examination the pending claims must be interpreted as broadly as their terms reasonably allow.");” See MPEP § 2111. The entire cited portion states “A system may include one or more monitoring devices and monitoring applications. The system detects, by the monitoring devices and/or applications, an event associated with a target component in the monitored system (Operation 302). For example, the system may identify values or events in an event log associated with a component being monitored by a monitoring application. The event log may identify: sensor values, data throughput values, data storage values, application states, and access events, such as identifying requests from entities to access applications or devices.” The broadest reasonable interpretation of “event codes”, in light of the specification, includes application states (such as “OK,” and “not responding”). Specification, ¶16 “The event codes may represent events of any severity (i.e., critical events, warning events and/or informational events) and from any source (i.e., hardware events, management events, serviceable events, customer serviceable events, and/or non-serviceable events).” Here, the application states can be considered the event codes.
Argument 2:
“Patti et al. does not disclose "accessing a metadata file including a plurality of records,
each record including an event code and a device parameter associated with the event code"
and/or "identifying, using the metadata file, the device parameter that is associated with the particular event code"…The cited paragraph provides no evidence that the collected metadata is ever stored in a manner that forms "a metadata file including a plurality of records, each record including an event code and a device parameter associated with the event code." (Applicant's claim 1). Rather, Patti's metadata associated with an event is collected in response to a user selecting the event and the metadata is then used to present a runbook in the runbook selection interface.” (Remarks, page 9-10).
Examiners Response:
Examiner respectfully disagrees, the cited portion of Patti et al. states “One or more embodiments present a runbook selection interface that allows a user to select an event. The system collects metadata associated with the selected event. The metadata may include event data, such as a time of the event, a device on which the event occurred, programs running when the event occurred, and users affected by the event. The metadata may also include topology data, including the topological relationships of system components in the system in which the event occurred. The system presents a runbook in the runbook selection interface to execute to remediate the selected event based on topology attributes and event attributes.” (Pattie et al., col 3, lines 41-52). Here, the metadata is inherently a plurality of records, further the broadest reasonable interpretation of the device parameter included in the metadata includes “a device on which the event occurred” in the metadata.
Argument 3:
“…Patti discloses that "[t]he system collects metadata associated with the selected event" (Patti, col. 3, lines 41-43; emphasis added), where "[t]he metadata may include event data, such as a time of the event, a device on which the event occurred, programs running when the event occurred, and users affected by the event" and "[t]he metadata may also include topology data, including the topological relationships of system components in the system in which the event occurred." (Patti, col. 3, lines 43-49; emphasis added). The Applicant asserts that this "event data" does not disclose the claimed "device parameter". Specifically, Patti's collected metadata includes DATA surrounding the selected EVENT. DATA includes raw inputs or sample measurements that are obtained from a monitored device at the time that the particular EVENT occurs. This does not disclose the Applicant's claimed "accessing a metadata file including a plurality of records, each record including an event code and a device parameter associated with the event code." An event code represents a type of event rather than a specific occurrence of the event and a device parameter represents a variable of interest rather than a specific value measured from a monitored device. Furthermore, Patti's metadata is specific to a particular event and does not disclose the claimed metadata file includes a plurality of records, where each record includes an event code and device parameter associated with the event code.” (Remarks, page 10).
Examiners Response:
Examiner respectfully disagrees, the broadest reasonable interpretation of the claim includes “a device on which the event occurred” within the metadata being considered a device parameter. Further, applicant asserts “An event code represents a type of event rather than a specific occurrence of the event and a device parameter represents a variable of interest rather than a specific value measured from a monitored device.” However, it is noted that the features upon which applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Argument 4:
“Patti does not disclose "sending a knowledge base query to a server hosting a knowledge base, wherein the knowledge base query includes the particular event code received from the
monitored device and a value of the device parameter that is specific to the monitored device”…Patti discloses that "the system may recommend a runbook for execution" (Patti, col. 9, lines 39-42), for example "the runbook selection engine 124 may identify attributes associated with a detected event", "identify a similarity between the attributes of the detected event and attributes of one or more historical system events 135", "identify runbooks applied to the historical system events 135", "select one or more of the runbooks based on a similarity of the attributes of the historical system events 135 and the presently-detected event." (Patti, col. 9, lines 40-54; emphasis added). The Applicant asserts that none of these steps of the runbook selection engine 124 disclose "sending a knowledge base query to a server hosting a knowledge base." Similarly, Patti does not disclose "receiving the response from the server hosting the knowledge base" as set out in a later limitation of claim 1.” (Remarks, page 11).
Examiners Response:
Examiner respectfully disagrees, the cited portion of Patti et al. states “According to another example, the system may recommend a runbook for execution based on a similarity between a detected event and one or more historical system events 135. For example, the runbook selection engine 124 may identify attributes associated with a detected event. Attributes may include, for example, log values, sensor values, and topology characteristics. The runbook selection engine 124 may identify a similarity between the attributes of the detected event and attributes of one or more historical system events 135. The runbook selection engine 124 may identify runbooks applied to the historical system events 135. The runbook selection engine 124 may select one or more of the runbooks applied to the historical system events 135 to apply to the presently-detected event based on a similarity between the attributes of the historical system events 135 and the presently-detected event.” Patti et al., when considered in its entirety, further discloses “Alternatively, or additionally, a data repository 130 may be implemented or executed on a computing system separate from the event remediation platform 120. A data repository 130 may be communicatively coupled to the event remediation platform 120 via a direct connection or via a network. Information describing a system topology 131, system data 132, runbooks 133, historical system topologies 134, and historical system events 135 may be implemented across any of components within the system 100.” (Patti et al., col 7, lines 1-10) as well as “FIG. 6 illustrates a monitored system 601 that is monitored by an event remediation platform 610. The monitored system 601 includes nodes 602-506 and a database 607. User terminals 608 and 609 access the nodes 602-606 and the database 607 via a network.” (Patti et al., col 30, lines 17-20). Here, the recommendation of runbooks for a certain event to a server can be considered sending a knowledge base query to a server hosting a knowledge base. Further, the “receiving the response from the server hosting the knowledge base" as set out in a later limitation of claim 1 had been mapped to figure 6, which likewise discloses a server (monitored system) and device (user terminal) system in which responses are sent and received.
Argument 5:
“The Applicant asserts that Patti's "user feedback" does not disclose "the value of the device parameter for the monitored device" as expressly set out in this claim limitation. Furthermore, Patti expressly states that the "user feedback" is used to "update runbook ratings", wherein the updated runbook ratings affect whether or not a particular runbook will be recommended "the next time the save event occurs." (Patti, col. 4, lines 63-67). Accordingly, Patti's "user feedback" does not enable the runbook selection engine "to refine a determination of a service action to be included in a response" to the knowledge base query.” (Remarks, page 12).
Examiners Response:
Examiner respectfully disagrees, the cited portion of Patti et al. states “According to another example, the system may recommend a runbook for execution based on a similarity between a detected event and one or more historical system events 135. For example, the runbook selection engine 124 may identify attributes associated with a detected event. Attributes may include, for example, log values, sensor values, and topology characteristics. The runbook selection engine 124 may identify a similarity between the attributes of the detected event and attributes of one or more historical system events 135. The runbook selection engine 124 may identify runbooks applied to the historical system events 135. The runbook selection engine 124 may select one or more of the runbooks applied to the historical system events 135 to apply to the presently-detected event based on a similarity between the attributes of the historical system events 135 and the presently-detected event.” Further, Pattie et al. discloses “One or more embodiments present a runbook selection interface that allows a user to select an event. The system collects metadata associated with the selected event. The metadata may include event data, such as a time of the event, a device on which the event occurred, programs running when the event occurred, and users affected by the event. The metadata may also include topology data, including the topological relationships of system components in the system in which the event occurred. The system presents a runbook in the runbook selection interface to execute to remediate the selected event based on topology attributes and event attributes.” (Pattie et al., col 3, lines 41-52). The broadest reasonable interpretation of “the value of the device parameter for the monitored device” includes log values such as “a device on which the event occurred”. Further, Patti et al. discloses that they system may update the runbook ratings, not that it is an express requirement. “The system may update runbook ratings based on the user feedback.” (Patti et al., col 4, lines 63-64).
Regarding claim 2:
Argument 6:
“…Applicant reasserts that Patti does not disclose the use of event codes. Rather, Patti discloses a system that detects events. (Patti, FIG. 2, step 202 "detect event"). There is no evidence that Patti identifies a detected event by an event code…Applicant reasserts that Patti's metadata is collected from the monitored device in response to detecting an event on the monitored device. (Patti, Abstract, lines 2-4). Furthermore, Patti's disclosed metadata only contains the event data and/or topology data for a monitored device in which the event occurred (Patti, col. 3, lines 41-52), rather than disclosing a "metadata file" that "includes a record for each event code that the knowledge base associates with more than one service action depending upon the value of the device parameter." (Applicant's claim 2). While Patti's historical system events presumably includes multiple events, Patti's disclosed metadata is for a single detected event. (Patti, col. 9, lines 39-54). Accordingly, Patti fails to disclose "wherein the metadata file includes a record for each event code that the knowledge base associates with more than one service action depending upon the value of device parameter.” (Remarks, page 13).
Examiners Response:
Examiner respectfully disagrees, Applicant's arguments regarding claim 2 rely upon the arguments asserted with respect to claim 1, and are thus unpersuasive.
Regarding claim 3:
Argument 7:
“The cited portion of Patti (i.e., Patti, col. 7, lines 48-60) disclose that "[a]n event detection engine 122 monitors the data obtained by the data collection engineer 121 to detect an event in the system 110." (Patti, col. 7, lines 49-51). Then, Patti discloses an example of how the event detection engine may detect an event and provides a list of exemplary events. (Patti, col. 7, lines 51-65). The cited portion of Patti does not disclose any "knowledge base query", anything that is "sent to the server" and/or "wherein the value for the device parameter that is specific to the monitored device is automatically sent to the server in the knowledge base query."” (Remarks, page 14).
Examiners Response:
Examiner respectfully disagrees, the broadest reasonable interpretation of a "knowledge base query" includes a query to a database “The system may generate information about the results by analyzing results that have been generated by executing operation(s) of the candidate runbook prior to a user selection of a runbook for remediating an event. Alternatively, or additionally, the system may obtain information about the results by executing a query that returns the information from a database (without obtaining the results themselves by executing the operation(s) of the candidate runbook).” (Patti et al., col 5, lines 30-37). Further, Pattie et al. discloses the value for the device parameter that is specific to the monitored device is automatically sent to the server in the knowledge base query. The cited portion includes “An event detection engine 122 monitors the data obtained by the data collection engine 121 to detect an event in the system 110. For example, the event detection system 122 may monitor activity logs generated by one or more applications running in the system 110 and sensor data generating output values based on characteristics of devices in the system 110 to detect a failure of one or more components in the system 110.” (Pattie et al., col 7, lines 48-56). Here, the characteristics of devices can be considered the device parameters, and can be considered to be automatically sent to the server in the knowledge base query as they are included in the above database query.
Regarding claim 4:
Argument 8:
“The rejection asserts that "it is inherent that any data including metadata is updated upon interaction." MPEP Section 2112(IV) says that "[i]n relying upon the theory of inherency, the examiner must provide a basis in fact and/or technical reasoning to reasonably support the determination that the allegedly inherent characteristic necessarily flows from the teachings of the applied prior art. Ex parte Levy, 17 USPQ2d 1461, 1464 (Bd. Pat. App. & Inter. 1990)." However, according to express teachings of Patti, "[t]he system collects metadata associated with the selected event." (Patti, col. 3, lines 42-43). This metadata represents the state of the monitored device at the time that the monitored devices experiences the event. The Applicant asserts that this is a snapshot of data taken at a particular point in time and there is no basis for later updating this metadata. By contrast, the Applicant's claim 4 is directed "[t]he computer program product of claim 1, the operations further comprising: receiving an update to the metadata file from the server", where claim 1 refers to "a metadata file including a plurality of records, each record including an event code and a device parameter associated with the event code." (see Applicant's claim 1). Accordingly, the metadata file may be updated, for example to include a new "event code" and/or to associated a different "device parameter" with the event code, since the claimed metadata is not a snapshot of data associated with an event.” (Remarks, page 15).
Examiners Response:
Examiner respectfully disagrees, the cited portion states “One or more embodiments present a runbook selection interface that allows a user to select an event. The system collects metadata associated with the selected event. The metadata may include event data, such as a time of the event, a device on which the event occurred, programs running when the event occurred, and users affected by the event. The metadata may also include topology data, including the topological relationships of system components in the system in which the event occurred. The system presents a runbook in the runbook selection interface to execute to remediate the selected event based on topology attributes and event attributes.” (Patti et al., col 3, lines 41-52). The broadest reasonable interpretation of receiving an update to the metadata file from the server includes the collection of metadata. Every time metadata is collected it can be considered an update to the metadata file, even if it is the first collection.
Regarding claim 5:
Argument 9:
“Applicant asserts that Patti's disclosure of "an ID of the server" does not disclose "an operating system version installed on the monitored device, a firmware version installed on the monitored device, and/or a model number of the monitored device." The Applicant asserts that a model number identifies a type of server (which may be common to many servers in a given system), whereas "an ID of the server" is a unique code specific to a single server (to distinguish that server from all other servers in the given system).” (Remarks, page 16).
Examiners Response:
Examiner respectfully disagrees, the broadest reasonable interpretation of “model number of the monitored device” includes “an ID of the server” as disclosed in Patti et al. It is noted the claim recites alternative language, and Patti et al. teaches at least one of the alternatives.
Regarding claim 10:
Argument 10:
“While Patti discloses "detecting the event" (Patt, col. 33, line 11), there is no disclosure of "receiving an event notification from the monitored device." Furthermore, while Patti discloses "a graphical user interface (GUI) for presenting one or more runbooks as recommendations for remediating an event" (Patti, col. 33, lines 26-27; see also FIGS. 8A-B event 817 and runbooks 818 and 819), Patti does not disclose "requesting the log data from the monitored device in response to user input requesting to investigate and or remediate the event identified by the event notification" as set out claim 10.” (Remarks, page 16).
Examiners Response:
Examiner respectfully disagrees, Patti et al., when considered as a whole, discloses “receiving an event notification from the monitored device”. Patti et al. discloses an event detection engine which detects an event in the system “An event detection engine 122 monitors the data obtained by the data collection engine 121 to detect an event in the system 110. For example, the event detection system 122 may monitor activity logs generated by one or more applications running in the system 110 and sensor data generating output values based on characteristics of devices in the system 110 to detect a failure of one or more components in the system 110.” (Patti et al., col 7, lines 49-56). Further, the notification can be considered to come from the monitored device as the monitored device generates the log entry “For example, a failure to log in to an application or device may be detected based on a log entry generated by the application or device.” (Patti et al., col 15, lines 44-46). Patti et al. further discloses "requesting the log data from the monitored device in response to user input requesting to investigate and or remediate the event identified by the event notification" the broadest reasonable interpretation of the limitation includes the system accessing or utilizing the log data from the system after a user requests to investigate the event. Patti et al. teaches that the user initiates user input requesting to investigate and or remediate the event “in one or more embodiments, the system presents a runbook selection interface to allow a user to select an event for which the user would like to execute a runbook. The system may execute the operations associated with steps of one or more candidate runbooks associated with an event when the user selects an interface element associated with the event in the runbook selection interface.” (Patti et al., col 6, lines 29-36). Patti et al. further discloses requesting the log data from the monitored device “For example, a candidate runbook may include a step that describes an operation to “check data transmission logs.” The system obtains a set of results by performing an analysis of the data transmission logs by comparing actual values to expected values.” (Patti et al., col 26, lines 40-44).
Regarding claim 11:
Argument 11:
“The rejection of claim 11 asserts that Patti et al. discloses "[t]he computer program product of claim 1, wherein the value of the device parameter associated with the particular event code is provided in a token, and wherein the token is sent to the knowledge base (col. 33, lines 9-60)." (Office Action dated Nov. 13, 2025; page 4, lines 18-20). The cited portion of Patti does not mention a token. In fact, a word search of the entire specification of Patti does not return any instance of the term "token."” (Remarks, page 17).
Examiners Response:
Examiner respectfully disagrees, when considered as a whole, Patti et al. discloses “[t]he computer program product of claim 1, wherein the value of the device parameter associated with the particular event code is provided in a token, and wherein the token is sent to the knowledge base.” The broadest reasonable interpretation of a token holding parameters sent to the knowledge base includes tags holding values “The tags may include a name of the event, system components associated with runbook operations, system applications associated with runbook operations, and relationships among the components.” (Patti et al., col 16, lines 61-65).
Regarding claim 12:
Argument 12:
“The cited portion of Patti is directed to how "to identify which runbooks ... to display on a runbook selection interface as a recommendation to remediate the detected event." (Patti, col. 33, lines 19-24). "FIGS. 8A and 8B illustrate a detailed example of a graphical user interface (GUI) for presenting one or more runbooks as recommendations for remediating an event." (Patti, col. 33, lines 25-27). "Based on a selection, by a user, of the user interface element associated with the event 817, the event remediation engine initiates a process to select one or more runbooks to recommend for remediating the event." (Patti, col. 33, lines 44-47). "A user may select an interface element 818 to display a set of steps for remediating the identified event." (Patti, col. 33, lines 58-60). So, the Applicant asserts that the operations disclosed by Patti at col. 33, lines 9-60 occur in response to a user selection (i.e., not automatically) and the operations terminate in displaying "a set of steps for remediating the identified event." (Patti, col. 33, lines 58-60). Patti does not disclose "automatically causing the identified service action to be implemented on the monitored device" as set out in claim 12.” (Remarks, page 18).
Examiners Response:
Examiner respectfully disagrees, when considered whole, Patti et al. discloses automatically causing the identified service action to be implemented on the monitored device. “According to one or more embodiments, the system selects one or more operations, from among the independently-executable operations of a candidate runbook, to perform based on one or both of event data associated with a detected event and topology data associated with the detected event. For example, if a detected event is assigned a name “login attempt failure,” the system may analyze event data to identify the time of the event, an ID of the server running an application on which the login attempt was made, and applications running on the server. The system may analyze the system topology to identify components in the monitored system in communication with the server running an application on which the login attempt was made. The system may identify a set of candidate runbooks associated with an event type “login attempt failure.” The system may select operations to perform in connection with one or more of the candidate runbooks based on the event data and topology data. For example, the system may perform, based on the obtained event data, an operation associated with an independently-executable operation of a candidate runbook to “check authorization level required by application.” (Patti et al., col 25, lines 24-45). According to another example, the system may perform, based on the obtained system topology data, an operation associated with an independently-executable operation of another candidate runbook to “check status of gateway in communication with server.”” Here, the broadest reasonable interpretation of the systems selection of operations from the runbooks can include automatically implementing the service actions.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thornhill et al. (US 11,080,121 B2) discloses generation, by machine logic, of runbooks for problem events. Generation of runbooks including the following operations: receiving operator commands in a command line interface for an event group relating to an issue, wherein the operator commands resolve the issue; and storing the operator commands as related artifacts of the event group with mapping to affected resources. The method may match arguments of the operator commands to event metadata fields of events in the event group to generalize the arguments to the event metadata and to generate a runbook of generalized operator commands for future instances of an event group of a similar type..
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB Z SUSSMAN MOSS whose telephone number is (571) 272-1579. The examiner can normally be reached Monday - Friday, 9 a.m. - 5 p.m. ET.
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, Kakali Chaki can be reached at (571) 272-3719. 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.
/J.S.M./Examiner, Art Unit 2122
/KAKALI CHAKI/Supervisory Patent Examiner, Art Unit 2122
Prosecution Insights