DETAILED ACTION
This Action is in response to Applicant’s amendment filed on 12/23/25.
Claims 2, 8 and 16 have been previously cancelled
Claims 1, 3-7, 9-15 and 17-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 claim 1, that Ajmera does not disclose the limitation “generate metadata that indexes the flow logs…”. In particular, the applicant states that while Ajmera describes data fields as indexed fields, Ajmera does not mention “generat[ing] metadata” for the fields and only mentions user-defined metadata and intrinsic metadata (see applicant’s remarks; pages 6 and 7).
Response to argument – The examiner respectfully disagrees. While Ajmera mentions user-defined metadata and intrinsic metadata regarding the P4 specification, as noted by the applicant, Ajmera also discloses description of data, i.e. metadata, regarding the flow logs. The examiner notes that metadata, as known to one of ordinary skill in the art, is defined as information about data or a data resource, such as a name, characteristics, properties, origin, history, location, etc. It offers additional information about data or the data resource to inform users of the meaning of the data or data resource.
In particular, Ajmera discloses a flow log entry includes a list of data fields, such as a first field, a second field, and a third field. The third field can contain a value indicating a virtual private cloud tag (emphasis added) (see Ajmera; paragraph 0045). The data fields are indexed fields that include indexed field values (emphasis added). The index fields are the first field, the second field, the third field and the fourth field (see Ajmera; paragraph 0046). The third field can be used to determine a flow key (see Ajmera; paragraph 0047). Additionally, the indexed fields may include a virtual private cloud name (emphasis added) (see Ajmera; paragraph 0048). While the term “metadata” is not used, information such as a virtual private cloud tag or cloud name, is generated for an indexed field of the flow log entry. In other words, the flow log is organized using a cloud tag or cloud name field, in a list of indexed fields, to find specific information in the flow log, e.g. a network packet pertaining to the particular virtual private cloud.
Therefore, Ajmera does in fact disclose the limitation “generate metadata that indexes the flow logs…” by the network appliance generating the log entry, and as such, generates the indexed fields and values, since the indexed fields and values are included in the generated log entry and organizing the flow log by using information, such as a virtual private cloud tag or cloud name, for an indexed field in a list of indexed fields. As such, the rejection has been maintained.
The applicant argues the same reasons as that of claim 1 for claims 7 and 15 (see applicant’s remarks; page 7). As such, the same rationale discussed above regarding claim 1 applies equally as well to claims 7 and 15.
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, 3-5, 7, 9-15 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Ajmera et al. (U.S. 2022/0335008 A1) (applicant submitted prior art; see IDS filed 10/16/23) in view of Su et al. (U.S. 2022/0129468 A1).
Regarding claims 1 and 15, Ajmera discloses a network appliance and method for, comprising:
circuitry (Ajmera; paragraph 0052; Ajmera discloses a network appliance having an integrated circuit) configured to:
generate flow logs describing operation of the network appliance (see Ajmera; paragraph 0072; Ajmera discloses the network appliance producing log objects. A log entry is created that is a record, i.e. “flow log”, of a network packet that was received and processed i.e. “operation of the network appliance”. The log entry is stored in the log object and the process can loop back. As such, multiple log entries produced and stored, i.e. multiple flow logs. The examiner notes that the applicant’s specification states flow logs are included in log objects, see applicant’s specification as filed; paragraph 0035);
generate metadata that indexes the flow logs (see Ajmera; paragraphs 0045-0048 and Figure 2; Ajmera discloses a flow log entry is generated by a network appliance. The log entry includes a list of data fields. Some of the data fields are indexed fields that include indexed field value information, i.e. “metadata”, such as, a virtual private cloud tag or a virtual private cloud name. The index fields are the first field, the second field, the third field and the fourth field. The third field can be used to determine a flow key. Therefore, information, i.e. “metadata”, such as a virtual private cloud tag or virtual private cloud name, is generated for an indexed field of the flow log entry. In other words, the network appliance generates the log entry, and as such, generates the indexed fields and values, since the indexed fields and values are included in the generated log entry. And the flow log is organized, i.e. “indexes”, using a cloud tag or cloud name field, in a list of indexed fields, to find specific information in the flow log, e.g. a network packet pertaining to the particular virtual private cloud);
wherein the metadata comprises indices indicating where different types of data are found in the flow logs (see Ajmera; paragraphs 0044-0047; Ajmera discloses a log object includes a log entry which includes data fields containing values. The data fields are indexed fields containing an indexed field value, i.e. “metadata”, and each indexed field can be used to determine a flow key via a lookup table. Further, for the field value a log entry indicator indicates the first log entry’s location. In other words, “indicating where different types of data are found in the flow logs” by the indexed fields containing values used to determine a flow key via a lookup table, and even further an indicator indicating the log entry's location); and
transmit the flow logs and the metadata to a central analyzer configured to merge the flow logs and the metadata with flow logs and metadata received from a plurality of network appliances (see Ajmera; paragraphs 0009, 0034-0036, 0046 and Figure 1; Ajmera discloses an object store, i.e. “central analyzer”, receives the log objects from a plurality of network appliances. The object store processes the received log objects, which include the log entries, i.e. “flow logs” and indexed data fields, i.e. “metadata”. The object store creates an indexed searchable object, also implemented as a network flow log database, for storing and searching all the log entries of network traffic flows received from the network appliances. In other words, the object store combines the received log objects, which include the log entries and indexed data fields, from the plurality of network appliances, i.e. “merge the flow logs and the metadata with flow logs and metadata received from a plurality of network appliances” into the indexed searchable object, also implemented as a network flow log database. The examiner notes that the applicant’s specification states the central analyzer includes an object store, see applicant’s specification as filed; paragraph 0034).
While Ajmera discloses “generate metadata that indexes the flow logs…”, as discussed above, Ajmera does not explicitly disclose wherein the indices in the metadata are reverse indices corresponding directly to text in the flow logs that index the flow logs against the text present in the flow logs.
In analogous art, Su discloses wherein the indices in the metadata are reverse indices corresponding directly to text in the flow logs that index the flow logs against the text present in the flow logs (see Su; paragraphs 0023, 0033 and 0053; Su discloses a full-text index may dynamically manage a data object, for example log data, i.e. “flow logs”, and may provide a reverse index, i.e. “reverse indices”, for mapping from words in the data object to the data object, i.e. “reverse indices corresponding directly to text in the flow logs…”. For example, performing a full-text search in a log storage system in order to find a log including a keyword. The search is carried out in the reverse index to find all logs including the keyword, i.e. “…that index the flow logs against the text present in the flow logs”).
One of ordinary skill in the art would have been motivated to combine Ajmera and Su because they both disclose features of search log data, 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 have incorporate Su’s reverse indexing into the system of Ajmera in order to provide the benefit of scalability by allowing the network appliance to produce log objects (see Ajmera; paragraph 0072) that can be full-text searched in an accurate and efficient way (see Su; paragraph 0053).
Regarding claims 3, 9 and 17, Ajmera and Su discloses all the limitations of claims 1, 7 and 15 as discussed above, and further the combination of Ajmera and Su clearly discloses wherein the indices point to different data fields in the flow logs (see Ajmera; paragraphs 0045 and 0046 and Figure 2; Ajmera discloses the log entries include indexed data fields that include indexed field values, i.e. “different data fields in the flow logs”).
Regarding claims 4, 10 and 18, Ajmera and Su discloses all the limitations of claims 1, 7, and 15 as discussed above, and further the combination of Ajmera and Su clearly discloses wherein the flow logs describe operations performed by a firewall executing in the network appliance (see Ajmera; paragraphs 0059 and 0072; Ajmera discloses a network appliance including a CPU core to implement packet processing operations such as firewalling, i.e. “a firewall executing in the network appliance”. The network appliance creates a log entry, i.e. “flow log”, that is a record of the network packet that was received and processed).
Regarding claims 5, 13 and 19, Ajmera and Su discloses all the limitations of claims 1, 7 and 15, as discussed above, and further the combination of Ajmera and Su clearly discloses wherein the circuitry is configured to package the flow logs and the metadata together into an indexed binary file which is transmitted to the central analyzer (see Ajmera; paragraphs 0045, 0046, and 0072; Ajmera discloses the network appliance creates the log object, which includes the log entries, i.e. “flow logs” and indexed data fields, into a file, such as in a binary object format, i.e. “indexed binary file”. The log object is sent to the object store, i.e. “central analyzer”).
Regarding claim 7, Ajmera discloses a central analyzer, comprising:
one or more processors (see Ajmera; paragraph 0038; Ajmera discloses an object store, i.e. “central analyzer”, receiving and processing, i.e. “processors”, log objects); and
memory storing an application that is configured to perform an operation (see Ajmera; paragraph 0038 and Figure 1; Ajmera discloses volatile and nonvolatile memory, the operation comprising:
receiving flow logs and metadata from each of a plurality of network appliances, wherein the metadata indexes the flow logs (see Ajmera; paragraphs 0009, 0034, 0045-0048 and Figures 1 and 2; Ajmera discloses an object store, i.e. “central analyzer”, receives log objects from a plurality of network appliances. The object store processes the received log objects, which include log entries, i.e. “flow logs” and indexed data fields that include value information, i.e. “metadata”, such as, a virtual private cloud tag or a virtual private cloud name. The index fields are the first field, the second field, the third field and the fourth field. The third field can be used to determine a flow key. Therefore, the value information, i.e. “metadata”, such as the virtual private cloud tag or virtual private cloud name, is generated for an indexed field of the flow log entry, i.e. “metadata…wherein the metadata indexes the flow logs”. In other words, the flow log is organized, i.e. “indexes”, using a cloud tag or cloud name field, in a list of indexed fields, to find specific information in the flow log, e.g. a network packet pertaining to the particular virtual private cloud),
wherein the metadata comprises indices indicating where different types of data are found in the flow logs (see Ajmera; paragraphs 0045-0047; Ajmera discloses a log object includes a log entry which includes data fields containing values. The data fields are indexed fields containing an indexed field value, i.e. “metadata”, and each indexed field can be used to determine a flow key via a lookup table. Further, for the field value a log entry indicator indicates the first log entry’s location. In other words, “indicating where different types of data are found in the flow logs” by the indexed fields containing values used to determine a flow key via a lookup table, and even further an indicator indicating the log entry's location);
merging the metadata from the plurality of network appliances (see Ajmera; paragraphs 0034-0036, 0046 and Figure 1; Ajmera discloses the object store creates an indexed searchable object, also implemented as a network flow log database, for storing and searching all the log objects including the indexed data fields, i.e. “metadata”, received from the plurality of network appliances. In other words, the object store combines the received log objects, which include the indexed data fields from the plurality of network appliances, i.e. “merging the metadata from the plurality of network appliances” into the indexed searchable object, also implemented as a network flow log database); and
merging the flow logs from the plurality of network appliances, wherein the merged metadata and the merged flow logs are part of a searchable flow log database (see Ajmera; paragraphs 0034-0036, 0046 and Figure 1; Ajmera discloses the object store creates an indexed searchable object, also implemented as a network flow log database, i.e. “a searchable flow log database”, for storing and searching all the log objects including the log entries, i.e. “flow logs”, received from the plurality of network appliances. In other words, the object store combines the received log objects, which include the log entries, from the plurality of network appliances, i.e. “merging the flow logs from the plurality of network appliances” into the indexed searchable object, also implemented as a network flow log database).
While Ajmera discloses “wherein the metadata indexes the flow logs…”, as discussed above, Ajmera does not explicitly disclose wherein the indices in the metadata are reverse indices corresponding directly to text in the flow logs that index the flow logs against the text present in the flow logs.
In analogous art, Su discloses wherein the indices in the metadata are reverse indices corresponding directly to text in the flow logs that index the flow logs against the text present in the flow logs (see Su; paragraphs 0023, 0033 and 0053; Su discloses a full-text index may dynamically manage a data object, for example log data, i.e. “flow logs”, and may provide a reverse index, i.e. “reverse indices”, for mapping from words in the data object to the data object, i.e. “reverse indices corresponding directly to text in the flow logs…”. For example, performing a full-text search in a log storage system in order to find a log including a keyword. The search is carried out in the reverse index to find all logs including the keyword, i.e. “…that index the flow logs against the text present in the flow logs”).
One of ordinary skill in the art would have been motivated to combine Ajmera and Su because they both disclose features of search log data, 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 have incorporate Su’s reverse indexing into the system of Ajmera in order to provide the benefit of scalability by allowing the network appliance to produce log objects (see Ajmera; paragraph 0072) that can be full-text searched in an accurate and efficient way (see Su; paragraph 0053).
Regarding claim 11, Ajmera and Su discloses all the limitations of claim 7, as discussed above, and further the combination of Ajmera and Su clearly discloses wherein the flow logs comprises performing a block merge of flow logs received from different ones of the plurality of network appliances (see Ajmera; paragraphs 0034-0036, 0046 and Figure 1; Ajmera discloses the object store creates an indexed searchable object, also implemented as a network flow log database for storing and searching all the log objects including the log entries, i.e. “flow logs”, received from the plurality of network appliances, i.e. “different ones of the plurality of network appliances”. In other words, the object store combines all the received log objects, which include the log entries, from the different plurality of network appliances, i.e. “block merge of flow logs received from different ones of the plurality of network appliances” into the indexed searchable object, also implemented as a network flow log database).
Regarding claim 12, Ajmera and Su discloses all the limitations of claim 7, as discussed above, and further the combination of Ajmera and Su clearly discloses wherein merging the metadata comprises performing a block merge of metadata received from different ones of the plurality of network appliances (see Ajmera; paragraphs 0034-0036, 0046 and Figure 1; Ajmera discloses the object store creates an indexed searchable object, also implemented as a network flow log database, for storing and searching all the log objects including the indexed data fields, i.e. “metadata”, received from the plurality of network appliances, i.e. “different ones of the plurality of network appliances”. In other words, the object store combines all the received log objects, which include the indexed data fields from the different plurality of network appliances, i.e. “block merge of metadata received from different ones of the plurality of network appliances” into the indexed searchable object, also implemented as a network flow log database).
Regarding claim 14, Ajmera and Su discloses all the limitations of claim 7, as discussed above, and further the combination of Ajmera and Su clearly discloses wherein merging the metadata and the flow logs comprises merging indexed binary files received the plurality of network appliances into a single instance of a larger indexed file, wherein the larger indexed file is part of the searchable flow log database (see Ajmera; paragraphs 0035, 0036, 0045, 0046, 0072 and Figure 3; Ajmera discloses the network appliance creates an indexed searchable object, also implemented as a network flow log database, i.e. “a searchable flow log database”, for storing and searching all the log objects received. The log objects, which include the log entries, i.e. “flow logs” and indexed data fields, into files, such as in a binary object format, i.e. “indexed binary files”, and a main binary object file that is part of the indexed searchable object).
Claims 6 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ajmera et al. (U.S. 2022/0335008 A1) and Su et al. (U.S. 2022/0129468 A1), as applied to claims 1 and 15 above, and further in view of Sommers et al. (U.S. 11,853,254 B1).
Regarding claim 6, Ajmera and Su discloses all the limitations of claim 1, as discussed above. Further, while Ajmera discloses “a network appliance…circuitry”, as discussed above, the combination of Ajmera and Su does not explicitly disclose wherein the circuitry is part of a data processing unit (DPU) in the network appliance.
In analogous art, Sommers discloses wherein the circuitry is part of a data processing unit (DPU) in the network appliance (see Sommers; column 18 lines 4-16; Sommers discloses a DPU of a smartswitch, i.e. “network appliance”, generates metadata associated with NetFlow information).
One of ordinary skill in the art would have been motivated to combine Ajmera, Su and Sommers because they all disclose features of collecting log information, 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 have incorporate Sommers’ smartswitch into the combined system of Ajmera and Su in order to provide the benefit of scalability by allowing the network appliance to produce log objects (see Ajmera; paragraph 0072) that include metrics associated with traffic, such as, a performance metric and performing packet encapsulation (see Sommers; column 18 lines 9-16).
Regarding claim 20, Ajmera and Su discloses all the limitations of claim 15, as discussed above. Further, while Ajmera discloses “generating, at a network appliance, metadata”, as discussed above, the combination of Ajmera and Su does not explicitly disclose wherein metadata is generated by a DPU in the network appliance.
In analogous art, Sommers discloses wherein metadata is generated by a DPU in the network appliance (see Sommers; column 18 lines 4-16; Sommers discloses a DPU of a smartswitch, i.e. “network appliance”, generates metadata associated with NetFlow information).
One of ordinary skill in the art would have been motivated to combine Ajmera, Su and Sommers because they all disclose features of collecting flow records, 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 have incorporate Sommers’ smartswitch into the combined system of Ajmera and Su in order to provide the benefit of scalability by allowing the network appliance to produce log objects (see Ajmera; paragraph 0072) that include metrics associated with traffic, such as, a performance metric and performing packet encapsulation (see Sommers; column 18 lines 9-16).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
James et al. (U.S. 11,392578 B1) discloses generating metadata for a metadata catalog and indexing.
Fink et al. (U.S. 11,914,566 B2) discloses indexing and relaying log data.
THIS ACTION IS MADE FINAL. 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 02/09/26
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458