Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 4, 11 and 13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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(s) 4, 11, 13, 25-30, 32 and 34-37 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov).
Claims 4 and 28: Pillay discloses a computer-implemented method for managing the deployment of software applications, comprising:
receiving an application build request for a software application (par. [0055] “A developer initiates build process 400”);
extracting software source code elements and at least one of: one or more documents, one or more logs, or one or more Software-as-a-Service (SaaS) products (col. [0032] “An object ( … artifact) … may include source code, documentation, binary code, text file, XML file and the like”), for the software application from a source code repository in response to the application build request (par. [0055] “a first artifact collection (type 1) is pulled”);
performing automated security procedures to ensure integrity of the software source code elements (par. [0040] “provide security control for an actionable feature at the right access level”, par. [0056] determines data dependencies … verifies whether all data definitions are provided”);
combining code suitable of the target platform into a requested baseline application build package in a secure build server (par. [0057] “The logical build is a combination of build artifacts and artifacts metadata description”, par. [0058] “applying the logical build at block 411”);
storing the requested baseline application build package into an application product depot (par. [0059] “the artifact collections are moved to build server 104 … and labeled”);
receiving a request to deploy at least one baseline application build package into a destination deployment environment (par. [0064] “a developer providing target server information at block 602”);
extracting a copy of the at least one baseline application build package from the application product depot (par. [0064] “components (comprising one or more of the collected artifacts) are selected at block 604”, par. [0065] the build package … are extracted at block 607”);
creating metadata to identify the at least one baseline application build package to be installed into the destination deployment environment (par. [0064] “Metadata is generated at block 608 based on the build number””);
associating the metadata with the destination deployment environment (par. [0066] “a release may have many builds and build deployment process and build deployment process 500 may progress contingent on the build number”, par. [0064] “current build version and the updated build version”);
installing the at least one baseline application build package and accompanying metadata into the destination deployment environment (par. [0067] “deployment of the objects at the target server at block 611”); and
linking the metadata with the at least one baseline application build package installed into the destination deployment environment (par. [0066] “a release may have many builds and build deployment process and build deployment process 500 may progress contingent on the build number”, par. [0064] “current build version and the updated build version”).
Pillay does not explicitly disclose:
generating a Universal Application Notation (UAN) representation of the software source code elements;
transforming the UAN representation of the software source code elements into code suitable of a target platform.
Kirilov teaches:
generating a Universal Application Notation (UAN) representation of the software source code elements (col. 9, lines 17-23 “the JSON schema descriptions for the object models may be universal … models that are created based on the schemas are universal and describe universal object models which can be used in … application generator engine 332”);
transforming the UAN representation of the software source code elements into code suitable for a target platform (col. 10, lines 5-8 “the application generator engine 332 uses a first blueprint to generate an application that uses the Angular framework”).
It would have been obvious before the effective filing date of the claimed invention to generate a UAN representation of the software source code elements and transform the UAN representation into code suitable for a target platform. Those of ordinary skill in the art would have been motivated to do so “so developers can choose different frameworks as a target output” (Kirilov col. 9, 23-28).
Claims 11 and 32: Pillay and Kirilov teach claims 4 and 28, further comprising generating an alert in response to a detected failure in the software application in the deployment environment and tracing the detected failure back to the software source code elements (Pillay par. [0068] “a deployment error is detected”).
Claims 13 and 34: Pillay and Kirilov claims 4 and 28, wherein the software source code elements are versioned and the method further comprises identifying a version of the software source code elements used in the baseline application build package (par. [0064] “current build version and the updated build version”).
Claims 25 and 35: Pillay and Kirilov teach claims 4 and 28, wherein the UAN representation comprises JavaScript Object Notation (JSON) code (Kirilov col. 9, lines 17-23 “the JSON schema descriptions”).
Claims 26 and 36: Pillay and Kirilov teach claims 4 and 28, wherein the software source code elements are in a first computer language, and the code suitable for the target platform are in a second computer language (Pillay par. [0075] “different handler types 903-907 … Python handler 910, C++ handler 911”, Java handler 912, Kirilov col. 7, line 56-col. 8, line 3 “generate the metabridge model form the application generated within the design tool 113”, col. 10, lines 5-14 “type script … SAS”, col. 15, lines 45-49 “a variety of programming languages may be used”, it would at least have been obvious for the first and second code elements to be in first and second computer language to ensure the transformation produces code in a language appropriate for the target framework).
Claims 27 and 37: Pillay and Kirilov teach claims 26 and 36, wherein the UAN representation corresponds to a descriptive language, and at least one of the first computer language or the second computer language corresponds to C, C++, or Objective C (Pillay par. [0075] “C++ handler 911”).
Claim 29: Pillay and Kirilov teach claim 28 wherein the application build request includes a specification of software components to be included in the baseline application build package and the method further comprises verifying that the software components meet one or more compatibility requirements of the software application (Pillay par. [0065] “determines whether any selected component is incompatible the target server”).
Claim 30: Pillay and Kirilov teach claim 28, wherein the requested baseline application build package is encrypted and decrypted by the secure build server using cryptographic techniques to ensure confidentiality of the software source code elements (Panigrahi par. [0112] “transferred via an encrypted link … using SFTP … secured through the use of SSH (Secure Shell) host keys”).
Claim(s) 5-8 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of US 2021/0064742 to Panigrahi (Panigrahi).
Claim 5: Pillay and Kirilov teach claim 4, wherein the automated security procedures include code validation (e.g. par. [0056] “verifies whether all data definitions are provided”) to ensure the software source code elements comply with coding standards (par. [0009] “provides security control”).
Pillay and Kirilov do not explicitly teach ensuring software source code elements are free from malicious code.
Panigrahi teaches automated security procedures including ensuring software source code elements are free from malicious code (par. [0112] “the computer executable code is virus scanned”).
It would have been obvious at the time of filing to virus scan the code. Those of ordinary skill in the art would have been motivated to do so to as a known security measure which would have produced only the expected results.
Claim 6: Pillay, Kirilov and Panigrahi teach claim 5 wherein the application build request includes a specification of software components to be included in the baseline application build package and the method further comprises verifying that the software components meet one or more compatibility requirements of the software application (Pillay par. [0065] “determines whether any selected component is incompatible the target server”).
Claim 7: Pillay, Kirilov and Panigrahi teach claim 6, wherein the requested baseline application build package is encrypted and decrypted by the secure build server using cryptographic techniques to ensure confidentiality of the software source code elements (Panigrahi par. [0112] “transferred via an encrypted link … using SFTP … secured through the use of SSH (Secure Shell) host keys”).
Claim 8: Pillay, Kirilov and Panigrahi teach the method of claim 7, wherein the destination deployment environment is a cloud-based infrastructure (Panigrahi par. [0039] “a virtualization environment 220 … a plurality of virtual machines 310”) and the metadata includes parameters for configuring the destination deployment environment (Pillay par. [0061] “listing all build included artifacts and containing attributes to specify build artifact type and location”).
Claim 14: Pillay, Kirilov and Panigrahi teach claim 7, wherein the destination deployment environment is a virtual machine (Panigrahi par. [0039] “a virtualization environment 220 … a plurality of virtual machines 310”) and the method further comprises creating a snapshot of the virtual machine before installing the baseline application build package, such that the virtual machine can be rolled back to the snapshot in an event of a failure (Pillay par. [0067] “takes a snapshot … of the target environment”).
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of US 2021/0064742 to Panigrahi (Panigrahi) in view of US 2020/0285462 to Sabath et al. (Sabath).
Claim 9: Pillay, Kirilov and Panigrahi teach the method of claim 8, wherein the metadata includes a change log for the software application, including a record of all modifications to the software application (Pillay [0058] “identify artifacts (objects) that were changed during the build process”).
Pillay, Kirilov and Panigrahi do not explicitly teach:
a record of one or more user accounts responsible for making the modifications.
Sabath teaches:
a record of one or more user accounts responsible for making the modifications (par. [0064] “the list is used to track changes made and by which user”).
It would have been obvious before the effective filing date of the claimed invention to include a record of user accounts. Those of ordinary skill in the art would have been motivated to do so as data known to be included in an audit trail (see Pillay par. [0058] “an audit trail of code changes”) which would have produced only the expected results.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of US 2021/0064742 to Panigrahi (Panigrahi) in view of US 2020/0285462 to Sabath et al. (Sabath) in view of US 20140075428 to Van Elsas et al. (Van Elsas).
Claim 10: Pillay, Kirilov, Panigrahi and Sabath teach claim 9, but do not teach wherein the metadata includes performance metrics for the software application in the deployment environment, including data on at least one of: response times, processing speeds, and memory usage.
Van Elsas teaches
metadata including performance metrics for a software application in the deployment environment, including data on at least one of processing speeds, and memory usage (par. [0037] “expected application metadata can include … the application run-time memory usage, the application run-time processing usage”).
It would have been obvious at the time of filing to include performance metrics including processing speeds, and memory usage. Those of ordinary skill in the art would have been motivated to do so to provide additional means to identify/select the respective application/artifacts.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of US 2021/0064742 to Panigrahi (Panigrahi) in view of US 2020/0285462 to Sabath et al. (Sabath) in view of us 9,253,244 to Heitmann et al. (Heitmann).
Claim 12: Pillay, Kirilov, Panigrahi and Sabath teach claim 9, but do not teach wherein the metadata includes a list of all supporting documents and tickets related to the baseline application build package.
Heitmann teaches metadata including supporting documents and tickets (“resource datastore 118 may include … trouble tickets … technical documentation”).
It would have been obvious at the time of filing to include supporting documents and tickets. Those of ordinary skill in the art would have been motivated to do so to provide assistance in identifying and resolving problems.
Claim(s) 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of US 20140075428 to Van Elsas et al. (Van Elsas).
Claim 31: Pillay and Kirilov teach claim 28, but do not teach wherein the metadata includes performance metrics for the software application in the deployment environment, including data on at least one of: response times, processing speeds, and memory usage.
Van Elsas teaches
metadata including performance metrics for a software application in the deployment environment, including data on at least one of processing speeds, and memory usage (par. [0037] “expected application metadata can include … the application run-time memory usage, the application run-time processing usage”).
It would have been obvious at the time of filing to include performance metrics including processing speeds, and memory usage. Those of ordinary skill in the art would have been motivated to do so to provide additional means to identify/select the respective application/artifacts.
Claim(s) 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2016/0139916 to Pillay et al. (Pillay) in view of US 11,385,867 to Kirilov et al. (Kirilov) in view of us 9,253,244 to Heitmann et al. (Heitmann).
Claim 33: Pillay and Kirilov teach claim 28, but do not teach wherein the metadata includes a list of all supporting documents and tickets related to the baseline application build package.
Heitmann teaches metadata including supporting documents and tickets (col. 48-65 “resource datastore 118 may include … trouble tickets … technical documentation”).
It would have been obvious at the time of filing to include supporting documents and tickets. Those of ordinary skill in the art would have been motivated to do so to provide assistance in identifying and resolving problems.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199
Prosecution Insights