DETAILED ACTION
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 Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant’s amendment is considered to have overcome the applied rejection. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Le (US 2016/0202960 A1).
Where Applicant argues that “one of ordinary skill in the art would not modify Bojjireddy to receive data already signed, and confirm the signature, because that would moot Bojjireddy's purpose of creating the secure code and signing it as secure code,” the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the 5/14/2025 Office action specifies that one of ordinary skill in the art would have been motivated to make sure that submitted software code and data are in fact authored by the same person as the authenticated user in [0021]-[0023] of Bojjireddy. Since Bojjireddy receives and processes the code 224 as in FIG. 2 and [0034], it would increase security and trust to verify that the received code is the sent code. Otherwise, the processing of Bojjireddy may end up signing different or malicious code.
Where Applicant argues that “one of ordinary skill in the art would not draw from Allen any reason to modify Bojjireddy's trusted execution environment for protecting code during build time,” it is noted that Allen is now relied upon for the build data further comprising signed build data and the determining step further comprising determining whether the signed build data is valid. It is considered that one of ordinary skill in the art would desire data integrity generally.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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) 1-3 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bojjireddy (US 2019/0180006 A1) in view of Le (US 2016/0202960 A1) and Allen (US 10,805,087 B1).
Regarding claim 1, Bojjireddy discloses: A method of enforcing build-time (e.g., FIG. 2 and [0032] of Bojjireddy) application protection in the cloud, comprising:
receiving, in a cloud computing environment (i.e., conversion service and cloud in [0021] and [0064] of Bojjireddy), from a cloud protection toolchain executing in a build-time environment (i.e., software development pipeline in Bojjireddy—e.g., FIG. 1 and 2), build data (i.e., software program code and data in Bojjireddy), wherein the build data comprises first developer credentials (i.e., developer API key in [0021]-[0023] of Bojjireddy), and protection parameters (e.g., template files in [0046]-[0047] of Bojjireddy) for a build of a first application having one or more unprotected components to be protected (protecting only certain portions of code as per at least [0029] of Bojjireddy);
Refer to at least [0021]-[0023], [0029], [0035], and [0046]-[0048] of Bojjireddy with respect to developers submitting software code and data to be protected by the conversion service, where portions to be protected are indicated. The developers authenticate to the service with their API keys.
determining, in the cloud computing environment, whether the first developer credentials are authorized; and
Refer to at least [0021]-[0023] of Bojjireddy with respect to authenticating via the API keys.
based on the determining, protecting the unprotected components using the protection parameters.
Refer to at least FIG. 3, [0024], [0030], [0033], and [0038] of Bojjireddy with respect to the conversion service outputting a protected version of the software code and data.
Bojjireddy does not disclose: the build data further comprising signed build data and instrumentation parameters; the determining step further comprising determining whether the signed build data is valid; protecting the components further using the instrumentation parameters and in the build-time environment. However, Bojjireddy in view of Le discloses: the build data further comprising instrumentation parameters; protecting the components further using the instrumentation parameters and in the build-time environment.
Refer to at least FIG. 2, [0051], [0053], and [0057]-[0058] of Le with respect to build phase instrumentation and obtaining the associated configuration data.
The teachings of Bojjireddy and Allen concern modifying and securing software code, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bojjireddy-Le to further implement enabling instrumentation for at least the purpose of measuring performance and diagnosing errors.
Bojjireddy-Le does not specify: the build data further comprising signed build data; the determining step further comprising determining whether the signed build data is valid. However, Bojjireddy-Le in view of Allen discloses: the build data further comprising signed build data; the determining step further comprising determining whether the signed build data is valid.
Refer to at least FIG. 2 of Allen with respect to code from an author entity having a signature and digital certificate.
Refer to at least 502-508 FIG. 5 and Col. 9. Ll. 31-53 of Allen with respect to verifying both signed code/patch code and author credentials together; at least Col. 2, Ll. 36-47 of Allen with respect to modifying signed code to enable instrumentation.
The teachings of Bojjireddy-Le and Allen concern modifying and securing software code, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bojjireddy-Le to further include the developer signing their submitted software code and data, as well as to implement obtaining and verifying signed code and data before further transformation, for at least the purpose of improving security by verifying that the submitted software code and data actually belong to the submitting entity at each stage; and that the submitted code and data are the intended code and data to be processed.
Regarding claim 2, it is rejected for substantially the same reasons as claim 1 above (e.g., [0020]-[0021] and [0064] of Bojjireddy with respect to the interfaces).
Regarding claim 3, Bojjireddy-Le-Allen discloses: The method of claim 1, further comprising: collecting second developer credentials; determining that the second developer credentials are not consistent with at least one of the first developer credentials, instrumentation and protection parameters and are therefore not authorized; and based on the unauthorized developer credentials, failing to register the first application.
Refer to at least [0021]-[0023] of Bojjireddy with respect to authenticating users to the service via their respective API keys.
Refer to at least Col. 5, Ll. 35-45 of Allen with respect to a trust store of authorized personnel to be distinguished from unauthorized personnel via their credentials.
Therefore it would have been obvious to modify the teachings of Bojjireddy to further include a trust store of authorized users for at least the purpose of increasing security and allowing implementation of more granular access control policies.
Regarding claim 6, Bojjireddy-Le-Allen discloses: The method of claim 1, further comprising an alerting tool, executing in the cloud computing environment, generating a real-time alert in accordance with the collected protection parameters.
Refer to at least Col. 9, Ll. 37-44 of Allen with respect to outputting a warning responsive to failed verification of submitted code and its associated security information.
Therefore it would have been obvious to modify the teachings of Bojjireddy to further include the conversion service outputting a warning associated with the software code and data for at least the purpose of informing developers of an issue to be corrected (e.g., retrying submission or providing proper credentials).
Claim(s) 4-5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bojjireddy-Le-Allen as applied to claims 1-3 and 6 above, and further in view of Reddy (US 2019/0303579 A1).
Regarding claim 4, Bojjireddy-Li-Allen does not disclose: generating audit data for the build and determining that the first application is authorized based on compliance of the audit data with the collected protection parameters. However, Bojjireddy-Le-Allen in view of Reddy discloses: generating audit data for the build and determining that the first application is authorized based on compliance of the audit data with the collected protection parameters.
Refer to at least FIG. 16, [0027]-[0036], and [0173] of Reddy with respect to auditing and compliance information.
The teachings of Reddy likewise concern protecting application builds, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to modify the teachings of Bojjireddy-Le-Allen to further include auditing and compliance for at least the purpose of tamper protection as per the cited portions of Reddy.
Regarding claim 5, Bojjireddy-Le-Allen-Reddy discloses: The method of claim 4, further comprising a reporting tool, executing in the cloud computing environment, generating a security report based on the audit data, wherein the security report identifies variances from the collected protection parameters.
Refer to at least [0176]-[0178] of Reddy with respect to reports about security properties / compliance of the software asset.
This claim would have been obvious for substantially the same reasons as claim 4 above.
Claim(s) 7-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bojjireddy-Le-Allen as applied to claims 1-3 and 6 above, and further in view of Ismael (US 10,474,813 B1).
Regarding claim 7, Bojjireddy-Le-Allen discloses modifications to customize operation, fix bugs, enable instrumentation, add additional libraries, and to enable software logging or debugging features (e.g., Col. 2, Ll. 36-47 and Col. 3, Ll. 66-Col. 4, Ll. 15 of Allen), but does not specify: defining additional protection policies to track runtime metrics; executing, in a runtime environment, instrumented executables of the first application to generate the runtime metrics, wherein instrumentation is embedded into the instrumented executables according to the additional protection policies; an instrumentation cloud tool, executing in the cloud computing environment, gathering the runtime metrics from the runtime environment; generating, in an audit reporting tool executing in the cloud computing environment, a security report that tracks the runtime metrics and identifies variances from the collected protection parameters ; and transmitting the security report for further processing. However, Bojjireddy-Le-Allen in view of Ismael discloses: defining additional protection policies to track runtime metrics; executing, in a runtime environment, instrumented executables of the first application to generate the runtime metrics, wherein instrumentation is embedded into the instrumented executables according to the additional protection policies; an instrumentation cloud tool, executing in the cloud computing environment, gathering the runtime metrics from the runtime environment;
Refer to at least Col. 5, Ll. 25-46, Col. 7, Ll. 50-55, Col. 9, Ll. 8-35, Col. 10, Ll. 10-13, and Col. 10, Ll. 59-63 of Ismael with respect to instrumentation logic for run-time monitoring.
generating, in an audit reporting tool executing in the cloud computing environment, a security report that tracks the runtime metrics and identifies variances from the collected protection parameters ; and transmitting the security report for further processing.
Refer to at least Col. 10, Ll. 64-Col. 11, Ll. 27 and Col. 15, Ll. 20-33 of Ismael with respect to logging the results of dynamic analysis and identifying malicious changes.
The teachings of Ismael likewise concern modifications to customize operation, fix bugs, enable instrumentation, add additional libraries, and to enable software logging or debugging features. They further concern virtualization and containers. Accordingly, they are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to modify the teachings of Bojjireddy-Le-Allen to further include enabling malware classification via additional instrumentation logic for dynamic analysis and logging functionality for at least the purpose of further securing the converted application (i.e., at runtime).
Regarding claim 8, it is rejected for substantially the same reasons as claim 7 above (i.e., the citations and obviousness rationale).
Regarding claim 9, Bojjireddy-Le-Allen-Ismael discloses: The method of claim 7, further comprising an alerting tool, executing in the cloud computing environment, generating a real-time alert notification based on the runtime metrics exceeding a predefined threshold as defined in the collected protection parameters.
Refer to at least Col. 18, Ll. 7-10 of Ismael with respect to a warning concerning detection of malware and application of remediation.
Refer to at least Col. 14, Ll. 40-47 of Ismael with respect to a configured threshold for detection of malware.
This claim would have been obvious for substantially the same reasons as claim 7 above (i.e., additional security).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432