Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/10/2026 has been entered.
Detailed Action
Applicant amended claims 1, 12-13 and 20, canceled claim 18-19 and presented claims 1-17 and 20-22 for reconsideration on 01/02/2026.
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.
Claims1, 3-22 are rejected under 35 U.S.C. 103(a) as being unpatentable over SESHADRI et al., Pub. No.: US 2023/0185855 A1 (hereinafter Seshadri), in view of Karagiannis et al., “Chidroid: A Mobile Android Application for Log Collection and Security Analysis in Healthcare and IoMT” (hereinafter Karagiannis)
Claim 1. Seshadri teaches:
A method comprising:
detecting, by a log data system, an event associated with data operations of a data storage system; (¶¶ 20, 22-24, an event of interest is detected, the detected event of interest is logged in a particular format using a configuration file and stored based on an ingest configuration: “Ops-ingest 206 can include an in-memory matcher 208 configured to identify and/or tag event data from any log data during processing that corresponds to particular events of interest…These events of interest can be included as part of an ingest configuration that is received at log intelligence application 212 and log data indexing service 214. The ingest configuration can also include instructions for how processed unindexed log data files are organized…the instructions specify groupings of particular types of log entries into corresponding log data files. For example, all log entries associated with software development environments can be grouped in a first data file while all log entries associated with operational environments can be grouped in a second data file. This type of grouping can be specified in the ingest configuration and can reduce a number of log data files that need to be searched when a query specifies a search for log entries associated only with a particular environment”)
selecting and accessing, by the log data system based on the detecting the event, a stored log definition file in a log definition namespace, the stored log definition file defining a log data grouping format, wherein the stored log definition file is selected from a plurality of stored log definition files based on one or more properties of the event, the plurality of stored log definition files respectively defining different log data grouping formats usable to generate log data; (¶¶ 20, 22-24, the ingest configuration is a log definition file accessed for groupings of particular types of log entries as specified)
generating, by the log data system based on the stored log definition file, log data in the log data grouping format for the event; (¶¶ 20, 22-24, a log definition file, an ingest configuration is accessed for groupings of particular types of log entries as specified)
identifying, by the log data system based on the log data grouping format, a log rule for the log data; and (¶¶ 20, 22-24, it is also determined whether the log data should be saved in a cloud storage or another storage: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
applying, by the log data system, the log rule to the log data. (¶¶ 20, 22-24, it is also determined whether the log data should be saved in a cloud storage or another storage: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
Seshadri did not specifically disclose but Karagiannis discloses defining log data structure formats. (Karagiannis, pp. 2 and 9, wherein log collection and distribution to a cloud or other endpoints is performed based on defined instruction including required log data structure formats: “ There are two main Chidroid configuration files included in the APK: (i) “config.toml” and (ii) “rules.toml”. The first (config.toml) is used to set up sources and sinks (outputs), while the second (rules.toml) is used to define the privacy rules and to set up the needed transformations to parse the sources to the required format”)
Seshadri discloses using user defined instruction for identifying particular events of interest and specific type of data in a log data so that a number of log data files that need to be searched can be reduced when a query specifies a search for log entries associated only with a particular environment. Seshadri further discloses the capability of transforming log data generated in different formats to a unified format. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing defined log data structure formats to be used for transforming log data as defined for achieving the same predictable result of providing the log data as requested.
Claim 12. Seshadri teaches:
A method comprising:
receiving, by a cloud-based log data system and from an on-premises endpoint system, log data associated with operations of the on-premises endpoint system, wherein the log data is generated by the on-premises endpoint system based on a stored log definition file that is selected, by the on-premises endpoint system, from a plurality of stored log definition files that respectively define different log data grouping formats usable to generate log data in the different log data grouping formats, wherein the selected stored log definition file defines a log data grouping format in which the log data is generated, the log data grouping format mapped to a log rule specifying that the log data be sent from the on-premises endpoint system to the cloud-based log data system; (¶¶ 20, 22-24 a log definition file, an ingest configuration, is accessed for groupings of particular types of log entries as specified; it is also determined whether the log data should be saved in a cloud storage or another storage: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
detecting, by the cloud-based log data system based on the log data, a condition associated with the operations of the on-premises endpoint system; and (¶¶ 20, 23, log data is stored in a “cloud storage location or in a server owned by the entity running the servers generating the log data” based on a condition)
initializing, by the cloud-based log data system based on the condition, a transition from the on-premises endpoint system sending additional log data to the cloud-based log data system to the on-premises endpoint system sending the additional log data to an on-premises log data system. (¶¶ 20, 23, log data is stored in a cloud storage or another storage based on a condition: “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as A WS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.…Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
Seshadri did not specifically disclose but Karagiannis discloses defining log data structure formats. (Karagiannis, pp. 2 and 9, wherein log collection and distribution to a cloud or other endpoints is performed based on defined instruction including required log data structure formats: “ There are two main Chidroid configuration files included in the APK: (i) “config.toml” and (ii) “rules.toml”. The first (config.toml) is used to set up sources and sinks (outputs), while the second (rules.toml) is used to define the privacy rules and to set up the needed transformations to parse the sources to the required format”)
Seshadri discloses using user defined instruction for identifying particular events of interest and specific type of data in a log data so that a number of log data files that need to be searched can be reduced when a query specifies a search for log entries associated only with a particular environment. Seshadri further discloses the capability of transforming log data generated in different formats to a unified format. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing defined log data structure formats to be used for transforming log data as defined for achieving the same predictable result of providing the log data as requested.
Claim 20. Seshadri teaches:
A computer program product embodied in a non-transitory computer readable storage medium and comprising computer instructions for:
receiving, from an on-premises endpoint system, a subset of log data associated with operations of the on-premises endpoint system, wherein the subset of log data is generated by the on-premises endpoint system based on a stored log definition file that is selected, by the on-premises endpoint system, from a plurality of stored log definition files that respectively define different log data grouping formats usable to generate log data in the different log data grouping formats, wherein the selected stored log definition file defines a log data grouping format in which the subset of log data is generated, the log data grouping format mapped to a log rule specifying that the subset of log data be sent from the on-premises endpoint system to a cloud-based log data system; (¶¶ 20, 22-24 a log definition file, an ingest configuration, is accessed for formatting/groupings of particular types of log entries as specified; it is also determined whether the log data should be saved in a cloud storage or another storage: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
detecting, based on the log data, a condition associated with the operations of the on-premises endpoint system; and (¶¶ 20, 23, log data is stored in a “cloud storage location or in a server owned by the entity running the servers generating the log data” based on a condition)
initializing, based on the condition, a transition from the on-premises endpoint system sending additional log data to the cloud-based log data system to the on-premises endpoint system sending the additional log data to an on-premises log data system. (¶¶ 20, 23, log data is stored in a cloud storage or another storage based on a condition: “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as A WS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.…Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
Seshadri did not specifically disclose but Karagiannis discloses defining log data structure formats. (Karagiannis, pp. 2 and 9, wherein log collection and distribution to a cloud or other endpoints is performed based on defined instruction including required log data structure formats: “ There are two main Chidroid configuration files included in the APK: (i) “config.toml” and (ii) “rules.toml”. The first (config.toml) is used to set up sources and sinks (outputs), while the second (rules.toml) is used to define the privacy rules and to set up the needed transformations to parse the sources to the required format”)
Seshadri discloses using user defined instruction for identifying particular events of interest and specific type of data in a log data so that a number of log data files that need to be searched can be reduced when a query specifies a search for log entries associated only with a particular environment. Seshadri further discloses the capability of transforming log data generated in different formats to a unified format. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing defined log data structure formats to be used for transforming log data as defined for achieving the same predictable result of providing the log data as requested.
Seshadri as modified by Karagiannis teaches:
Claim 3. The method of claim 1, wherein the applying the log rule to the log data comprises:
detecting, based on the log data, a condition associated with the operations of an on-premises endpoint system; and (Seshadri, ¶¶ 20, 23, log data is stored in a cloud storage or another storage based on a condition: “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as A WS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.…Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
initializing, based on the condition, a transition from the on-premises endpoint system sending additional log data to the log data system to the on-premises endpoint system sending the additional log data to a second log data system. (Seshadri, ¶¶ 20, 23, log data is stored in a cloud storage or another storage based on a condition: “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as A WS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.…Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
Claim 4. The method of claim 3, wherein the condition comprises a resource usage level exceeding a predetermined threshold. (Seshadri, ¶¶ 23-24, “a particular event of interest” can be any event such as “a resource usage level exceeding a predetermine threshold”)
Claim 13 is rejected under the same rationale.
Claim 5. The method of claim 3, wherein the initializing the transition comprises providing metadata associated with the transition to the second log data system. (Seshadri, ¶¶ 20-23, metadata/location of a particular storage has to be provided for storing log data in the particular location: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”)
Claim 14 is rejected under the same rationale.
Claim 6. The method of claim 1, wherein the applying the log rule to the log data comprises selecting, from a plurality of storage locations, a storage location for the log data based on the log data structure format. (Seshadri, ¶¶ 18, 20, 22-24, log data is stored in a cloud storage and/or another storage according to a format associated with the storage: “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as AWS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.”)
Claim 7. The method of claim 6, wherein the plurality of storage locations comprises an on-premises storage location and a cloud-based storage location. (Seshadri; ¶¶ 20, 22-24, log data is stored in storges “housed on the premises of a large corporation and/or cloud storage”)
Claim 8. The method of claim 1, wherein the applying the log rule to the log data comprises retaining the log data for a specified time period. (Seshadri, ¶¶ 20- 21, wherein “long or short-term storage” and “historical events” suggests that log data is retained as required for a specified time period to be quired as “historical event”)
Claim 9. The method of claim 1, further comprising:
receiving a request for a portion of the log data; and identifying, based on the log data structure format, the portion of the log data. (Seshadri, ¶¶ 30-31, a query is processed for retrieving a requested portion of data log stored in a particular location: “Since log file storage 110 may have the log data files stored in multiple locations or across multiple storage arrays, additional efficiency can be realized by assigning each execution core files that are located in only a subset of the storage locations”, Karagiannis, pp. 2 and 9)
Claim 10. The method of claim 9, wherein the identifying the portion of the log data comprises:
extracting an embedded query from the request, wherein the embedded query comprises a set of metadata values corresponding to one or more fields associated with the log data structure format; and matching the set of metadata values to the portion of the log data. (Seshadri, ¶¶ 28-29, a request is a submitted query from which query parameters/criteria are extracted for retrieving requested portions of log data; Karagiannis, pp. 2 and 9)
Claim 11. The method of claim 9, further comprising generating, based on the log data structure format in response to the request, summary data associated with the portion of the log data. (Seshadri, ¶ 28, wherein “The query…to search only the identified files for the requested information… the file location information can be accompanied by an actual or estimated number of records matching the criteria from the submitted query in each file” suggests a summary from particular log files are generated, Karagiannis, pp. 2 and 9)
Claim 15. The method of claim 14, wherein the metadata comprises an indication of a cooling-off period. (Karagiannis, p. 10, wherein “Chidroid can execute and collect the logs from Logcat and distribute the data for analysis. They are collected and shipped before being naturally erased by filling in all the reserved ring buffer sizes” indicates that the metadata comprises an indication of a colling-off period)
Claim 16. The method of claim 12, further comprising:
establishing, by the on-premises endpoint system, a connection with the on-premises log data system; (Seshadri, ¶¶ 20-23, a connection has to be established for sending log data to another storage: “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”) a connection has to be established for sending data to an on-premises server)
ceasing, by the on-premises endpoint system based on an indication of a cooling-off period received from the cloud-based log data system, the connection. (Seshadri, ¶¶ 20-23, 27, a connection has to be established/ceased for sending log data to a cloud storage or another storage; a cooling-off period is a condition determined by ops-ingest for sending a particular log data to a particular location: “log data can be retained on a computing system that generated it for a predetermined amount of time but offloading the log data is fairly standard since it generally takes up substantial amounts of storage space as it accumulates over time”, “Ops-ingest is also generally responsible for determining whether a subset of the incoming log data containing a particular log event or series of log events should also be saved in a rapid access cloud storage location or in a server owned by the entity running the servers generating the log data”, “data files can be grouped/partitioned based on customer defined query conditions before persisting the log data files to log storage 110…each data file can be associated with only a single type of environment…such as …a staging environment and a production environment”)
Claim 17. The method of claim 12, further comprising aggregating the log data with the additional log data using a synthesizer block. (Seshadri, ¶¶ 20, 25, 29-30, wherein “Log data storage system 112 can take the form of large storage arrays housed on the premises of a large corporation and/or cloud storage hosted on a cloud provider such as AWS, Azure, Google Cloud Platform, IBM Cloud, Oracle Cloud Infrastructure, etc.” and “Since log file storage 110 may have the log data files stored in multiple locations or across multiple storage arrays, additional efficiency can be realized by assigning each execution core files that are located in only a subset of the storage locations… aggregation core 410 may also be leveraged to search for and query one or more of the log data files identified by log data indexing service 214” indicates that based on the location of log data and additional log data in a cloud storage and another storage, requested log data is retrieved and aggregated)
Claim 21. The method of claim 1, wherein the stored log definition file defines fields for the log data structure format, the fields include a log identifier field. (Seshadri, ¶ 24, wherein “the instructions specify groupings of particular types of log entries into corresponding log data files. For example, all log entries associated with software development environments can be grouped in a first data file while all log entries associated with operational environments can be grouped in a second data file” suggests the instruction comprises a log identifier field, Karagiannis, pp. 2 and 9)
Claim 22. The method of claim 1, wherein the stored log definition file comprises a log identifier and selecting the stored log definition file from the plurality of stored log definition files comprises: generating an identifier corresponding to the event based on the one or more properties of the event; matching the identifier corresponding to the event to the log identifier of the stored log definition file. (Seshadri, ¶ 24, wherein “the instructions specify groupings of particular types of log entries into corresponding log data files. For example, all log entries associated with software development environments can be grouped in a first data file while all log entries associated with operational environments can be grouped in a second data file” suggests matching an identifier of a particular environment with events generated by the particular environment)
Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Seshadri and Karagiannis as applied to claim 1 above, in view of Dhanapal et al., "An effective mechanism to regenerate HTTP flooding DDoS attack using real time data set” (Dhanapal).
Claim 2. Seshadri as modified taught the method of claim 1; Seshadri as modified did not but Dhanapal discloses, wherein the generating the log in the log data structure format comprises generating the log data in an efficient binary format. (Dhanapal, sec. II,B and p1 of attached document, wherein log data is stored in binary format)
Seshadri discloses generating a unified format because different computing systems can output raw log data in different formats and Karagiannis discloses transforming log data into a required format. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing wherein the generating the log in the log data structure format comprises generating the log data in an efficient binary format because doing so would further provide for converting different formats to a binary format as desired for achieving the same predictable result of processing and storing log data.
Response to Amendment and Arguments
Applicant’s arguments with respect to rejected claims have been fully considered but are moot in view of the new ground of rejections as provided above.
Applicant’s arguments with respect to Seshadri have been considered but are not persuasive for at least the following reason.
Applicant argues: “Seshardi does not disclose that, based on the detection of an event, the ingest configuration is selected from a plurality of ingest configurations based on one or more properties of the event. Rather, the single ingest configuration of Seshardi includes user-defined events of interest and is pro grammatically used to detect those events of interest in the ingested raw log data. Thus, the ingest configuration is already used to identify an event represented in log data and cannot be selected and accessed based on the event. Without the ingest configuration being used to identify the event, there is no disclosure in Seshardi about how to detect the event. Moreover, there is no disclosure in Seshardi of multiple ingest configurations or of selecting and accessing one of the multiple ingest configurations based on properties of a detected event.”
In response: Claim 1 recites “detecting, by a log data system, an event associated with data operations of a data storage system”. Claim 1 does not recite any specific manner for event detection. Therefore, detecting an event of interest based on a user defined instruction is not in contrast with detecting a particular event. Seshardi explicitly discloses detecting an event by receiving log data from a computing system. “Computing systems 202, which can represent computing systems 102-110 from FIG. 1, supply log data to a routing agent 204”. The received events in log data are further processed for identifying “particular events of interest” using “an in-memory matcher that can be configured using log intelligence dashboard 210, where an administrator is able to specify events of interest to identify from the log data and other instructions for ingest”. Evidently, there are multiple ingest configuration because “an administrator is able to specify events of interest to identify from the log data and other instructions for ingest”. See ¶¶ 24-25 for examples.
Conclusion
The prior arts made of record in PTO-326 and not relied upon are considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHSEN ALMANI whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9:00 to 5:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only.
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159
Prosecution Insights