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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/19/2025 has been entered.
Response to Arguments
The present office action is responsive to communication filed on 12/19/2025. Claims 1 and 7 have been amended. Claims 5 and 11 have been cancelled. Claims 3 and 9 have been previously cancelled. Claims 1, 2, 4, 6, 7, 8, and 10 are currently pending.
In the remarks filed 08/01/2025, applicant traversed the then-pending rejection under 35 U.S.C. 101 and presented arguments on pages 6–9 asserting that the independent claims are not directed to an abstract idea and, alternatively, that the recited limitations integrate any alleged judicial exception into a practical application and provide “significantly more” under the 2019 Revised Patent Subject Matter Eligibility Guidance. Those arguments formed the basis for withdrawal of the 101 rejection in the final Office action mailed 11/06/2025. Upon reconsideration of the application after the filing of the RCE, and in view of the present claim set and current subject-matter eligibility guidance (MPEP 2106; 2019 PEG), the Office is not persuaded by the positions taken in applicant’s 08/01/2025 remarks for the reasons set forth in the 35 U.S.C. 101 analysis below and the response to arguments as follows:
“Claim 1-6 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. The claim recites unit test case-based security design flaw detection method which appears to be a 'process' and one of the four statutory categories of invention (Step 1 of the Subject Matter Eligibility Test); and Claim 7-11 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. The claim recites unit test case-based security design flaw detection method which appears to be a 'process' and one of the four statutory categories of invention (Step 1 of the Subject Matter Eligibility Test). This rejection is respectfully traversed. While not conceding the appropriates of the Examiner's rejections, but merely to advance prosecution of the instant application, independent claims 1 and 7 have been amended in a manner that they as a whole present integrate the exception into a practical application through a specific and meaningful improvement in the field of software security testing. Claim 1 now reads (Emphasis added): A unit test case-based security design flaw detection method performed in a security design flaw detection apparatus for detecting a security design flaw of a software system, the method comprising: collecting a unit test case for the software system from an external device and preprocessing the unit test case; generating a first test case by testing whether the software system violates a security policy using the preprocessed unit test case; generating a second test case that is a data set for testing a function of the software system based on the first test case; and detecting a vulnerability of the software system by executing the second test case, wherein generating the first test case comprises, performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case. Step 2A, Prong One - The Claims Are Not Directed to a Judicial Exception Alone The Examiner asserts that the claims are directed to a mental process-namely, collecting, analyzing, and displaying data in a way that could be performed in the human mind. Applicant respectfully disagrees with the Examiner because Applicant believes that this assertion is based on a mischaracterization of the claimed invention. The present claims do not merely analyze data at a high level of generality. Rather, the claimed method includes specific technical steps for detecting software vulnerabilities by automatically generating test cases and applying three distinct and concrete security policy check, such as access control, integrity, and confidentiality, based on the processed unit test case. These steps practically cannot be performed by the human mind, as they require interactions with the software system under test and involve automated generation and execution of test cases using real system inputs. The operations go beyond mental processes or generic data analysis, and they are grounded in a structured, technical solution for enhancing software security verification. Step 2A, Prong Two - The Claims Integrate the Exception Into a Practical Application Assuming arguendo the claims to recite a judicial exception, which Applicant does not concede, the claims as a whole clearly integrate this exception into a practical application. At least the following elements, which were added by the present amendment, demonstrate this: performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case. These features are not generic or abstract functions. Rather, they represent concrete technical operations performed during automated test case generation, providing a structured framework for identifying specific classes of security vulnerabilities in a software system. This process results in an improved software testing mechanism that goes beyond conventional unit testing. It does not simply append a security check, but transforms how security flaws are detected, leveraging automated, policy-based testing within a software test execution environment. Step 2B - The Claims Recite Significantly More Than a Judicial Exception Furthermore, the claims also provide "significantly more" than the alleged abstract idea. The combination of the features of preprocessing the unit test case, automatically generating functional test cases based on the result of layered security policy checks, and executing these for vulnerability detection constitutes a non-conventional and non-generic arrangement of steps that improves the functioning of the software testing process. The Examiner's assertion that these steps could be performed by one of ordinary skill in the art is conclusory and unsupported by evidence. The claimed invention is not a generic automation of human activity; it is a specific technical implementation of multi-layered security policy enforcement during test generation, which is neither routine nor well-understood in the art, In conclusion, the amended Claim 1 comprises at least the additional step of performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case, performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case, and performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case. This additional step, combined with the other recited steps, enables the computer system to be improved in its processing accuracy, efficiency, and speed in detecting a security design flaw of a software system. This improvement to the function (i.e., processing efficiency and speed) of a computer is one of the limitations that are indicative of integration into a practical application (see MPEP 2106.05(a)). Therefore, the respective claims as a whole are not directed to an abstract idea of not including additional elements that are sufficient to amount to significantly more than the judicial exception, but directed to the security design flaw detection method operating the additional steps related to the improvement to the functions of a computer, and thus goes beyond the enumerated abstract ideas and respectively directed to patent eligible subject. Accordingly, it is respectively submitted that the pending claims are directed to patent- eligible subject matter because they do not invoke any other judicial exception. Based on the foregoing, this rejection under 35 U.S.C. § 101 is respectfully requested to be withdrawn.”
Examiner respectfully disagrees. Applicant’s contention that the amended independent claims are no longer directed to a judicial exception is not persuasive because, under the broadest reasonable interpretation and in view of the 2019 Revised Patent Subject Matter Eligibility Guidance and MPEP 2106, the claims still recite nothing more than collecting, analyzing, and generating data according to security rules to detect software vulnerabilities, which is an abstract idea. The added limitations relating to the three “specific” security policy tests (access control, integrity, confidentiality) and the automatic generation and execution of test cases are, in substance, rule based evaluation and manipulation of information about software behavior, and thus fall squarely within the abstract idea groupings (mental processes and data analysis) identified in the 2019 guidance, even though they are implemented on a computer. Applicant’s argument under Step 2A, Prong One that the claimed steps “practically cannot be performed by the human mind” because they involve interactions with a software system and use “real system inputs” is not dispositive. The eligibility inquiry turns on the character of the claimed operations, not whether a human would realistically perform them at scale. Here, the operations include receiving test code, applying security rules to that code, creating additional test code based on the results, executing the code, and drawing a conclusion about the presence of vulnerabilities, which are all forms of information analysis and evaluation. That they are carried out in an automated testing environment does not change the fact that the claim is directed to an abstract data-analysis concept akin to those found ineligible in cases such as Electric Power Group and Recentive.
Nor is applicant’s Step 2A, Prong Two position persuasive. The fact that the abstract idea is applied in the specific field of software security testing, and that the security policies are organized as a “first,” “second,” and “third” test, amounts at most to a field of use and to specifying the content of the rules being applied, which the 2019 guidance treats as insufficient to integrate a judicial exception into a practical application. The recited “security design flaw detection apparatus,” “external device,” and execution of test cases on a “software system” are implemented on standard computer hardware and networks as described in the specification and do not represent an improvement to the functioning of a computer itself or to another technology in the sense contemplated by MPEP 2106.05(a). No particular machine beyond a generic computer is claimed, no transformation of an article to a different state or thing is affected beyond manipulation of information, and the additional steps of collecting unit tests and executing generated tests are merely data gathering and post-solution activity. Thus, the additional elements do not meaningfully limit the abstract idea so as to integrate it into a practical application.
Applicant’s Step 2B argument that the combination of preprocessing unit test cases, layered policy checks, and automatic test generation and execution is “non-conventional and non-generic” is also unavailing. The specification describes implementing the claimed method on a conventional Ubuntu Linux system using ordinary processors, memory, communication, and storage, and characterizes the components as software modules performing expected roles such as crawling repositories, classifying and parsing code, applying security policies, generating fuzzed test inputs, and executing tests. These are typical operations of automated testing and security tools, and applicant has not pointed to any recited claim element or combination that effects a technological change in how the computer or network itself operates, as opposed to using the computer as a tool to perform security analysis. Assertions that the claimed method improves “processing accuracy, efficiency, and speed” of security testing are not tied to any specific technical mechanism in the claim and therefore amount to no more than the generic benefit of automating an abstract process on a computer, which the 2019 guidance and MPEP 2106.05 make clear is insufficient to supply an inventive concept. In the absence of concrete, non-generic implementation details in the claim that change the way the computer performs these operations at a technical level, the additional elements, individually and in combination, are well-understood, routine, and conventional activities in the field. Accordingly, the amended claims remain directed to an abstract idea under Step 2A and do not recite additional elements that amount to “significantly more” under Step 2B, and the rejection under 35 U.S.C. 101 is reasserted.
Applicant’s arguments filed 12/19/2025, with respect to the rejections of claims 1-4 and 6-10 under 35 USC 103, as seen in pages 6-9 of the Remarks, over Hicks et al (US PGPub No. 20210034755-A1 ) in view of Kotler et al. (US PGPub No. 20160306980-A1) and Sabanayagam et al. (US PGPub No. 20200167268-A1) with the amended limitation of the generation of the second case are met have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new ground of rejection is made in additional view of Baba et al. (US PGPub No. 20210365355-A1).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
…a preprocessing unit … in claim 7.
…a security policy test unit… in claim 7.
…a test case generation unit… in claim 7.
…a vulnerability detection unit… in claim 7.
…an access control check unit… in claim 7.
…a data integrity verification unit… in claim 7.
…a data confidentiality unit… in claim 7.
…a random generation unit… in claim 7.
…a combination generation unit… in claim 7.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7, 8, and 10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitation a “ preprocessing unit ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a preprocessing unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “security policy test unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a security policy test unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “a test generation unit ” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a test generation unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “vulnerability detection unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a vulnerability detection unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “access control check unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a access control check unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “data integrity verification unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a data integrity verification unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “data confidentiality unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a data confidentiality unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “random generation unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a random generation unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim limitation a “combination generation unit” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The limitation of a combination generation unit is not defined by the claims, the specification further does not provide a structure for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the score of the invention. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Regarding claims 8 and 10:
Claims 8 and 10 do not add apply additional elements than those already disclosed in claim 1, and merely adds indefiniteness. Furthermore, none of the claims further elaborated the structure of the claim limitations.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 2, 4, 6, 7, 8, and 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself, in accordance with 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) and MPEP 2106.
The claim 1 recites a method which appears to be a ‘process’ and one of the four statutory subject matter categories of inventions (Step 1 of the Subject Matter Eligibility Test).
However, the claim appears to not qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test).
In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of:
“…collecting a unit test case for the software system from an external device and preprocessing the unit test case…”
“…generating a first test case by testing whether the software system violates a security policy using the preprocessed unit test case…”
“… generating a second test case that is a data set for testing a function of the software system based on the first test case…”
“...detecting a vulnerability of the software system by executing the second test case…”
“...performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case…”
“…performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case…”
“…performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case...”
The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of: collecting and preprocessing data (e.g., unit test cases from an external device) , evaluating the data using rules (e.g., applying security policies: access control, integrity confidentiality), generating additional data based on evaluations (i.e., first and second test cases) , and interpreting execution results of the second test case to detect a vulnerability. The steps of performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of the Subject Matter Eligibility). The abstract idea falls in the category. The abstract idea falls in the category of a mental process, for example, evaluation, judgements, and opinion (MPEP 2106.06). The acts of collecting, analyzing, and manipulating information according to rules to reach a conclusion (i.e., presence or absence of vulnerabilities), fits into the “mental processes” grouping of abstract ideas in accords to the 2019 PEG (concepts that can be performed in the human mind or using pen and paper, as well as the “certain methods of organizing human activity” category to the extent they involve rule-based evaluation and decision-making. For example, the courts found that a claim to “collecting information, analyzing it, and displaying certain results of the collection and analysis”, where the data analysis steps are recited at a high level of generality, could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353‐54, 119 USPQ2d 1739, 1741‐42 (Fed. Cir. 2016).
In Step 2A, Prong Two, examiner determine whether the claim integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 1 Is not integrated into practical application because the generically recited computer elements do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using computer implementation and large scale automation, reviewing test inputs, checking them against security rules, generating further test cases, and deciding whether vulnerability enabling human decision making without using automated software testing in any meaningful way to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984.
Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial exception.
Regarding claims 2, 4, and 6:
Claims 2, 4, and 6 do not add any additional elements than those already disclosed in claim 1, and merely further abstract ideas. Further, none of the claims integrated the judicial exception into practical application.
The claim 7 recites an apparatus which appears to be a ‘machine’ and one of the four statutory subject matter categories of inventions (Step 1 of the Subject Matter Eligibility Test).
However, the claim appears to not qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test).
In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of:
“…collecting a unit test case for the software system from an external device and preprocessing the unit test case…”
“…a test case generation unit for generating a second test case that is a data set for testing a function of the software system based on the first test case…”
“…. a vulnerability detection unit for detecting a vulnerability of the software system by executing the second test case…”
“…a data integrity verification unit for performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case…”
“….a data confidentiality unit for performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case…”
“…wherein the test case generation unit comprises, a random generation unit for generating the second test case by manipulating the first test case with a randomly generated data type and value; and a combination generation unit for generating the second testcase by combining an unpreprocessed unit test case with the first test case…”
The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of: collecting and preprocessing data (e.g., unit test cases from an external device) , evaluating the data using rules (e.g., applying security policies: access control, integrity confidentiality), generating additional data based on evaluations (i.e., first and second test cases) , and interpreting execution results of the second test case to detect a vulnerability. The steps of performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of the Subject Matter Eligibility). The abstract idea falls in the category. The abstract idea falls in the category of a mental process, for example, evaluation, judgements, and opinion (MPEP 2106.06). The acts of collecting, analyzing, and manipulating information according to rules to reach a conclusion (i.e., presence or absence of vulnerabilities), fits into the “mental processes” grouping of abstract ideas in accords to the 2019 PEG (concepts that can be performed in the human mind or using pen and paper, as well as the “certain methods of organizing human activity” category to the extent they involve rule-based evaluation and decision-making. For example, the courts found that a claim to “collecting information, analyzing it, and displaying certain results of the collection and analysis”, where the data analysis steps are recited at a high level of generality, could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353‐54, 119 USPQ2d 1739, 1741‐42 (Fed. Cir. 2016).
In Step 2A, Prong Two, examiner determine whether the claim as a whole integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 7 is not integrated into practical application because the generically recited computer elements:
“…unit case-based security design flaw detection apparatus…”
“… a preprocessing unit…”
“…a security policy test unit…”
“…a test generation unit…”
“… a vulnerability detection unit…”
“…data confidentiality unit…”
“…a random generation unit…”
“…a combination generation unit…”
do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using computer implementation and large scale automation, reviewing test inputs, checking them against security rules, generating further test cases, and deciding whether vulnerability enabling human decision making without using automated software testing in any meaningful way to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984.
Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial exception.
Regarding to claims 8 and 10
Claims 8 and 10 do not add any additional elements than those already disclosed in claim 7, and merely adds further abstract ideas. Furthermore, none of the claims integrate the judicial exception into a practical application.
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.
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.
Claims 1-4 and 6-10 are rejected under 35 U.S.C. 103 as being unpatentable over Hicks et al (US PGPub No. 20210034755-A1 ) in view of Kotler et al. (US PGPub No. 20160306980-A1), Sabanayagam et al. (US PGPub No. 20200167268-A1), and Baba et al. (US PGPub No. 20210365355-A1).
With respect to claim 1, Hicks teaches a unit test case-based security design flaw detection method performed in a security design flaw detection apparatus for detecting a security design flaw of a software system, (Abstract: The method further includes executing the penetration test and detecting an unauthorized access being performed during the penetration test. ).
the method comprising: collecting a unit test case for the software system from an external device and preprocessing the unit test case; (¶0034: As depicted in Figure 2, a method to automatically generate penetration tests and testing security of computer system according to one or more embodiments of the present invention. The method includes running an existing system test, at block 210. The system test is a test that is used to test the functionality of the computer program. The system test can be one from a set of multiple system tests that are developed for the computer program. All the system tests can be used to generate respective penetration tests. ).
generating a first test case by testing whether the software system violates a security policy using the preprocessed unit test case; (¶0035: In this regards, in one or more embodiments of the present invention, the execution of the system test is monitored to identify if a predetermined PC or SVC is invoked by the system test, at block 220. The PC and/or SVC can be one from predetermined list of PCs and/or SVCs. Monitoring the PC and/or SVC can include monitoring for a particular system signal from a specific list of system signals, for example, an interrupt, an abort, illegal instruction, erroneous arithmetic instruction, or any other such system-level signals. ).
generating a second test case that is a data set for testing a function of the software system based on the first test case; and (¶0037: Further, the method includes generating a penetration test by adjusting the system test and setting up a framework to detect the vulnerability, at block 230. For example, the PC/SVC in the system test is adjusted according to an entry in a predetermined attack vector. Further in Figure 3, depicts a block diagram to visualize a generation of a penetration test from an existing system test according to one or more embodiments of the present invention. Here, the system test 310 includes a PC/SVC 312.);
detecting a vulnerability of the software system by executing the second test case, (¶0088-0089: Upon dispatching and testing the target software by both the fitting and analysis service 218 and the dispatcher 206, the reporting service may aggregate a report of testing results. In at least one implementation, the reporting service 222 may categorize vulnerabilities that are identified into different groupings such as flaws, faults, failures, crashes, exploits, and/or other groupings. These categorized vulnerabilities may be further organized and normalized such that similar defects are presented in a meaningful manner to a developer.).
Hicks does not disclose:
a unit test case for the software system from an external device
However, Sabanayagam teaches a unit test case for the software system from an external device (¶0025: As seen in Figure 1, in operation, the unit test generation engine 106 is configured to retrieve the codebase extract from the repository on receiving a request for generation of a unit test for a selected class or method. The unit test generation engine 106 analyses the code base extract and identifies one or more potential executable paths within the selected method using a path solving technique.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Sabanayagam with regards an external device to the method of Hicks in order to provide a cost effective way and provides superior performance (Sabanayagam ¶0004).
Hicks in view Sabanayagam of does not disclose:
software system violates a security policy using the preprocessed unit test case;
wherein generating the first test case comprises, performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case.
However, Kotler teaches software system violates a security policy using the preprocessed unit test case; (¶0032: Breach scenario (or simply referred to as a breach)—as used herein, is generally intended to include one or more malicious actions that represent a scenario that was found successful from an attacker point of view (e.g., by playing a sequence of moves in a scenario on one or more defined devices) and violating a security policy; Scenario—as used herein, is generally intended to include a sequence of playbook moves executed over specific devices (e.g., by simulation) in attempt to violate a security policy (e.g., from device A, exploit operating system (OS) vulnerability on device B to run a remote process that will read finance report file from the local disk, encrypt it using some given key, and send it as attachment by using Gmail Simple Mail Transfer Protocol (SMTP) service to a given email address); ¶0060: As seen in Figure 1, the data platform 106 may analyze raw simulation events from the queue, identify full breach scenarios, and identify or produce breach scenario events. In one or more embodiments, data platform 106 may further provide reporting, online/cloud analytical processing, analytics, data mining, process mining, complex event processing, benchmarking, predictive analytics and prescriptive analytics.);
wherein generating the first test case comprises, performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; ( ¶0077-¶0083 & ¶0179: Figure 4 presents a flowchart of a method for preparing a breach simulation for verification invention. The method allows for the verification of a breach by determining proper execution of breach tasks and whether data received and transmitted from all parties involved in a breach are consistent with a breach. The prepared tasks are sent to the simulator nodes, step 404. Sending a task to a simulator node may include loading data onto a simulator node module, loading the data onto a programmable chip or memory for execution by a processor/processor core, or generating a virtual device configured to perform the task. Each simulator node may represent one or more parties (e.g., client devices and servers), devices, networks, and systems participating in a breach scenario. Tasks on the simulator nodes are executed/simulated, step 406. Kotler ¶0161: Scenario 4 – Compliance & Security Policy: Security policy is a definition of what it means to be secure for a system, organization or other entity. For systems, the security policy addresses on functions and flow among them, constraint on access by external systems and adversaries including programs and access to data by people. ).
performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and (¶0140-0141: Simulator A will simulate a HTTP Server with an interactive form. Simulator B will simulate a SQL injection scanner. Simulator A will connect to the HTTP server and start “enumerating” different SQL injection attacks using the interactive form fields. Or Simulator A will simulate an application within a container (e.g., Mobile Application Management Solution). Simulator B will simulate a server with exposed TCP port on production site. Simulator A will attempt to scan the simulated server and reach the open TCP port.);
performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case. (¶0166: Scenario 4.2—Health Insurance Portability and Accountability Act (HIPAA)/Protected Health Information (PHI) Encryption: The security rule does not expressly prohibit the use of email for sending electronic PHI. However, the standards for access control (45 CFR §164.312(a)), integrity (45 CFR §164.312(c)(1)), and transmission security (45 CFR §164.312(e)(1)) require covered entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against the unauthorized access to electronic PHI sent and received over email communications. The standard for transmission security (§164.312(e)) has been updated to enforce the use of encryption. This means that each covered entity must assess its use of open networks, identify the available and appropriate means to protect electronic PHI as it is transmitted, select a solution, and document the decision. The security rule allows for electronic PHI to be sent over an electronic open network as long as it is adequately protected.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kolter with regards to violation to security policy to the method of Hicks in view of Sabanayagam in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
Hicks in view of Sabanayagam and Kotler does not disclose:
wherein generating the second test case comprises, generating the second test case by manipulating the first test case with a randomly generated data type and value, or generating the second test case by combining an unprocessed unit test case with the first test case.
However, Baba teaches wherein generating the second test case comprises, generating the second test case by manipulating the first test case with a randomly generated data type and value, or generating the second test case by combining an unprocessed unit test case with the first test case. (¶0061: The test generation unit 170 the generates the i-th test case by joining (i-1)-th test case and the test case for the i-th step and stores the i-th test case in memory 920. Alternatively, the test generation unit 170 use the test generation function to generate respective test cases for the first step to the i-th step, in accordance the second generation scheme M2. The test generation unit 170 then generates the i-th test case by joining the test cases for the first step to the i-th step and stores th i-th test case in the memory 920. As further exemplified in ¶0072 and Figure 2, within Step S6, the non-symbol generation unit 150 joins the test case generated from the (i−1) steps and a test case candidate for an i-th step which is randomly generated on the basis of the specification information read in step S1. The non-symbol generation unit 150 then regards a joined test case as a test case candidate for i steps and the process advances to step S7. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Baba with regards to generating the second test case by manipulating the first test case with a randomly generated data type and value to the method of Hicks in view of Sabanayagam and Kotler in order to reduce the time period to generate a new test case (Baba ¶0015).
With respect to claim 4, the combination of Hicks in view of Sabanayagam, Kotler, and Baba teaches the method of claim 1 (see rejection of claim 1 above) wherein the first security policy test, the second security policy test, and the third security policy test are performed according to a preset order. (Kolter ¶0083:As seen in Figure 4, Breach simulation task(s) are prepared by the simulation orchestrator, step 402. Preparing the breach simulation task(s) may include reading a configuration for a specific breach scenario type and preparing a list of tasks to be simulated, taking into account one or more moves in a playbook, one or more configured data assets, and simulator nodes in the system, etc. A breach scenario may comprise a sequence of one or more moves applied on the simulator nodes with specific configurations, data assets, etc. The simulation orchestrator can prepare tasks for all participating parties (characterized by simulator nodes) involved in a given simulation. A simulation can occur on a single simulator node or between multiple simulator nodes.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kolter with regards to violation to security policy to the method of Hicks in view of Sabanayagam and Baba in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
With respect to claim 6, the combination of Hicks in view of Sabanayagam, Kotler, and Baba teaches the method of claim 1 (see rejection of claim 1 above) a computer-readable storage medium, storing a computer program for performing the unit test case-based security design flaw detection method according to claim 1. (Hicks ¶0005: According to one or more embodiments of the present invention, a computer program product comprising a computer-readable memory that has computer-executable instructions stored thereupon, the computer-executable instructions when executed by a processor cause the processor to perform a method.)
With respect to claim 7, Hicks teaches a unit test case-based security design flaw detection apparatus(¶0052- 0053: These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks..) for detecting a security design flaw of a software system, the apparatus comprising: (Abstract: The method further includes executing the penetration test and detecting an unauthorized access being performed during the penetration test. ).
a preprocessing unit for collecting a unit test case for the software system from an external device and preprocessing the unit test case; (¶0034: As depicted in Figure 2, a method to automatically generate penetration tests and testing security of computer system according to one or more embodiments of the present invention. The method includes running an existing system test, at block 210. The system test is a test that is used to test the functionality of the computer program. The system test can be one from a set of multiple system tests that are developed for the computer program. All the system tests can be used to generate respective penetration tests. ).
a security policy test unit for generating a first test case by testing whether the software system violates a security policy using the preprocessed unit test case; (¶0035: In this regards, in one or more embodiments of the present invention, the execution of the system test is monitored to identify if a predetermined PC or SVC is invoked by the system test, at block 220. The PC and/or SVC can be one from predetermined list of PCs and/or SVCs. Monitoring the PC and/or SVC can include monitoring for a particular system signal from a specific list of system signals, for example, an interrupt, an abort, illegal instruction, erroneous arithmetic instruction, or any other such system-level signals. ).
a test case generation unit for generating a second test case that is a data set for testing a function of the software system based on the first test case; and(¶0037: Further, the method includes generating a penetration test by adjusting the system test and setting up a framework to detect the vulnerability, at block 230. For example, the PC/SVC in the system test is adjusted according to an entry in a predetermined attack vector. Further in Figure 3, depicts a block diagram to visualize a generation of a penetration test from an existing system test according to one or more embodiments of the present invention. Here, the system test 310 includes a PC/SVC 312.).
a vulnerability detection unit for detecting a vulnerability of the software system by executing the second test case. (¶0088-0089: Upon dispatching and testing the target software by both the fitting and analysis service 218 and the dispatcher 206, the reporting service may aggregate a report of testing results. In at least one implementation, the reporting service 222 may categorize vulnerabilities that are identified into different groupings such as flaws, faults, failures, crashes, exploits, and/or other groupings. These categorized vulnerabilities may be further organized and normalized such that similar defects are presented in a meaningful manner to a developer.)
Hicks does not disclose:
a unit test case for the software system from an external device
However, Sabanayagam teaches a unit test case for the software system from an external device (¶0025: As seen in Figure 1, in operation, the unit test generation engine 106 is configured to retrieve the codebase extract from the repository on receiving a request for generation of a unit test for a selected class or method. The unit test generation engine 106 analyses the code base extract and identifies one or more potential executable paths within the selected method using a path solving technique.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Sabanayagam with regards an external device to the method of Hicks in order to provide a cost effective way and provides superior performance (Sabanayagam ¶0004).
Hicks in view Sabanayagam of does not disclose:
software system violates a security policy using the preprocessed unit test case;
wherein the security policy test unit comprises, an access control check unit for performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; a data integrity verification unit for performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and a data confidentiality unit for performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case.
However, Kotler teaches software system violates a security policy using the preprocessed unit test case; (¶0032: Breach scenario (or simply referred to as a breach)—as used herein, is generally intended to include one or more malicious actions that represent a scenario that was found successful from an attacker point of view (e.g., by playing a sequence of moves in a scenario on one or more defined devices) and violating a security policy; Scenario—as used herein, is generally intended to include a sequence of playbook moves executed over specific devices (e.g., by simulation) in attempt to violate a security policy (e.g., from device A, exploit operating system (OS) vulnerability on device B to run a remote process that will read finance report file from the local disk, encrypt it using some given key, and send it as attachment by using Gmail Simple Mail Transfer Protocol (SMTP) service to a given email address); ¶0060: As seen in Figure 1, the data platform 106 may analyze raw simulation events from the queue, identify full breach scenarios, and identify or produce breach scenario events. In one or more embodiments, data platform 106 may further provide reporting, online/cloud analytical processing, analytics, data mining, process mining, complex event processing, benchmarking, predictive analytics and prescriptive analytics.).
wherein the security policy test unit comprises, an access control check unit for performing a first security policy test to identify whether authorization is granted through an access control check on the preprocessed unit test case; (¶0077-¶0083 & ¶0179: Figure 4 presents a flowchart of a method for preparing a breach simulation for verification invention. The method allows for the verification of a breach by determining proper execution of breach tasks and whether data received and transmitted from all parties involved in a breach are consistent with a breach. The prepared tasks are sent to the simulator nodes, step 404. Sending a task to a simulator node may include loading data onto a simulator node module, loading the data onto a programmable chip or memory for execution by a processor/processor core, or generating a virtual device configured to perform the task. Each simulator node may represent one or more parties (e.g., client devices and servers), devices, networks, and systems participating in a breach scenario. Tasks on the simulator nodes are executed/simulated, step 406. Kotler ¶0161: Scenario 4 – Compliance & Security Policy: Security policy is a definition of what it means to be secure for a system, organization or other entity. For systems, the security policy addresses on functions and flow among them, constraint on access by external systems and adversaries including programs and access to data by people. ).
a data integrity verification unit for performing a second security policy test to identify whether data has been changed or tampered without authorization through an integrity check on the preprocessed unit test case; and( ¶0140-0141: Simulator A will simulate a HTTP Server with an interactive form. Simulator B will simulate a SQL injection scanner. Simulator A will connect to the HTTP server and start “enumerating” different SQL injection attacks using the interactive form fields. Or Simulator A will simulate an application within a container (e.g., Mobile Application Management Solution). Simulator B will simulate a server with exposed TCP port on production site. Simulator A will attempt to scan the simulated server and reach the open TCP port.);
a data confidentiality unit for performing a third security policy test to identify whether data is encrypted through a confidentiality check on the preprocessed unit test case, (¶0166: Scenario 4.2—Health Insurance Portability and Accountability Act (HIPAA)/Protected Health Information (PHI) Encryption: The security rule does not expressly prohibit the use of email for sending electronic PHI. However, the standards for access control (45 CFR §164.312(a)), integrity (45 CFR §164.312(c)(1)), and transmission security (45 CFR §164.312(e)(1)) require covered entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against the unauthorized access to electronic PHI sent and received over email communications. The standard for transmission security (§164.312(e)) has been updated to enforce the use of encryption. This means that each covered entity must assess its use of open networks, identify the available and appropriate means to protect electronic PHI as it is transmitted, select a solution, and document the decision. The security rule allows for electronic PHI to be sent over an electronic open network as long as it is adequately protected.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kolter with regards to violation to security policy to the method of Hicks in view Sabanayagam in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
Hicks in view Sabanayagam and Kotler does not disclose:
wherein the test case generation unit comprises, a random generation unit for generating the second test case by manipulating the first test case with a randomly generated data type and value; and combination generation unit for generating the second test case by combining an unprocessed unit test case with the first test case.
However, Baba teaches wherein the test case generation unit comprises, a random generation unit for generating the second test case by manipulating the first test case with a randomly generated data type and value; and (¶0062-0063: The non-symbol generation unit 150 randomly generates an input value which serves as a test case candidate in accordance with the specification information read by the program acquisition unit 110.);
combination generation unit for generating the second test case by combining an unprocessed unit test case with the first test case. (¶0061: The test generation unit 170 the generates the i-th test case by joining (i-1)-th test case and the test case for the i-th step and stores the i-th test case in memory 920. Alternatively, the test generation unit 170 use the test generation function to generate respective test cases for the first step to the i-th step, in accordance the second generation scheme M2. The test generation unit 170 then generates the i-th test case by joining the test cases for the first step to the i-th step and stores th i-th test case in the memory 920. As further exemplified in ¶0072 and Figure 2, within Step S6, the non-symbol generation unit 150 joins the test case generated from the (i−1) steps and a test case candidate for an i-th step which is randomly generated on the basis of the specification information read in step S1. The non-symbol generation unit 150 then regards a joined test case as a test case candidate for i steps and the process advances to step S7. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Baba with regards to generating the second test case by manipulating the first test case with a randomly generated data type and value to the method of Hicks in view of Sabanayagam and Kotler in order to reduce the time period to generate a new test case (Baba ¶0015).
With respect to claim 10, the combination of Hicks in view of Sabanayagam, Kotler, and Baba teaches the apparatus of claim 7 (see rejection of claim 7 above), wherein the first security policy test, the second security policy test, and the third security policy test are performed according to a preset order. (Kolter ¶0083:As seen in Figure 4, Breach simulation task(s) are prepared by the simulation orchestrator, step 402. Preparing the breach simulation task(s) may include reading a configuration for a specific breach scenario type and preparing a list of tasks to be simulated, taking into account one or more moves in a playbook, one or more configured data assets, and simulator nodes in the system, etc. A breach scenario may comprise a sequence of one or more moves applied on the simulator nodes with specific configurations, data assets, etc. The simulation orchestrator can prepare tasks for all participating parties (characterized by simulator nodes) involved in a given simulation. A simulation can occur on a single simulator node or between multiple simulator nodes.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kotler with regards to violation to security policy to the method of Hicks in view of Sabanayagam and Baba in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
Claims 2 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Hicks et al (US PGPub No. 20210034755-A1 ) in view of Kotler et al. (US PGPub No. 20160306980-A1), Sabanayagam et al. (US PGPub No. 20200167268-A1), Baba et al. (US PGPub No. 20210365355-A1), and Sato et al. (US PGPub No.20200311284-A1 ).
With respect to claim 2, the combination of Hicks in view of Sabanayagam, Kotler, and Baba teaches the method of claim 1 (see rejection of claim 1 above) wherein preprocessing the unit test case comprises, preprocessing the unit test case by classifying code snippets included in the unit test case, and (Hicks ¶0033: Accordingly, one or more embodiments of the present invention facilitate making use of existing test cases in regression buckets to automatically generate penetration tests. Without the features provided by one or more embodiments of the present invention, due to the modernization of penetration testing tools, there was a need to create new penetration tests to verify the older code with new attack vectors that were missed or that arose due to timing windows and the modernization of computer technology. Alternatively, or in addition, the monitoring can include monitoring for a specific opcode in the machine language that is being executed. The monitoring can further include monitoring for particular function calls being made (coding snippets). ).
combining or changing the unit test case based on the classified code snippets. (Hicks ¶0036: Here, generating a penetration test by adjusting the system test can include adding lines of code for penetration testing into the system test itself. Accordingly, when the system test is executed next time, penetration testing is also performed. Alternatively, or in addition, generating the penetration test includes generating code, dynamically, and automatically, in the form of a new test, where the lines of code in the newly generated test when executed perform the penetration test.).
Hicks in view of Sabanayagam, Kotler, and Baba but does not disclose:
classifying code snippets included in the unit test case
However, Sato teaches classifying code snippets included in the unit test case (¶0088: As seen in Figure 15, In subsequent step S406, the scenario creation unit 23 of the test scenario generation device 1 determines whether the order of the attack classification code of the test scenarios created in step 405 coincides with any pattern of the scenario pattern information 800.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Sato with regards to classifying to the method of Hicks in view of Sabanayagam, Kolter, and Wu in order to protect against cyberattacks (Sato ¶0003).
With respect to claim 8, the combination of Hicks in view of Sabanayagam, Kotler, and Baba teaches the apparatus of claim 7 (see rejection of claim 7 above) wherein the preprocessing unit preprocesses the unit test case by classifying code snippets included in the unit test case, (Hicks ¶0033: Accordingly, one or more embodiments of the present invention facilitate making use of existing test cases in regression buckets to automatically generate penetration tests. Without the features provided by one or more embodiments of the present invention, due to the modernization of penetration testing tools, there was a need to create new penetration tests to verify the older code with new attack vectors that were missed or that arose due to timing windows and the modernization of computer technology. Alternatively, or in addition, the monitoring can include monitoring for a specific opcode in the machine language that is being executed. The monitoring can further include monitoring for particular function calls being made (coding snippets). ).
combining or changing the unit test case based on the classified code snippets. (Hicks ¶0036: Here, generating a penetration test by adjusting the system test can include adding lines of code for penetration testing into the system test itself. Accordingly, when the system test is executed next time, penetration testing is also performed. Alternatively, or in addition, generating the penetration test includes generating code, dynamically, and automatically, in the form of a new test, where the lines of code in the newly generated test when executed perform the penetration test.).
Hicks in view of Sabanayagam, Kotler, and Baba but does not disclose:
classifying code snippets included in the unit test case
However, Sato teaches classifying code snippets included in the unit test case (¶0088: As seen in Figure 15, In subsequent step S406, the scenario creation unit 23 of the test scenario generation device 1 determines whether the order of the attack classification code of the test scenarios created in step 405 coincides with any pattern of the scenario pattern information 800.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Sato with regards to classifying to the method of Hicks in view of Sabanayagam, Kolter, and Baba in order to protect against cyberattacks (Sato ¶0003).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Richard et al. (US Pat No. 6625760-B1) discusses iteration test case by combining a previous test case with a random shard .
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437