Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bansod (US 2015/0193229, hereinafter Bansod) in view of Chen (US 2020/0342065, hereinafter Chen).
Regarding claim 1, Bansod discloses
A system comprising:
a virtual machine (VM) configured to (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines):
mount a snapshot storage volume (paragraph [0050]: system 300 requires only one initial mounting of a given hardware snapshot volume (on storage array A at 471) to a corresponding build-node (on friendly build machine computing device S) when the working copy of the software base is first propagated to system 300), the snapshot storage volume storing a set of build dependencies (paragraph [0036]: FIG. 3 depicts some salient portions of a system 300 for efficient propagation of a software base and for enabling more efficient informal/friendly software builds; paragraph [0041]: a snapshot may be thought of as an instant image of data at a given point in time (e.g., a volume such as a volume comprising official software base 352));
execute a software build workflow (paragraph [0061]: At block 472, the respective build-node on computing device S, illustratively build-node BNn, is available for use to generate a friendly build; paragraph [0063]: build-node BNn incorporates friendly changes into the software base, as received from block 484 on computing device DD) using the set of build dependencies stored within the snapshot storage volume (paragraph [0036]: FIG. 3 depicts some salient portions of a system 300 for efficient propagation of a software base and for enabling more efficient informal/friendly software builds; paragraph [0041]: a snapshot may be thought of as an instant image of data at a given point in time (e.g., a volume such as a volume comprising official software base 352));
produce an software build action result of the software build workflow (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block).
In particular, Bansod discloses modifying the software base (i.e., the build dependencies) during the execution of the software build workflow (Bansod paragraph [0063]: build-node BNn incorporates friendly changes into the software base; paragraph [0081]: the build-node incorporates the received friendly changes into the software base, which results in a changed software base of a different (second) version).
Bansod does not explicitly disclose writing, to an overlay snapshot storage volume, a difference between the set of build dependencies in the snapshot storage volume and the set of build dependencies as modified during execution of the software build workflow. Chen discloses writing, to an overlay snapshot storage volume, a difference between the set of build dependencies in the snapshot storage volume and the set of build dependencies as modified (paragraph [0022]: The present embodiments relate in one aspect to a snapshot of a thinly provisioned volume or other logical data construct, which snapshot comprises metadata relating to changed parts of the address range only in relation to an ancestor; paragraph [0023]: the snapshot comprising a mapping table and memory values of the volume… which values entered differ from an ancestor of the snapshot; paragraph [0059]: each device 105 is enabled to send difference data at a Point in Time (PiT) since the last snapshot was taken… Remote system 110 is enabled to receive difference data in message 130 and build hierarchical snapshot tree 120; Note: A snapshot volume that stores only the “changed parts” or “difference data” relative to an ancestor/base snapshot is the functional definition of an overlay snapshot storage volume).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software build system of Bansod to utilize the hierarchical snapshot storage mechanism of Chen, such that when the software base is modified during the execution of the software build workflow (as in Bansod), the system writes only the difference between the original data and the modified data to an overlay snapshot storage volume (as in Chen). The motivation would have been to significantly reduce storage space requirements and improve system efficiency by only saving the incremental data changes (deltas) generated during the software build workflow, rather than duplicating the entire software base for every friendly build (Chen paragraphs [0022], [0075]).
Regarding claim 2, Bansod discloses
wherein the set of build dependencies comprises one or more of a compiler, a software library, a minifier, and a bundler (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art).
Regarding claim 3, Bansod discloses
wherein the software build action result comprises one of compiled object code, bundled interpreted code, and code test results (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art).
Regarding claim 4, Bansod discloses
further comprising: a host computing device configured to execute the virtual machine (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines), wherein the snapshot storage volume is stored on (paragraph [0040]: Element 360: Storage array A (360) is a storage device and/or system comprising a collection of storage media (preferably high availability disks) that are commonly accessible via a body of software, firmware, and/or hardware that controls and manages the collection; furthermore, according to the illustrative embodiment, storage array A is equipped with so-called hardware snapshot technology) a local physical drive connected to the host computing device (paragraph [0036]: System 300 comprises: storage array A (element 360) and computing device S (element 370), which are communicatively coupled to each other as well as to computing device CC (element 350) and computing device(s) DD (elements 380) as shown … The depicted elements are communicatively coupled as shown, i.e., they communicate electronically with each other via at least a respective wired or wireless communication link according to the illustrative embodiment; they may be in direct electronic communication, e.g., via dedicated lines, or may be indirectly connected, e.g., via public and/or private telecommunications network(s) such as a local area network, a private intranet and/or the Internet, without limitation).
Regarding claim 5, Bansod discloses
further comprising: a host computing device configured to execute the virtual machine (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines), wherein the snapshot storage volume is stored on (paragraph [0040]: Element 360: Storage array A (360) is a storage device and/or system comprising a collection of storage media (preferably high availability disks) that are commonly accessible via a body of software, firmware, and/or hardware that controls and manages the collection; furthermore, according to the illustrative embodiment, storage array A is equipped with so-called hardware snapshot technology) a remote virtual drive configured to be accessed over a network by the host computing device (paragraph [0036]: System 300 comprises: storage array A (element 360) and computing device S (element 370), which are communicatively coupled to each other as well as to computing device CC (element 350) and computing device(s) DD (elements 380) as shown … The depicted elements are communicatively coupled as shown, i.e., they communicate electronically with each other via at least a respective wired or wireless communication link according to the illustrative embodiment; they may be in direct electronic communication, e.g., via dedicated lines, or may be indirectly connected, e.g., via public and/or private telecommunications network(s) such as a local area network, a private intranet and/or the Internet, without limitation).
Regarding claim 6, Bansod discloses
wherein the software build action result is written to the snapshot storage volume (paragraph [0064]: At block 478, build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art. Thus, the friendly executable or friendly build is designated to have the second version number, corresponding to the second version of the software base, e.g., version 1.0.1. The friendly executable now comprises the friendly changes in executable form, e.g., working diagnostics, working features, etc.).
Regarding claim 7, Bansod discloses
wherein the software build action result is written to a modification layer of the snapshot storage volume (paragraph [0044]: the component implementing the snapshot management software layer (e.g., the given build-node on computing device S) may derive a set of pointers and/or data that represents the snapshot.; paragraph [0064]: At block 478, build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art. Thus, the friendly executable or friendly build is designated to have the second version number, corresponding to the second version of the software base, e.g., version 1.0.1. The friendly executable now comprises the friendly changes in executable form, e.g., working diagnostics, working features, etc.).
Regarding claim 8, Bansod discloses
A method comprising:
receiving, by a build server, a software build workflow comprising a software build action (paragraph [0036]: System 300 comprises: storage array A (element 360) and computing device S (element 370), which are communicatively coupled to each other as well as to computing device CC (element 350) and computing device(s) DD (elements 380) as shown … The depicted elements are communicatively coupled as shown, i.e., they communicate electronically with each other via at least a respective wired or wireless communication link according to the illustrative embodiment; they may be in direct electronic communication, e.g., via dedicated lines; paragraph [0059]: At block 462, storage array A receives the transfer of the software base, i.e., a first version of the software base that is illustratively designated version 1.0.0; paragraph [0060]: Computing device S is illustratively configured with a plurality of build-nodes BN1-BNn, each build-node comprising at least one processor-core on computing device S);
booting, by the build server, a virtual machine (VM) (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines):
mounting, by the VM, a snapshot storage volume (paragraph [0050]: system 300 requires only one initial mounting of a given hardware snapshot volume (on storage array A at 471) to a corresponding build-node (on friendly build machine computing device S) when the working copy of the software base is first propagated to system 300) storing a set of build dependencies (paragraph [0036]: FIG. 3 depicts some salient portions of a system 300 for efficient propagation of a software base and for enabling more efficient informal/friendly software builds; paragraph [0041]: a snapshot may be thought of as an instant image of data at a given point in time (e.g., a volume such as a volume comprising official software base 352));
executing, by the VM, a software build workflow (paragraph [0061]: At block 472, the respective build-node on computing device S, illustratively build-node BNn, is available for use to generate a friendly build; paragraph [0063]: build-node BNn incorporates friendly changes into the software base, as received from block 484 on computing device DD) using the set of build dependencies stored within the snapshot storage volume (paragraph [0036]: FIG. 3 depicts some salient portions of a system 300 for efficient propagation of a software base and for enabling more efficient informal/friendly software builds; paragraph [0041]: a snapshot may be thought of as an instant image of data at a given point in time (e.g., a volume such as a volume comprising official software base 352)); and
producing a software build action result of the software build action (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block); and
returning the software build action result as an output of the software build workflow (paragraph [0064]: Once the friendly executable has been built, computing device S transmits it electronically to computing device DD, where it is received at block 486).
In particular, Bansod discloses modifying the software base (i.e., the build dependencies) during the execution of the software build workflow (Bansod paragraph [0063]: build-node BNn incorporates friendly changes into the software base; paragraph [0081]: the build-node incorporates the received friendly changes into the software base, which results in a changed software base of a different (second) version).
Bansod does not explicitly disclose writing, to an overlay snapshot storage volume, a difference between the set of build dependencies in the snapshot storage volume and the set of build dependencies as modified during execution of the software build workflow. Chen discloses writing, to an overlay snapshot storage volume, a difference between the set of build dependencies in the snapshot storage volume and the set of build dependencies as modified (paragraph [0022]: The present embodiments relate in one aspect to a snapshot of a thinly provisioned volume or other logical data construct, which snapshot comprises metadata relating to changed parts of the address range only in relation to an ancestor; paragraph [0023]: the snapshot comprising a mapping table and memory values of the volume… which values entered differ from an ancestor of the snapshot; paragraph [0059]: each device 105 is enabled to send difference data at a Point in Time (PiT) since the last snapshot was taken… Remote system 110 is enabled to receive difference data in message 130 and build hierarchical snapshot tree 120; Note: A snapshot volume that stores only the “changed parts” or “difference data” relative to an ancestor/base snapshot is the functional definition of an overlay snapshot storage volume).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the software build system of Bansod to utilize the hierarchical snapshot storage mechanism of Chen, such that when the software base is modified during the execution of the software build workflow (as in Bansod), the system writes only the difference between the original data and the modified data to an overlay snapshot storage volume (as in Chen). The motivation would have been to significantly reduce storage space requirements and improve system efficiency by only saving the incremental data changes (deltas) generated during the software build workflow, rather than duplicating the entire software base for every friendly build (Chen paragraphs [0022], [0075]).
Regarding claim 15 referring to claim 8, Bansod discloses A system comprising: at least one processor; and a non-transitory computer-readable medium, operatively coupled to the at least one processor, the non-transitory computer-readable medium storing computer executable instructions that, when executed by the at least one processor, cause the system to perform a method comprising: … (paragraphs [0088] and [0096]).
Regarding claims 9 and 16, Bansod discloses
wherein the set of build dependencies comprises one or more of a compiler, a software library, a minifier, and a bundler (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art).
Regarding claims 10 and 17, Bansod discloses
wherein the software build action result comprises one of compiled object code, bundled interpreted code, and code test results (paragraph [0064]: build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art).
Regarding claims 11 and 18, Bansod discloses
wherein the snapshot storage volume is stored on (paragraph [0040]: Element 360: Storage array A (360) is a storage device and/or system comprising a collection of storage media (preferably high availability disks) that are commonly accessible via a body of software, firmware, and/or hardware that controls and manages the collection; furthermore, according to the illustrative embodiment, storage array A is equipped with so-called hardware snapshot technology) a local physical drive connected to the host computing device (paragraph [0036]: System 300 comprises: storage array A (element 360) and computing device S (element 370), which are communicatively coupled to each other as well as to computing device CC (element 350) and computing device(s) DD (elements 380) as shown … The depicted elements are communicatively coupled as shown, i.e., they communicate electronically with each other via at least a respective wired or wireless communication link according to the illustrative embodiment; they may be in direct electronic communication, e.g., via dedicated lines, or may be indirectly connected, e.g., via public and/or private telecommunications network(s) such as a local area network, a private intranet and/or the Internet, without limitation), the host computing device configured to execute the virtual machine (VM) (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines), .
Regarding claims 12 and 19, Bansod discloses
wherein the snapshot storage volume is stored on (paragraph [0040]: Element 360: Storage array A (360) is a storage device and/or system comprising a collection of storage media (preferably high availability disks) that are commonly accessible via a body of software, firmware, and/or hardware that controls and manages the collection; furthermore, according to the illustrative embodiment, storage array A is equipped with so-called hardware snapshot technology) a remote virtual drive configured to be accessed over a network by a host computing device (paragraph [0036]: System 300 comprises: storage array A (element 360) and computing device S (element 370), which are communicatively coupled to each other as well as to computing device CC (element 350) and computing device(s) DD (elements 380) as shown … The depicted elements are communicatively coupled as shown, i.e., they communicate electronically with each other via at least a respective wired or wireless communication link according to the illustrative embodiment; they may be in direct electronic communication, e.g., via dedicated lines, or may be indirectly connected, e.g., via public and/or private telecommunications network(s) such as a local area network, a private intranet and/or the Internet, without limitation), the host computing device configured to execute the virtual machine (VM) (paragraph [0094]: Various components of the illustrated systems can be implemented in one or more virtual machines), .
Regarding claims 13 and 20, Bansod discloses
wherein the software build action result is written to the snapshot storage volume (paragraph [0064]: At block 478, build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art. Thus, the friendly executable or friendly build is designated to have the second version number, corresponding to the second version of the software base, e.g., version 1.0.1. The friendly executable now comprises the friendly changes in executable form, e.g., working diagnostics, working features, etc.).
Regarding claim 14, Bansod discloses
wherein the software build action result is written to a modification layer of the snapshot storage volume (paragraph [0044]: the component implementing the snapshot management software layer (e.g., the given build-node on computing device S) may derive a set of pointers and/or data that represents the snapshot.; paragraph [0064]: At block 478, build-node BNn on computing device S compiles (or builds) a "friendly executable" that is based on the second version of the software base from the preceding block. Compilers and build tools for this operation are well known in the art. Thus, the friendly executable or friendly build is designated to have the second version number, corresponding to the second version of the software base, e.g., version 1.0.1. The friendly executable now comprises the friendly changes in executable form, e.g., working diagnostics, working features, etc.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
George et al. (US 2023/0359585) discloses the mechanism of writing only the changed data to a new snapshot object (paragraphs [0073]-[0075])..
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 [0037] 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 [0037] 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
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, April Y. Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 09/04/2026
Prosecution Insights