Prosecution Insights
Last updated: April 19, 2026
Application No. 18/786,923

On-Demand Generation of Audit Log Data

Final Rejection §103
Filed
Jul 29, 2024
Examiner
ALMANI, MOHSEN
Art Unit
2159
Tech Center
2100 — Computer Architecture & Software
Assignee
Pure Storage Inc.
OA Round
2 (Final)
50%
Grant Probability
Moderate
3-4
OA Rounds
4y 0m
To Grant
72%
With Interview

Examiner Intelligence

Grants 50% of resolved cases
50%
Career Allow Rate
189 granted / 374 resolved
-4.5% vs TC avg
Strong +21% interview lift
Without
With
+21.3%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
24 currently pending
Career history
398
Total Applications
across all art units

Statute-Specific Performance

§101
12.4%
-27.6% vs TC avg
§103
49.4%
+9.4% vs TC avg
§102
21.5%
-18.5% vs TC avg
§112
10.0%
-30.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 374 resolved cases

Office Action

§103
Detailed Action Applicant amended claims 1, 11-13, 15-16 and 20; canceled claims 8-9 and added claims 21-22 and presented claims 1-7 and 10-22 for reconsideration on 12/23/2025. 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. Claims 1-7, 10-13 and 16-22 are rejected under 35 U.S.C. 103(a) as being unpatentable over Dhanapal et al., "An effective mechanism to regenerate HTTP flooding DDoS attack using real time data set” (Dhanapal), in view of NA et al. Pub. No.: US 2023/0096408 A1. Claim 1. Dhanapal teaches: A method comprising: storing, by a storage system, audit data generated in an efficient binary format, the audit data comprising internal metadata representative of data operations within the storage system; (sec. B, the data sets are in compressed binary logs format: “The data sets are available in the compressed binary logs file format. Totally 249 gunzip binary logs files are available” and “The purpose of read tool is to understand the number of request available in the given file” indicates that data comprises information/metadata representing operations within the storage system) detecting, by the storage system, a request for a portion of the audit data; (sec. B, a given file is a portion of the data sets: “The purpose of read tool is to understand the number of request available in the given file”) converting, by the storage system based on the request, the portion of the audit data to an expanded data format configured for external use; and (sec. B, a given file is processed and converted to a human readable file: “The recreate tool converts the given binary file into the human readable log file”) providing, by the storage system, the converted portion of the audit data. (sec. B, the converted file is provided: “The recreate tool converts the given binary file into the human readable log file. It processing such as mapping Object ID into actual resource in request, time stamp, etc. The example output of the read, checklog and recreate tools are shown in the Figure 1”) Dhanapal did not explicitly disclose generating data in a binary format. NA explicitly discloses generating a binary log format: ¶¶ 71-75, “the storage device 100 may snapshot the storage device 100 in response to the get log page command, thereby generating log data… the storage device 100 may store the generated log data in a memory… the storage device 100 may transmit the log data to the host 200. That is, the storage device 100 may transmit the log data, loaded from the memory…to the host 200. In this case, the storage device 100 may convert and transmit a format (e.g., a binary format) of the log data on the basis of a format supported by the host 200… the host 200 may analyze an internal state of the storage device 100 on the basis of the transmitted log data”) A binary data must have been generated to be used. 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 generating data in a binary format because doing so would further provide for an explicit disclosure of generating a binary file for further processing for achieving the same predictable result as disclosed by Dhanapal. Claims 16 and 20 are rejected under the same rationale as above. Claim 2. The method of claim 1, further comprising: presenting, by the storage system, an audit data directory including pseudo-files organized by attributes of the audit data, each pseudo-file representing a subset of the audit data; (Dhanapal, secs. B and C, provided tools select a given binary file from partitioned binary files, e.g. a directory of binary files: “To keep the size of the file minimal in any particular day, the collected logs may be divided into one or more intervals. For example, if logs are divided into three intervals, then there 1, 2, 3 are the values of <SUB-INTERVAL>”; also see p. 4 of the document attached to Dhanapal: “Due to the volume of data, the binary log has been split into a number of intervals. Each interval represents one day of the overall log…In order to keep the size of each log file below 50 MB some of the 1 day intervals needed to be divided into subintervals…In total there are 249 binary log files for the 92 days during which the access logs were collected) receiving, by the storage system, a request to access a pseudo-file included in the audit data directory; and (see above, a given binary file is a split of a larger binary file that can be converted to human readable file) processing, by the storage system, the request to access the pseudo-file as the request for the portion of the audit data, the portion of the audit data corresponding to the subset of the audit data represented by the pseudo-file. (see above, a given binary file is a split of a larger binary file that can be converted into the human readable log file) Claim 17 is rejected under the same rationale. Claim 3. The method of claim 2, wherein the converting the portion of the audit data comprises converting the subset of the audit data to the expanded data format; and wherein the providing the converted portion of the audit data comprises storing the converted portion of the audit data in a directory as a generated file for responding to audit data read requests. (Dhanapal, converted/recreated files as noted above are used/stored for further analysis, secs. B, C, III.A: “To keep the size of the file minimal in any particular day, the collected logs may be divided into one or more intervals. For example, if logs are divided into three intervals, then there 1, 2, 3 are the values of <SUB-INTERVAL>”; “This module takes the Web Server logs generated using recreate tool as input, processes it and generates output file which contains only HTTP GET requests”; also see p. 8 of the document attached to Dhanapal: “The binary log files were created on an HP PA-RISC machine. As a result, the binary files are in big endian (i.e., network order) format. The three example programs were written knowing that the binary files are in big endian format. Each program attempts to determine the format utilized by the platform you are working on, and convert it accordingly”) Claim 18 is rejected under the same rationale. Claim 4. The method of claim 2, wherein the converting the portion of the audit data comprises converting the subset of the audit data to the expanded data format on-the-fly during the processing the request to access the pseudo-file; and wherein the providing the converted portion of the audit data comprises returning the converted portion in response to the request for the portion of the audit data. (Dhanapal, a portion is converted by recreate tool when it is requested, e.g., based on the requested file name and date attribute, secs. B, C, III.A,“To keep the size of the file minimal in any particular day, the collected logs may be divided into one or more intervals. For example, if logs are divided into three intervals, then there 1, 2, 3 are the values of <SUB-INTERVAL>”; “This module takes the Web Server logs generated using recreate tool as input, processes it and generates output file which contains only HTTP GET requests”; also see p. 8 of the document attached to Dhanapal: “The binary log files were created on an HP PA-RISC machine. As a result, the binary files are in big endian (i.e., network order) format. The three example programs were written knowing that the binary files are in big endian format. Each program attempts to determine the format utilized by the platform you are working on, and convert it accordingly”) Claim 5. The method of claim 1, wherein the detecting the request for the portion of the audit data comprises: determining that the request includes an embedded query; (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) extracting the embedded query from the request; and (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) using the extracted query to query the audit data to identify the portion of the audit data. (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) Claim 19 is rejected under the same rationale. Claim 6. The method of claim 5, wherein: the request is to access contents of a pseudo-file having a filename, the filename included in the request and comprising the embedded query; and (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) the converted portion of the audit data is provided as the contents of the pseudo-file. (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) Claim 7. The method of claim 5, wherein the query comprises a set of metadata values indicating one or more of a set of network addresses, identifying requesting client systems, a set of timestamps, a set of ranges of timestamps, a directory indicating a selection of files within the directory, a set of user identities, or a set of filename patterns. (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log”) Claim 8-9. (Canceled) Claim 10. The method of claim 1, wherein the data operations comprise data access requests, and wherein the audit data comprises one or more of accessed pathnames, timestamps of the data access requests, accessing users, accessing client hosts, elapsed times to complete the data access requests, amounts of data transferred for the data access requests, or completion statuses of the data access requests. (Dhanapal, sec. II, binary log files comprises “huge diversities of request to multiple servers…1.3 Billion HTTP requests to total number of 89996 unique resources, involving 2770107 different IP addresses to the 33 servers across four geographical locations”, fig. 3; also see p. 1 of the document attached to Dhanapal: “The World Cup access logs have been converted from Common Log Format to a more compact binary format. Each entry in the binary log is a fixed size, and represents a single request to the site. The format of a request in the binary log looks like: struct request { uint32_t timestamp; uint32_t clientID; uint32_t objectID; uint32_t size; uint8_t method; uint8_t status; uint8_t type; uint8_t server;}”) Claim 11. The method of claim 1, wherein: generating, by the storage system, the audit data in the efficient binary format comprises using a data reduction algorithm by storing references for a set of audit entries within the audit data to audit metadata associated with an additional set of audit entries within the audit data. (Dhanapal, sec. B, the audit data sets are in compressed binary logs file format suggest storing references for a set of audit entries within the audit data to audit metadata associated with an additional set of audit entries within the audit data; NA, ¶¶ 71-75, “the storage device 100 may snapshot the storage device 100 in response to the get log page command, thereby generating log data… the storage device 100 may store the generated log data in a memory… the storage device 100 may transmit the log data to the host 200. That is, the storage device 100 may transmit the log data, loaded from the memory…to the host 200. In this case, the storage device 100 may convert and transmit a format (e.g., a binary format) of the log data on the basis of a format supported by the host 200… the host 200 may analyze an internal state of the storage device 100 on the basis of the transmitted log data”) Claim 12. The method of claim 1, wherein: generating, by the storage system, the audit data in the efficient binary format using an incremental compression algorithm. (Dhanapal, sec. B, the audit data sets are in compressed binary logs file format suggest using a compression algorithm, e.g., an incremental compression algorithm, NA, ¶¶ 71-75) Claim 13. The method of claim 1, further comprising: receiving, by the storage system, a request to access a pseudo-object included in an object store associated with the storage system; and (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”, a given file name is the name of an object/file; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log…Example: read each of the 1000 requests in the test_log”) processing, by the storage system, the request to access the pseudo-object as the request for the portion of the audit data, the portion of the audit data corresponding to a subset of the audit data represented by the pseudo-object. (Dhanapal, sec. B, read tool determines a given file name as a query for reading the file to “to understand the number of request available in the given file”, a given file name is the name of an object/file; also see p. 2 of the document attached to Dhanapal: “The read tool is a very simple tool that will read each request in a binary log and print the total number of requests contained in that log…Example: read each of the 1000 requests in the test_log”) Claim 21. The method of claim 1, wherein the audit data in the efficient binary format is stored in a binary audit namespace that is not presented to a client. (Dhanapal, Abs., wherein “The data sets are stored in processed log format due to security and confidential reasons” and NA, ¶¶ 71-75, 189, wherein “The connecting interface 1480 may be implemented as various interface types such as advanced technology attachment (ATA), serial ATA (SATA), external SATA (e-SATA), small computer small interface (SCSI), serial attached SCSI (SAS), peripheral component interconnection (PCI), PCI express (PCie ), NVMe, IEEE 1394, universal serial bus (USB), secure digital (SD) card, multi-media card (MMC), eMMC, UFS, embedded universal flash storage (eUFS), and compact flash (CF)” suggests the binary data is stored in a binary audit namespace that is not presented to a client) Claim 22. The method of claim 21, wherein provided the converted portion of the audit data comprises storage the converted portion of the audit data in an audit namespace that is presented to the client. (Dhanapal, wherein converted/recreated files as noted above are used/stored for further analysis, secs. B, C, III.A: “To keep the size of the file minimal in any particular day, the collected logs may be divided into one or more intervals. For example, if logs are divided into three intervals, then there 1, 2, 3 are the values of <SUB-INTERVAL>”; “This module takes the Web Server logs generated using recreate tool as input, processes it and generates output file which contains only HTTP GET requests”; also see p. 8 of the document attached to Dhanapal: “The binary log files were created on an HP PA-RISC machine. As a result, the binary files are in big endian (i.e., network order) format. The three example programs were written knowing that the binary files are in big endian format. Each program attempts to determine the format utilized by the platform you are working on, and convert it accordingly”; NA, ¶¶ 71-75, 189) Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over Dhanapal and NA as applied to claim 1 above, in view of Genovese et al., “Data Mesh: the newest paradigm shift for a distributed architecture in the data world and its application” (Genovese). Claim 14. Dhanapal as modified taught the method of claim 1; Dhanapal as modified did not teach but Genovese teaches wherein the converted portion of the audit data is provided from an object store using an application programming interface. (Genovese, wherein a user can access data stored in an object store such as Amazon S3 using an application programming interface: pp. 40-43, “Amazon Simple Storage Service (Amazon S3) is an object storage cloud service. The primary goal of S3 is to store any type of file in any quantity in the cloud for a variety of use cases (including data lake, data mesh, websites, mobile applications, backup and restore, storage, enterprise applications, IoT devices, and big data analytics), while providing industry-leading scalability, data availability, security, and performance. It can be stored static content for serving it directly to the end users, or internal data (configuration, system state, intermediate states and logs)… Buckets and objects are AWS resources in terms of implementation, and Amazon S3 provides APIs to manage them…”, pp. 45-46, “A REST API, often referred to as a RESTful API, is an application programming interface (API or web API) that adheres to the REST architecture style’s restrictions and allows interaction with RESTful web services… the API defines the content sought by the consumer (the request) and the content demanded by the producer (the response). As a result, the API serves as a bridge between users or customers and the online resources or services they wish to access”) Dhanapal as modified provides for processing data sets that are in compressed binary logs format and converting a requested portion of the dataset into human readable 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 converted portion of the audit data is provided from an object store using an application programming interface because doing so would further provide for using any available services as needed for achieving the same predictable outcome of processing compressed binary logs format. Claim 15 is rejected under 35 U.S.C. 103(a) as being unpatentable over Dhanapal and NA as applied to claim 1 above, in view of Lu et al. "A High Performance Cluster File System with Standard Network File System Interface” (Lu). Claim 15. Dhanapal as modified taught the method of claim 1; Dhanapal as modified did not but Lu teaches wherein the storage system comprises a file server, and wherein the data operations comprise one or more of Network File System (NFSl requests or Server Message Block (SMB) requests. (Lu, secs. I, II wherein a file system can be accessed using a standard network file system: “This paper provides a novel high performance cluster file system with standard network file system access interface: CFS-SI. CFS-SI has not only the high performance of cluster file system, but also the standard network file system access interface. Then, the client can make use of high performance file service without modifying their own software… the FSN runs as Network File System [4] (NFS) or Common Internet File System [5] CIFS) daemon. So, the client can access the CFSSI by standard NFS or CIFS client software”) Dhanapal as modified provides for processing data sets that are in compressed binary logs format and converting a requested portion of the dataset into human readable 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 converted portion of the audit data is provided from an object store using an application programming interface because doing so would further provide for processing log files generated based on accessing a file server using a standard network file system access interface for achieving the same predictable outcome of processing compressed binary logs format. Response to Amendment and Arguments Applicant’s arguments with respect to amended claims have been fully considered but are moot in view of the new ground of rejections as provided above. Conclusion 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 extension fee 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 Mohsen Almani whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9 AM-5 PM, ET. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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
Read full office action

Prosecution Timeline

Jul 29, 2024
Application Filed
Sep 22, 2025
Non-Final Rejection — §103
Dec 23, 2025
Examiner Interview Summary
Dec 23, 2025
Applicant Interview (Telephonic)
Dec 23, 2025
Response Filed
Apr 04, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596740
INFERRING RIGHT LEAF-CATEGORY FOR A PRODUCT USING LLM
2y 5m to grant Granted Apr 07, 2026
Patent 12591605
COMPUTER SESSION MANAGEMENT USING A LANGUAGE MODEL
2y 5m to grant Granted Mar 31, 2026
Patent 12547620
NETWORK CONFIGURATION AND MONITORING USING A FEDERATED GATEWAY
2y 5m to grant Granted Feb 10, 2026
Patent 12541551
Behavioral Curation of Media Assets
2y 5m to grant Granted Feb 03, 2026
Patent 12499084
Maintaining Block Level Snapshots Using Free Storage Space
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
50%
Grant Probability
72%
With Interview (+21.3%)
4y 0m
Median Time to Grant
Moderate
PTA Risk
Based on 374 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month