DETAILED ACTION
The Office Action is in response to claims filed 4/4/2024.
Claims 1-20 are pending.
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 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because the claims are directed to a computer readable medium. However, the computer readable medium can be construed to cover a transitory form of signal transmission (often referred to as “signals per se” and thus, the claim does not fall within one of the statutory categories of invention. However, the claim can be amended to fall within one of the statutory categories of invention. Therefore, the claimed system is ineligible subject matter under 101.
Claims 16-20 depend upon claim 15 and does not cure the deficiency of claim 15. Therefore, claims 16-20 are rejected for the same reasons set forth in the rejection of claim 15.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claims 1-20 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claims 1-7 are directed to a system, which is a machine, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites the limitations:
(a) “expect a publish command”
(b) “identify a name of the development branch”
(c) “modify, prior to the publish command, a scope in a metadata file of the branch package with the name of the development branch before the publish command is executed.”
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
(2) the dependency manager comprises at least one processor and memory;
(3) at the automation tool, the at least one processor is configured to cause the dependency manager at least to execute a scope modification routine to:
(4) to publish a branch package for a development branch of main code to the package registry;
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. The limitation (a-c) in the context of the claim encompasses a human expecting a publish command from a computer, identifying software development branches, and modifying files in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to expect a publish command from a computer, identify software development branches, and modify files. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
(2) the dependency manager comprises at least one processor and memory;
(3) at the automation tool
The additional elements (1) to (3) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The dependency manager, package registry, and automation tool are used as a tool to perform the scope modification steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional elements:
(5) publish a branch package for a development branch of main code to the package registry;
The additional element (5) is mere data gathering/transmitting/outputting recited at a high level of generality and thus, are insignificant extra-solution activities. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Also, the claim recites the additional element:
(6) the at least one processor is configured to cause the dependency manager at least to execute a scope modification routine
The additional element (6) merely indicates a field of use or technological environment in which the judicial exception is performed. Although the additional element (6) limits the identified judicial exceptions (a) and (b), however, this type of limitation merely confines the use of the abstract idea to a particular field of use or technological environment and thus, fails to add an inventive concept to the claims. See MPEP § 2106.05(h).
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
(2) the dependency manager comprises at least one processor and memory;
(3) at the automation tool
The additional elements (1) to (3) amount to no more than mere instructions to apply the judicial exception using generic computer components. The analysis under Step 2A, Prong Two is carried through to Step 2B. The use of a computer or other machinery in its ordinary capacity does not integrate a judicial exception into a practical application or provide significantly more.
Also, the claim recites the additional elements:
(5) publish a branch package for a development branch of main code to the package registry;
The additional element (5) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to publish a branch package to a repository. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Also, the claim recites the additional element:
(6) the at least one processor is configured to cause the dependency manager at least to execute a scope modification routine
The additional element (6) merely indicates a field of use or technological environment in which the judicial exception is performed. Although the additional element (6) limits the identified judicial exceptions (a) and (b), however, this type of limitation merely confines the use of the abstract idea to a particular field of use or technological environment and thus, fails to add an inventive concept to the claims. See MPEP § 2106.05(h).
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, only the idea of a solution or outcome, insignificant extra-solution activities, and a field of use or technological environment, and therefore do not provide an inventive concept. The claim is not patent eligible.
Step 1: Claims 8-14 are directed to a method, which is a process (a series of steps or acts), and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 8 recites the limitations:
(a) “expecting a publish command”
(b) “identifying a name of the development branch”
(c) “modifying, prior to the publish command, a scope in a metadata file of the branch package with the name of the development branch before the publish command is executed.”
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
(2) to publish a branch package for a development branch of main code to the package registry;
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. The limitation (a-c) in the context of the claim encompasses a human expecting a publish command from a computer, identifying software development branches, and modifying files in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to expect a publish command from a computer, identify software development branches, and modify files. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
The additional element (1) is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the judicial exception using generic computer components. The dependency manager, package registry, and automation tool are used as a tool to perform the scope modification steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional elements:
(2) publish a branch package for a development branch of main code to the package registry;
The additional element (2) is mere data gathering/transmitting/outputting recited at a high level of generality and thus, are insignificant extra-solution activities. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
The additional element (1) amounts to no more than mere instructions to apply the judicial exception using generic computer components. The analysis under Step 2A, Prong Two is carried through to Step 2B. The use of a computer or other machinery in its ordinary capacity does not integrate a judicial exception into a practical application or provide significantly more.
Also, the claim recites the additional elements:
(2) publish a branch package for a development branch of main code to the package registry;
The additional element (2) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to publish a branch package to a repository. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, only the idea of a solution or outcome, insignificant extra-solution activities, and a field of use or technological environment, and therefore do not provide an inventive concept. The claim is not patent eligible.
Step 1: Claims 15-20 are directed to a computer-readable medium.
Step 2A, Prong One: Claim 15 recites the limitations:
(a) “expecting a publish command”
(b) “identifying a name of the development branch”
(c) “modifying, prior to the publish command, a scope in a metadata file of the branch package with the name of the development branch before the publish command is executed.”
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
(1)A computer readable medium embodying programmed instructions executed by a processor, wherein the instructions direct the processor to implement a method comprising
(2) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
(3) to publish a branch package for a development branch of main code to the package registry;
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. The limitation (a-c) in the context of the claim encompasses a human expecting a publish command from a computer, identifying software development branches, and modifying files in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper to expect a publish command from a computer, identify software development branches, and modify files. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
(1)A computer readable medium embodying programmed instructions executed by a processor, wherein the instructions direct the processor to implement a method comprising
(2) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
The additional elements (1-2) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The dependency manager, package registry, automation tool, processor and memory are used as a tool to perform the scope modification steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional elements:
(3) publish a branch package for a development branch of main code to the package registry;
The additional element (3) is mere data gathering/transmitting/outputting recited at a high level of generality and thus, are insignificant extra-solution activities. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering/transmitting/outputting, and, as such, the additional elements do not impose any meaningful limits on the claim. The additional elements amount to necessary data gathering/transmitting/outputting. See MPEP § 2106.05(g).
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
(1)A computer readable medium embodying programmed instructions executed by a processor, wherein the instructions direct the processor to implement a method comprising
(2) a dependency manager implemented on an automation tool communicatively coupled to a package registry that stores code packages comprising main packages and branch packages;
The additional elements (1-2) amount to no more than mere instructions to apply the judicial exception using generic computer components. The analysis under Step 2A, Prong Two is carried through to Step 2B. The use of a computer or other machinery in its ordinary capacity does not integrate a judicial exception into a practical application or provide significantly more.
Also, the claim recites the additional elements:
(3) publish a branch package for a development branch of main code to the package registry;
The additional element (3) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to publish a branch package to a repository. Therefore, the limitations remain insignificant extra-solution activities even upon reconsideration and do not amount to significantly more.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, only the idea of a solution or outcome, insignificant extra-solution activities, and a field of use or technological environment, and therefore do not provide an inventive concept. The claim is not patent eligible.
Claims 2, 9, and 16 recite an additional limitation “the metadata file comprises a JavaScript Object Notation package file” which describe the files used in the mental process and is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas.
Claims 3, 10, and 17 recite the abstract idea to “expect the publish command” which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas.
The claims further recite additional elements that do not integrate the abstract idea into a practical application. The claims recite the additional element of “at the automation tool” which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). The claims further recite the additional element “when a build process for the development branch advances to a publish phase.” That does no more than generally link a judicial exception to a particular technological environment, which is merely indicating a field of use or technological environment to apply a judicial exception (See MPEP 2106.05(h)). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional elements do not amount to significantly more than the abstract idea. The claims recite the additional element of “at the automation tool” which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). The claims further recite the additional element “when a build process for the development branch advances to a publish phase.” That does no more than generally link a judicial exception to a particular technological environment, which is merely indicating a field of use or technological environment to apply a judicial exception (See MPEP 2106.05(h)). Accordingly, the additional element in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claims 4, 11, and 18 recite the additional limitation “predict an install command… to install one or more dependencies specified for the development branch; and modify, prior to the install command, each dependency of the one or more dependencies in the metadata file to reference a published branch package corresponding with the dependency when a valid published branch package is found in the package registry.” which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas.
The claims recite an additional element that does not integrate the abstract idea into a practical application. The claims recite the additional element “at the automation tool” which is which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional elements do not amount to significantly more than the abstract idea. The claims recite the additional element of “at the automation tool” which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional element in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claims 5, 12, and 19 recite the additional limitation “determine…and predict the install command based on the notification” which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas.
The claims recite additional elements that do not integrate the abstract idea into a practical application. The claims recite the additional element “that the automation tool receives a notification of a commit operation issued to a version control system for the development branch” which is directed to the insignificant extra solution activity of mere data gathering (See MPEP 2106.05(g)). Accordingly, the additional elements cannot integrate the abstract idea into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The claims recite additional elements that does not amount to significantly more than the abstract idea. The claims recite the additional element “that the automation tool receives a notification of a commit operation issued to a version control system for the development branch” which has been determined to be well-known, routine, and/or conventional activity of receiving or transmitting data over a network (See MPEP 2106.05(d)(II)). Accordingly, the additional element in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claims 6, 13, and 20 recite the additional limitation “the modifying each dependency of the one or more dependencies in the metadata file… identifying a dependency name and a version requirement of the dependency; searching the branch registry for a published branch package published with a scoped name that matches the dependency name and matches a branch name of the development branch; determining, when a published branch package is found that matches the dependency name and the branch name of the development branch, whether a version of the published branch package satisfies the version requirement; and modifying, when the version satisfies the version requirement, the dependency name to reference the published branch package.” which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitations fall under the “Mental Processes” group of abstract ideas.
The claims recite additional elements that do not integrate the abstract idea into a practical application. The claims recite the additional element “the package registry comprises a main registry that stores the main packages and a branch registry that stores the branch packages; … for each dependency of the one or more dependencies:” which is which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional element does not amount to significantly more than the abstract idea. The claims recite the additional element “the package registry comprises a main registry that stores the main packages and a branch registry that stores the branch packages; … for each dependency of the one or more dependencies:” which is which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional element in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claims 7 and 14 recite an additional element that does not integrate the abstract idea into a practical application. The claims recite the additional element “retain the dependency name for the dependency when a published branch package is not found that matches the branch name of the development branch and satisfies the version requirement.” which is directed to the insignificant extra solution activity of mere data gathering (See MPEP 2106.05(g)). Accordingly, the additional elements cannot integrate the abstract idea into a practical application because it does not impose any meaningful limits upon practicing the abstract idea.
The additional element does not amount to significantly more than the abstract idea. The claims recite the additional element “retain the dependency name for the dependency when a published branch package is not found that matches the branch name of the development branch and satisfies the version requirement” which has been determined to be well-known, routine, and/or conventional activity of electronic recordkeeping (See MPEP 2106.05(d)(II)). Accordingly, the additional element in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20250208855 A1 hereinafter “Armenta” in view of US 20170052879 A1 hereinafter “Chandra”.
.
With regards to claim 1, Armenta teaches
An apparatus, comprising: a dependency manager implemented on an automation tool (Armenta [0051], “In some embodiments, the service providers (also referred to as service vendors) 401 may be third-party service providers specialized in developing software/applications/services using Continuous Integration and Continuous Deployment (CI/CD) methodologies and deploying them on the cellular network 120 [An apparatus, comprising: a dependency manager]. As a brief example, developers of a service providers 401 may use a version control system to manage source codes of the new application or service, set up repositories and branches to enable code versioning, and configure a selected CI tool to automatically trigger builds when code changes are pushed to the repository [implemented on an automation tool]. Build scripts or configuration files (e.g., YAML) can be generated and defined to specify the required build steps, dependencies, and environment configurations. Unit tests are incorporated into the CI pipeline to verify the correctness and functionality of individual components or units within the new application or new service. Static code analysis tools may be used to analyze code quality, identify potential issues, and enforce coding standards. Once the new application or new service is built, the complied code and any required dependencies may be packaged into an artifact in a deployable format.”) communicatively coupled to a package registry that stores code packages comprising main packages and branch packages; (Armenta [0067], “Database 418 is responsible for storing various data and files [a package registry that stores code] received in and generated by the service management system 402 [communicatively coupled to], including the artifact or upgrade artifact [packages comprising main packages and branch packages], instruction, attribute data, prioritization data (e.g., priority list, priority ranks, etc.), performance criteria data, configuration script, test performance metrics data, real-time performance metrics data, among others.”) [Examiner’s Note: An artifact is described as a packaged and version software component or set of files. Thus, an artifact and an upgrade artifact can be descriptive of main and branch packages (different versions of the same package)]
the dependency manager comprises at least one processor and memory; (Armenta [0092], “According to a set of embodiments, some or all of the operations of such methods are performed by the computer system 700 in response to processor 710 executing one or more sequences of one or more instructions, which might be incorporated into the operating system 760 and/or other code, such as an application program 765, contained in the working memory 735. Such instructions may be read into the working memory 735 from another computer-readable medium, such as one or more of the storage device(s) 725. Merely by way of example, execution of the sequences of instructions contained in the working memory 735 might cause the processor(s) 710 to perform one or more procedures of the methods described herein. Additionally or alternatively, portions of the methods described herein may be executed through specialized hardware.”)
Armenta teaches the at least one processor…to cause the dependency manager does not teach: the at least one processor is configured to cause the dependency manager at least to execute a scope modification routine to:
expect a publish command at the automation tool to publish a branch package for a development branch of main code to the package registry;
identify a name of the development branch;
and modify, prior to the publish command, a scope in a metadata file of the branch package with the name of the development branch before the publish command is executed.
However, in an analogous art Chandra teaches the at least one processor is configured to cause the dependency manager at least to execute a scope modification routine to: (Chandra [0034], “The unified sandbox infrastructure in accordance with one embodiment orchestrates a federated set of component sandboxes. From the user's perspective, there is one overarching sandbox that collects individual changes/customizations made across the various components and allows the user to centrally manage changes. Each pluggable component can each have its own version of a repository (e.g., a metadata repository) and can participate in an orchestrated lifecycle of actions, such create, refresh and publish, within the sandbox. By having multiple customization tools use a common sandbox, customizations that are related can all be published (making them available to all users) together.”)
expect a publish command at the automation tool (Chandra [0041-43], “Federated component sandboxes 312-318 implement a versioning scheme and register to participate in the unified sandbox [at the automation tool]. Unified sandbox orchestration module 326 manages operations defined in a sandbox state model such as, for example, those shown in FIGS. 4 and 8, across the various component sandboxes 312-318 … Create (branch) operation 402 creates a new sandbox with a default configuration (e.g., a sandbox which includes application framework artifacts such as, for example, ADF and ApplCore based changes). Publish operation 404 calls a “publish” action 408 on active sandbox components of the unified sandbox. Components backup their state and attempt to publish the sandbox.”) to publish a branch package for a development branch of main code to the package registry; (Chandra [0084-85], “Life cycle 1200 includes branch, refresh, delete, and publish operations. The branch operation includes creating a working copy for the unified sandbox (this is when copies of customization artifacts are made for isolated updates) [for a development branch of main code]. The refresh operation includes bringing in changes from mainline to the repository (this operation can be repeated as needed) [of main code to the package registry] … The publish operation includes merging the changes in the branch back to mainline. To maintain atomicity of the transaction and minimize merge conflicts, the unified sandbox framework guarantees that: changes from all participating sandboxed repositories are either all committed or all rolled back; sandboxed repository is always refreshed to reflect the latest changes in mainline before it is published; and only one unified sandbox is published at a time (i.e., the publishing of unified sandboxes is synchronized) [to publish a branch package].”)
identify a name of the development branch; (Chandra [0080], “For each sandbox, a branch of the repository is created. When a user is in a sandbox, the copies from the corresponding branch are utilized. A sandboxed repository is a set of customization artifacts that share the same sandboxing and labeling mechanism. A sandboxed repository supports versioning and branching as shown, for example, in FIG. 9.”)
and modify, prior to the publish command, a scope in a metadata file of the branch package with the name of the development branch before the publish command is executed. (Chandra [0081], “FIG. 9 illustrates a sequence diagram 900 of the functionality of versioning and branching supported by a sandbox repository, in accordance with an embodiment of the invention. Versioning refers to the ability to create a version history of the repository and allow access to older versions. Branching refers to the ability to create multiple copies of the repositories for independent updates, and the ability to create new artifacts in these copies. All artifacts in a sandboxed repository share the same label. The unified sandbox framework allows exactly one label to represent a snapshot of all artifacts of a sandboxed repository. This label is used at runtime to identify which versions of customization artifacts make up a state where applications run correctly.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Chandra into the teachings of Armenta. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of creating multiple virtual instances within a repository/database with isolation to make changes for eventual publishing and environment updates (Chandra [0030]).
Claim 8 is directed to a method corresponding to the apparatus limitations as disclosed in claim 1. Thus, claim 8 is rejected for the same reasons set forth in claim 1.
Claim 15 is directed to a computer-readable medium embodying programmed instructions executed by a processor corresponding to the apparatus limitations as disclosed in claim 1. Thus, claim 15 is rejected for the same reasons set forth in claim 1.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Armenta in view of Chandra as applied to claims 1, 8, and 15 above, and further in view of US 20220100480 A1 hereinafter “Makarevich”.
With regards to claim 2, the rejection of claim 1 is incorporated.
The combination of Armenta and Chandra teaches a metadata file but does not teach: the metadata file comprises a JavaScript Object Notation package file.
However, in an analogous art Makarevich teaches the metadata file comprises a JavaScript Object Notation package file. (Makarevich [0050], “The package manager wrapper 120 runs in conjunction with the package manager 108 to implement the enhanced dependency-management functionality described below. In this regard, the present disclosure includes a routine (written in Javascript and executable in the Nodejs runtime environment) that modifies a package's top-level and child package.json files in a way that enables more efficient and flexible dependency management. The developer invokes the routine by entering a command (in the illustrated embodiment named “dependency-update:initialise”) into a CLI that the package manager wrapper 120 provides. The “dependency-update:initialise” command takes one or more dependencies in Semver format (for example <pacakge@version>) as arguments.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Makarevich into the teachings of Armenta in view of Chandra. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra, wherein a metadata file to specify dependencies is written in JavaScript Object Notation. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of enabling a package manager that can allow developers to selectively update dependencies in a package/repository (Makarevich [0071]).
Claim 9 is directed to a method corresponding to the apparatus limitations as disclosed in claim 2. Thus, claim 8 is rejected for the same reasons set forth in claim 2.
Claim 16 is directed to a computer-readable medium embodying programmed instructions executed by a processor corresponding to the apparatus limitations as disclosed in claim 2. Thus, claim 16 is rejected for the same reasons set forth in claim 2.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Armenta in view of Chandra as applied to claims 1, 8, and 15 above, and further in view of US 20090300076 A1 hereinafter “Friedman”.
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Armenta and Chandra does not teach: expect the publish command at the automation tool when a build process for the development branch advances to a publish phase
However, in an analogous art Friedman teaches expect the publish command at the automation tool when a build process for the development branch advances to a publish phase (Friedman [0070-74], “In one implementation, the virtualization environment 120 may further include a build engine 175, which may be configured to build an image of the appliance that the user created, configured, personalized, and/or otherwise developed within the development environment 130 [automation tool when a build process for the development branch] … In one implementation, the build engine 175 may then store the completed build of the appliance image in the appliance repository 180, and the user may be provided with one or more options to interact with the appliance image. For example, names, version numbers, image formats, compressed and uncompressed sizes, build dates, or other information relating to the user's appliance images may be displayed within the user interface 125 [advances to a publish phase]. As such, the user may delete one or more of the images from the appliance repository 180, publish one or more of the images to the appliance marketplace, and/or deploy one or more of the images for execution in one or more runtime environments [expect the publish command].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Friedman into the teachings of Armenta in view of Chandra. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra, and providing the developer with tools to allow for interaction with the build process in a virtual instance to submit and publish changes, as in Friedman. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of managing the virtual application lifecycle in the process of creating, building, configuring, monitoring, and modifying in a user-driven manner (Friedman [0035]).
Claim 10 is directed to a method corresponding to the apparatus limitations as disclosed in claim 3. Thus, claim 10 is rejected for the same reasons set forth in claim 3.
Claim 17 is directed to a computer-readable medium embodying programmed instructions executed by a processor corresponding to the apparatus limitations as disclosed in claim 1. Thus, claim 17 is rejected for the same reasons set forth in claim 1.
Claim(s) 4-5,11-12, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Armenta in view of Chandra as applied to claims 1, 8 and 15 above, and further in view of Friedman and further in view of US 20060288055 A1 hereinafter “Johnson”.
With regards to claim 4, the rejection of claim 1 is incorporated.
The combination of Armenta and Chandra does not teach: predict an install command at the automation tool to install one or more dependencies specified for the development branch;
However, in an analogous art Friedman teaches predict an install command at the automation tool to install one or more dependencies specified for the development branch; (Friedman [0082-84], “In one implementation, the requests may further include criteria for searching the repository database for certain packages, patterns, or other software components that match the search criteria. As such, the request received from the user in operation 240 may identify one or more packages, patterns, or other software to be added to and/or banned from the base virtual appliance [specified for the development branch] … For example, in one implementation, operation 255 may include the dependency resolution service invoking an active resolution daemon to identify any software components that may be dependent, recommended, suggested, and/or conflicting with respect to the selected component [automation tool to]. In particular, the active resolution daemon may scan one or more resolution graphs to identify annotations and/or metadata that explicitly describe dependencies for the component, in addition to any pre-installation scripts, post-installation scripts, and/or content associated with the component to introspectively identify further dependencies (e.g., based on documentation included in the package). Thus, in response to resolving the dependencies for the particular component, operation 255 may include automatically adding any required dependencies to the appliance, and may further include automatically removing any conflicting dependencies from the appliance [install one or more dependencies]. Additionally, in one implementation, any recommended and/or suggested dependencies may be automatically added in operation 255, or the user may optionally be notified of such dependencies to provide the user with control over whether or not to include the recommended and/or suggested dependencies [predict an install command].”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Friedman into the teachings of Armenta in view of Chandra. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra, and providing the developer with tools to allow for interaction with the build process in a virtual instance to submit and publish changes, as in Friedman. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of managing the virtual application lifecycle in the process of creating, building, configuring, monitoring, and modifying in a user-driven manner (Friedman [0035]).
The combination of Armenta, Chandra, and Friedman does not teach: modify, prior to the install command, each dependency of the one or more dependencies in the metadata file to reference a published branch package corresponding with the dependency when a valid published branch package is found in the package registry
However, in an analogous art Johnson teaches modify, prior to the install command, each dependency of the one or more dependencies in the metadata file to reference a published branch package corresponding with the dependency (Johnson [0080-81], “Representing updates as changesets not only saves space and bandwidth, but such an approach may also allow merging. Chances to file contents and changes file metadata, such as permissions, may be intelligently merged, in accordance with some embodiments of the present invention. This capability may be useful for maintaining a branch of an application or library while keeping current with vendor maintenance and/or while adding a couple of patches to meet local needs. Local changes may also be preserved in essentially the same way. When, for example, a few lines are added to a configuration file on an installed system and then a new version of an application is released with changes to that configuration file, the two can be merged unless there is a direct conflict (unusual, but possible). If there is a conflict, it is marked as such so that modifications can be applied. Also, if something as simple as a file's permissions are changed, then those chances will be preserved across upgrades.”) when a valid published branch package is found in the package registry. (Johnson [0173-174], “Moreover, a package may be identified by a version string that encodes the ancestry of the package and/or the component(s)/file(s) that are associated therewith. The tree structure can be searched to select at least a subset of the files to be provisioned at block 1010. According to some embodiments of the present invention, the version string may be used in selecting files for provisioning. For example, the version string may include a label portion that comprises a unique identifier within a domain of use. The various branches of the tree structure may be searched to select files from those branches that are associated with a particular branch name. The order that the development branches are searched may be user-configured using a list of labels that specifies the sequence. In some embodiments, a branch name label may include a tag field that can be associated, for example, with multiple development branches. In this way, files may be selected from a plurality of development branches using this common tag.”) [Examiner’s Note: A library is something that a software component could be dependent upon. Thus, a library is a dependency that can be referenced with file metadata. Furthermore, a package (also described as a dependency could be already published in accordance with prior change tracking ([0171]) and searchable for eventual provisioning using tags and labels]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Johnson into the teachings of Armenta in view of Chandra and further in view of Friedman. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra, and providing the developer with tools to allow for interaction with the build process in a virtual instance to submit and publish changes, as in Friedman, wherein metadata can reference branched/versioned individualized instances of dependency packages, as in Johnson. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of allowing repository-based source code management and package management to allow intelligent branching based on change sets (Johnson [0059]).
With regards to claim 5, the rejection of claim 4 is incorporated.
The combination of Armenta and Chandra does not teach determine that the automation tool receives a notification of a commit operation issued to a version control system for the development branch, and predict the install command based on the notification.
However, in an analogous art Friedman teaches determine that the automation tool receives a notification of a commit operation issued to a version control system for the development branch, and predict the install command based on the notification. (Friedman [0085-86]), “In one implementation, once the user has selected one or more software components to be added to and/or banned from the appliance and any dependencies for the particular components have been resolved, an impact analysis may be performed in an operation 260 to identify any resulting changes to the appliance. For example, operation 260 may include generating a visual notification informing the user of the impact (e.g., displaying a list of packages added to or deleted from the appliance, a data impact on the appliance in terms of megabytes, gigabytes, etc.) [determine that the automation tool receives a notification of a commit operation issued to a version control system]. Additionally, the impact notification may provide the user with one or more undo capabilities and/or error correction capabilities. For example, the undo capabilities may enable the user to remove one or more packages that were added to the appliance, override a ban placed on one or more packages due to a conflicting dependency, override the removal of a package from the appliance due to a conflicting dependency, or otherwise undo one or more changes to the appliance. In addition, if a particular change to an appliance causes an error, inconsistency, or other issue that cannot be resolved automatically, the error correction capabilities may include displaying a warning or other notification together with one or more options or recommendations to correct the issue. In one implementation, after the user has selected the packages, patterns, or other software components to be included in and/or banned from the appliance, the user may configure and personalize an image to be built for the appliance in an operation 270. For example, in operation 270, the user may configure the build to establish settings relating to locale, network configuration, identity management, login preferences, database configuration, storage and memory, or various other settings [and predict the install command based on the notification] … In one implementation, operation 270 may then include building a bootable image of the appliance, wherein one or more virtual machines may be launched to create a contained build environment within which the appliance image may be generated [for the development branch]. The user may then deploy the appliance image for execution in one or more runtime environments (e.g., the user may download the appliance image for execution in a local runtime environment, load the appliance image within a hosted runtime environment, deploy the appliance image to a cloud computing environment, etc.). As such, the method illustrated in FIG. 2 and described herein may provide a simple and repeatable process for managing the creation of virtual appliances.”) [Examiner’s Note: Operation 270 occurs after the notification, so the developer has the opportunity to make software adjustments and install accordingly.]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Friedman into the teachings of Armenta in view of Chandra. This combination of teachings would have resulted in an automated dependency packaging service coupled to a database to enable various versioning lifecycle actions, as in Armenta, while managing sandboxes or branches for isolated versioning instances with collected customizations to eventually publish accordingly, as in Chandra, and providing the developer with tools to allow for interaction with the build process in a virtual instance to submit and publish changes, as in Friedman. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of managing the virtual application lifecycle in the process of creating, building, configuring, monitoring, and modifying in a user-driven manner (Friedman [0035]).
Claims 11-12 are directed to a method corresponding to the apparatus limitations as disclosed in claims 4-5. Thus, claims 11-12 are rejected for the same reasons set forth in claim 4-5.
Claims 18-19 are directed to a computer-readable medium embodying programmed instructions executed by a processor corresponding to the apparatus limitations as disclosed in claim 4-5. Thus, claim 18-19 rejected for the same reasons set forth in claims 4-5.
Allowable Subject Matter
Claims 6-7, 13-14, and are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. 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 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights