DETAILED ACTION
This action is in response to application 18/777973, filed on 7/19/2024. Claims 1-20 are pending. 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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 7, 9-11, 14-18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by USPGPUB 2022/0360504, hereinafter “Kairali.”
Regarding claim 1, Kairali anticipates “A method comprising:
receiving, on at least one computer system, application source code and configuration information; (see, e.g., Kairali, para. 60; “the environment of FIG. 4 includes computing device 420 that runs a Code and Deployment Readiness Optimizer (CDRO) 425.”; para. 62; “the user device 430 pushes a microservice code to the CDRO 425”; para. 63; “the microservice code includes source code and one or more config files.”)
generating, by the at least one computer system, a first model from the application source code, the first model describing dependencies between the application source code and a plurality of cloud resources on one or more cloud environments; (see, e.g., Kairali, para. 64; “the CDRO 425 scans the microservice code to determine services and resources used by the microservice code . . . the CDRO 425 runs a comprehensive code scan on the microservice code.”)
searching, by the at least one computer system, the first model for a plurality of predefined cloud resource calls for accessing the plurality of cloud resources; (see, e.g., Kairali, para. 64; “the code scan is based on predefined patterns of code usage and is utilized to identify services and resources associated with the microservice code . . . the CDRO 425 stores or has access to a library of predefined patterns of code usage, where each pattern is defined as corresponding to a service (e.g., identity and access, logging, key management, database, certificates, etc.).”)
extracting, by the at least one computer system, a plurality of application source code calls from the first model corresponding to the plurality of cloud resource calls; (see, e.g., Kairali, para. 64; “the CDRO 425 uses the code scan to look for the predefined patterns in the microservice code. When the code scan finds one of the predefined patterns in a portion of the microservice code (e.g., a group of lines of the microservice code), the CDRO 425 identifies that portion of the microservice code as being associated with the service that corresponds to the identified pattern (e.g., as defined in the library).”; “the CDRO 425 using the code scan might determine that lines 17-21 of the microservice code are associated with an identity and access management service of the source cloud platform, and that lines 23-29 of the microservice code are associated with a key management service of the source cloud platform.”)
determining, by the at least one computer system, application source code dependencies on the plurality of cloud resources based on the extracted plurality of application source code calls; (see, e.g., Kairali, para. 66; “the CDRO 425 uses the code scan to determine runtime failures and dependencies, as well as services required for operation performed by the code. Examples of services required for operations that are determined by the code scan include, but are not limited to, communications services (e.g., Slack, New Relic, etc.). In implementations, the code scan may be configured (e.g., via appropriate programming and predefined patterns) to scan for any desired predefined runtime failures and dependencies, and any desired predefined services required for operation.”) and
generating, by the at least one computer system, infrastructure-as-code files based on the determined application source code dependencies to deploy executable application code corresponding to the application source code on the target cloud environment.” (see, e.g., Kairali, para. 83; “At step 4.7, the CDRO 425 generates a new deployment file for the microservice code on the target cloud platform based on the microservice code as modified at step 4.6. In embodiments, the CDRO 425 generates a Kubernetes deployment file using the modified microservice code (including any modified config files). At step 4.8, the system deploys the modified microservice code to the target cloud platform using the new deployment file from step 4.7. At this stage, the user may utilize the modified microservice code with the target cloud platform.”).
Regarding claim 2, Kairali anticipates “The method of claim 1, further comprising determining parameters associated with each of the plurality of application source code calls from the first model.” (see, e.g., Kairali, para. 73-74).
Regarding claim 3, Kairali anticipates “The method of claim 2, further comprising extracting parameter values for each determined parameter from the first model.” (see, e.g., Kairali, para. 81-82).
Regarding claim 4, Kairali anticipates “The method of claim 1, further comprising generating a dependency specification comprising dependencies between application source code calls and the plurality of cloud resources.” (see, e.g., Kairali, para. 66).
Regarding claim 5, Kairali anticipates “The method of claim 1, wherein a first portion of components of the application source code are deployed on a first cloud environment and a second portion of components of the application source code are deployed on a second cloud environment.” (see, e.g., Kairali, para. 83-84).
Regarding claim 7, Kairali anticipates “The method of claim 1, wherein searching the first model for a plurality of predefined cloud resource calls comprises: accessing the model by a plurality of processes each configured to search the model for different categories of cloud resource calls; and for each category of the cloud resource calls, determine unique application source code dependencies on corresponding cloud resources.” (see, e.g., Kairali, para. 66).
Regarding claim 9, Kairali anticipates “The method of claim 1, wherein the configuration information comprises configuration information specifying particular cloud resources the application source code relies on and configurations for the particular cloud resources.” (see, e.g., Kairali, para. 82).
Regarding claim 10, Kairali anticipates “The method of claim 1, further comprising receiving an indication of at least one target cloud environment of a plurality of cloud environments to deploy the application source code.” (see, e.g., Kairali, para. 62; “the user device 430 pushes a microservice code to the CDRO 425 for the purpose of adapting the microservice code to a target cloud platform.”)
Regarding claim 11, Kairali anticipates “The method of claim 1, further comprising determining, from one or more of the application source code or the configuration information, at least one target cloud environment of a plurality of cloud environments to deploy the application source code.” (see, e.g., Kairali, para. 62; “In the example shown in FIG. 4, the target cloud platform is cloud platform 405 c. In this example, the microservice code is configured to run on a source cloud platform (e.g., cloud platform 405 a) and the user wishes to adapt the microservice code to run on the target cloud platform 405 c.”).
Regarding claim 14, Kairali anticipates “The method of claim 1, further comprising provisioning the one or more cloud environments using the infrastructure-as-code files.” (see, e.g., Kairali, para. 83).
Regarding claim 15, Kairali anticipates “The method of claim 14, wherein said provisioning the one or more cloud environments generates at least one new cloud environment and deploys at least a portion of the executable application code on the at least one new cloud environment.” (see, e.g., Kairali, para. 83-84).
Regarding claim 16, Kairali anticipates “The method of claim 14, wherein said provisioning the one or more cloud environments modifies at least one existing cloud environment and deploys at least a portion of the executable application code on the at least one existing cloud environment.” (see, e.g., Kairali, para. 83-84).
Regarding claim 17, Kairali anticipates “The method of claim 1, further comprising:
storing a plurality of predefined policies in a policy database; (see, e.g., Kairali, para. 67)
storing a plurality of resource templates in a resource template database; (see, e.g., Kairali, para. 68-69, 93)
generating, from the dependency specification, a list of cloud resources; (see, e.g., Kairali, para. 70-72)
selecting, based on the list of cloud resources, a first subset of resource templates from the resource template database; (see, e.g., Kairali, para. 77)
selecting, based on the list of cloud resources, a first subset of predefined policies from the policy database; (see, e.g., Kairali, para. 75) and
modifying one or more of the first subset of resource templates based on the first subset of predefined policies, (see, e.g., Kairali, para. 78-79, 82) wherein the infrastructure-as-code files, when executed, configure the cloud resources based on the modified one or more first subset of resource templates.” (see, e.g., Kairali, para. 83-84).
Regarding claim 18, Kairali anticipates “The method of claim 17, wherein the resource templates comprise template configuration data to configure the cloud resources to conform with particular policies.” (see, e.g., Kairali, para. 68-69, 93).
Regarding claim 20, Kairali anticipates “A computer system comprising: at least one processor; at least one non-transitory computer readable medium storing computer executable instructions that, when executed by the at least one processor, cause the computer system to perform a method of automatically deploying an application comprising:
receiving application source code and configuration information for the application; (see, e.g., Kairali, para. 60; “the environment of FIG. 4 includes computing device 420 that runs a Code and Deployment Readiness Optimizer (CDRO) 425.”; para. 62; “the user device 430 pushes a microservice code to the CDRO 425”; para. 63; “the microservice code includes source code and one or more config files.”)
determining application source code dependencies on a plurality of cloud resources of one or more cloud environments; (see, e.g., Kairali, para. 66; “the CDRO 425 uses the code scan to determine runtime failures and dependencies, as well as services required for operation performed by the code. Examples of services required for operations that are determined by the code scan include, but are not limited to, communications services (e.g., Slack, New Relic, etc.). In implementations, the code scan may be configured (e.g., via appropriate programming and predefined patterns) to scan for any desired predefined runtime failures and dependencies, and any desired predefined services required for operation.”) and
generating infrastructure-as-code files based on the determined application source code dependencies to automatically deploy executable application code corresponding to the application source code on the one or more cloud environments.” (see, e.g., Kairali, para. 83; “At step 4.7, the CDRO 425 generates a new deployment file for the microservice code on the target cloud platform based on the microservice code as modified at step 4.6. In embodiments, the CDRO 425 generates a Kubernetes deployment file using the modified microservice code (including any modified config files). At step 4.8, the system deploys the modified microservice code to the target cloud platform using the new deployment file from step 4.7. At this stage, the user may utilize the modified microservice code with the target cloud platform.”).
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.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kairali and USPGPUB 2016/0147529, hereinafter “Coleman.”
Regarding claim 6, Kairali discloses “The method of claim 1,” but does not appear to disclose the limitation “further comprising: receiving one or more custom code libraries external to the application source code; and expanding the first model to incorporate the one or more custom code libraries.” Coleman discloses (at para. 64) incorporating a custom external software code library into a software build result intended for cloud platform deployment. Coleman and Kairali are directed toward cloud deployment and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine Coleman’s disclosure of including custom external software code with the multi-platform deployment adaptation disclosures of Kairali, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability to improve the adaptation of software for different cloud platforms. Accordingly, the instant claim is unpatentable over the combination of Coleman and Kairali.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kairali and USPGPUB 2021/0117548, hereinafter “Gokhman.”
Regarding claim 8, Kairali anticipates “The method of claim 7,” but does not appear to disclose the limitations “further comprising de-duplicating the plurality of program calls extracted from the first model to produce unique application source code dependencies.” Gokhman discloses, at para. 61, processing source code to identify packages on which the source code depends, and then to “implement deduplication of identical package instances.” Gokhman and Kairali are directed toward software engineering and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the deduplication of Gokhman with the multi-platform deployment adaptation disclosures of Kairali, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability to reduce the size of software deployments. Accordingly, the instant claim is unpatentable over the combination of Gokhman and Kairali.
Claims 12-13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kairali and USPGPUB 2022/0269580, hereinafter “Balasubramanian.”
Regarding claims 12-13, Kairali discloses “The method of claim 1,” but does not disclose the further limitations “wherein the first model represents at least a structure, a control flow, and a data flow of the application source code and corresponding cloud resources” and “wherein the first model is a code property graph or an abstract syntax tree.” Balasubramanian discloses (at para. 64) modelling source code with an abstract syntax tree depicting code structure and control and data flow. Balasubramanian and Kairali are directed toward software engineering and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the source code modelling of Balasubramanian with the multi-platform deployment adaptation disclosures of Kairali, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability to improve source code analysis. Accordingly, the instant claim is unpatentable over the combination of Balasubramanian and Kairali.
Regarding claim 19, Kairali discloses “A computer implemented method comprising:
receiving application source code and configuration information; (see, e.g., Kairali, para. 60; “the environment of FIG. 4 includes computing device 420 that runs a Code and Deployment Readiness Optimizer (CDRO) 425.”; para. 62; “the user device 430 pushes a microservice code to the CDRO 425”; para. 63; “the microservice code includes source code and one or more config files.”)
generating a first model from the application source code, the first model describing dependencies between the application source code and a plurality of cloud resources on one or more cloud environments; (see, e.g., Kairali, para. 64; “the CDRO 425 scans the microservice code to determine services and resources used by the microservice code . . . the CDRO 425 runs a comprehensive code scan on the microservice code.”)
searching the first model for a plurality of predefined cloud resource calls for accessing the plurality of cloud resources, (see, e.g., Kairali, para. 64; “the code scan is based on predefined patterns of code usage and is utilized to identify services and resources associated with the microservice code . . . the CDRO 425 stores or has access to a library of predefined patterns of code usage, where each pattern is defined as corresponding to a service (e.g., identity and access, logging, key management, database, certificates, etc.).”) wherein searching the first model for a plurality of predefined cloud resource calls comprises: accessing the model by a plurality of processes each configured to search the model for different categories of cloud resource calls; and for each category of the cloud resource calls, determine unique application source code dependencies on corresponding cloud resources; (see, e.g., Kairali, para. 66)
extracting a plurality of application source code calls from the first model corresponding to the plurality of cloud resource calls; (see, e.g., Kairali, para. 64; “the CDRO 425 uses the code scan to look for the predefined patterns in the microservice code. When the code scan finds one of the predefined patterns in a portion of the microservice code (e.g., a group of lines of the microservice code), the CDRO 425 identifies that portion of the microservice code as being associated with the service that corresponds to the identified pattern (e.g., as defined in the library).”; “the CDRO 425 using the code scan might determine that lines 17-21 of the microservice code are associated with an identity and access management service of the source cloud platform, and that lines 23-29 of the microservice code are associated with a key management service of the source cloud platform.”)
determining application source code dependencies on the plurality of cloud resources based on the extracted plurality of application source code calls; (see, e.g., Kairali, para. 66; “the CDRO 425 uses the code scan to determine runtime failures and dependencies, as well as services required for operation performed by the code. Examples of services required for operations that are determined by the code scan include, but are not limited to, communications services (e.g., Slack, New Relic, etc.). In implementations, the code scan may be configured (e.g., via appropriate programming and predefined patterns) to scan for any desired predefined runtime failures and dependencies, and any desired predefined services required for operation.”)
generating, based on said determining, a dependency specification comprising dependencies between application source code calls and the plurality of cloud resources; (see, e.g., Kairali, para. 66)
generating, from the dependency specification, a list of cloud resources; (see, e.g., Kairali, para. 70-72)
selecting, based on the list of cloud resources, a first subset of resource templates from the resource template database, (see, e.g., Kairali, para. 77) the resource template database storing a plurality of resource templates; (see, e.g., Kairali, para. 68-69, 93)
selecting, based on the list of cloud resources, a first subset of predefined policies from the policy database, (see, e.g., Kairali, para. 75) the policy database storing a plurality of predefined policies; (see, e.g., Kairali, para. 67)
modifying one or more of the first subset of resource templates based on the first subset of predefined policies; (see, e.g., Kairali, para. 78-79, 82) and
generating infrastructure-as-code files based on the determined application source code dependencies to deploy executable application code corresponding to the application source code on the one or more cloud environments, (see, e.g., Kairali, para. 83; “At step 4.7, the CDRO 425 generates a new deployment file for the microservice code on the target cloud platform based on the microservice code as modified at step 4.6. In embodiments, the CDRO 425 generates a Kubernetes deployment file using the modified microservice code (including any modified config files). At step 4.8, the system deploys the modified microservice code to the target cloud platform using the new deployment file from step 4.7. At this stage, the user may utilize the modified microservice code with the target cloud platform.”) wherein the infrastructure-as-code files, when executed, configure the cloud resources based on the modified one or more first subset of resource templates.” (see, e.g., Kairali, para. 83-84).
Kairali discloses does not disclose the underlined portion of the limitation:
generating a first model from the application source code, the first model describing dependencies between the application source code and a plurality of cloud resources on one or more cloud environments, wherein the first model represents at least a structure, a control flow, and a data flow of the application source code and corresponding cloud resources.”
Balasubramanian discloses (at para. 64) modelling source code with an abstract syntax tree depicting code structure and control and data flow. Balasubramanian and Kairali are directed toward software engineering and therefore are analogous art. On or before the effective filing date of the instant application, one of ordinary skill in the art would have deemed it obvious to try to combine the source code modelling of Balasubramanian with the multi-platform deployment adaptation disclosures of Kairali, thereby obtaining the invention of the instant claim. A clear and predictable benefit of so combining would have appeared as the ability to improve source code analysis. Accordingly, the instant claim is unpatentable over the combination of Balasubramanian and Kairali.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN D COYER whose telephone number is 571-270-5306. The examiner can normally be reached Monday-Friday 12pm-10pm Eastern Time. 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.
/Ryan D. Coyer/Primary Examiner, Art Unit 2191
