DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to communication filed 10/7/2025.
The instant application having application No. 18/351,506 filed on July 13, 2023, claims foreign priority to the Chinese application CN202310615518.5 filed on May 29, 2023.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on October 7, 2025 has been entered.
Status of the Claims
Claims 1, 5, 6, 9, 10, 13, 14, 15, and 18 are amended, claims 8 and 17 are canceled. Claims 1-7, 9-16, and 18 are currently pending in the application.
Response to Amendment
(A). Regarding claim objections: Applicant’s amendment to claims appropriately addressed the objection to claim 8 which is incorporated into claim 1, the objection is withdrawn. The objection to claim 10 is maintained because “the version management server”, still lacks antecedent basis.
(B). Regarding 35 U.S.C. § 101 rejection: Amended claims are still abstract idea without significantly more, new ground of rejections to the claims 1-7, 9-16, and 18 under 35 U.S.C. § 101 is presented in the following 101 rejections.
(C). Regarding art rejection: In regards to pending claims Applicant’s arguments are not persuasive; further, Applicant's amendments necessitated new grounds of rejections presented in the following art rejection.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Objections
Claims 1-7 and 9 are objected to because of the following informalities:
Claim 1, lines 11-12, “and inputs version application information”, suggestion: -and to input version application information-.
Claim 1, lines 20-21, “and inputs the configuration data”, suggestion: -and to input the configuration data-.
Claim 1, Line 29, -the memory of the deployment server-
Dependent claims 2-7 and 9 are objected to for the same reason because they depend from claim 1.
Claims 10-18 are objected to because of the following informalities:
Claim 10, line 12, “the version management server”, lacks antecedent basis.
Claims 11-16 and 18 are objected to for the same reason because they depend from claim 10.
Appropriate correction is required.
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-7, 9-16, and 18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
With respect to claim 1, This claim is within at least one of the four categories of patent eligible subject matter as it is directed to a system claim under Step 1.
Under Prong 1, Step 2A:
However, the limitations of claim 1,
“wherein the processor of the development server is configured to execute the version management module to establish a plurality of branches according to a plurality of branch establishing commands …;“
“wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database …;”
“wherein the processor of the development server is further configured to execute the compilation management module to append operation data to the application code to generate an operation application code.”
as drafted, are processes that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components/software. That is, other than reciting generic computer components/software, nothing in the claim elements precludes the steps from practically being performed in the mind. For example, but for the “the processor of the development server is configured to execute the version management module” language, “establish” in the context of this claim encompasses the user manually establish a plurality of branches according to a plurality of branch establishing commands. Similarly, but for the “the processor of the development server is further configured to execute the version management module” language, “convert” in the context of this claim encompasses the user manually convert the configuration code into configuration data corresponding to a development database. And, but for the “the processor of the development server is further configured to execute the compilation management module” language, “append” in the context of this claim encompasses the user manually append operation data to the application code to generate an operation application code. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas under Prong 1 Step 2A
Under Prong 2, Step 2A:
The judicial exception is not integrated into a practical application. The claim recites the following additional elements
“a development server”,
“a version management server”,
“a development database”,
“a processor”,
“a memory”,
“a version management module” and
“… to store a version management module”,
“… inputs version application information corresponding to different branches into the version management server”,
“… wherein the plurality of branches corresponds to different version application information”,
“wherein for each branch, the version management server obtains a corresponding configuration code according to the version application information and inputs the configuration code into the development server”,
“wherein for each branch, the development database stores the configuration data in a corresponding storage block according to an application type and a version category of the configuration data,
wherein the development database stores a plurality of configuration data corresponding to different branches in different storage blocks,
wherein the application program management system further comprises a deployment server, wherein the deployment server is coupled to the version management server and comprises a processor and a memory, wherein the memory of deployment server stores a compilation management module,
wherein the processor of the deployment server is configured to execute the compilation management module to receive a version release command and obtains a corresponding application code by the version management server searching the plurality of configuration data from the development database according to the version release command”
Wherein “a development server”,
“a version management server”,
“a development database”,
“a processor”,
“a memory”,
“a version management module” are cited as generic computer components/software, or merely as a tool to implement the identified abstract idea, do not integrate the judicial exception into a practical application. Refer to MPEP 2106.05(f). the “store” and “input” processes are insignificant extra-solution data retrieval activity, such as data transmitting, according to MPEP 2106.05(g); “… wherein the plurality of branches corresponds to different version application information”, as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h). The “receive” and “obtain” processes are insignificant extra-solution data retrieval activity, such as data gathering, according to MPEP 2106.05(g); thus, not indicative of an integration into a practical application.
Under Step 2B:
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements
“a development server”,
“a version management server”,
“a development database”,
“a processor”,
“a memory”,
“a version management module” that are mere use of generic computer/software to implement the abstract idea, thus, are not an inventive concept. The “store”, “input”, “receive”, and “obtain” processes are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II). “… wherein the plurality of branches corresponds to different version application information”, as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself. See MPEP § 2106.05(h). Accordingly, the claim does not appear to be patent eligible under 35 USC 101.
With respect to claim 10, This claim is within at least one of the four categories of patent eligible subject matter as it is directed to a method claim under Step 1.
This claim recites a method that is disclosed in claim 1 and therefore recites the same abstract idea as claim 1, please see the office action analysis regarding claim 1.
Claim 10 does not recite more additional elements that are not recited in claim 1.
With respect to claims 2 and 11, “wherein the processor of the development server is further configured to execute the version management module to receive application change information, and to store the application change information in a corresponding storage block in the development database according to an application type and a version category in the application change information,
wherein the version management server records a changed item according to the application change information to generate a change record and stores the change record in a corresponding storage block in the version management server according to the application type and the version category” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually record a changed item and generates a change record. The “receive” and “store(s)” are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
With respect to claims 3 and 12, “wherein the change record comprises at least one of a submission record of the application type, the version category, and a code change.” as drafted, is merely indicating a field of use or technological environment in which to apply a judicial exception, and does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h).
With respect to claims 4 and 13, “wherein the memory of the development server further stores a data synchronization module,
wherein the processor of the development server is configured to execute the data synchronization module to output corresponding synchronization information to the version management server according to a synchronization command, which is received,
wherein the version management server finds a corresponding application code according to an application type and a version category of the synchronization information and outputs the application code to the development server,
wherein the processor of the development server is further configured to execute the data synchronization module to convert the application code into a data structure conforming to the development database and then generates synchronization data,
wherein the development database receives the synchronization data and updates a storage block corresponding to the application type and the version category of the synchronization information” Wherein “the memory”, “the processor”, “the development server”, “a data synchronization module”, “the version management server” and “the development database” are cited as generic computer components, do not integrate the judicial exception into a practical application and do not amount to significantly more. The limitation “finds a corresponding application code according to an application type and a version category of the synchronization information” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually find the code according to the provided information. The limitation “converts the application code into a data structure conforming to the development database and then generates synchronization data” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually convert the application code into a data structure conforming to the development database and generate synchronization data. The “output”, “receive” and “update” processes are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
With respect to claims 5 and 14, “wherein the memory of the development server further stores a merge management module,
wherein the processor of the development server is configured to execute the merge management module to receive a first branch merging command and outputs the first branch merging command to the version management module,
wherein the version management server determines whether a plurality of merge application codes corresponding to the first branch merging command can execute a merging process,
when the version management server determines that the plurality of merge application codes belong to codes that can execute the merging process, the version management server performs merging to the plurality of merge application codes and outputs a merged result to the development database.” Wherein “the development server”, “a merge management module”, “the processor”, “the version management server”, “the version manager” and “the development database” are cited as generic computer components, do not integrate the judicial exception into a practical application and do not amount to significantly more. The limitations “determines whether a plurality of merge application codes corresponding to the first branch merging command can execute a merging process”, “determines that the plurality of merge application codes belong to codes that can execute the merging process” and “performs merging to the plurality of merge application codes” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually determine whether a plurality of merge application codes can execute a merging process, or the user can manually perform the merging. The “receive” and “output” processes are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
With respect to claims 6 and 15, “wherein when the version management server determines that the plurality of merge application codes belong to codes that cannot execute the merging process, the version management server outputs a determined result,
wherein the processor of the development server is further configured to execute the merge management module to receive a second branch merging command and outputs the second branch merging command to the version management module,
wherein the version management server determines whether the second branch merging command belongs to a code that can execute the merging process.” Wherein “the version management server”, “the processor”, ” the development server”, “the merge management module” and “the version manager” are cited as generic computer components, do not integrate the judicial exception into a practical application and do not amount to significantly more. The limitations “determines that the plurality of merge application codes belong to codes that cannot execute the merging process”, and “determines whether the second branch merging command belongs to a code that can execute the merging process” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually determine whether a plurality of merge application codes can execute a merging process. The “receive” and “output” processes are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
With respect to claims 7 and 16, “wherein the memory of the development server further stores a user management module and a data management module,
wherein the processor of the development server is configured to execute the user management module to determine whether a current application code conforms to a permission setting according to the permission setting corresponding to the command,
wherein the processor of the development server is configured to execute the data management module to generate an application path according to the branch establishing command and input the application path into the development database,
wherein the development database stores the configuration data in the corresponding storage block according to the application path.” Wherein “the memory”, “the development server”, “a user management module”, “a data management module”, “the processor” and “the development database” are cited as generic computer components, do not integrate the judicial exception into a practical application and do not amount to significantly more. The limitations “determine whether a current application code conforms to a permission setting according to the permission setting corresponding to the command”, and “generate an application path according to the branch establishing command” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually determine whether a current application code conforming to a permission setting, and can manually generate an application path according the command. The “input”, and “store” processes are insignificant extra-solution activities such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
With respect to claims 9 and 18, “further comprising an operation database, wherein the operation database is coupled to the deployment server,
wherein the memory of the deployment server further stores a version release management module,
wherein the processor of the deployment server is configured to execute the version release management module to convert the operation application code into a data structure conforming to the operation database and then generates version release data,
wherein the processor of the development server is further configured to execute the version release management module to input the version release data into the operation database.” Wherein “an operation database”, “the deployment server”, “the memory”, “a version release management module”, and “the processor” are cited as generic computer components, do not integrate the judicial exception into a practical application and do not amount to significantly more. The limitation “convert the operation application code into a data structure conforming to the operation database and then generates version release data” as drafted, is functions that, under its broadest reasonable interpretation, recites the abstract idea of a mental process. The limitation encompasses a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. E.g. the user can manually convert the operation application code into a data structure conforming to the operation database and then generate version release data. The “stores” and “input” processes are insignificant extra-solution activity such as gathering and transmitting data which is recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 9-12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tauber et al. (US 20170372247 A1 – hereinafter Tauber) in view of Cartledge et al. (US 20080307393 A1 – hereinafter Cartledge), DeHaan (US 20100058330 A1-- hereinafter DeHaan) and Karunakaran et al. (US 20210004225 A1 -- hereinafter Karunakaran).
With respect to claim 1 (currently amended), Tauber discloses An application program management system (e.g. Fig. 1A), comprising:
a development server (e.g. Fig. 1A, computing systems 100);
a version management server (e.g. para [0103], “… where at least one of the major release version identifier or the minor release version identifier are centrally managed and maintained by a central server on which the server branch management module is located so that any users need to contact the central server to create or alter such identifiers. …” wherein a central server reads on a version management server) coupled to the development server;
a development database (e.g. Fig. 1A, Code Repository 108) coupled to the development server;
wherein the development server comprises:
a processor, configured to execute programmable instructions (e.g. Fig. 4); and
a memory, connected to the processor, and configured to store a version management module (e.g. Fig. 4),
wherein the processor of the development server is configured to execute the version management module to establish a plurality of corresponding branches [according to a plurality of branch establishing commands] and inputs version application information corresponding to different branches into the version management server (e.g. para [0102], “… The branch management module 104 may create one or more branches off an existing branch at 202A for a software application. In response to the one or more created branches, the information about the one or more branches or the parent branch (e.g., a master branch, a feature branch, a release branch, etc.) off which these one or more branches are created may be updated to reflect the fact that this parent branch now includes these one or more created branches as one or more child branches.” Wherein updating the parent branch reads on inputs version application information into the version manager), wherein the plurality of branches corresponds to different version application information (e.g. para [0047], “… a master branch with a unique master identifier for the release of a software application as well as a plurality of additional branches such as one or more feature branches, one or more release branches, etc. that bifurcate from the master branch.” Also refer to para [0048]);
wherein for each branch, the version management server obtains a corresponding configuration code according to the version application information and inputs the configuration code into the development server (e.g. Fig. 2A, para [0103], “The branch management module 104 may also track and manage artifacts and their corresponding version identifiers at 206A by using, for example, a major release version identifier, a minor release version identifier, a patch version identifier, etc. where at least one of the major release version identifier or the minor release version identifier are centrally managed and maintained by a central server on which the server branch management module is located so that any users need to contact the central server to create or alter such identifiers. …” wherein the central server reads on version management server, and version identifiers read on configuration code. The branch management module which is part of development server tracks the version identifiers indicates the configuration code (version identifiers) is input into the development server);
[wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database] and inputs the configuration data into the development database (e.g. Fig. 2A, after step 214A, the code is input into code repository which suggests that the configuration data is input into development database);
wherein for each branch, the development database stores the configuration data in a corresponding storage block according to an application type and a version category of the configuration data (e.g. Fig. 1A, para [0052], “When a version of a software application is to be released, the branch management module 104 creates and stores a box set 150 that includes a plurality of artifacts 152 in the deployment repository 110 which is further communicably coupled with a continuous deployment dashboard (CDD) 112. …” this paragraph indicates that data is stored according to a version category, wherein the artifacts read on configuration data, also see para [0047]. Para [0060], “… the code repository 108 may, for example, categorize artifacts and store deployment artifacts 102B, one or more quality tests 104B, one or more smoke tests 106B …” this paragraph indicates that artifacts (read on configuration data) are stored according to application types).
wherein the development database stores a plurality of configuration data corresponding to different branches in different storage blocks (e.g. Fig. 1A, para [0052], “ When a version of a software application is to be released, the branch management module 104 creates and stores a box set 150 that includes a plurality of artifacts 152 in the deployment repository 110 which is further communicably coupled with a continuous deployment dashboard (CDD) 112. …” wherein artifacts 152 read on configuration data, and box set 150 read on different storage blocks),
wherein the application program management system further comprises a deployment server, wherein the deployment server is coupled to the version management server and comprises a processor and a memory, wherein the memory of deployment server stores a compilation management module (e.g. Fig. 1A, wherein system 100 reads on the application program management system, the deployment repository 110 and continuous deployment dashboard 112 suggest a deployment server, which is coupled to the branch management modules which suggest version management server, the release management module reads on a compilation management module, refer to para [0070] for detailed functions of the release management module. Fig. 4 shows processor and memory in a computing system suitable for implanting the management system/server.),
wherein the processor of the deployment server is configured to execute the compilation management module to receive a version release command and obtains a corresponding application code by the version management server searching the plurality of configuration data from the development database according to the version release command (e.g. para [0109], “… a release identifier may be identified from one or more release identifiers at 202B for a deployment for a release of a software application.” Wherein the release identifier suggests the version release command. Also see para [0110]. Para [0048], “… The branch management module 104 may track some or all deployable or non-deployable artifacts and function in tandem with the release management module 102 to fill or augment the box set (e.g., 150) to include everything (e.g., artifacts) to support a deployment.” wherein the branch management module 104 suggests a version management server. Para [0112], “… the box set generated at 204B includes the link structures to all artifacts but not the actual copies of any of the artifacts. The generated box set may be stored in the deployment repository 110, while the actual copies of the artifacts referenced by the link structures are stored in the code repository 108 in these embodiments. …” this paragraph indicates that artifacts are searched from code repository which reads on searching the plurality of configuration data from the development database),
Tauber does not appear to explicitly disclose
(wherein the processor of the development server is configured to execute the version management module to establish a plurality of corresponding branches) according to a plurality of branch establishing commands,
wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database;
wherein the processor of the development server is further configured to execute the compilation management module to append operation data to the application code to generate an operation application code.
However, in analogous art, Cartledge discloses
(wherein the processor of the development server is configured to execute the version management module to establish (e.g. para [0023], “… If the directory also does not exist in the central SCM system 50 (i.e., D6 is "no"), then S7 and S8 generate a command to add the directory 70 in the central SCM system 40 and the command is written into the batch file 35, respectively. …” wherein the directory reads on a branch, a command to add the directory reads on a branch establishing command),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Tauber with the invention of Cartledge because it provides techniques for synchronizing code from a plurality of Software Configuration Management (SCM) systems to support concurrent development in multi-SCM system environments. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of synchronizing code from a plurality of Software
Configuration Management (SCM) systems to support concurrent development in multi-SCM system environments as suggested by Cartledge (see [0005-0007]).
Tauber as modified by Cartledge does not appear to explicitly disclose
wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database;
wherein the processor of the development server is further configured to execute the compilation management module to append operation data to the application code to generate an operation application code.;
However, in analogous art, DeHaan discloses
wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database (e.g. Fig. 4, steps 410 and 412. Para [0066], “After location, in 410, the cobbler server 102 can generate a profile 210 for the located configuration template 208. The profile 210 can be configured to associate the software distribution 204 with the located configuration template 208. For example, a user can select profile 210 for installing the software distribution 204 on a target machine 116. In response, the cobbler server 102 can retrieve the configuration template 208 associated with the profile 210 in order to generate a configuration file for the installation process.” wherein the configuration file reads on configuration data).
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 invention of DeHaan because it provides techniques for automatically customizing and configuring the system and software to make it ready for operation. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for automatically customizing and configuring the system and software to make it ready for operation as suggested by DeHaan (see [0002, 0010-0012]).
Tauber as modified by Cartledge and DeHaan does not appear to explicitly disclose
wherein the processor of the development server is further configured to execute the compilation management module to append operation data to the application code to generate an operation application code.;
However, this is taught in analogous art, Karunakaran (e.g. Fig. 4, step 406, “append the proposed block to the working distributed ledger”. Para [0095], “… where the system appends the proposed block to the working distributed ledger. At this stage, the working distributed ledger contains a copy of the master source code plus the commits made by the developer. Accordingly, the working distributed ledger may contain changes that are ready to be merged into the main branch (e.g., the master source code).”).
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 invention of Karunakaran because it provides an efficient and more secure way to provide synchronization of code within the computing environment. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an efficient and more secure way to provide synchronization of code within the computing environment as suggested by Karunakaran (see [0002, 0004]).
With respect to claim 2 (previously presented), Tauber discloses wherein the processor of the development server is further configured to execute the version management module to receive application change information (e.g. para [0092], “… These techniques may thus optionally identify changes, if any, made to a software application or a portion thereof since the last release or commit at 154H. …”), and to store the application change information in a corresponding storage block in the development database according to an application type and a version category in the application change information (e.g. para [0105], “… Artifacts on a common identifier may be branched into a box set at 212A for subsequent software build or deployment. More specifically, an artifact and its version identifier are tracked and updated when there is a change to the artifact. For example, when a user commits or saves the state of the branch the user is on, the branch management module 104 may take a snapshot of the artifacts and store a reference to this snapshot regardless of whether or not the computing system is connected to the server on which the server branch management module is located.” Wherein subsequent software build suggests the application type is application program for the artifacts, and the version identifier and the server branch management module suggest a version category),
wherein the version management server records a changed item according to the application change information to generate a change record and stores the change record in a corresponding storage block in the version management server according to the application type and the version category (e.g. para [0085], “… Some examples of project information that may be generated or retrieved by the information generation and retrieval module 106G may include, for example, change log information, …” para [0106], “… and both the snapshot as well as the newly created or modified second artifact will be merged with the records on the server once the computing system returns online. …” wherein the change log and/or snapshots read on a change record, and merging the snapshots with artifact indicates that the snapshots are stored according to the application type and version category, because the artifacts are stored according to the application type and version category, refer to office action regarding previous limitation).
With respect to claim 3 (original), Tauber discloses wherein the change record comprises at least one of a submission record of the application type, the version category, and a code change (e.g. para [0105], “…an artifact and its version identifier are tracked and updated when there is a change to the artifact. ….” Wherein version identifier reads on the version category).
With respect to claim 9 (currently amended), Tauber as modified by Cartledge, DeHaan and Karunakaran discloses The application program management system according to claim [[8]] 1, Karunakaran further discloses further comprising an operation database, wherein the operation database is coupled to the deployment server (e.g. Fig. 1, the distribute ledgers 162 and/or 122 read on the operation database),
wherein the memory of the deployment server further stores a version release management module (e.g. Fig. 1, the computer readable instructions 160 comprises a version release management module, also see para [0090-0098] where the operations performed by the system suggest a version release management module in the system),
wherein the processor of the deployment server is configured to execute the version release management module to convert the operation application code into a data structure conforming to the operation database and then generates version release data (e.g. Fig. 4, steps 407 and 408),
wherein the processor of the development server is further configured to execute the version release management module to input the version release data into the operation database (e.g. Fig. 4, step 409, append the proposed block to the master distributed ledger).
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 invention of Karunakaran because it provides an efficient and more secure way to provide synchronization of code within the computing environment. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an efficient and more secure way to provide synchronization of code within the computing environment as suggested by Karunakaran (see [0002, 0004]).
With respect to claim 10 (currently amended), it is directed to a method that is disclosed in claim 1, please see the rejections directed to claim 1 above which also cover the limitations recited in claim 10.
With respect to claim 11 (currently amended), it recites same features as claim 2, and is rejected for the same reason.
With respect to claim 12 (original), it recites same features as claim 3, and is rejected for the same reason.
With respect to claim 18, it recites same features as claim 9, and is rejected for the same reason.
Claims 4-6 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Tauber in view of Cartledge, DeHaan and Karunakaran as applied to claims 1 and 10 respectively, in further view of BIRD et al. (US 20220164672 A1 -- hereinafter BIRD) and Mak et al. (US 20170212751 A1 -- hereinafter Mak).
With respect to claim 4 (currently amended), Tauber as modified by Cartledge, DeHaan and Karunakaran discloses The application program management system according to claim 1, Cartledge further discloses wherein the memory of the development server further stores a data synchronization module (e.g. Fig. 1, synchronization agent 30),
wherein the version management server finds a corresponding application code according to an application type and a version category of the synchronization information and outputs the application code to the development server (e.g. Fig. 3A, para [0022], “An embodiment of the method starts with the synchronizing agent 30, at D1 and D2, obtaining source code (e.g., files 60, directories 70, etc.) from both the central SCM system 40 and the foreign SCM system(s) 50. …” wherein the central SCM reads on the version manager, the synchronizing agent is part of development server shown in Fig. 1, and the synchronizing agent obtaining source code from SCMs suggests that the central SCM outputs the application code. para [0025], “In this manner, the synchronization agent 30 is iteratively verifying (e.g., reading) from the list of files 60 and directories 70 from the foreign SCM system 50 source code whether each file is one of: a new directory 70, an existing directory 70, a new file 60, or an existing file 60. …” wherein the directory 70 and files 60 in the foreign SCM are corresponding to the directory 70 and files 60 in the central SCM, directory 70 suggests for certain application or application type, existing or new directory suggests version category. For motivation to combine, please refer to office action regarding claim 1 above),
wherein the processor of the development server is further configured to execute the data synchronization module to convert the application code into a data structure conforming to the development database and then generates synchronization data (e.g. Fig. 3A, S7 generate SCM command to add directory, S10 generate SCM command to add file. For motivation to combine, please refer to office action regarding claim 1 above),
but does not appear to explicitly disclose
wherein the processor of the development server is configured to execute the data synchronization module to output corresponding synchronization information to the version management server according to a synchronization command, which is received,
wherein the development database receives the synchronization data and updates a storage block corresponding to the application type and the version category of the synchronization information.
However, in analogous art, BIRD discloses
wherein the processor of the development server is configured to execute the data synchronization module to output corresponding synchronization information to the version management server according to a synchronization command, which is received (e.g. para [0084], “… The merge conflict tool 606 may recognize a git merge command which finds a common base to combine changes from several branches. The merge conflict tool 606 obtains the changed programs A, B and the common base O (block 704). …” wherein the merge conflict tool 606 reads on the data synchronization module, and the git merge command reads on a synchronization command. para [0082], “… The service 600 includes a version-control component 604 that tracks changes made to the files in a source code repository over time.” Wherein version control component 604 reads on the version management server, the merge conflict tool obtains the changed programs suggests that the merge conflict tool outputs corresponding synchronization information to the version management server such as changed programs, so that the changed programs are obtained),
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 invention of BIRD because it provides an automated system for resolving program merges which saves user’s time and efforts. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an automated system for resolving program merges which saves user’s time and efforts as suggested by BIRD (see [0003, 0005]).
Tauber as modified by Cartledge, DeHaan, Karunakaran and BIRD does not appear to explicitly disclose
wherein the development database receives the synchronization data and updates a storage block corresponding to the application type and the version category of the synchronization information. However, this is taught in analogous art, Mak (e.g. Fig. 3, step 320, para [0037], “… then merge error detection program 114 triggers version control software 110 to proceed with merging child code stream 118 into main code stream 116.” Wherein main code stream 116 reads on the development database. Para [0028], “… As version control software 110 begins, either automatically or as a result of a prompt or trigger from a software developer, to merge child code stream 118 into main code stream 116, merge error detection program 114 detects the beginning of a merge process. In one embodiment, merge error detection program 114 may also detect version control software 110 performing a rebase operation on the child stream just before or as part of the beginning of the merge process, …” para [0028] discloses software type, i.e. child code stream, wherein the child code stream suggests version category).
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 invention of Mak because it provides techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams as suggested by Mak (see [0011]).
With respect to claim 5 (currently amended), Tauber as modified by Cartledge, DeHaan and Karunakaran discloses The application program management system according to claim 1, but does not appear to explicitly disclose wherein the memory of the development server further stores a merge management module,
wherein the processor of the development server is configured to execute the merge management module to receive a first branch merging command and outputs the first branch merging command to the version management module,
wherein the version management server determines whether a plurality of merge application codes corresponding to the first branch merging command can execute a merging process,
when the version management server determines that the plurality of merge application codes belong to codes that can execute the merging process, the version management server performs merging to the plurality of merge application codes and outputs a merged result to the development database.
However, in analogous art, BIRD discloses wherein the memory of the development server further stores a merge management module (e.g. Fig. 6 Merge Conflict Tool which serves as both data synchronization and merge management),
wherein the processor of the development server is configured to execute the merge management module to receive a first branch merging command and outputs the first branch merging command to the version management module (e.g. para [0084], “… The merge conflict tool 606 may recognize a git merge command which finds a common base to combine changes from several branches. The merge conflict tool 606 obtains the changed programs A, B and the common base O (block 704). …” wherein a git merge command reads on a first branch merging command. para [0082], “… The service 600 includes a version-control component 604 that tracks changes made to the files in a source code repository over time.” Wherein version control component 604 reads the version manager, the merge conflict tool obtains the changed programs suggests that the merge conflict tool outputs the first branch merging command to the version manager),
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 invention of BIRD because it provides an automated system for resolving program merges which saves user’s time and efforts. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing an automated system for resolving program merges which saves user’s time and efforts as suggested by BIRD (see [0003, 0005]).
Tauber as modified by Cartledge, DeHaan, Karunakaran and BIRD does not appear to explicitly disclose
wherein the version management server determines whether a plurality of merge application codes corresponding to the first branch merging command can execute a merging process,
when the version management server determines that the plurality of merge application codes belong to codes that can execute the merging process, the version management server performs merging to the plurality of merge application codes and outputs a merged result to the development database.
However, in analogous art, Mak discloses
wherein the version management server determines whether a plurality of merge application codes corresponding to the first branch merging command can execute a merging process (e.g. para [0032], “If merge error detection program 114 determines there are un-reviewed software development activities in the child stream that contain a file with the missing changes (“yes” branch, decision block 309), then merge error detection program 114 flags the conflicts (step 310). …”),
when the version management server determines that the plurality of merge application codes belong to codes that can execute the merging process, the version management server performs merging to the plurality of merge application codes and outputs a merged result to the development database (e.g. para [0037], “… If merge error detection program 114 does not detect any potential merge errors, then merge error detection program 114 triggers version control software 110 to proceed with merging child code stream 118 into main code stream 116.” Wherein the main code stream reads on the development database).
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 invention of Mak because it provides techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams as suggested by Mak (see [0011]).
With respect to claim 6 (currently amended), Tauber as modified by Cartledge, DeHaan, Karunakaran, BIRD and Mak discloses The application program management system according to claim 5, Mak further discloses wherein when the version management server determines that the plurality of merge application codes belong to codes that cannot execute the merging process, the version management server outputs a determined result (e.g. Fig. 3, step 316 and 318, for motivation to combine, please refer to office action regarding claim 5 above),
wherein the version management server determines whether the second branch merging command belongs to a code that can execute the merging process (e.g. para [0032], “If merge error detection program 114 determines there are un-reviewed software development activities in the child stream that contain a file with the missing changes (“yes” branch, decision block 309), then merge error detection program 114 flags the conflicts (step 310). …” for motivation to combine, please refer to office action regarding claim 5 above).
Bird further discloses
wherein the processor of the development server is further configured to execute the merge management module to receive a second branch merging command and outputs the second branch merging command to the version management module (e.g. para [0084], “… The merge conflict tool 606 may recognize a git merge command which finds a common base to combine changes from several branches. The merge conflict tool 606 obtains the changed programs A, B and the common base O (block 704). …” wherein a git merge command reads on a first branch merging command. para [0082], “… The service 600 includes a version-control component 604 that tracks changes made to the files in a source code repository over time.” Wherein version control component 604 reads the version manager, the merge conflict tool obtains the changed programs suggests that the merge conflict tool outputs the first branch merging command to the version manager. For motivation to combine, please refer to office action regarding claim 5 above).
With respect to claim 13 (currently amended), it recites same features as claim 4, and is rejected for the same reason.
With respect to claim 14 (currently amended), it recites same features as claim 5, and is rejected for the same reason.
With respect to claim 15 (currently amended), it recites same features as claim 6, and is rejected for the same reason.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Tauber in view of Cartledge, DeHaan and Karunakaran as applied to claims 1 and 10 respectively, in further view of Mak and Bandaru et al. (US 20230393825 A1 -- hereinafter Bandaru).
With respect to claim 7 (previously presented), Tauber as modified by Cartledge, DeHaan and Karunakaran discloses The application program management system according to claim 1, Cartledge further discloses wherein the memory of the development server further stores [a user management module] and a data management module,
wherein the processor of the development server is configured to execute the data management module to generate an application path according to the branch establishing command and input the application path into the development database (e.g. para [0023], “… If the directory also does not exist in the central SCM system 50 (i.e., D6 is "no"), then S7 and S8 generate a command to add the directory 70 in the central SCM system 40 and the command is written into the batch file 35, respectively. …” wherein generating a command to add the directory suggests a data management module. for motivation to combine, please refer to office action regarding claim 1),
but does not appear to explicitly disclose wherein the memory of the development server further stores a user management module and (a data management module),
wherein the processor of the development server is configured to execute the user management module to determine whether a current application code conforms to a permission setting according to the permission setting corresponding to the command,
wherein the development database stores the configuration data in the corresponding storage block according to the application path.
However, in analogous art, Mak discloses
wherein the development database stores the configuration data in the corresponding storage block according to the application path (e.g. Fig. 3, step 320, para [0037], “… then merge error detection program 114 triggers version control software 110 to proceed with merging child code stream 118 into main code stream 116.” Wherein main code stream 116 reads on the development database. The merge includes the created directory as taught by Cartledge above, the created directory reads on configuration data).
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 invention of Mak because it provides techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for reducing the risk of unintentional changes being introduced to the main source stream during a stream merge by automatically detecting potential merge issues or errors during the merging of source code streams as suggested by Mak (see [0011]).
Tauber as modified by Cartledge, DeHaan, Karunakaran and Mak does not appear to explicitly disclose wherein the memory of the development server further stores a user management module and (a data management module),
wherein the processor of the development server is configured to execute the user management module to determine whether a current application code conforms to a permission setting according to the permission setting corresponding to the command, However, this is taught in analogous art, Bandaru (e.g. para [0045], “Step 304 includes obtaining approval for the merge request. For example, a notification (e.g., an email) can be sent to the team lead specified in the merge request. Alternatively, or additionally, a notification is sent to a security approver to provide approval for any profiles and/or permission set components related to the components, which act as an access control mechanism. If the changes do not modify profile or permission set files, then a service account can automatically provide the approval in at least some embodiments. ….” Para [0043], “…These steps are assumed to be performed by the software deployment system 105 utilizing at least in part merge request logic 120.” Wherein the merge request logic 120 reads on a user management module, and the software deployment system is analogous to the development server, hence renders the claim feature obvious).
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 invention of Bandaru because it can provide significant advantages relative to conventional software deployment techniques by integrating quality checks before merging code changes which mitigates technical problems associated with deploying large applications to cloud-based computing environments. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of integrating quality checks before merging code changes which mitigates technical problems associated with deploying large applications to cloud-based computing environments as suggested by Bandaru (see [0004]).
With respect to claim 16 (original), it recites same features as claim 7, and is rejected for the same reason.
Response to Arguments
Applicant's arguments regarding 101 and 103 rejections filed 10/7/2025 have been fully considered but they are not persuasive.
At p14 first paragraph of the Remarks, Applicant argued that “… The application program management system is used for data interaction with different servers and database and is therefore not a purely mental activity and cannot be performed in the human brain.”
Examiner respectfully disagrees, because, as set forth in the office action, the servers and the database are cited as generic computer/software components, merely used as tools to implement the identified abstract idea of mental processes.
At p14 second paragraph of the Remarks, Applicant argued that “… the application program management system in this application is actually an Apache Subversion (svn) software version control system, ... These tasks not only involve enormous amounts of data, but the computational logic is also designed for specific server system architecture.”
Examiner respectfully disagrees, because, the tasks cited in the claims are, e.g. reading/retrieving data, storing data, receiving data, and outputting data, these tasks are insignificant extra-solution activities and are recognized as well-understood, routine, and conventional activity, see MPEP § 2106.05(d)(II). As explained in 40, the application program management system including servers and database are merely used as tools to implement abstract idea of mental processes without significantly more.
At p14 last paragraph of the Remarks, Applicant argued that “… the amended claim 1 specifically defines that the development server can establish a plurality of branches according to a plurality of branch establishing commands and inputs version application information corresponding to different branches into the version management server. …. Therefore, the invention of the amended claim 1 has integrated the abstract idea into a practical application and significantly improves the prior art.”
Examiner respectfully disagrees, because, as set forth in the office action, and as explained above, the establishing a plurality of branches according to a plurality of branch establishing commands is mental process, i.e. human can manually perform the task. Inputting data/information, storing data, receiving command, obtaining code by searching database are insignificant extra-solution activities such as reading and storing data, gathering and transmitting data which are recognized as well-understood, routine, and conventional activities, see MPEP § 2106.05(d)(II). The servers and database are merely used as tools to implement abstract idea of mental processes, do not integrate the identified abstract idea into a practical application.
At p15 first full paragraph of the Remarks, Applicant argued that “…, the amended claim 1 specifically defines the application program management system can efficiently record configuration data of different versions of the application program, …, thereby improving the execution efficiency of application program.”
Examiner respectfully disagrees, because, as set forth in the office action, recording configuration data is mental process. use of the application program management system with a unified management portal may improve execution efficiency, but the improved execution efficiency is the benefit of the using the system/computer, it does not improve technology, the system/computer is merely used as a tool to implement the identified abstract idea, does not amount to significantly more.
At p15 second full paragraph of the Remarks, Applicant argued that “… at least the features of "the compilation management module obtaining a corresponding application code by the version management server searching the plurality of configuration data from the development database according to the version release command; and the compilation management module appending operation data to the application code to generate an operation application code" recited in the amended claim 1 are not disclosed by prior art, and can improve upon the prior art.”
Examiner respectfully disagrees, because, as set forth in the office action, obtaining and searching data from a database is insignificant extra-solution activities such as reading data from storage/database and is recognized as well-understood, routine, and conventional activities, see MPEP § 2106.05(d)(II). Appending operation data to the application code is mental process, i.e. human can manually perform the appending task. The compilation management module and the database are cited as generic computer/software components to implement the identified abstract idea, do not amount to significantly more.
At p15 last two paragraphs of the Remarks, Applicant argued that “… the proposed amended claim 1 should include additional elements that are sufficient to amount to significantly more than the judicial exception.” And “… withdrawal of the rejections under 35 U.S.C.101 is respectfully requested.”
Examiner respectfully disagrees, because, as explained, and as set forth in the office action, the additional elements are either insignificant extra-solution activities which are recognized as well-understood, routine, and conventional activities; or generic computer/software components merely used as tools to implement the identified abstract idea, do not amount to significantly. Thus, the rejections under 35 U.S.C.101 are maintained.
At p17 last full paragraph to p18 first paragraph of the Remarks, Applicant argued that “Tauber only teaches that the branch management module may create a plurality of version identifiers of a plurality of artifacts for track and manage the artifacts, but the Tauber does not teach the identifiers can further use to record different version application information and different configuration codes corresponding different application program versions. …” and “Therefore, the applicant respectfully submits that Tauber fails to disclose the feature "wherein the processor of the development server is configured to execute the version management module to establish a plurality of branches according to a plurality of branch establishing commands and inputs version application information corresponding to different branches into the version management server, wherein the plurality of branches corresponds to different version application information" as recited in amended claim 1. ….”
Examiner respectfully disagrees, because, as set forth in the office action above, para [0102] of Tauber as cited in the office above, teaches creating branches for software application, wherein the branches suggest different versions; and updating the branches to reflect the fact, wherein updating the branches reads on “inputs version application information corresponding to different branches into the version management server”. para [0047-0048] of Tauber as cited in the office action above further teaches the plurality of branches corresponding to different version application information. Thus Tauber teaches the limitation “wherein the processor of the development server is configured to execute the version management module to establish a plurality of branches according to a plurality of branch establishing commands and inputs version application information corresponding to different branches into the version management server, wherein the plurality of branches corresponds to different version application information” as recited in amended claim 1.
At p18 last paragraph and p19 first paragraph of the Remarks, Applicant argued that “Moreover, referring to paragraph [0108] of the specification of Tauber, Tauber only teaches the newly created or modified artifacts may be merged into the code repository, …. Tauber does not teach configuration code of claim 1, nor convert a code to configuration data corresponding to the database type. Tauber also does not teach the module stores the configuration data corresponding to the identifier or artifact according to the application type and the version category. In addition, referring to paragraph [0066] of DeHaan, although DeHaan teach the configuration template, but DeHaan does not disclose how to generate the configuration template. DeHaan does not teach the different configuration templates are stored according to the application type and the version category in the database.” And “Therefore, the applicant respectfully submits that Tauber and DeHaan fail to disclose the features “wherein for each branch, the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database and inputs the configuration data into the development database” and “wherein for each branch, the development database stores the configuration data in a corresponding storage block according to an application type and a version category of the configuration data” as recited in amended claim 1. Cartledge, BIRD, Mak, Bandaru, and Karunakaran also does not teach the above features recited in amended claim 1.”
Examiner respectfully disagrees, because, as set forth in the office action above, Fig. 2A, of Tauber illustrates software development and release processes, after step 214A, code is input into code repository, wherein the input code reads on configuration data because it was configured, e.g. a box set for build and deployment. Para [0052] and [0047] of Tauber as cited in the office action above, teach that data is stored according to a version category, and the artifacts (read on configuration data) are stored according to application type. Tauber does not appear to explicitly teach “the processor of the development server is further configured to execute the version management module to convert the configuration code into configuration data corresponding to the development database”, but in analogous art, DeHaan discloses, e.g. para [0066], generating profile for the located configuration template, and the profile can be configured to associate the software distribution with the located configuration template. Wherein the configuration template reads on configuration code, and the profile reads on the configuration data. Thus, the combination of Tauber and DeHaan teaches the claim features under discussion.
At p19 last full paragraph of the Remarks, Applicant argued that “The applicant explains that the SCM of Tauber only use to handle file-level or branch-level management, which is a relatively coarse scope. Different form Tauber, the invention of claim 1 utilizes the dual dimensions of application type and version category for store configuration data, …, going beyond the scope of traditional SCM.”
Examiner respectfully disagrees, because, as set forth in the office action above, Tauber teaches using version category to store configuration data, e.g. Fig. 1A, para [0052]l and storing configuration data according to application type, e.g. para [0047] as cited in the office action above.
At p19 last paragraph of the Remarks, Applicant argued that “Karunakaran only teach can search the latest version of the source code. However, the invention of claim 1 is not limited to searching for the latest version of the configuration data, but according to the version release command.”
Examiner respectfully disagrees, as set forth in the office action above, Tauber is cited for teaching searching configuration data according to version release command, e.g. para [0109-0110] as cited in the office action above.
At p20 first full paragraph of the Remarks, Applicant argued that “Therefore, the applicant respectfully submits that Karunakaran fail to disclose the features “wherein the processor of the deployment server is configured to execute the compilation management module to receive a version release command and obtains a corresponding application code by the version management server searching the plurality of configuration data from the development database according to the version release command” as recited in amended claim 1. Tauber, DeHaan Cartledge, BIRD, Mak, and Bandaru also does not teach the above features recited in amended claim 1.”
Examiner respectfully disagrees, because, as explained in 56 and 58, Tauber teaches the claim feature under discussion.
At p20 second full paragraph of the Remarks, Applicant argued that “For at least the evidence and reasons submitted above, Applicant respectfully submits that Tauber, DeHaan Cartledge, BIRD, Mak, Bandaru, and Karunakaran fail to disclose or suggest the above-mentioned features in claim 1. Thus claim 1 should stand novel, non-obvious, and patentable over the arts of record. Reconsideration and withdrawal of the rejections on claim 1 are respectfully requested.”
Examiner respectfully disagrees, because, as explained above, the cited references teach the claim features in claim 1 under discussion, the claim is rejected.
At p20 last two paragraphs of the Remarks, Applicant argued that the other claims are patentable based on the arguments for claim 1.
Examiner respectfully disagrees, because, as explained above, the cited references teach the claim features under discussion, claim 1 is rejected, all other claims are similarly rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. For example Coscarelli et al. US 20210255854 A1 teaches automated branching workflow for a version control system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zengpu Wei whose telephone number is 571-270-1302. The examiner can normally be reached on Monday to Friday from 8:00AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets, can be reached on 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZENGPU WEI/Examiner, Art Unit 2197