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 .
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.
Claims 1, 13-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kolawa et la. (US 7,877,780 B2) and further in view of David et al. (US 2017/0315903 A1).
As per claim 1, Kolawa et al. teaches the claimed invention including, “A computer system for confirming whether user generated code meets defined coding standards, the computer system comprising:
a conversion module configured to receive one or more text documents including defined coding standards and generate an executable computer program code based on the defined coding standards;”
Kolawa et al. teaches security policies involve how the code needs to be written so that is not vulnerable to attack (column 3, lines 49-50). A natural language policy is converted into sample code through an interpretation of the policies (column 4, lines 18-21). Also see column 4, lines 56-65.
“a violation module in communication with the conversion module, the violation module configured to receive the computer program code and user generated code, and execute the computer program code to determine whether one or more violations of the defined coding standards are present in the user generated code; and”
Kolawa et al. teaches in block 104, static analysis rules are created on the same code which represents the policy. The created static analysis rules enforce code that represents the policy (column 4, lines 20-55). Also see column 5,lines 10-14. Once the static analysis rules have been implemented to enforce the security policy, they are included in a static analysis configuration and can be run unobtrusively as part of an automated nightly test build to ensure that violations are identified as soon as they are introduced. By referring to the security policy, developers can understand why these violations are security vulnerabilities, as well as how to fix the problem and secure the code (column 6,lines 34-50). Also see abstract and figure 1.
Kolawa et al. teaches does not explicitly appear to teach, “an alert module in communication with the violation module, the alert module configured to, in response to the one or more violations being present in the user generated code, generate a notification indicating the one or more violations of the defined coding standards in the user generated code.”
David et al. teaches a report generator that generates a report listing the coding rule violations identified by a defect finder (0031). Also see 0089—0091 and 0108.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kolawa et al. with David et al. because both teach using static analysis to determine code violations. Kolawa et al. does not explicitly teach generating a report/notification of a coding violation however, this is well known to one of ordinary skill in the art as can be seen in David et al. Reporting violation would allow a developer to know the existence of an issue and give them information to solve it.
As per claim 13, David et al. further teaches, “The computer system of claim 1, wherein the alert module is configured to transmit the notification to a computing device used by an individual to generate the user generated code.”
A report generator generates one or more reports containing the results of the defect detection processing. The report generator may output the one or more reports. The report generator may present the annotated and/or commented version of the code in a code editor window presented on a display (0089-0091).
As per claim 14, David et al. further teaches, “The computer system of claim 13, wherein the notification is a visual notification or an audible notification.”
A report generator generates one or more reports containing the results of the defect detection processing. The report generator may output the one or more reports. The report generator may present the annotated and/or commented version of the code in a code editor window presented on a display (0089-0091).
As per claims 15-16 and 20, they contain similar limitations to claim 1 and 13 and are therefore rejected for similar reasons.
Claims 2-6 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Kolawa et la. (US 7,877,780 B2) and David et al. (US 2017/0315903 A1) as applied to claims 1 and 15 above, and further in Groeneween et al. (US 2024/0004623 A1).
As per claim 2, Kolawa et al. teaches in many cases, the static analysis tool can automatically correct the code so that it complies with the security policy (column 4, lines 9-12). However, Kolawa et al. does not explicitly appear to teach, “The computer system of claim 1, further comprising a recommendation module configured to receive the user generated code and generate one or more recommendations based on the user generated code and one or more previous coding examples.”
Groeneween et al. teaches selecting syntax subtree code which that corresponds to a weak spot found by the weak spot analysis operations and submit the context of the syntax subtree code to a weakness fixer to automatically receive a fix candidate from the weakness fixer (0004). Also see 0020, 0044, 0047, 005, 0063, 0078 and 0206-0209.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kolawa et al. with Groeneween et al. because both teach using static analysis to determine vulnerabilities in code. Kolwa et al. teaches issue/vulnerabilities can be automatically corrected but does not explicitly teach how. Groeneween et al. teaches the use of AI to determine fixes. Finding weak spots in software code and offering suitable suggestions to fix them will improve developer efficiency and code quality and therefore would have been obvious to try.
As per claim 3, Groeneween et al. further teaches, “The computer system of claim 2, wherein the alert module is configured to receive the one or more recommendations from the recommendation module and generate the notification indicating the one or more recommendations.”
Code strengthening suggestions are presented (0004). A suggestion may include one or more fix candidates, and may also include related data such as a confidence score (0209). Also see 0064 and 0078. Refer to claim 2 for the motivation to combine.
As per claim 4, Groeneween et al. further teaches, “The computer system of claim 2, wherein the recommendation module includes a cognitive model trained based on the one or more previous coding examples.”
Groeneween et al. teaches the use of AI assisted fixers (0020). Also see 0044, 0081, 0091. The suggest is made using a trained machine learning model (0091). The AI-based fixer could be trained on labeled data which includes common mistakes and their respective fixes (0101). Refer to claim 2 for the motivation to combine.
As per claim 5, Groeneween et al. further teaches, “The computer system of claim 4, wherein the cognitive model is configured to:
identify a completion state of the user generated code; and
generate the one or more recommendations based on the one or more previous coding examples at a completion state of previously generated code corresponding to the completion state of the user generated code.”
Groeneween et al. teaches the use of AI assisted fixers (0020). Also see 0044, 0081, 0091. The suggest is made using a trained machine learning model (0091). The AI-based fixer could be trained on labeled data which includes common mistakes and their respective fixes (0101). The software receives a set of several suggestions (fix candidates) and chooses an optimal one or a optimal subset to present to the user. The set of fix candidates can collectively come from one or more weakness fixers. The optimal subset may be chosen based on a ranking. Ranking may be based on number of compiler errors generated, similarity in the user of variable names, number of unit tests passed, code generator confidence scores, or a combination thereof (0063). Refer to claim 2 for the motivation to combine.
As per claim 6, Groeneween et al. further teaches, “The computer system of claim 5, wherein the identified completion state of the user generated code is a numerical representation.”
Groeneween et al. teaches the set of fix candidates can collectively come from one or more weakness fixers. The optimal subset may be chosen based on a ranking. Ranking may be based on number of compiler errors generated, similarity in the user of variable names, number of unit tests passed, code generator confidence scores, or a combination thereof (0063). Refer to claim 2 for the motivation to combine.
As per claim 17-18, they contain similar limitations to claim 2-5 and are therefor rejected for similar reasons.
Claims 7-12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over over Kolawa et la. (US 7,877,780 B2) and David et al. (US 2017/0315903 A1) as applied to claims 1 and 15 above, and further in Lassoued et al. (US 2020/0367807 A1)
As per claim 7, Kolawa et al. and David et al. do not explicitly appear to teach, “ The computer system of claim 1, further comprising:
at least one sensor configured to monitor a characteristic of an individual while the individual is generating the user generated code; and
a cognitive state module configured to receive the characteristic from the sensor and determine whether the individual is experiencing a degraded cognitive state based on the characteristic and a threshold.”
Lassoued et al. teaches intelligent monitoring of the health state of a user which engaged in use of a computer device (0015). A determined health state can be a users stress level being below and/or above a defined threshold and one or more mitigation actions are suggested (0016). A determined health state of a user may be characterized by one or more measurable parameters such as, stress level, sleepiness, fatigue/tiredness, emotional state/mood, etc. A health state parameter may be measured by a device such as a sensor (0018). Also see figure 4. User computer activities that are monitored include programming in a computing programming language (0027). Also see 0073.
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Kolawa et al. Groeneween et al. and David et al. with Lassoued et al. All three references Kolawa et al. Groeneween et al. and David et al. teach the use of static analysis to determine vulnerabilities of code. Lassoued et al. teaches monitoring a user using a computer such as programming to determine their health state such as their stress level and recommends an action to correct/mitigate it. This will allow the programmer of Kolawa et al. Groeneween et al. and David et al. to be monitored and recommend them to take a break or some other action when their stress is high which will improve their computer use and therefore would have been obvious to try.
As per claim 8, Lassoued et al. further teaches, “The computer system of claim 7, wherein:
the cognitive state module is in communication with the alert module;
the cognitive state module is configured to generate one or more recommendations in response to the individual experiencing the degraded cognitive state; and
the alert module is configured to generate the notification indicating the one or more recommendations.”
Lassoued et al. teaches a determined health state can be a user’s stress level being below and/or above a defined threshold and one or more mitigation actions are suggested (0016). A notification is generated when stress or fatigue is detected and displayed in a GUI (0091). Also see figure 4. Refer to claim 7 for the motivation to combine.
As per claim 9, Lassoued et al. further teaches, “The computer system of claim 8, wherein the one or more recommendations includes a physical action for the individual or a user interface action for a computing device used by the individual to generate the user generated code.”
A mitigation action can include the user postponing action, swapping/changing tasks and/or getting up and walking (0016). Refer to claim 7 for the motivation to combine.
As per claim 10, Lassoued et al. further teaches, “The computer system of claim 7, wherein the at least one sensor includes an on-body sensor attached to the individual to monitor a physiological characteristic of the individual while the individual is generating the user generated code.”
The sensor can be on body such as a heart rate monitor, watch, and/or temperature sensor (0023). Refer to claim 7 for the motivation to combine.
As per claim 11, Lassoued et al. further teaches, “The computer system of claim 7, wherein the at least one sensor includes an off-body sensor remote from the individual to monitor a behavioral characteristic of the individual while the individual is generating the user generated code.”
The sensor can also be off body such as a IOT device, computer and/or tablet (0023). Refer to claim 7 for the motivation to combine.
As per claim 12, Lassoued et al. further teaches, “The computer system of claim 7, wherein the threshold is an adjustable threshold specific to the individual.”
Calculations can be performed to find a threshold (0034). The health states of a user can be monitored by keeping/maintained, one or more parameters representing a characteristic, feature, or property of the health state of the user, below, above, and/or equal to a defined threshold (depending on the parameter) to avoid defined/extended periods/peeks of exposure of the one or more parameters to the user (0073). Also see 0078and 0082-0083. Refer to claim 7 for the motivation to combine.
As per claim 19, it contains similar limitations to claim 7-8 and are therefore rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights