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 .
DETAILED ACTION
This Office Action is in response to the application 17/201,923 in response to the Pre-Appel Brief Conference decision filled on 06/11/2025. Claims 1-4, 6-13, 15-20 have been examined and are pending in this application. This application is being re-opened, and this Action is counted as a Non-FINAL.
Response to Arguments
Applicant arguments on page 10-11 of the remarks have been considered. The Examiner
agrees with the Applicant. In light of this clarification, prosecution is reopened and the
application is being returned to non-final status. A new rejection under 35 USC § 103 is
present bellowed based on new considered prior art.
Claim Rejections - 35 USC § 103
Claims 1-2, 7, 10-11, 16 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1)
Regarding Claim 1
Anderson discloses:
A method for controlling access to a security credential, the method being implemented by at least one processor, the method comprising:
receiving, by the at least one processor from a user, a first set of software code (Anderson: col. 10 line 45 - line 50: the continuous deployment system receives source code modifications for a software project from a developer);
testing, by the at least one processor, the first set of code (Anderson: col. 11 line 5 - line 18: automatically initiating one or more software tests, including testing whether functionality provided by the code is working correctly, whether the performance of the application is within the desired parameters, and whether the results provided by the application are correct; col. 11 line 21 - line 31: determining whether the one or more software tests, including functionality tests, bug tests, performance tests, and compliance tests, have been passed; col. 11 line 51 - line 57: automatic approval may be granted when the one or more software tests are passed);
deploying, by the at least one processor, the first set of software code to a predetermined destination (Anderson Claim 1: causing an approved software package to be deployed to a deployment environment);
wherein the certification includes an indication that the first set of code satisfies a predetermined quality standard that is measurable by using at least one metric from among a first metric that relates to stability, a second metric that relates to performance, a third metric that relates to unit test coverage, a fourth metric that relates to a presence of at least one code review, a fifth metric that relates to a list of tickets that have been implemented in previous changes, a sixth metric that relates to a size of a release, a seventh metric that relates to a delta of a metric that relates to a previous release, and an eighth metric that relates to maintainability (Anderson: col. 11 line 9 - line 25: software tests check the performance of the software package). Because claim 1 requires only at least one of the recited metrics, Anderson's performance related teaching satisfies the recited second metric.
Anderson does not explicitly disclose receiving, by the at least one processor, a certification that the first set of code has passed at least one test. However, Mantripragada discloses determining whether formal testing of a test package was successful and, following successful testing and quality assurance processing, generating a QA seal for the final software package, wherein the QA seal is a data structure providing an intelligent software token that includes a security token, software package profile, environment profile, user profile, and related metadata, and is subsequently retrieved and verified against a QA seal stored in a separate repository (Mantripragada: ¶[0020], ¶[0028]-¶[0029], ¶[0043]-¶[0052], ¶[0140], ¶[0145], FIG. 10, steps 1004, 1014; FIG. 2, steps 202-204).
It would have been obvious to modify Anderson's automated testing and approval workflow to incorporate Mantripragada's QA seal generation, storage, retrieval, and verification, because Anderson and Mantripragada are analogous art directed to automated software testing and deployment, and Mantripragada's QA seal provides an independently verifiable indication that required testing and quality approvals had been completed before deployment.
The combination of Anderson and Mantripragada do not explicitly disclose requesting, by the at least one processor from a credential source, at least one from among a credential that indicates that the certification has been received and an authorization to use the credential; and when the at least one from among the credential and the authorization to use the credential has been received, deploying, by the at least one processor, the first set of software code to a predetermined destination. However, Yuhan discloses deployment tools configured to seek approval for each deployment through a deployment approval system before performing the deployment (Yuhan: col. 2 line 1 - line 5); a deployment approvals manager that, once a deployment is approved, authorizes the deployment tool to perform the deployment by providing the deployment tool with a credential or token, e.g., a one-time password, that allows the deployment tool to access the group of resources to perform the deployment (Yuhan: col. 8 line 22 - line 33); and a deployment tool that, having received approval and credentials, uses the credentials to access the target resource and perform the deployment (Yuhan: col. 12 line 55 - col. 13 line 4, FIG. 3).
It would have been obvious to one having ordinary skill in the art to modify the Anderson/Mantripragada system with Yuhan's credential based deployment authorization mechanism because Anderson, Mantripragada, and Yuhan are analogous art directed to controlling and automating software deployment, and Yuhan's mechanism ensures that a deployment tool is permitted to access and modify a target resource only after applicable deployment conditions have been satisfied and authorization has been granted.
Regarding Claim 2
Anderson as modified above discloses the limitations of claim 1. Anderson further discloses wherein the method is implemented in a continuous integration/continuous deployment (CI/CD) pipeline environment (Anderson, FIG. 3 and corresponding description: pipeline model 305 represents the path that source code takes from check-in of changes to deployment to production, and includes an application stage, multiple testing stages, and a production stage; see also Anderson, col. 4–5, describing source-code check-in, package build, deployment to a CDS stage, approval-workflow testing, promotion through stages, and deployment to production).
Regarding Claim 7
Regarding claim 7, the combination of Anderson, Mantripragada, and Yuhan discloses the limitations of claim 1. Yuhan further discloses wherein the credential includes at least one from among a security token, a key, and a signed object (Yuhan, col. 11, lines 8–12: "the credentials dispenser 208 is configured approve deployments by providing the deployment tool 218 with credentials, e.g., access keys or secret keys, for accessing resources being targeted by the deployment"). Because claim 7 requires only at least one of the recited alternatives, Yuhan's disclosure of access keys or secret keys satisfies the recited "key" alternative.
Regarding Claim 10
Claim 10 is directed to a method corresponding to the computer-implemented method in
claim 1. Claim 10 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a method corresponding to the computer-implemented method in
claim 2. Claim 11 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to a method corresponding to the computer-implemented method in
claim 7. Claim 16 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to a method corresponding to the computer-implemented method in
claim 1. Claim 19 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 is directed to a method corresponding to the computer-implemented method in
claim 2. Claim 20 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Claims 3 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1) as applied to claim 1 and 10 above, and in further view of Ramakrishna (US 2020/0019493 A1).
Regarding Claim 3
Anderson as modified above discloses the limitations of claim 1. Anderson further discloses testing software to determine whether the software successfully performs a predetermined function (Anderson, col. 11, lines 5–10: the software tests "can check whether functionality provided by the code is working correctly"; see also Anderson, col. 5, lines 30–35: test programs or test scripts are run against the environment revision and multiple tests may be run to test particular functionality). The combination of Anderson, Mantripragada, and Yuhan does not expressly disclose that the functionality test is a unit test. However, Ramakrishna discloses this limitation. Ramakrishna discloses performing one or more unit tests on new software code to generate unit-test results, wherein the one or more unit tests may include a workflow test used to determine whether the new software code is providing a desired functionality and/or process execution (Ramakrishna, ¶[0025]). Ramakrishna further discloses selecting a unit test from a plurality of unit tests and performing, via a development environment, the selected unit test on the new software code to generate a unit-test result (Ramakrishna, ¶¶[0085]–[0086]; FIG. 4, blocks 415–420).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the functionality testing stage of the Anderson/Mantripragada/Yuhan system to use Ramakrishna's unit testing technique because Ramakrishna's unit test provides a known technique for determining whether new software code provides the desired functionality already tested generally by Anderson. Such a modification would have predictably provided a more specific implementation of Anderson's functionality testing within the automated software testing and deployment pipeline.
Regarding Claim 12
Claim 12 is directed to a method corresponding to the computer-implemented method in
claim 3. Claim 12 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Claims 4 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1) as applied to claim 1 and 10 above, and in further view of Agarwal (US 2018/0300220 A1).
Regarding Claim 4
Anderson as modified above discloses the limitations of claim 1. The combination of Anderson, Mantripragada, and Yuhan does not expressly disclose the following limitation “wherein the testing comprises subjecting the first set of software code to a regulatory test designed to determine whether the first set of software complies with a predetermined governmental regulation”. However, in an analogous art, Agarwal discloses a governmental regulation system/method that includes: wherein the testing comprises subjecting the first set of software code to a regulatory test designed to determine whether the first set of software complies with a predetermined governmental regulation (Agarwal Paragraph 34: describes validation routines that include criteria for managing the container validation process, specifically stating that these criteria may be used to determine whether the validation process meets regulatory requirements set by a government agency. This states that the system applies regulatory tests to ensure compliance with government-mandated standards.).
Given the teaching of Agarwal, a person having ordinary skill in the art before the
effective filing date of the claimed invention would have readily recognized the desirability and
advantages of modifying the teachings of Anderson/Mantripragada/Yuhan to integrate a feature in which software code is subjected to a regulatory test designed to determine compliance with
predetermined governmental regulations. One of ordinary skills in the art would have been
motivated to do so because Agarwal recognizes that by including validation routines that manage
container validation processes and ensure compliance with regulatory requirements, the software
code can be effectively assessed for adherence to governmental regulations. The validation
routines, which include criteria for evaluating compliance with regulatory standards, facilitate
the enforcement of such requirements, thereby improving the reliability and regulatory
compliance with the containerized application (Agarwal Paragraph 34).
Regarding Claim 13
Claim 13 is directed to a method corresponding to the computer-implemented method in
claim 4. Claim 13 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1) as applied to claim 1 and 10 above, and in further view of Simpson (US 2016/0142434 A1).
Regarding Claim 6
Regarding claim 6, Anderson as modified above discloses the limitations of claim 1. Anderson further discloses that the testing comprises subjecting the first set of software code to a compliance test designed to determine whether the first set of software code complies with a predetermined standard (Anderson, col. 11, lines 21–31: the continuous deployment system determines whether the one or more software tests have been passed, including functionality tests, bug tests, performance tests, and compliance tests; claim 20 "wherein the software tests check for compliance with a compliance policy"). Anderson further discloses that software compliance policies may implement security standards, including PCI data-security standards and FISMA information-security standards, and that the continuous deployment system monitors whether a software revision has been approved as complying with the applicable compliance policy (Anderson, col. 10, lines 8–27). Anderson does not expressly disclose that the security test is specifically designed to determine whether the software is protected from an external intrusion. However, Simpson discloses this feature. Simpson discloses subjecting software to a security test in which an attack from a malicious source is simulated in order to determine whether the software is vulnerable to that attack (Simpson, ¶[0002]: "Manual penetration testing is one technique of security validation. In manual penetration testing, an attack from a malicious source is simulated on a web page. An attack typically includes inserting malicious code into communications with the web page"). Simpson further discloses attacking a web request by injecting malicious code into the request in an attempt to exploit functionality not intended by the user and thereafter processing the server response to determine whether a vulnerability exists (Simpson, ¶¶[0017]–[0018]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Anderson's compliance testing process to incorporate Simpson's simulated attack penetration testing when evaluating compliance with Anderson's information security requirements because doing so applies a known security testing technique to an automated software testing and deployment system to achieve the predictable result of verifying, prior to deployment, that the software does not contain vulnerabilities exploitable through external malicious attacks. Anderson further discloses that, when a determination is made that the first set of software code complies with the predetermined security standard the testing further comprises confirming a time window within which deployment of the first set of software code is permitted to be performed. Anderson expressly recites "determining a time window operative on the selected software package" and "deploying the selected software package during a time when the time window is open" (Anderson, claim 8 and claim 26). Anderson further teaches that, where a promotion configuration includes a time window defining times when promotions may take place, automated actions are held until the time window opens (Anderson, col. 7, lines 44–48).
Regarding Claim 15
Claim 15 is directed to a method corresponding to the computer-implemented method in
claim 6. Claim 15 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Claim 8 and 17 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1) as applied to claim 1 and 10 above, and further in view of Yabe (US 2018/0278603 A1).
Regarding Claim 8
Regarding claim 8, the combination of Anderson, Mantripragada, and Yuhan discloses the limitations of claim 1, including a credential used to authorize access to target resources (Yuhan, col. 8, lines 22–33). The combination does not expressly disclose that the authorization to use the credential includes a claim that proves that the user has access to the credential. However, Yabe discloses this limitation. Yabe discloses a signed access token that itself functions as a credential proving authorization of access, wherein the signed access token is structured as a set of claims, including a "sub" (Subject) claim representing an identifier of the subject of the token (Yabe, ¶[0004]: "the service B receives a token (hereinafter referred to as an access token) to prove the authorization of access to data within the range permitted by the user"; ¶[0053]: "JWT is a method for expressing URL-safe claims using a data structure based on JavaScript Object Notation (JSON)"; ¶[0054]: "'sub' (Subject) represents an identifier of a subject of JWT"). Yabe further discloses that a resource server verifies the digital signature of the signed access token and decrypts the token to acquire the claims, including the subject claim, in order to determine whether the requesting client has sufficient authority to access the requested resource (Yabe, ¶¶[0075]–[0076]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the credential of the Anderson/Mantripragada/Yuhan system to incorporate Yabe's claims based signed access token, because doing so applies a known technique for embedding a verifiable claim of subject identity within a credential to a similar deployment authorization system yielding the predictable result of allowing the entity relying on the credential to verify that the presenting party is the legitimate holder of that credential.
Regarding Claim 17
Claim 17 is directed to a method corresponding to the computer-implemented method in claim 8. Claim 17 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Claim 9 and 18 is rejected under 35 U.S.C. 103 as being unpatentable over Anderson (US 8,677,315 B1) in view of Mantripragada (US 2015/0199188 A1), in view of Yuhan (US 9,438,599 B1) as applied to claim 1 and 10 above, and further in view of Mahiddini (US 2014/0109114 A1).
Regarding Claim 9
Regarding claim 9, the combination of Anderson, Mantripragada, and Yuhan discloses the limitations of claim 1, including deploying the first set of software code to a predetermined destination. The combination does not expressly disclose that the predetermined destination comprises an application programming interface (API). However, Mahiddini discloses this limitation. Mahiddini discloses an API gateway configured to identify a software code object for deployment, wherein the code object includes executable code for performing at least one function, and to automatically generate an API for mapping function calls for the at least one function to the executable code for performing the at least one function (Mahiddini, ¶[0007]: "an Application Programming Interface (API) gateway configured to identify a software code object for deployment... The API gateway further configured to query the code object for the least one function, to automatically generate an API for mapping function calls for the at least one function to executable code for performing the at least one function"). Mahiddini further discloses that the API gateway communicates with a developer system to identify and deploy code objects to implement web services, and that deploying the code objects results in the automatic generation and publication of APIs for the code objects' functions (Mahiddini ¶[0026]: "API gateway 102 communicates with developer system 116 to identify and deploy code objects 108-110 to implement web services... After identifying the functions, control system 104 automatically generates and publishes APIs for the functions").
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the deployment destination of the Anderson/Mantripragada/Yuhan system to be an API gateway as taught by Mahiddini, because doing so applies a known deployment destination and technique for exposing deployed code via an automatically generated API to a similar automated software deployment pipeline, yielding the predictable result of making the deployed software code accessible to remote applications via a published API.
Regarding Claim 18
Claim 18 is directed to a method corresponding to the computer-implemented method in
claim 9. Claim 18 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to SAAD ABDULLAH whose telephone number is 571-272-1531.
The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be
reached on 571-272-2092.
Information regarding the status of an application may be obtained from the Patent
Application Information Retrieval (PAIR) system. Status information for published applications
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished
applications is available through Private PAIR only. For more information about the PAIR
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would
like assistance from a USPTO Customer Service Representative or access to the automated
information system, call 800- 786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/ Examiner, Art Unit 2431
/LYNN D FEILD/ Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights