DETAILED ACTION
This action is in response to the claims filed December 28, 2023. Claims 1-20 are pending. Claims 1. 11, and 16 are independent claims.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim 1, the limitations “compare the second version identifier with the third version identifier, wherein the second version identifier matching the third version identifier indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and call under the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional elements “A system for maintaining synchronization of code for a production environment, the system comprising”, “one or more memories”, “one or more processors, communicatively coupled to the one or more memories, configured to”, “from a deployment system”, and “selectively cause, responsive to whether the second version identifier matches the third version identifier, deployment of the codebase in the production environment by the deployment system” are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer, and/or mere computer components. See MPEP 2106.05(f). The additional limitation “receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version identifier associated with a previous codebase that is updated by the codebase” and “retrieve, responsive to the request and from an entry associated with the code repository in a data structure, a third version identifier associated with a current codebase most-recently successfully deployed in the production environment” do nothing more than add the insignificant extra solution activity of merely gathering an transmitting data to the judicial exception. See MPEP 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of “A system for maintaining synchronization of code for a production environment, the system comprising”, “one or more memories”, “one or more processors, communicatively coupled to the one or more memories, configured to”, “from a deployment system”, and “selectively cause, responsive to whether the second version identifier matches the third version identifier, deployment of the codebase in the production environment by the deployment system” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. See MPEP 2106.05(f). For the limitations “receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version identifier associated with a previous codebase that is updated by the codebase” and “retrieve, responsive to the request and from an entry associated with the code repository in a data structure, a third version identifier associated with a current codebase most-recently successfully deployed in the production environment”, the courts have identified mere data gathering and transmitting to be well-understood, routine, and conventional. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. 101.
Claim 2 does not recite additional mental steps. The limitation “wherein the one or more processors, to selectively cause deployment of the codebase, are configured to” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above. The limitation “transmit, to the deployment system and responsive to the second version identifier matching the third version identifier, an indication to deploy the codebase in the production environment” amounts to mere data gathering and transmission, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 3, the limitation “determine whether the codebase is an initial codebase for the code repository” is an additional mental step. The limitation “wherein the one or more processors are further configured to” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 4 does not recite additional mental steps. The limitation “wherein the one or more processors are further configured to: cause deployment of the codebase in the production environment responsive to a determination that the codebase is the initial codebase for the code repository” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 5, the limitation “determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment” is an additional mental step. The limitation “wherein the one or more processors are further configured to” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 6 does not recite additional mental steps. The limitation “wherein the one or more processors, to selectively cause deployment of the codebase, are configured to: cause deployment of the codebase in the production environment responsive to a determination that the code repository is not associated with the pending codebase deployment” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 7 does not recite additional mental steps. The limitation “wherein the one or more processors are further configured to: queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 8 does not recite additional mental steps. The limitation “wherein the one or more processors are further configured to” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above. The limitation “cause, responsive to the second version identifier not matching the third version identifier, transmission of one or more notifications indicating that deployment of the codebase is canceled” amounts to mere data gathering and transmission, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 9 does not recite additional mental steps. The limitation “wherein the one or more processors, to selectively cause deployment of the codebase, are configured to: cause deployment of the codebase in the production environment responsive to the second version identifier matching the third version identifier” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 10, the limitation “wherein the first version identifier, the second version identifier, and the third version identifier are commit hashes” merely further describes the first, second, and third version identifiers of the mental and data gathering steps of claim 1, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 11, the limitations “comparing the second version identifier with the third version identifier, wherein the second version identifier matching the third version identifier indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and call under the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional elements “A method of maintaining synchronization of code for a production environment, comprising”, and “causing, responsive to the second version identifier matching the third version identifier, deployment of the codebase in the production environment” are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer, and/or mere computer components. See MPEP 2106.05(f). The additional limitations “receiving a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version identifier associated with a previous codebase that is updated by the codebase”, and “retrieving, from an entry associated with the code repository in a data structure, a third version identifier associated with a current codebase most-recently successfully deployed in the production environment” do nothing more than add the insignificant extra solution activity of merely gathering an transmitting data to the judicial exception. See MPEP 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of “A method of maintaining synchronization of code for a production environment, comprising”, and “causing, responsive to the second version identifier matching the third version identifier, deployment of the codebase in the production environment” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. See MPEP 2106.05(f). For the limitations “receiving a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version identifier associated with a previous codebase that is updated by the codebase”, and “retrieving, from an entry associated with the code repository in a data structure, a third version identifier associated with a current codebase most-recently successfully deployed in the production environment”, the courts have identified mere data gathering and transmitting to be well-understood, routine, and conventional. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. 101.
Claim 12 does not recite additional mental steps. The limitation “wherein causing deployment of the codebase comprises: transmitting, to a deployment system, an indication to deploy the codebase in the production environment” amounts to mere data gathering and transmission, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Claim 13 does not recite additional mental steps. The limitation “receiving an indication of whether deployment of the codebase in the production environment succeeded or failed” amounts to mere data gathering and transmission, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above. The limitation “updating, responsive to the indication indicating that deployment succeeded, the entry in the data structure to replace the third version identifier with the first version identifier” amounts to merely storing data to memory, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B. See MPEP 2106.05(g) and MPEP 2106.05(d).
Regarding claim 14, the limitations “determining whether the codebase is an initial codebase for the code repository” and “determining, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment” are additional mental steps. The limitation “queueing the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment” and “releasing the codebase from the queue when the code repository is no longer associated with the pending codebase deployment” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 15, the limitation “wherein the entry in the data structure indicates: the code repository, the third version identifier, and a deployment status for the code repository” merely further describes the data structure data structure of the data gathering step of claim 11, which amounts to mere data gathering, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 16, the limitations “compare the second commit hash with the third commit hash, wherein the second commit hash matching the third commit hash indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and call under the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional elements “A non-transitory computer-readable medium storing a set of instructions for maintaining synchronization of code for a production environment, the set of instructions comprising”, “one or more instructions that, when executed by one or more processors of a device, cause the device to”, “from a deployment system”, and “cause, responsive to the second commit hash matching the third commit hash, deployment of the codebase in the production environment” are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer, and/or mere computer components. See MPEP 2106.05(f). The additional limitations “receive, …, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first commit hash associated with the codebase and a second commit hash associated with a previous codebase that is updated by the codebase” and “retrieve, responsive to the request and from a data structure, a third commit hash associated with a current codebase most-recently successfully deployed in the production environment” do nothing more than add the insignificant extra solution activity of merely gathering an transmitting data to the judicial exception. See MPEP 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements of “A non-transitory computer-readable medium storing a set of instructions for maintaining synchronization of code for a production environment, the set of instructions comprising”, “one or more instructions that, when executed by one or more processors of a device, cause the device to”, “from a deployment system”, and “cause, responsive to the second commit hash matching the third commit hash, deployment of the codebase in the production environment” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. See MPEP 2106.05(f). For the limitations “receive, …, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first commit hash associated with the codebase and a second commit hash associated with a previous codebase that is updated by the codebase” and “retrieve, responsive to the request and from a data structure, a third commit hash associated with a current codebase most-recently successfully deployed in the production environment”, the courts have identified mere data gathering and transmitting to be well-understood, routine, and conventional. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. 101.
Claim 17 does not recite additional mental steps. The limitation “wherein the one or more instructions, that cause the device to cause deployment of the codebase, cause the device to:” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above. The limitation “transmit, to a deployment system, an indication to deploy the codebase in the production environment” amounts to mere data gathering and transmission, which is insignificant extra solution activity which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 18, the limitation “generate, responsive to the request, a record for the codebase signifying that the codebase is awaiting deployment” is an additional mental step. The limitation “wherein the one or more instructions, when executed by the one or more processors, further cause the device to” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 19, the limitations “determine whether the codebase is an initial codebase for the code repository” and “determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment” are additional mental steps. The limitations “wherein the one or more instructions, when executed by the one or more processors, further cause the device to” and “queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
Regarding claim 20, the limitation “monitor, in a data structure, a deployment status associated with the code repository” is an additional mental step. The limitations “wherein the one or more instructions, when executed by the one or more processors, further cause the device to” and “release the codebase from the queue responsive to the deployment status changing from a pending status to a non-pending status” amounts to the mere instruction to apply a generic computer/computer component, which does not amount to practical application under Prong 2, nor to significantly more under Step 2B, as discussed above.
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 (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.
Claims 1-2, 8-13, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 11544050 B1 (hereinafter “Ankit”), in view of US 20150026132 A1 (hereinafter “Arnaudov”).
Regarding claim 1, Ankit discloses:
A system for maintaining synchronization of code for a production environment, the system comprising (Abstract):
one or more memories (Fig. 14); and
one or more processors, communicatively coupled to the one or more memories, configured to (Fig. 14):
- receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version [snapshot] associated with a previous codebase that is updated by the codebase (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot”; Column 17, lines 28-42, “In element 911, a SDDS-generated identifier of the patch may be shown, and an identifier of the pipeline and stage(s) to which the patch is directed may be automatically displayed in element 913. …The user may use check boxes shown in the “Select” column of element 915 to specify the environments to which the patch is to be deployed automatically by the PAT, and submit a request to deploy the patch to the selected environments via element 917” [receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version [snapshot] associated with a previous codebase that is updated by the codebase]) [Examiner’s remarks: When requesting to build, a version identifier of the current build is provided, and a pre-build snapshot is retrieved representing the previous codebase version.];
- retrieve, responsive to the request and from an entry associated with the code repository in a data structure, a third version [snapshot] associated with a current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [retrieve, responsive to the request and from an entry associated with the code repository in a data structure, a third version [snapshot] associated with a current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A snapshot of the software state of the target deployment environment (third version snapshot) is acquired which represents the current state of the deployment environment. The current state represents the most recent deployment.];
- compare the second version [snapshot] with the third version [snapshot], wherein the second version [snapshot] matching the third version [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [compare the second version [snapshot] with the third version [snapshot], wherein the second version [snapshot] matching the third version [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A comparison of the second and third snapshots representing the previous version and the current deployment environment may be compared to ensure that the versions match.]; and
- selectively cause, responsive to whether the second version [snapshot] matches the third version [snapshot], deployment of the codebase in the production environment by the deployment system (Column 20, lines 37-43, “After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [selectively cause, responsive to whether the second version identifier matches the third version identifier, deployment of the codebase in the production environment by the deployment system]”) [Examiner’s remarks: The deployment is allowed or disallowed based on the results of the second and third version snapshots matching.].
Ankit discloses second and third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 2, the rejection of claim 1 is incorporated; and Ankit further discloses:
- transmit, to the deployment system and responsive to the second version [snapshot] matching the third version [snapshot], an indication to deploy the codebase in the production environment (Column 20, lines 30-43, “Before deploying the patch to the target environment, in at least some embodiments the SDDS may confirm or verify that the software version set (SVS) of the environment has not changed since the snapshot/representation mentioned in the context of element 1216 was obtained. As such, an automated verification of the validity of the patch for the target deployment environment may be performed in such embodiments. After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [transmit, to the deployment system and responsive to the second version [snapshot] matching the third version [snapshot], an indication to deploy the codebase in the production environment]”).
Ankit discloses second and third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 8, the rejection of claim 1 is incorporated; and Ankit further discloses:
- cause, responsive to the second version [snapshot] not matching the third version [snapshot], transmission of one or more notifications indicating that deployment of the codebase is canceled (Column 3, lines 38-41, “(e) providing dynamically updated notifications regarding the status of various patch related operations (such as builds or deployments)”; Column 20, lines 37-43, “After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS”) [Examiner’s remarks: The deployment is cancelled if the current environment and previous code version don’t match. Ankit allows for notifications of deployment status which may include cancellations of deployments.].
Ankit discloses second and third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 9, the rejection of claim 1 is incorporated; and Ankit further discloses:
- cause deployment of the codebase in the production environment responsive to the second version [snapshot] matching the third version [snapshot] (Column 20, lines 30-43, “Before deploying the patch to the target environment, in at least some embodiments the SDDS may confirm or verify that the software version set (SVS) of the environment has not changed since the snapshot/representation mentioned in the context of element 1216 was obtained. As such, an automated verification of the validity of the patch for the target deployment environment may be performed in such embodiments. After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [cause deployment of the codebase in the production environment responsive to the second version [snapshot] matching the third version [snapshot]]”).
Ankit discloses second and third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 10, the rejection of claim 1 is incorporated; and Ankit further discloses
wherein the first version identifier…are commit hashes (Column 16, lines 4-14, “From the set of code modifications, the user may choose the ones that are to be included in the patch, and the selected commits or modifications may be displayed in region 713 of tab 509. For each commit or modification selected for inclusion in the patch, the following information may be displayed in the depicted embodiment in region 713: the name or identifier of the package to which the commit belongs, the name or identifier of the branch, the identifier of the commit, as well as any commit notes (e.g., comments or annotations explaining the changes made in the commit)”), and the second version [snapshot], and the third version [snapshot] (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot”; Column 17, lines 28-42, “In element 911, a SDDS-generated identifier of the patch may be shown, and an identifier of the pipeline and stage(s) to which the patch is directed may be automatically displayed in element 913. …The user may use check boxes shown in the “Select” column of element 915 to specify the environments to which the patch is to be deployed automatically by the PAT, and submit a request to deploy the patch to the selected environments via element 917”) …
Ankit does not explicitly disclose the second version snapshot, or third version snapshot being commit hashes.
However, Arnaudov discloses commit hashes (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots and using hashes as version identifiers.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “commit hashes”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 11, Ankit discloses:
A method of maintaining synchronization of code for a production environment, comprising (Abstract):
- receiving a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version [snapshot] associated with a previous codebase that is updated by the codebase (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot”; Column 17, lines 28-42, “In element 911, a SDDS-generated identifier of the patch may be shown, and an identifier of the pipeline and stage(s) to which the patch is directed may be automatically displayed in element 913. …The user may use check boxes shown in the “Select” column of element 915 to specify the environments to which the patch is to be deployed automatically by the PAT, and submit a request to deploy the patch to the selected environments via element 917” [receiving a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first version identifier associated with the codebase and a second version [snapshot] associated with a previous codebase that is updated by the codebase]) [Examiner’s remarks: When requesting to build, a version identifier of the current build is provided, and a pre-build snapshot is retrieved representing the previous codebase version.];
- retrieving, from an entry associated with the code repository in a data structure, a third version [snapshot] associated with a current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [retrieving, from an entry associated with the code repository in a data structure, a third version [snapshot] associated with a current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A snapshot of the software state of the target deployment environment (third version snapshot) is acquired which represents the current state of the deployment environment. The current state represents the most recent deployment.];
- comparing the second version [snapshot] with the third version [snapshot], wherein the second version [snapshot] matching the third version [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [comparing the second version [snapshot] with the third version [snapshot], wherein the second version [snapshot] matching the third version [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A comparison of the second and third snapshots representing the previous version and the current deployment environment may be compared to ensure that the versions match.]; and
- causing, responsive to the second version [snapshot] matching the third version [snapshot], deployment of the codebase in the production environment (Column 20, lines 37-43, “After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [causing, responsive to the second version [snapshot] matching the third version [snapshot], deployment of the codebase in the production environment]”) [Examiner’s remarks: The deployment is allowed or disallowed based on the results of the second and third version snapshots matching.].
Ankit discloses second and third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 12, the rejection of claim 11 is incorporated; and Ankit further discloses:
- transmitting, to a deployment system, an indication to deploy the codebase in the production environment (Column 20, lines 30-43, “Before deploying the patch to the target environment, in at least some embodiments the SDDS may confirm or verify that the software version set (SVS) of the environment has not changed since the snapshot/representation mentioned in the context of element 1216 was obtained. As such, an automated verification of the validity of the patch for the target deployment environment may be performed in such embodiments. After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [transmitting, to a deployment system, an indication to deploy the codebase in the production environment]”).
Regarding claim 13, the rejection of claim 11 is incorporated; and Ankit further discloses:
- receiving an indication of whether deployment of the codebase in the production environment succeeded or failed (Column 17, lines 43-51, “After a request to deploy the patch is submitted, interface elements similar to those shown in FIG. 10 may be presented to provide information about the requested deployment(s). Elements 911 and 913 may remain as they were shown in FIG. 9 , but the environments region 1015 may now show a system-generated deployment identifier and deployment status (e.g., “in-progress”, “completed”, etc.) of the patch with respect to each of the environments that were selected for deployment earlier”); and
- updating, responsive to the indication indicating that deployment succeeded, the entry in the data structure to replace the third version [snapshot] with the first version identifier (Column 21, lines 1-5, “A representation or snapshot of the current deployed software version set (i.e., the set of software currently in use) at the target deployment environment of the target stage before the patch build is initiated may be obtained and stored (element 1307) in the depicted embodiment. This snapshot may be referred to as SVS-pre, as it precedes the patch build”) [Examiner’s remarks: When the deployment is successful, the snapshot representing the code of the last successful deployment would be replaced by the current successful deployment.].
Ankit discloses third version snapshots. Ankit does not explicitly disclose the snapshots being version identifiers.
However, Arnaudov discloses version identifiers (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “version identifiers”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 15, the rejection of claim 11 is incorporated; and Ankit further discloses:
- wherein the entry in the data structure indicates: the code repository, the third version identifier, and a deployment status for the code repository (Column 17, lines 43-51, “After a request to deploy the patch is submitted, interface elements similar to those shown in FIG. 10 may be presented to provide information about the requested deployment(s). Elements 911 and 913 may remain as they were shown in FIG. 9 , but the environments region 1015 may now show a system-generated deployment identifier and deployment status (e.g., “in-progress”, “completed”, etc.) of the patch with respect to each of the environments that were selected for deployment earlier”; Column 20, lines 22-26, “A representation or snapshot of a currently-deployed software version set (SVS), referred to as a pre-patch build at a target deployment environment of the patch may be obtained at the SDDS in the depicted embodiment (element 1216)”) [Examiner’s remarks: The data entry may include information regarding the code repository, the deployment status, and a snapshot of the most recently deployed code in the environment.].
Regarding claim 16, Ankit discloses:
A non-transitory computer-readable medium storing a set of instructions for maintaining synchronization of code for a production environment, the set of instructions comprising (Fig. 14):
one or more instructions that, when executed by one or more processors of a device, cause the device to (Fig. 14):
- receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first commit [identifier] associated with the codebase and a second commit [snapshot] associated with a previous codebase that is updated by the codebase (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot”; Column 17, lines 28-42, “In element 911, a SDDS-generated identifier of the patch may be shown, and an identifier of the pipeline and stage(s) to which the patch is directed may be automatically displayed in element 913. …The user may use check boxes shown in the “Select” column of element 915 to specify the environments to which the patch is to be deployed automatically by the PAT, and submit a request to deploy the patch to the selected environments via element 917” [receive, from a deployment system, a request to deploy a codebase of a code repository in a production environment, wherein the request indicates a first commit [snapshot] associated with the codebase and a second commit [snapshot] associated with a previous codebase that is updated by the codebase]) [Examiner’s remarks: When requesting to build, a version identifier of the current build is provided, and a pre-build snapshot is retrieved representing the previous codebase version.];
- retrieve, responsive to the request and from a data structure, a third commit [snapshot] associated with a current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [retrieve, responsive to the request and from a data structure, a third commit [snapshot] associated with a current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A snapshot of the software state of the target deployment environment (third version snapshot) is acquired which represents the current state of the deployment environment. The current state represents the most recent deployment.];
- compare the second commit [snapshot] with the third commit [snapshot], wherein the second commit [snapshot] matching the third commit [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment (Column 9, lines 34-48, “In at least some embodiments, to ensure that a patch is not deployed to an environment that has changed during the time since the patch workflow began or the time since the patch build was requested, a snapshot representing a record of the software state of the target deployment environment may be obtained at a PAT 128, e.g., just prior to the request of the build. Such a snapshot may indicate the currently-deployed software version set in use at the target deployment environment prior to the build. The pre-build snapshot may be used by the PAT, before deploying the patch produced by a successful build, to verify that the deployed software version set has not changed in the interim in at least some embodiments—e.g., a new snapshot of the environment's software state may be created and compared with the pre-build snapshot [compare the second commit [snapshot] with the third commit [snapshot], wherein the second commit [snapshot] matching the third commit [snapshot] indicates that the previous codebase is the current codebase most-recently successfully deployed in the production environment]”) [Examiner’s remarks: A comparison of the second and third snapshots representing the previous version and the current deployment environment may be compared to ensure that the versions match.]; and
- cause, responsive to the second commit [snapshot] matching the third commit [snapshot], deployment of the codebase in the production environment (Column 20, lines 37-43, “After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [cause, responsive to the second commit [snapshot] matching the third commit [snapshot], deployment of the codebase in the production environment]”) [Examiner’s remarks: The deployment is allowed or disallowed based on the results of the second and third version snapshots matching.].
Ankit discloses a first identifier and second and third commit snapshots. Ankit does not explicitly disclose the identifiers or snapshots being hashes.
However, Arnaudov discloses hashes (Paragraph [0001], “In computer systems, a snapshot may be used to preserve a state of a system at a particular point in time”; Paragraph [0015], “For example, when a snapshot is created based on the virtual storage 151, the data contained in the virtual storage 151 may be processed by the hash-based snapshot module 143 into hash codes. The hash codes may then be stored in a snapshot file associated with the snapshot”; Paragraph [0030], “Thus, the hash-based snapshot module 143 may utilize the hash code and the collision count to uniquely identify the data blocks 311-316”) [Examiner’s remarks: Ankit discloses having version snapshots for comparison purposes. Arnaudov discloses taking hashes of file system snapshots and using the hashes as identifiers of data. One of ordinary skill in the art understands that the snapshot of Ankit may be combined with the version identifiers of Arnaudov to use hashed version identifiers of snapshots instead of snapshots.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Arnaudov into the teachings of Ankit to include “hashes”. As stated in Arnaudov, “Thus, the hash version of the snapshot file may be hundreds times smaller than a conventional snapshot file. As a result, the performance of the many snapshot operations, such as the collapsing of a hash-based snapshot, may be better than similar snapshot operations performed on a conventional snapshot” (Paragraph [0015]). Explicitly used hashes of snapshots instead of snapshots makes comparison faster by decreasing the amount of information needing to be compared. Therefore, it would be obvious to one of ordinary skill in the art to combine the version comparison in deployment of Ankit with the hashed snapshots of Arnaudov.
Regarding claim 17, the rejection of claim 16 is incorporated; and Ankit further discloses:
- transmit, to a deployment system, an indication to deploy the codebase in the production environment (Column 20, lines 30-39, “Before deploying the patch to the target environment, in at least some embodiments the SDDS may confirm or verify that the software version set (SVS) of the environment has not changed since the snapshot/representation mentioned in the context of element 1216 was obtained. As such, an automated verification of the validity of the patch for the target deployment environment may be performed in such embodiments. After the verification, the deployment of the patch to the target deployment environment may then be initiated (element 1225). Note that if the software state of the target deployment environment is found to be different than indicated in the earlier representation, in at least some embodiments the deployment of the newly-built patch may be disallowed or prohibited by the SDDS [transmit, to a deployment system, an indication to deploy the codebase in the production environment]”).
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over US 11544050 B1 (hereinafter “Ankit”), in view of US 20150026132 A1 (hereinafter “Arnaudov”), further in view of 20180157478 A1 (hereinafter “Wong”).
Regarding claim 3, the rejection of claim 1 is incorporated; and the combination of Ankit and Arnaudov does not explicitly disclose:
- determine whether the codebase is an initial codebase for the code repository.
However, Wong discloses:
- determine whether the codebase is an initial codebase for the code repository (Paragraph [0006], “In another general aspect, a computer-implemented method can include providing, by a server and to a computing device, source code for a web application included in a source code repository, receiving, by the server and from the computing device, modified source code for a first version of the web application, the modified source code being marked for review, building the first version of the web application, storing the first version of the web application in a version repository, the first version of the web application being designated as a test version, receiving an indication that the first version of the web application is set as an override targeting the first version of the web application for testing in a production environment, and based on receiving an indication that the first version of the web application is approved for deployment [determine whether the codebase is an initial codebase for the code repository]”) [Examiner’s remarks: The first code is determined to be first version of a web application and stored in repository].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wong into the combined teachings of Ankit and Arnaudov to include “determine whether the codebase is an initial codebase for the code repository”. As stated in Wong, “In another example, an update to a web application can fix one or more errors or issues for the web application. The deployment (rollout) of the updated (or new) web application to a production environment (e.g., the public at large) can provide a user with increased functionality and/or corrections for existing problems with the web application” (Paragraph [0002]). Knowing whether a code is the first in the repository allows for quicker deployment, by confirming that there is no dependent code in deployment which may contradict the current code. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code a codebase is the initial codebase.
Regarding claim 4, the rejection of claim 3 is incorporated; and the combination of Ankit and Arnaudov does not explicitly disclose:
- cause deployment of the codebase in the production environment responsive to a determination that the codebase is the initial codebase for the code repository.
However, Wong discloses:
- cause deployment of the codebase in the production environment responsive to a determination that the codebase is the initial codebase for the code repository (Paragraph [0006], “In another general aspect, a computer-implemented method can include providing, by a server and to a computing device, source code for a web application included in a source code repository, receiving, by the server and from the computing device, modified source code for a first version of the web application, the modified source code being marked for review, building the first version of the web application, storing the first version of the web application in a version repository, the first version of the web application being designated as a test version, receiving an indication that the first version of the web application is set as an override targeting the first version of the web application for testing in a production environment, and based on receiving an indication that the first version of the web application is approved for deployment [cause deployment of the codebase in the production environment responsive to a determination that the codebase is the initial codebase for the code repository]”) [Examiner’s remarks: The first code is determined to be first version of a web application and stored in repository and confirmed for deployment.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wong into the combined teachings of Ankit and Arnaudov to include “cause deployment of the codebase in the production environment responsive to a determination that the codebase is the initial codebase for the code repository”. As stated in Wong, “In another example, an update to a web application can fix one or more errors or issues for the web application. The deployment (rollout) of the updated (or new) web application to a production environment (e.g., the public at large) can provide a user with increased functionality and/or corrections for existing problems with the web application” (Paragraph [0002]). Knowing whether a code is the first in the repository allows for quicker deployment, by confirming that there is no dependent code in deployment which may contradict the current code. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code a codebase is the initial codebase.
Claims 5-7, 14, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11544050 B1 (hereinafter “Ankit”), in view of US 20150026132 A1 (hereinafter “Arnaudov”), further in view of 20180157478 A1 (hereinafter “Wong”), and further in view of US 20140013315 A1 (hereinafter “Genevski”).
Regarding claim 5, the rejection of claim 3 is incorporated; and the combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment.
However, Genevski discloses:
- determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Genevski checks whether this is a currently overlap in deployment requests to an environment.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update.
Regarding claim 6, the rejection of claim 5 is incorporated; and the combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- cause deployment of the codebase in the production environment responsive to a determination that the code repository is not associated with the pending codebase deployment.
However, Genevski discloses:
- cause deployment of the codebase in the production environment responsive to a determination that the code repository is not associated with the pending codebase deployment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”; Paragraph [0045], “If it is determined that the set of components affected by the deployment of the next version of the component and the one or more sets of components affected by the currently processed deployment of the other components does not overlap, at 570 the next version of the software component is deployed in the cloud environment”) [Examiner’s remarks: Code is deployed instead of scheduled when there are no overlapping deployments.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “cause deployment of the codebase in the production environment responsive to a determination that the code repository is not associated with the pending codebase deployment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update.
Regarding claim 7, the rejection of claim 5 is incorporated; and the combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment.
However, Gevenski discloses:
- queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Code is placed into a sequence (queue) if there are overlapping components in the request.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update.
Regarding claim 14, the rejection of claim 11 is incorporated; and the combination of Ankit and Arnaudov does not explicitly disclose:
- determining whether the codebase is an initial codebase for the code repository;
- determining, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment;
- queueing the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment; and
- releasing the codebase from the queue when the code repository is no longer associated with the pending codebase deployment.
However, Wong discloses:
- determining whether the codebase is an initial codebase for the code repository (Paragraph [0006], “In another general aspect, a computer-implemented method can include providing, by a server and to a computing device, source code for a web application included in a source code repository, receiving, by the server and from the computing device, modified source code for a first version of the web application, the modified source code being marked for review, building the first version of the web application, storing the first version of the web application in a version repository, the first version of the web application being designated as a test version, receiving an indication that the first version of the web application is set as an override targeting the first version of the web application for testing in a production environment, and based on receiving an indication that the first version of the web application is approved for deployment [determining whether the codebase is an initial codebase for the code repository]”) [Examiner’s remarks: The first code is determined to be first version of a web application and stored in repository].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wong into the combined teachings of Ankit and Arnaudov to include “determining whether the codebase is an initial codebase for the code repository”. As stated in Wong, “In another example, an update to a web application can fix one or more errors or issues for the web application. The deployment (rollout) of the updated (or new) web application to a production environment (e.g., the public at large) can provide a user with increased functionality and/or corrections for existing problems with the web application” (Paragraph [0002]). Knowing whether a code is the first in the repository allows for quicker deployment, by confirming that there is no dependent code in deployment which may contradict the current code. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code a codebase is the initial codebase.
The combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- determining, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment;
- queueing the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment; and
- releasing the codebase from the queue when the code repository is no longer associated with the pending codebase deployment.
However, Genevski discloses:
- determining, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Genevski checks whether this is a currently overlap in deployment requests to an environment.];
- queueing the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Code is placed into a sequence (queue) if there are overlapping components in the request.]; and
- releasing the codebase from the queue when the code repository is no longer associated with the pending codebase deployment (Paragraph [0046], “Alternatively, if it is determined that the set of components affected by the deployment of the next version of the component and the one or more sets of components affected by the currently processed deployment of the other components overlap, at 560, deployment of the next version of the software component is postponed until the deployment of the another component is processed. Thus, the deployment of the next version of the software component may be postponed until overlapping requests are processed”) [Examiner’s remarks: Code is held back from deployment (in queue) until overlapping (pending) code is processed.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “determining, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment”, “queueing the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment”, and “releasing the codebase from the queue when the code repository is no longer associated with the pending codebase deployment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update.
Regarding claim 18, the rejection of claim 16 is incorporated; and the combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- generate, responsive to the request, a record for the codebase signifying that the codebase is awaiting deployment.
However, Genevski discloses:
- generate, responsive to the request, a record for the codebase signifying that the codebase is awaiting deployment (Paragraph [0047], “Another queue may be a quarantine queue that keeps or refers to components under quarantine. To illustrate with reference to FIG. 4, if a request to deploy component ‘B’ 420 is received, component ‘B’ 420 is added to the scheduler queue and components ‘A’ 410, ‘B’ 420, and ‘C’ 430 are added to the quarantine queue since components ‘A’ 410, ‘B’ 420, and ‘C’ 430 constitute the set of components affected by the deployment of component ‘B’ 420”) [Examiner’s remarks: a record (quarantine queue, scheduler queue) indicates codebases which are awaiting deployment.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “generate, responsive to the request, a record for the codebase signifying that the codebase is awaiting deployment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Keeping track of what has and hasn’t been deployed ensures that code can efficiently deploy with less direct human intervention. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with records of deployment.
Regarding claim 19, the rejection of claim 16 is incorporated; and the combination of Ankit and Arnaudov does not explicitly disclose:
- determine whether the codebase is an initial codebase for the code repository;
- determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment; and
- queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment.
However, Wong discloses:
- determine whether the codebase is an initial codebase for the code repository (Paragraph [0006], “In another general aspect, a computer-implemented method can include providing, by a server and to a computing device, source code for a web application included in a source code repository, receiving, by the server and from the computing device, modified source code for a first version of the web application, the modified source code being marked for review, building the first version of the web application, storing the first version of the web application in a version repository, the first version of the web application being designated as a test version, receiving an indication that the first version of the web application is set as an override targeting the first version of the web application for testing in a production environment, and based on receiving an indication that the first version of the web application is approved for deployment [determine whether the codebase is an initial codebase for the code repository]”) [Examiner’s remarks: The first code is determined to be first version of a web application and stored in repository].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Wong into the combined teachings of Ankit and Arnaudov to include “determine whether the codebase is an initial codebase for the code repository”. As stated in Wong, “In another example, an update to a web application can fix one or more errors or issues for the web application. The deployment (rollout) of the updated (or new) web application to a production environment (e.g., the public at large) can provide a user with increased functionality and/or corrections for existing problems with the web application” (Paragraph [0002]). Knowing whether a code is the first in the repository allows for quicker deployment, by confirming that there is no dependent code in deployment which may contradict the current code. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code a codebase is the initial codebase.
The combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment; and
- queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment.
However, Genevski discloses:
- determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Genevski checks whether this is a currently overlap in deployment requests to an environment.]; and
- queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment (Paragraph [0025], “In one embodiment, deployment requests may be frequently and concurrently sent. Thus, numerous deployment requests may be processed at the same time. To schedule the deployment of the next version of the software component, it is determined if there are deployment requests that are currently processed. And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected. Based on the dependency analysis, it is determined whether the currently processed deployment requests overlap with the deployment request of the next version. If there are overlapping requests, the deployment of the next version of the software component is postponed until such requests are processed.”) [Examiner’s remarks: Code is placed into a sequence (queue) if there are overlapping components in the request.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “determine, responsive to a determination that the codebase is not the initial codebase for the code repository, whether the code repository is associated with a pending codebase deployment in the production environment” and “queue the codebase in a queue responsive to a determination that the code repository is associated with the pending codebase deployment”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update.
Regarding claim 20, the rejection of claim 19 is incorporated; and the combination of Ankit, Arnaudov, and Wong does not explicitly disclose:
- monitor, in a data structure, a deployment status associated with the code repository; and
- release the codebase from the queue responsive to the deployment status changing from a pending status to a non-pending status.
However, Gevenski discloses:
- monitor, in a data structure, a deployment status associated with the code repository (Paragraph [0047], “Another queue may be a quarantine queue that keeps or refers to components under quarantine. To illustrate with reference to FIG. 4, if a request to deploy component ‘B’ 420 is received, component ‘B’ 420 is added to the scheduler queue and components ‘A’ 410, ‘B’ 420, and ‘C’ 430 are added to the quarantine queue since components ‘A’ 410, ‘B’ 420, and ‘C’ 430 constitute the set of components affected by the deployment of component ‘B’ 420. If a request to deploy component ‘D’ 440 is received next, component ‘D’ 440 is next added to the scheduler queue and components ‘C’ 430 and ‘D’ 440 are added to the quarantine queue since components ‘C’ 430 and ‘D’ 440 constitute the set of components affected by the deployment of component ‘D’ 440. In accordance with process 500, the deployment of component ‘D’ 440 is postponed until component ‘B’ 430 is deployed and components ‘A’ 410, ‘B’ 420, and ‘C’ 430 are released from the quarantine. At 570, process 500 ends with deploying the next version of the software component in the cloud environment”) [Examiner’s remarks: A data structure (quarantine queue) is monitored for the deployment status of a code.]; and
- release the codebase from the queue responsive to the deployment status changing from a pending status to a non-pending status (Paragraph [0047], “Another queue may be a quarantine queue that keeps or refers to components under quarantine. To illustrate with reference to FIG. 4, if a request to deploy component ‘B’ 420 is received, component ‘B’ 420 is added to the scheduler queue and components ‘A’ 410, ‘B’ 420, and ‘C’ 430 are added to the quarantine queue since components ‘A’ 410, ‘B’ 420, and ‘C’ 430 constitute the set of components affected by the deployment of component ‘B’ 420. If a request to deploy component ‘D’ 440 is received next, component ‘D’ 440 is next added to the scheduler queue and components ‘C’ 430 and ‘D’ 440 are added to the quarantine queue since components ‘C’ 430 and ‘D’ 440 constitute the set of components affected by the deployment of component ‘D’ 440. In accordance with process 500, the deployment of component ‘D’ 440 is postponed until component ‘B’ 430 is deployed and components ‘A’ 410, ‘B’ 420, and ‘C’ 430 are released from the quarantine. At 570, process 500 ends with deploying the next version of the software component in the cloud environment”) [Examiner’s remarks: When a component (code) changes from pending to non-pending (moving off the quarantine list), the code is released (deployed).].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Genevski into the combined teachings of Ankit, Arnaudov, and Wong to include “monitor, in a data structure, a deployment status associated with the code repository” and “release the codebase from the queue responsive to the deployment status changing from a pending status to a non-pending status”. As stated in Gevenski, “And also it is determined if the request to deploy the next version of the software component may overlap with the currently processed requests. Overlapping deployment requests are such requests, where once the respective deployments are completed a common set of components may be affected” (Paragraph [0025]). Updating related components independently may cause conflicts between deployed code, leading to bugs. Allowing the code to deploy one at a time allows for controlled updates and better debugging. Therefore, it would be obvious to one of ordinary skill in the art to combine automated deployment with checking if code overlaps with a pending update and delaying updates accordingly.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. - US 20200004518 A1 discloses queues for source code deployment and integration.
- US 20180173510 A1 discloses deployment of one or multiple artifacts to an environment.
- US 20240086183 A1 discloses verification and comparison of software using code identifiers.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191