DETAILED ACTION
This Action is in response to Applicant’s amendment filed on 04/07/26.
Claims 1-5, 7-14, 16 and 18-20 have been amended.
Claims 1-20 are pending.
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 .
Response to Arguments
Argument – The applicant argues, in regards to the 103 rejection of claims 1, 14 and 20 (see applicant’s remarks; page 9) that the applied prior art references do not disclose the amended features of the claims. In particular, the applicant references the interview, held on 03/12/26, between the applicant’s attorney and the examiner.
Response to the argument - The examiner submits that the applicant’s arguments do not constitute a complete reply to the office action, and therefore do not comply with 37 CFR 1.111 (b) and (c) because they do not specifically point out how the language of the claims patentably distinguishes them from the references and do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references. Further, the arguments do not show how the amendments avoid such references.
In other words, while the arguments point to the interview, the arguments do not specifically point out the differences between the amended claim limitations and the prior art references.
Nonetheless, the examiner has introduced a new reference and a new ground(s) of rejection is provided. As seen in the rejection below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dwivedi et al. (U.S. 2022/0043807 A1) in view of Hsaio et al. (U.S. 12,028,208 B1), and further in view of Bingham et al. (U.S. 2014/0324862 A1).
Regarding claims 1, 14 and 20, Dwivedi discloses a system and method comprising one or more processors implemented in circuitry and having access to one or more non-transitory computer-readable media (see Dwivedi; paragraphs 0967 and 0968; Dwivedi discloses a processor configured to execute computer-executable instructions of a non-transitory computer-readable media), comprising instructions executable by the one or more processors to cause the system to:
based on a determination that an event associated with a network device of the plurality of network devices of a network has occurred (see Dwivedi; paragraphs 0139 and 0141; Dwivedi discloses events comprising machine data associated with a specific point in time are derived, i.e. “based on a determination…”, from devices, i.e. “an event associated with a network device of the plurality of network devices of a network has occurred”):
based on receiving a request for data corresponding to the event (see Dwivedi; paragraphs 0290 and 0397; Dwivedi discloses receiving a search query, i.e. “request for data”, from a client for a set of event data, i.e. “corresponding to the event”):
generate a response to the request based on the configuration information obtained from the time series store (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query, i.e. “the request”, for event data that is indexed for configuration files, i.e. “configuration information”); and
output the response to the request (see Dwivedi; paragraph 0400; Dwivedi discloses summarization information is provided for response to the query, i.e. “output the response to the request”).
While Dwivedi discloses a “time series store” (see Dwivedi; paragraph 0911), Dwivedi does not explicitly disclose store at a time series store, configuration information for the network device and for a time range associated with the event, wherein the time series store is configured to store configuration information for each time range of a plurality of time ranges; store, at an event store, event information comprising a pointer specifying a location of the configuration information at the time series store and an indication of a time that the event occurred; and obtain, from the location of the configuration information at the time series store, and using the pointer determined using the event information, the configuration information for the network device and for the time range associated with the event.
In analogous art, Hsiao discloses store at a time series store, configuration information deployed at the network device and for a time range associated with the event, wherein the time series store is configured to store configuration information for each time range of a plurality of time ranges (see Hsiao; column 7 line 62 – column 8 line 13, column 13 lines 33-48, column 16 lines 22-25, column 20 lines 63-65, column 22 lines 11-14 and column 37 lines 44-54; Hsiao discloses an event can include data from configuration files. A user is able to search for events in a specific time range. The system stores the events covering specific time ranges, i.e. “store at a time series store…a plurality of time ranges”. Event data with the specific time ranges is transmitted to a data storage server, i.e. “time series store”. The event data includes a list of event streams, as well as, configuration information generated for the event streams. For example, the user is able to search for time-series event data, e.g. data including the configuration information, that matches events, i.e. “configuration information for each time range…”);
store, at an event store, event information comprising a pointer specifying a location of the configuration information at the time series store and an indication of a time that the event occurred (see Hsaio; column 9 lines 30-38, column 20 lines 63-65, column 22 lines 11-19 and column 37 lines 44-54; Hsaio discloses the collected data, e.g. event data, is provided for storage in one or more data stores, i.e. “store, an event store”. Storage servers, i.e. “time series store”, include the event data, i.e. “event information”. The event data includes an unique identifier for the configuration information, i.e. “a pointer specifying a location of the configuration information”, for each event stream. Time-series data is provided with the event data, i.e. “an indication of a time that the event occurred”); and
obtain, from the location of the configuration information at the time series store, and using the pointer determined using the event information, the configuration information deployed at the network device and for the time range associated with the event (see Hsaio; column 13 lines 33-48, column 16 lines 22-25, column 20 lines 63-65, column 22 lines 11-19 and column 37 lines 44-54; Hsaio discloses searching and receiving, i.e. “obtain”, event data, from the data storage server, i.e. “time series store”, it was transmitted to, for a specific time range, i.e. “time range associated with the event”. The event data includes a list of event streams, as well as, a unique identifier, i.e. “location of the configuration”, for configuration information, i.e. “using the pointer determined using the event information”, generated for the event streams).
One of ordinary skill in the art would have been motivated to combine Dwivedi and Hsiao because they both disclose features event data tracking and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Hsaio’s event data capturing into the system of Dwivedi in order to provide the benefit of efficiency by streamlining the deployment of configuration of network capture (see Hsaio; column 22 lines 34-37).
While Hsiao discloses “store, at an event store, event information…” and “obtain, from the location of the configuration information at the time series store…”, as discussed above, the combination of Dwivedi and Hsiao does not explicitly disclose determine, using the event information stored at the event store, the pointer specifying the location of the configuration information at the time series store.
In analogous art, Bingham discloses determine, using the event information stored at the event store, the pointer specifying the location of the configuration information at the time series store (see Bingham; paragraphs 0070, 0076, 0136, 0185, 0192 and 0194; Bingham discloses a task definition includes defining requirements of resources to be used, i.e. “configuration information”. A queue entry, i.e. “pointer”, references a location of the task definition, i.e. “specifying the location of the configuration information…”. A task event identifies the information defining the task and can be stored in a time-series data store, i.e. “configuration information at the time series store”. An indexer, for the queue entry, may retrieve data events stored at an event data store, i.e. “using the event information stored at the event store”);
One of ordinary skill in the art would have been motivated to combine Dwivedi, Hsiao and Bingham because they all disclose features event data tracking and as such, are within the same environment.
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Bingham’s time range event data capturing into the combined system of Dwivedi and Hsaio in order to provide the benefit of efficiency by optimizing time based searches for current or historical data (see Bingham; paragraphs 0193 and 0203).
Further, Dwivedi discloses the additional limitations of claim 20, one or more non-transitory computer-readable storage media storing instructions (see Dwivedi; paragraph 0968; Dwivedi discloses non-transitory computer-readable media comprising computer-executable instructions that, when executed by a computing system).
Regarding claims 2 and 15, Dwivedi, Hsaio and Bingham discloses all the limitations of claims 1 and 14, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response, the instructions cause the system to generate data for a user interface (see Dwivedi; paragraphs 0299, 0312 and 0400; Dwivedi discloses the summarization information, i.e. “the response”, is provided to a user in the form of a graph, chart or other visualization. The visualization is seen via a user interface); and
wherein to output the response, the system is configured to cause a display of the user interface to present the configuration information (see Dwivedi; paragraphs 0144, 0312, 0336 and 0337; Dwivedi discloses the events associated with the configuration files, i.e. “configuration information”, are displayed, via a user interface, using an events tab).
Regarding claims 3 and 16, Dwivedi, Hsaio and Bingham discloses all the limitations of claims 1 and 14, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein the time series store comprises a plurality of intent graph models, each intent graph model of the plurality of intent graph models being deployed at the network for a corresponding time range of the plurality of time ranges and including an indication of the configuration information deployed at the network device at the corresponding time range (see Dwivedi; paragraphs 0144, 0228, 0299, 0336 and 0346; Dwivedi discloses the events associated with the configuration files are based on a specific time range, i.e. “configuration information deployed at the network device at the respective time range”. Visualizations, such as graphs, i.e. “graph models”, are used to display the events at the specific time range).
Regarding claims 4 and 17, Dwivedi, Hsaio and Bingham discloses all the limitations of claims 3 and 16, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response based on the configuration information (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query for event data that is indexed for configuration files, i.e. “configuration information”), the instructions cause the system to:
determine, based on the event, a configuration change (see Dwivedi; paragraphs 0217, 0290 and 0330; Dwivedi discloses transformations applied to events. Configurations may be updated, i.e. “configuration change”, by adding schema to the configuration files based on a user learning more about the data in the events, i.e. “based on the event”); and
determine, based on the pointer, a first intent graph model of the plurality of intent graph models, the first intent graph model corresponding to before the configuration change and a second intent graph model corresponding to after the configuration change (see Dwivedi; paragraphs 0144, 0336, 0346 and 0911; Dwivedi discloses replacing the event data, which includes the configuration files, with updated event data using the indexed field names, i.e. “based on the pointer”. Data models are used graphically to display the event data, i.e. “the first intent graph model”, and the updated event data, i.e. “a second intent graph model”, which replaced the prior event data. And the timeseries data store is optimized to conduct time-based modifications, i.e. “before the configuration change and…after the configuration change”).
Regarding claim 5, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 1, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein the event is a first event and, based on a determination that a second event associated with the network device has occurred (see Dwivedi; paragraphs 0144; Dwivedi discloses events, therefore a “first event” and a “second event”, are stored, i.e. “occurred”), the instructions cause the system to:
store at the time series store, telemetry information indicating a metric associated with the network device (see Dwivedi; paragraph 0139; Dwivedi discloses events may be derived from time series data where the time series data comprises a sequence of data points, such as performance measurements, i.e. “telemetry information”, from a computer system, i.e. “metric associated with the network device”, that are associated with successive points in time); and
store, at the event store, event information comprising a pointer to the telemetry information stored at the time series store and an indication of a time that the second event occurred (see Dwivedi; paragraph 0139; Dwivedi discloses events are stored, i.e. at a “event store”, and are derived from time series data where the time series data comprises a sequence of data points, such as performance measurements, i.e. “telemetry information”, that are associated with successive points in time, i.e. “indication of a time that the second event occurred”. In other words, since events are stored at a sequence of data points in time, then a first even and a second event will have the associated time).
Regarding claim 6, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 1, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein the event comprises a change to configuration information of the network device (see Dwivedi; paragraphs 0141, 0290 and 0330; Dwivedi discloses updated configuration files for the device).
Regarding claims 7 and 18, Dwivedi, Hsaio and Bingham discloses all the limitations of claims 1 and 14, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response based on the configuration information (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query for event data that is indexed for configuration files, i.e. “configuration information”), the instructions cause the system to:
determine, based on the event, a configuration change (see Dwivedi; paragraphs 0217, 0290 and 0330; Dwivedi discloses transformations applied to events. Configurations may be updated, i.e. “configuration change”, by adding schema to the configuration files based on a user learning more about the data in the events, i.e. “based on the event”); and
determine, based on the pointer, configuration information deployed at the network device corresponding to before the configuration change and configuration information deployed at the network device corresponding to after the configuration change (see Dwivedi; paragraphs 0144, 0336, 0346 and 0911; Dwivedi discloses replacing the event data, which includes the configuration files, with updated event data using the indexed field names, i.e. “based on the pointer”. Data models are used graphically to display the event data and the updated event data which replaced the prior event data. And the timeseries data store is optimized to conduct time-based modifications, i.e. “before the configuration change and…after the configuration change”).
Regarding claim 8, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 7, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response based on the configuration information (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query for event data that is indexed for configuration files, i.e. “configuration information”), the instructions cause the system to:
determine a first time corresponding to when the configuration change is provided by a user (see Dwivedi; paragraphs 0139, 0217, 0290 and 0330; Dwivedi discloses events are derived from time series data where the time series data comprises a sequence of data points that are associated with successive points in time, i.e. “a first time”. And configurations may be updated, i.e. “configuration change”, by adding schema to the configuration files based on a user learning more about the data in the events, i.e. “when the configuration change is provided by a user”); and
determine a second time corresponding to when the configuration change is applied at the network device (see Dwivedi; paragraphs 0139, 0217, 0290 and 0330; Dwivedi discloses events are derived from time series data where the time series data comprises a sequence of data points that are associated with successive points in time, i.e. “a second time”. And configurations may be updated, i.e. “configuration change”, by adding schema to the configuration files based on a user learning more about the data in the events. In other words, the configuration update occurs at the device at the respective point in time, i.e. “when the configuration change is applied at the network device).
Regarding claim 9, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 8, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response based on the configuration information (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query for event data that is indexed for configuration files, i.e. “configuration information”), the instructions cause the system to: determine user information for the user providing the configuration change (see Dwivedi; paragraphs 0290 and 0330; Dwivedi discloses updated configurations, i.e. “configuration change”, with the user adding field definitions. In other words, information for the field definitions added by the user, i.e. “user information”).
Regarding claim 10, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 1, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein to generate the response based on the configuration information (see Dwivedi; paragraphs 0144, 0228, 0399 and 0400; Dwivedi discloses summarization information, i.e. “a response”, is provided in response to the query for event data that is indexed for configuration files, i.e. “configuration information”), the instructions cause the system to:
determine, based on the event, a configuration change (see Dwivedi; paragraphs 0217, 0290 and 0330; Dwivedi discloses transformations applied to events. Configurations may be updated, i.e. “configuration change”, by adding schema to the configuration files based on a user learning more about the data in the events, i.e. “based on the event”); and
determine, based on the configuration information, telemetry information for the network device based on the configuration change (see Dwivedi; paragraphs 0139 and 0290; Dwivedi discloses events associated with update configurations, i.e. “based on the configuration change”, may be derived from time series data where the time series data comprises a sequence of data points, such as performance measurements from a computer system, i.e. “telemetry information for the network device”, that are associated with successive points in time).
Regarding claims 11 and 19, Dwivedi, Hsaio and Bingham discloses all the limitations of claims 1 ad 14, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein the instructions cause the system to: after the event information is stored at the event store and after a determination of the pointer, remove the event information for the event from the event store based on a determination that a time the event occurred satisfies a time constraint (see Dwivedi; paragraphs 0220, 0557, 0668, 1008; Dwivedi discloses indexed fields, i.e. “the pointer”, for event data stored in a data store, i.e. “event store”. The system can identify event data that satisfies a time constraint and is removed from the data store, i.e. “after storing the event information…remove the event information…from the event store”).
Regarding claim 12, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 11, as discussed above, and further the combination of Dwivedi, Hsaio and Bingham clearly discloses wherein the instructions cause the system configured to set the time constraint based on a user input (see Dwivedi; paragraphs 0335, 0338, 0421 and 0532; Dwivedi discloses accepting user input which includes a time range picker that enables the user to specify a time range, i.e. “time constraint”).
Regarding claim 13, Dwivedi, Hsaio and Bingham discloses all the limitations of claim 1, as discussed above, and further the combination Dwivedi, Hsaio and Bingham clearly discloses wherein to store the configuration information in the time series store (see Dwivedi; paragraph 0141, 0144, 0228; Dwivedi discloses machine data from a network device includes configuration files, i.e. “configuration information”. The configuration files are associated with the events. An indexer stores the events with an associated timestamp in a data store, i.e. “a time series store”), the instructions cause the system to compress the configuration information (see Dwivedi; paragraphs 0141, 0144, 0218 and 0220; Dwivedi discloses the machine data for the event, which is associated with the configuration files, i.e. “configuration information”, can be stored in a compressed format); and
wherein to store the event information, the instructions cause the system to store the event information for the event without compression (see Dwivedi; paragraph 0218; Dwivedi discloses the data can be stored in compressed or encrypted format. In other words, the data can be stored not in compression, i.e. “without compression”, format but encrypted).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sridhar et al. (U.S. 10,999,164 B1) discloses a reference pointer that will allow for a more efficient retrieval of event data from a data store.
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 ADAM A COONEY whose telephone number is (571)270-5653. The examiner can normally be reached M-F 7:30am-5:00pm (every other Fri off).
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, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.A.C/Examiner, Art Unit 2458 06/24/26
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights