Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
DETAILED ACTION
1. This Office Action is taken in response to Applicants’ Amendments and Remarks filed on 10/3/2025 regarding application 18/242,808 filed on 9/6/2023.
Claims 2-21 are pending for consideration.
2. Response to Amendments and Remarks
Applicants’ amendments and remarks have been fully and carefully considered, with the Examiner’s response set forth below.
(1) In response to the amendments and remarks, an updated claim analysis has been made. Refer to the corresponding sections of the following Office Action for details.
3. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
4. Claims 2-21 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Newly amended claim 2 recites “wherein the at least one type of file is automatically excluded based on the at least one type of file corresponding to virtual memory,” and Applicant points to paragraphs [0020], [0041], [0043], and [0062] of the Specification of the current Application for support of the written descriptions for this newly added limitation.
However, it is noted that paragraph [0041] recites “… In accordance with an embodiment of the invention, a copy of the contents of FAT 150 is made as backup FAT 160, which is optionally modified. The optional modification may include removing references to file system objects that have been excluded from backup per selections made in operator console 110.” Significantly, paragraph [0041] states that “file system objects that have been excluded from backup per selections made in operator console 110.” In other words, the file system objects that are excluded are selected by “using an operator console manually,” and not “automatically” as recited in claim 2.
Similarly, paragraph [0043] states “… According to an embodiment, exclusions can be pre-configured. For example, it may be pre-configured that files such as paging and virtual memory files (e.g., swap files), are always excluded from the backup.” Again, paragraph [0043] merely mentions pre-configured exclusion, and does not disclose that the exclusion is performed “automatically” as recited in claim 2.
Paragraphs [0020] and [0062] do not address “exclusion of file objects” at all.
In addition, paragraph [0050] of the Specification of the current Application recites “… The file system objects may include directories and files, specified individually or using file name masks. In an embodiment, if a directory is selected to be included in an image level backup, all data files in the directory and subdirectories below the selected directory are automatically selected for inclusion in the image level backup.” Thus, this passage explicitly states that “file objects to be included are “automatically” selected.
At the same time, paragraph [0050] also recites [In another embodiment of the invention, if a file system object such as a directory is selected to be excluded from an image level backup, all dependent file system objects, such as files within the excluded directory and all of its subdirectories, will not be processed in the image level backup. According to an embodiment, the list of data items to be included in the backup may be programmatically determined based upon the one or more data items selected by the user to be excluded from the backup. For example, it may programmatically be determined that all files or a predetermined subset of files, except for the user selected one or more files to be excluded, are enumerated and included in the list of file system objects to be backed up.” Therefore, paragraph [0050] specifically points out that “file objects to be excluded for backup are selected by the user manually,” instead of “automatically” as recited in claim 2.
Therefore, the newly added limitation “wherein the at least one type of file is automatically excluded based on the at least one type of file corresponding to virtual memory” lacks the support of written descriptions from the Specification of the current Application, as required under 35 U.S.C. 112(a).
Clarifications/corrections are needed.
Claims 3-8 are rejected by virtue of their dependency from claim 2.
Claim 9 suffers from the same deficiency as in claim 2.
Claims 10-15 are rejected by virtue of their dependency from claim 9.
Claim 16 suffers from the same deficiency as in claim 2.
Claims 17-21 are rejected by virtue of their dependency from claim 17.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and, In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.130(b).
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
6. Claims 2-4, 8-12, and 15-19 are rejected under the judicially created doctrine of obvious-type double patenting as being unpatentable over independent claims 1-17 of US Patent 11,789,823. Although not all of the conflicting claims are exactly identical, they are extremely similar and are not patentably distinct from each other as shown in the example below:
18/242,808
11,789,823
2. (New) A system for selective processing of file system objects for an image level backup, comprising: a backup engine in communication with a production virtual disk storage, wherein the production virtual disk storage comprises one or more virtual disk images and a file allocation table (FAT), and wherein the backup engine comprises: a receiving module configured to receive backup parameters for the image level backup, wherein the backup parameters include a selection of a virtual machine to backup and a selection of a plurality of file system objects including a first file system object to include in and a second file system object to exclude from the image level backup, wherein the plurality of file system objects are associated with one or more applications associated with the virtual machine; and a connection module configured to connect to a virtual disk image of the one or more virtual disk images corresponding to the selected machine, wherein the connection module is further configured to obtain data from the virtual disk image corresponding to the first file system object; a FAT processing module configured to: fetch a selected set of data blocks from the virtual disk image using the FAT, wherein the selected set of data blocks correspond to the first file system object, and wherein the FAT provides a location of the selected set of data blocks; prevent fetching a set of data blocks corresponding to the second file system object; generate empty content corresponding to the set of blocks corresponding to the second file system object; and create a backup FAT from the selected set of data blocks and the empty content; and a block processing module configured to save the backup FAT to a reconstructed disk image in the backup engine.
1. A system for selective processing of file system objects for an image level backup, comprising: a backup engine including: a receiving module configured to receive backup parameters for the image level backup, wherein the backup parameters include a selection of a machine to backup and a selection of a first file system object to include in and a second file system object to exclude from the image level backup, wherein the second file system object is marked for deletion; and a connection module configured to connect to production storage corresponding to the selected machine, wherein a connection module is further configured to obtain data from a source disk corresponding to a selected at least one file system object, and wherein the source disk is in the production storage; a file allocation table (FAT) processing module configured to: fetch a selected set of data blocks from the source disk, wherein the selected set of data blocks correspond to the first file system object; prevent fetching a set of data blocks corresponding to the second file system object; generate empty content corresponding to the set of blocks corresponding to the second file system object; and write the selected set of data blocks and a plurality of zeroed data blocks corresponding to the empty content to a backup FAT; and a block processing module configured to: create a reconstructed disk image based on the selected set of data blocks in the backup FAT and by skipping the plurality of zeroed data blocks; and store a compressed version of the reconstructed disk image as the image level backup.
Claim Rejections - 35 USC § 103
7. The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
8. Claim 2-7, 9-14, and 16-21 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over of Phillips (US Patent Application Publication 2011/0055299), in view of Stringham (US 8,200,637), and further in view of Kovacs et al. (US Patent Application Publication 2008/0250083, hereinafter Kovacs).
As to claim 2, Phillips discloses A system for selective processing of file system objects for an image level backup [The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097); In embodiments, the virtual machine image 202 may include at least one virtual disk image. A virtual disk image of the virtual machine image 202 may include a functional operating system and various applications. This virtual disk image may be referred to as a "system virtual disk." Another virtual disk image of the virtual machine image 202 may include substantially persistent user data 124, such as files, settings, and the like. This virtual disk image may be referred to as a "user virtual disk." Yet another virtual disk image of the virtual machine image 202 may include substantially transient user data 124. This virtual disk image may be referred to as a "transient virtual disk." The virtual machine image 202 may also include a so-called "memory image" that holds a suspended virtual machine's state (¶ 0131);
Stringham also teaches this limitation -- A system and method for creating a backup image from a volume including a plurality of files are described. Information specifying a subset of the files, but not all of the files, to backup may be received … The method may comprise identifying a subset of, but not all of, the plurality of blocks to copy into the backup image. The subset of blocks may include each data block for each file of the subset of files, and may also include blocks of one or more file system metadata structures needed for accessing the subset of files … (abstract)], comprising:
a backup engine in communication with a production virtual disk storage, wherein the production virtual disk storage comprises one or more virtual disk images and a file allocation table (FAT), and wherein the backup engine comprises: [as shown in figures 30-32; In embodiments, the virtual machine image 202 may include at least one virtual disk image. A virtual disk image of the virtual machine image 202 may include a functional operating system and various applications. This virtual disk image may be referred to as a "system virtual disk." Another virtual disk image of the virtual machine image 202 may include substantially persistent user data 124, such as files, settings, and the like. This virtual disk image may be referred to as a "user virtual disk." Yet another virtual disk image of the virtual machine image 202 may include substantially transient user data 124. This virtual disk image may be referred to as a "transient virtual disk." The virtual machine image 202 may also include a so-called "memory image" that holds a suspended virtual machine's state (¶ 0131);
Stringham more expressively teaches a file allocation table (FAT) -- backup and restore software, figure 1, 205; … The backup and restore software 205 may backup data blocks for the specified files to a block-based sparse backup image without backing up data blocks for other files of the volume 230 (c4 L17-27); As used herein, the term "volume" refers to data representing a set of files managed by file system software. The files may be organized in a hierarchy of directories or folders. In various embodiments the volume may be structured or implemented in accordance with any of various kinds of files systems. Examples of file systems include File Allocation Table (FAT) file systems (e.g., FAT32, FAT16, etc.); NTFS file systems; EXT2 or EXT3 file systems; Hierarchical File System (HFS) file systems; etc. (c4 L53-61);] comprising: a receiving module configured to receive backup parameters for the image level backup, wherein the backup parameters include a selection of a machine to backup [as shown in figures 30-32; … The system information may include an amount of data to be backed up, a wireless networking configuration, a configuration parameter, a status indicator, and so on (¶ 0146); … At block 1712, the method may, based at least in part on the clone, re-personalize a user's copy of the published master root disk image for use on the user's local computer. Re-personalizing the user's copy may include modifying a parameter embodied in the master root disk image. In embodiments, the parameter may include a computer name, a user account identifier, a system identifier, a hard variable of an operating system, and so on … (¶ 0220);
Stringham also teaches this limitation -- figure 2, steps 301, 303 and 305] and a selection of a first file system object to include in [The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097);
Stringham also teaches this limitation -- as shown in figure 4; … For example, the backup and restore software 205 may execute to create a block-based sparse backup image, mount a block-based sparse backup image, and/or restore a block-based sparse backup image to a target volume according to the methods described herein. The file filter driver 902 may execute to filter requests to access a block-based sparse backup image that has been mounted for access, as described in detail below (c3 L26-33); … The backup and restore software 205 may backup data blocks for the specified files to a block-based sparse backup image without backing up data blocks for other files of the volume 230 (c4 L17-27)] and a second file system object to exclude from the image level backup [The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097);
Stringham also teaches this limitation -- A system and method for creating a backup image from a volume including a plurality of files are described. Information specifying a subset of the files, but not all of the files, to backup may be received … The method may comprise identifying a subset of, but not all of, the plurality of blocks to copy into the backup image. The subset of blocks may include each data block for each file of the subset of files, and may also include blocks of one or more file system metadata structures needed for accessing the subset of files … (abstract); … The backup and restore software 205 may backup data blocks for the specified files to a block-based sparse backup image without backing up data blocks for other files of the volume 230 (c4 L17-27)], wherein the second file system object is marked for deletion [… If the user attempts to delete such a file, it may be replaced with an empty file marked as deleted … The deleted metastate may be associated with an empty file that may serve to obscure some same-named file in a lower level, denoting it as logically deleted … In an embodiment, file rename operations may be permitted. In an example, if a copied up or change stub file is renamed, an empty file marked deleted may be created with the original name, thus ensuring that the obscured lower-layer file remains obscured … (¶ 0269-0270);
Stringham also teaches this limitation -- … For example, the backup and restore software 205 may traverse the directory hierarchy and, for each directory, may determine whether the files (or other directories) referenced by the directory's entries actually exist. Entries representing files or directories whose data blocks do not exist may be deleted. In some embodiments deleting these entries may also cause other metadata structures to be updated, such as file allocation tables or a master file table (c12 L38-45)];
a connection module configured to connect to production storage corresponding to the selected machine, wherein the connection module is further configured to obtain data from a source disk corresponding to the selected at least one file system object, and wherein the source disk is in the production storage [as shown in figures 30-32; In embodiments, the virtual machine image 202 may include at least one virtual disk image. A virtual disk image of the virtual machine image 202 may include a functional operating system and various applications. This virtual disk image may be referred to as a "system virtual disk." Another virtual disk image of the virtual machine image 202 may include substantially persistent user data 124, such as files, settings, and the like. This virtual disk image may be referred to as a "user virtual disk." Yet another virtual disk image of the virtual machine image 202 may include substantially transient user data 124. This virtual disk image may be referred to as a "transient virtual disk." The virtual machine image 202 may also include a so-called "memory image" that holds a suspended virtual machine's state … (¶ 0131-0133);
Stringham also teaches this limitation -- as shown in figure 3, where the volume 230 is the source, and where data blocks corresponding to file 55A and file 55D are backed up in the block-based sparse backup image 240];
a file allocation table (FAT) processing module configured to:
identify a set of pre-configured exclusion files, wherein the set of pre-configured exclusion files comprises at least one of type of file that is automatically excluded from the image level backup [this limitation is taught by Kovacs -- In an exemplary embodiment, the backup configuration program 118 provides for execution of a method for locating files within the file space 110, 124 of the computer system 100 (FIG. 1). In the exemplary embodiment, the backup configuration program 118 shown in FIG. 1 is described in detail in the flow chart of FIG. 2. Referring to FIG. 2, the backup configuration program is configured such that certain pre-selected directories, applications and data files having certain extensions are automatically selected for backup at step 210. In addition, certain file extensions and file directories are predetermined to be irrelevant and are therefore, excluded for backup as shown in step 210. Furthermore, the pre-selected directories, application programs, data files and file extension types for backup maybe based upon at least one of user input and iteration information stored in a cache or file storage space 124 from a previous iteration of the backup configuration application as shown in step 210 (¶ 0025)], and wherein the at least one type of file is automatically excluded based on the at least one type of file corresponding to virtual memory [this limitation lacks the support of written descriptions from the Specification of the current Application, see Section 4 of this Office Action; this limitation is taught by Kovacs -- In an exemplary embodiment, the backup configuration program 118 provides for execution of a method for locating files within the file space 110, 124 of the computer system 100 (FIG. 1). In the exemplary embodiment, the backup configuration program 118 shown in FIG. 1 is described in detail in the flow chart of FIG. 2. Referring to FIG. 2, the backup configuration program is configured such that certain pre-selected directories, applications and data files having certain extensions are automatically selected for backup at step 210. In addition, certain file extensions and file directories are predetermined to be irrelevant and are therefore, excluded for backup as shown in step 210. Furthermore, the pre-selected directories, application programs, data files and file extension types for backup maybe based upon at least one of user input and iteration information stored in a cache or file storage space 124 from a previous iteration of the backup configuration application as shown in step 210 (¶ 0025)];
fetch FAT a selected set of data blocks from the source disk, wherein the selected set of data blocks correspond to the first file system object [this limitation is taught by Stringham -- figure 2, step 303, “wherein the subset includes the data blocks for the subset of files and the blocks for file system metadata structures needed for accessing the subset of files;” As used herein, the term "volume" refers to data representing a set of files managed by file system software. The files may be organized in a hierarchy of directories or folders. In various embodiments the volume may be structured or implemented in accordance with any of various kinds of files systems. Examples of file systems include File Allocation Table (FAT) file systems (e.g., FAT32, FAT16, etc.); NTFS file systems; EXT2 or EXT3 file systems; Hierarchical File System (HFS) file systems; etc. (c4 L53-61); The volume metadata may include a plurality of metadata structures … Examples of other metadata structures used by some file systems include a master file table (MFT), boot sector, file allocation tables, etc. (c5 L17-29); The subset of blocks identified for backup may also include blocks of one or more file system metadata structures other than directory structures, e.g., such as the boot sector, file allocation tables, master file table (MFT), etc. (c6 L19-22)];
prevent fetching, from the virtual disk image, a set of data blocks corresponding to the second file system object [The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097);
Stringham also teaches this limitation -- A system and method for creating a backup image from a volume including a plurality of files are described. Information specifying a subset of the files, but not all of the files, to backup may be received … The method may comprise identifying a subset of, but not all of, the plurality of blocks to copy into the backup image. The subset of blocks may include each data block for each file of the subset of files, and may also include blocks of one or more file system metadata structures needed for accessing the subset of files … (abstract); … The backup and restore software 205 may backup data blocks for the specified files to a block-based sparse backup image without backing up data blocks for other files of the volume 230 (c4 L17-27)] and the set of pre-configured exclusion files [this limitation is taught by Kovacs -- In an exemplary embodiment, the backup configuration program 118 provides for execution of a method for locating files within the file space 110, 124 of the computer system 100 (FIG. 1). In the exemplary embodiment, the backup configuration program 118 shown in FIG. 1 is described in detail in the flow chart of FIG. 2. Referring to FIG. 2, the backup configuration program is configured such that certain pre-selected directories, applications and data files having certain extensions are automatically selected for backup at step 210. In addition, certain file extensions and file directories are predetermined to be irrelevant and are therefore, excluded for backup as shown in step 210. Furthermore, the pre-selected directories, application programs, data files and file extension types for backup maybe based upon at least one of user input and iteration information stored in a cache or file storage space 124 from a previous iteration of the backup configuration application as shown in step 210 (¶ 0025)];
generate empty content corresponding to the set of blocks corresponding to the second file system object and the set of pre-configured exclusion files [… If the user attempts to delete such a file, it may be replaced with an empty file marked as deleted … The deleted metastate may be associated with an empty file that may serve to obscure some same-named file in a lower level, denoting it as logically deleted … In an embodiment, file rename operations may be permitted. In an example, if a copied up or change stub file is renamed, an empty file marked deleted may be created with the original name, thus ensuring that the obscured lower-layer file remains obscured … (¶ 0269-0270)]; and
create a backup FAT from the selected set of data blocks and the empty content [… If the user attempts to delete such a file, it may be replaced with an empty file marked as deleted … The deleted metastate may be associated with an empty file that may serve to obscure some same-named file in a lower level, denoting it as logically deleted … In an embodiment, file rename operations may be permitted. In an example, if a copied up or change stub file is renamed, an empty file marked deleted may be created with the original name, thus ensuring that the obscured lower-layer file remains obscured … (¶ 0269-0270);
FAT is taught by Stringham -- figure 2, step 303, “wherein the subset includes the data blocks for the subset of files and the blocks for file system metadata structures needed for accessing the subset of files;” The subset of blocks identified for backup may also include blocks of one or more file system metadata structures other than directory structures, e.g., such as the boot sector, file allocation tables, master file table (MFT), etc. (c6 L19-22)]; and
a block processing module configured to: read the determined selected set of data blocks [The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097);
Stringham also teaches this limitation -- figure 2, steps 301, 303, and 305; … For example, the backup and restore software 205 may execute to create a block-based sparse backup image, mount a block-based sparse backup image, and/or restore a block-based sparse backup image to a target volume according to the methods described herein. The file filter driver 902 may execute to filter requests to access a block-based sparse backup image that has been mounted for access, as described in detail below (c3 L26-33)]; and
save the backup FAT to a reconstructed disk image [this limitation is taught by Stringham -- as shown in figures 2 and 3]; and store a compressed version of the reconstructed disk image as the image level backup [Communications over the network 104 may be encrypted, compressed, or otherwise encapsulated. Thus, the user data 124, the system disk image 128, and so on may be encrypted, compressed, or otherwise encapsulated for communication over the network 104 (¶ 0119); The virtual workspace specification 200 may embody the copy of the virtual workspace 122. In embodiments, the virtual workspace specification 200 may be provided as one or more data files, each of which may be compressed, encrypted, and so on (¶ 0130); In an embodiment, the virtual structure of the user's data disk image may be accessed by accessing the user layer from the virtual file system and metadata may be used to describe which block's (down to the sector 512 byte) level has changed. Accordingly, identification of the changed blocks that need to be synchronized may be easy and a smaller amount of data may need to be sent to the server 3002. In an embodiment, changes to the user data may be compressed into binary patches based on the metadata stored with the user data and standards based mechanisms to give better performance. Use of the binary patches may provide a better performance than a performance provided by just a compression technique, both in terms of CPU and network bandwidth … (¶ 0354-0355)].
Regarding claim 2, Phillips does not teach a File Allocation Table (FAT).
However, FAT is well known and commonly used in the art to provide information regarding where each file is stored within the storage system.
For example, Stringham specifically teaches a File Allocation Table (FAT) [figure 2, step 303, “wherein the subset includes the data blocks for the subset of files and the blocks for file system metadata structures needed for accessing the subset of files;” As used herein, the term "volume" refers to data representing a set of files managed by file system software. The files may be organized in a hierarchy of directories or folders. In various embodiments the volume may be structured or implemented in accordance with any of various kinds of files systems. Examples of file systems include File Allocation Table (FAT) file systems (e.g., FAT32, FAT16, etc.); NTFS file systems; EXT2 or EXT3 file systems; Hierarchical File System (HFS) file systems; etc. (c4 L53-61); The volume metadata may include a plurality of metadata structures … Examples of other metadata structures used by some file systems include a master file table (MFT), boot sector, file allocation tables, etc. (c5 L17-29); The subset of blocks identified for backup may also include blocks of one or more file system metadata structures other than directory structures, e.g., such as the boot sector, file allocation tables, master file table (MFT), etc. (c6 L19-22)].
Therefore, it would have been obvious for one of ordinary skills in the art at the time of Applicant’s invention to include a File Allocation Table (FAT), as demonstrated by Stringham, and to incorporate it to the existing scheme disclosed by Phillips, in order to efficiently and quickly locate and access any file within the storage system.
Further regarding claim 2, Phillips on view of Stringham teaches excluding file system objects for backup [Phillips -- The management system 108 may receive and archive, from the client systems 102, a workspace's user data 124, a workspace's system disk image 128, and so on. In embodiments, the management system 108 may receive this user data 124 or system disk image 128 from the client systems 102 via the network 104. This may enable full or incremental backups of the workspace 122 … (¶ 0097);
Stringham -- A system and method for creating a backup image from a volume including a plurality of files are described. Information specifying a subset of the files, but not all of the files, to backup may be received … The method may comprise identifying a subset of, but not all of, the plurality of blocks to copy into the backup image. The subset of blocks may include each data block for each file of the subset of files, and may also include blocks of one or more file system metadata structures needed for accessing the subset of files … (abstract); … The backup and restore software 205 may backup data blocks for the specified files to a block-based sparse backup image without backing up data blocks for other files of the volume 230 (c4 L17-27)], but does not expressive teach that the file system objects are pre-configured for exclusion.
However, Kovacs specifically teaches excluding pre-determined/pre-configured file system objects for backup [In an exemplary embodiment, the backup configuration program 118 provides for execution of a method for locating files within the file space 110, 124 of the computer system 100 (FIG. 1). In the exemplary embodiment, the backup configuration program 118 shown in FIG. 1 is described in detail in the flow chart of FIG. 2. Referring to FIG. 2, the backup configuration program is configured such that certain pre-selected directories, applications and data files having certain extensions are automatically selected for backup at step 210. In addition, certain file extensions and file directories are predetermined to be irrelevant and are therefore, excluded for backup as shown in step 210. Furthermore, the pre-selected directories, application programs, data files and file extension types for backup maybe based upon at least one of user input and iteration information stored in a cache or file storage space 124 from a previous iteration of the backup configuration application as shown in step 210 (¶ 0025)].
Therefore, it would have been obvious for one of ordinary skills in the art at the time of Applicant’s invention to exclude pre-determined/pre-configured file system objects for backup, as demonstrated by Kovacs, and to incorporate it to the existing scheme disclosed by Phillips on view of Stringham, in order to efficiently and quickly locate and access any file within the storage system for backup, if necessary.
As to claim 3, Phillips on view of Stringham & Kovacs teaches The system of claim 2, wherein the virtual machine is selected from a plurality of virtual machines [Phillips -- Instances of the WEE may execute a set of virtual machines. These virtual machines may have access to a user interface of the personal computer on which the instance of the WEE is operating. Each of the user-visible workspaces may run a user accessible operating system … (¶ 0183)].
As to claim 4, Phillips on view of Stringham & Kovacs teaches The system of claim 2, wherein the reconstructed disk image is a replica virtual machine [Phillips – Embodiments of the WEE may include at least two caches. One cache may be adapted for caching relatively small objects and the other may be adapted to cache copy-on-write disk blocks and the like. Small objects such as virtual machine meta-data, virtualized applications, virtual workspaces meta-data, or the like may be replicated in their entirety within the cache for small objects. Regarding the cache for copy-on-write disk blocks, snapshots of user data may be stored locally in their entirety, before being uploaded to the management system 108 for backup (¶ 0196); In an embodiment, all changes may be made in the virtual application layer with the user layer being constant. In another embodiment, if the virtual application layer is discarded, the system may be restored to the point in time before the virtual application layer was created. It will be apparent to a person skilled in the art that though only two layers have been used in the above-mentioned examples, the same principles may be applied when there are more virtual layers (¶ 0258)].
As to claim 5, Phillips on view of Stringham & Kovacs teaches The system of claim 4, wherein the reconstructed disk image is configured to be accessible from a hypervisor host running the replica virtual machine [Phillips – Although a layered virtual file system may include unmanaged namespaces, a hypervisor may manage these namespaces or portions thereof, such as paging files, registry hives, layered virtual file system metadata and control information, and the like. Alternatively, a hypervisor may provide a virtual workspace in which an instance of the layered virtual file system may operate (¶ 0077)].
As to claim 6, Phillips on view of Stringham & Kovacs teaches The system of claim 2, wherein the reconstructed disk image is configured to be accessible as a local volume [Phillips – as shown in figures 30-32; Stringham – as shown in figure 3].
As to claim 7, Phillips on view of Stringham & Kovacs teaches The system of claim 2, wherein the reconstructed disk image is configured to be accessible as remote storage [Phillips – as shown in figures 30-32; Stringham – as shown in figure 3].
As to claim 9, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 10, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 11, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details.
As to claim 12, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to “As to claim 5” presented earlier in this Office Action for details.
As to claim 13, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details.
As to claim 14, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details.
As to claim 16, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to “As to claim 2” presented earlier in this Office Action for details.
As to claim 17, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to “As to claim 3” presented earlier in this Office Action for details.
As to claim 18, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to “As to claim 4” presented earlier in this Office Action for details.
As to claim 19, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to “As to claim 5” presented earlier in this Office Action for details.
As to claim 20, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to “As to claim 6” presented earlier in this Office Action for details.
As to claim 21, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to “As to claim 7” presented earlier in this Office Action for details.
9. Claims 8 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over Phillips on view of Stringham & Kovacs, and further in view of Abe (US patent 6,580,804).
Regarding claim 8, Phillips on view of Stringham & Kovacs teaches The system of claim 1, the block processing module further configured to: determine a previously processed FAT block in the selected set of data blocks [Stringham teaching determining whether a block is a previously backed up and unchanged block or a changed/new block - figure 8, 371, “identify changed data blocks;” ... An incremental backup image includes only the data blocks that have changed (as well as blocks for associated file system metadata structures) since a previous backup image was created. Thus, the incremental backup image is based on the previous backup image, which may be either a full backup image or another incremental backup image (c1 L46-52); In various embodiments any of various techniques may be used to identify the changed data blocks to copy into an incremental backup image and identify new files that need to be added to the incremental backup image. In some embodiments the backup and restore software 205 may use a bitmap, referred to as a Vdiff bitmap, which specifies which blocks of the volumes have changed since the previous backup image was created ... (cl3 L38-64); In some embodiments the backup and restore software 205 may store a table of contents in each backup image. An alternative technique to identify the files that have been moved or renamed such that they now match the rule set specifying which files need to be backed up may use the table of contents, e.g., by simply comparing the table of contents of the previous backup image to the table of contents of the current backup image. Any file that was not listed in the previous table of contents but is in the current table of contents may have all of its blocks included in the current incremental backup image (c14 L22-32)], but does not teach determining whether the previously processed FAT block is the last block of the source disk.
However, Abe specifically teaches determining whether the previously processed FAT block is the last block of the source disk [… After completing the act A109, it is determined whether or not the last block is processed in act A110 by comparing the counter value to the Nr value. If not all blocks are processed, the preferred process goes back to the act A108. On the other hand, all blocks have been processed, the preferred process terminates (c7 L67 to c8 L5); note that in this case, Nr is the corresponding number of blocks].
Therefore, it would have been obvious for one of ordinary skills in the art at the time of Applicant’s invention to determining whether the previously processed FAT block is the last block of the source disk, as demonstrated by Abe, and to incorporate it into the existing scheme disclosed by Phillips on view of Stringham & Kovacs, in order to make sure that all data blocks have been processed.
As to claim 15, it recites substantially the same limitations as in claim 8, and is rejected for the same reasons set forth in the analysis of claim 8. Refer to “As to claim 8” presented earlier in this Office Action for details.
Conclusion
10. Claims 2-21 are rejected as explained above.
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kenneth Lo can be reached on 571-272-9774. 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).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2136
November 30, 2025