DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. The Action is responsive to Applicant’s amendment, filed on July 10, 2026.
3. It is acknowledged that as a result of the amendment, claims 1, 10-13, 20, and 22-23 have been amended.
4. Claims 1-23 are pending.
Response to Arguments
5. Applicant’s arguments with respect to claims 1-23 have been considered but are moot in view of the new grounds of rejection necessitated by Applicant’s amendment of the claims.
Claim Rejections - 35 USC § 103
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
7. Claim(s) 1-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over BANGALORE et al (US 2017/0091045), in view of Per et al (US 7,831,789) hereinafter “BANGALORE” and “Per” respectively.
As per Claim 1, BANGALORE discloses:
A method for generating a backup using file-level scanning and block-level
scanning, the method comprising: obtaining a snapshot of a storage volume associated with a virtualization environment; (Par [0195], “identify data as compared to other approaches which can involve scanning an entire file system…” and par [0264-0265], “Restoring such files may require accessing multiple container files, chunk folders, and/or volume folders to obtain the requisite data blocks” and “dynamic triggering of block-level backups based on block change thresholds and corresponding file identities, according to an illustrative embodiment of the present invention. Data storage management system 200 (or “system 200”) may be an embodiment of an enhanced information management system comprising: client computing device 102 hosting application 110-A and file system 110-FS, as well as application-specific block-level data agent 270 and file system data agent 280”) reading a filesystem on the snapshot to identify one or more files; (Par [0267], “Primary storage device 104, which was described in more detail elsewhere herein, stores primary data 112, which is accessible by application 110-A and file system 110-FS. For example, in the course of operating, application 110-A may read and/or write from/to primary data 112 as is well known in the art.”) generating a file-level backup of data corresponding to each of the identified files; (Par [0155], “Any of the above types of backup operations can be at the volume level, file level, or block level. Volume level backup operations generally involve copying of a data volume (e.g., a logical disk or partition) as a whole. In a file-level backup, information management system 100 generally tracks changes to individual files and includes copies of files in the backup copy. For block-level backups…”) retrieving, after the file-level backup is generated, one or more block-level addresses corresponding to the file-level data; (Par [0246], “At step 6, illustratively based on instructions received from storage manager 140 at step 5, the specified media agent 1446 retrieves the most recent backup copy 116A from disk library 108A….” and par [0274], “110-A to provide consistent point-in-time protection—at the block level—for primary data 112 accessed by associated application 110-A”)
updating a bitmap indicating which data blocks have been read during the file-level backup determining which data blocks were read during the file-level backup based on the one or more block-level addresses and the bitmap; (Par [0154], “… it builds new full backup images (e.g., bitmaps)”, Par [0171], “Deduplication or single-instance storage is useful to reduce the amount of non-primary data. For instance, some or all of the above-described secondary copy operations can involve deduplication in some fashion. New data is read, broken down into data portions of a selected granularity (e.g., sub-file level blocks, files, etc.), compared with corresponding portions that are already in secondary storage, and only new portions are stored. Portions that already exist are represented as pointers to the already-stored data. Thus, a deduplicated secondary copy 116 may comprise actual data portions copied from primary data 112 and may further comprise pointers to already-stored data, which is generally more storage-efficient than a full copy.”) and generating a block-level backup by reading data blocks addresses not indicated by the bitmap as having been read during the file-level backup. (Par [0005], “The backup operation is a block-level backup. The illustrative dynamic scheme may reduce the processing load on the storage manager so that it may respond more flexibly to changing conditions according to block changes.”)
However, BANGALORE, do not specifically disclose: “updating a bitmap indicating which data blocks have been read during the file-level backup” and the “not indicated by the bitmap as having been read”
Per recites the above limitations as follows:
Col. 9, lines 1-35, “… in a particular implementation of bitmap updating algorithm shown in FIG. 1 as step 110. In step 202, the bitmap updating process begins. It should be noted that the steps in FIG. 2…” and “the record pointer (e.g., address of an initial storage block) is set, in other words, the records physical address is identified. In step 220, the record, to which the pointer points to, is read from the data storage device or from the snapshot of the data storage device. In step 225, the record, to which the pointer points to, is read from the backup. Note that processes 220 and 225 can occur in parallel to each other. In step 230, comparing of descriptors of logical storage units is provided. The descriptors can be compared entirely or partially (for example, only file names, time stamps of file modification and physical addresses of files' clusters can be compared).” And see Figures 1-2 and 5).
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date to incorporate the teachings of Per specifically updating the bitmap whenever the file has been read or backed up into the method of BANGALORE to take advantage on providing the state of the main storage after comparing bitmaps, marking physical storage units. The modification would have been obvious because one of the ordinary skills in the art would implement providing and recognizing the file-level backups according to prior and current storage by unmarking or using pointers to prior backup.
As per Claim 2, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: wherein generating the file-level backup further comprises:
reading data from each of the identified files in data chunks; hashing the data chunks; and comparing each of the data chunks to an existing deduplication index. (Par [0172], “… calculate and/or store signatures (e.g., hashes or cryptographically unique IDs) corresponding to the individual data portions in the source data and compare the signatures instead of comparing entire data portions. In some cases, only a single instance of each data portion is stored, and deduplication operations may therefore be referred to interchangeably as “single-instancing” operations. Depending on the implementation, however, deduplication operations can store more than one instance of certain data portions, but nonetheless significantly reduce stored-data redundancy” and see Figures 1H and 2).
As per Claim 3, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: wherein data blocks utilized by each file are flagged as previously read except for a utilized last data block. (Par [0282], “For example, a certain file such as a password file or customer configuration database may contain sensitive information and may be specially flagged for backup whenever any change to the file is detected. In this example, a block-change threshold of 0 bytes would be associated with the file ID and when data blocks in this file are detected to have changed (i.e., greater than 0 bytes), those data blocks would be backed up in a block-level backup.”).
As per Claim 4, the rejection of Claim 3 is incorporated, and BANGALORE further discloses: wherein generating the block-level backup further comprises: reading only data blocks that were not flagged as previously read during the generation of the file-level backup. (Par [0111], “Jobs agent 156 in some embodiments initiates, controls, and/or monitors the status of some or all information management operations previously performed, currently being performed, or scheduled to be performed by system 100. A job may be a logical grouping of information management operations such as generating backup copies of a primary data 112 subclient at a certain time every day.” And par [0210], “…particular flags (e.g., in metadata identifying a document or email as personal, confidential, etc.). An audit policy may further specify rules for handling sensitive objects.” And par [0274], “Application-specific block-level data agent 270 (or “data agent 270”) is an embodiment of a data agent…”).
As per Claim 5, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: further comprises: merging metadata from the file-level backup and the block-level backup into a unified record that references data blocks in the storage volume. (Par [0076], “…may create and manage multiple secondary copies 116 of a particular data object or metadata, each copy representing the state of the data object in primary data 112 at a particular point in time.” And par [0533], “…can be added, merged, or left out altogether”).
As per Claim 6, the rejection of Claim 5 is incorporated, and BANGALORE further discloses: further comprises: using the unified record to restore the one or more identified files corresponding to the file-level backup. (Par [0155], “…backup operations can be at the volume level, file level, or block level. Volume level backup operations generally involve copying of a data volume (e.g., a logical disk or partition) as a whole. In a file-level backup, information management system 100 generally tracks changes to individual files and includes copies of files in the backup copy. For block-level backups…”).
As per Claim 7, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: wherein obtaining a snapshot further comprises:
requesting a point-in-time snapshot of the storage volume via a hypervisor or
virtualization API. (Par [0056], “…The hypervisor provides resources to each virtual operating system such as a virtual processor, virtual memory, a virtual network device, and a virtual disk. Each virtual machine has one or more virtual disks. The hypervisor typically stores the data of virtual disks in files on the file system of the physical host machine, called virtual machine disk files (in VMware lingo) or virtual hard disk image files…”).Par [0149], “ A backup operation creates a copy of a version of primary data 112 at a particular point in time (e.g., one or more files or other data units). ” and Par [0201], “such reports may be specified and created at a certain point in time as a system analysis, forecasting, or provisioning tool. Integrated reports may also be generated that illustrate storage and performance metrics, risks and storage costing information. Moreover, users may create their own reports based on specific needs”).
As per Claim 8, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: wherein reading the filesystem on the snapshot further
comprises: mounting the snapshot as a read-only volume and enumerating directories to locate each file. (Par [0166], “Users in some cases gain read-only access to the record of files and directories of the snapshot.” And par [0132], “In one example, a media agent 144 operates on a first server computer and is in communication with a secondary storage device(s) 108 operating in a separate rack-mounted RAID-based system.”).
As per Claim 9, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: further comprises: flagging one or more partially used data blocks during the file-level backup if one or more data blocks are partially occupied by a file; and re-examining the one or more partially used blocks during the block-level backup. (Par [0282], “…may be specially flagged for backup whenever any change to the file is detected. In this example, a block-change threshold of 0 bytes would be associated with the file ID and when data blocks in this file are detected to have changed (i.e., greater than 0 bytes), those data blocks would be backed up in a block-level backup.”).
As per Claim 10, the rejection of Claim 1 is incorporated, and BANGALORE further discloses: comprises: storing a mapping of each block in the snapshot of the storage volume to either the file-level backup or the block-level backup. (Par [0155], “Any of the above types of backup operations can be at the volume level, file level, or block level.” And par [0147] Data movement operations can include by way of example, backup operations, archive operations, information lifecycle management operations such as hierarchical storage management operations, replication operations (e.g., continuous data replication), snapshot operations, deduplication or single-instancing operations, auxiliary copy operations, disaster-recovery copy operations, and the like. As will be discussed, some of these operations do not necessarily create distinct copies. Nonetheless, some or all of these operations are generally referred to as “secondary copy operations” for simplicity. Data movement also comprises restoring secondary copies and par [0285], “…storage manager 240 may instruct index server 240 to monitor block changes in certain data storage devices 104, data storage volumes, and/or set of blocks storing the contents of a given file…”).).
As per Claim 11, the rejection of Claim 1 is incorporated and BANGALORE further discloses: further comprises: generating a block-level manifest that associates each logical block address of the snapshot of the storage volume with a storage reference in a backup repository, wherein the block-level manifest enables restoration of the snapshot of the storage volume; (Par [0147] , par [0155], and par [0285], storage manager 240 may instruct index server 240 to monitor block changes in certain data storage devices 104, data storage volumes, and/or set of blocks storing the contents of a given file…”) and generating a file-level manifest that associates an identifier for each of the identified files with at least one storage reference, wherein the file-level manifest enables restoration of the identified files without requiring restoration of the snapshot of the storage volume. (Par [0005-0007], “Moreover, a novel communication architecture between data agents that operate in the illustrative system enables reverse lookup operations for identifying block-to-file relationships. Ordinarily, block-level monitoring and block-level backups are ignorant of file boundaries, file identities, and file system organization. The illustrative system is configured to discover the identity of a file based on the identity of the changed blocks being monitored” and par [0010], “file identifiers; folder identifiers; application identifiers; and/or time periods” and par [0285]).
As per Claims 12-23, being the non-transitory computer-readable medium and system claims corresponding to the system claims 1-11 respectively and rejected under the same reason set forth in connection of the rejections of Claims 1-11 and further BANGALORE discloses: (Par [0391]).
Conclusion
8. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
AGRAWAL (US-2021/017381-A1) and (US 2016/0078068), relates to deduplication or single-instance storage, which is useful to reduce the amount of non-primary data. For instance, some or all of the above-described secondary storage operations can involve deduplication in some fashion. New data is read, broken down into portions (e.g., sub-file level blocks, files, etc.) of a selected granularity, compared with blocks that are already in secondary storage, and only the new blocks are stored. Blocks that already exist are represented as pointers to the already stored data.
HARIDAS et al (US 2020/0293213), relates to backup operations can be at the volume level, file level, or block level. Volume level backup operations generally involve copying of a data volume (e.g., a logical disk or partition) as a whole. In a file-level backup, information management system 100 generally tracks changes to individual files and includes copies of files in the backup copy. For block-level backups, files are broken into constituent blocks, and changes are tracked at the block level.
9. 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.
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANGELICA RUIZ whose telephone number is (571)270-3158. The examiner can normally be reached M-F 10:00 am to 6:00 pm.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/ANGELICA RUIZ/Primary Examiner, Art Unit 2154 September 30, 2026
