DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The present office action is responsive to communication filed on 03/30/2026. Claims 1 and 7 have been amended. Claims 2 and 8 have been cancelled. Claims 3, 5, 9, and 11 have been previously cancelled. Claims 1, 4, 6, 7, and 10 are currently pending.
Applicant’s amendments and persuasive filed on 03/30/2026 with regards to 35 USC 112 and 35 USC 101, as seen in page 6-13 , have been considered and fully persuasive. Therefore, the respective rejections have been withdrawn.
Additionally, applicant’s argument with respect to 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), as seen in pages 13-16, are considered and fully persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Hu et al. (US PGPub No. 20190196947-A1), Han et al., CodeAlchemist: Semantics-aware code generation to find vulnerabilities in JavaScript engines, In NDSS., (Year: 2019), and Thompson et al. (US PGPub No. 20050076282-A1).
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, 6, 7, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Hicks et al (US PGPub No. 20210034755-A1 ) in view of Hu et al. (US PGPub No. 20190196947-A1), Han et al., (CodeAlchemist: Semantics-aware code generation to find vulnerabilities in JavaScript engines, In NDSS., (Year: 2019)), Kotler et al. (US PGPub No. 20160306980-A1), and Thompson et al. (US PGPub No. 20050076282-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. );
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:
the method comprising: collecting, by a crawler, a unit test case for the software system from an external device and preprocessing the unit test case;
However, Hu teaches the method comprising: collecting, by a crawler, a unit test case for the software system from an external device (¶0037: As seen in Figure 1, the application crawler 122 interacts with the application 110 to test various features 11 from a user interaction perspective based on contents of the test suite 114. During the execution of the application 110, the application crawler 122 collects metadata produced by the application 110. From the metadata, the application runner 120 produces a set of artifacts 124. The set of artifacts 124 includes data that is organized to enable investigation into multiple types of issues pertaining to operation of the application.) and preprocessing the unit test case; (¶0046: The application crawler 122 interacts with the application executor 306 so that the multiple test cases 302 can be applied to the execution of the application 110. To do so, the application crawler 122 receives the test cases 302 from the test suite interface 304. In effect, the test suite interface 304 obtains the test suite 114 and forwards the multiple test cases 302 to the application crawler 122 (collecting preprocessing unit test cases) .);
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 Hu with regards an collecting by a crawler to the method of Hicks in view of in order to better address/discover issues by providing support for rapid improvements and reliable updates (Hu ¶0006).
Hicks in view of Hu does not disclose:
wherein preprocessing the unit test case comprises, classifying, by a classifier, code snippets included in the unit test case into at least one of classes, functions, annotations, and variables; and
combining or changing, by a parser, the unit test case based on the classified code snippets to generate a preprocessed unit test case, wherein the parser changes a variable value used for calling a function in the unit test case by generating a test case that calls the function with a randomly modified value,
However, Han teaches wherein preprocessing the unit test case comprises, classifying, by a classifier, code snippets included in the unit test case into at least one of classes, functions, annotations, and variables; and (A. Semantics-aware Assembly, Page 4: The primary challenge of CodeAlchemist is to generate test cases i.e., JS code snippets that are both syntactically and semantically valid. To address the challenge, we propose semantics-aware assembly, a novel test case generation algorithm for JS engine fuzzing. The key intuition behind our approach is to fragmentize JS seeds into a set of combinable building blocks that we call code bricks. A code brick represents a valid JS Abstract Syntax Tree (AST). Therefore, a code brick (code snippet) itself can be evaluated by a JS engine (classifier) . For example, a JS statement can become a code brick, and a block of statements (BlockStatement) can also become a code brick. A precondition is a set of variable symbols as well as their types that are required to be defined to execute the code brick without a runtime error. postcondition describes what kinds of variables are available, i.e., defined, at the end of the code brick after evaluating it.);
combining or changing, by a parser, the unit test case based on the classified code snippets to generate a preprocessed unit test case, , (B. CodeAlchemist Architecture , Page 5: Figure 5 depicts the architecture of CodeAlchemist. At a high level it takes an input a JS engine under test, a set of seed files, and a set of user-configurable parameters and it outputs a set of three major components: SEED PARSER, CONSTRAINT ANALYZER, and ENGINE FUZZER. The SEED PARSER module breaks given JS seeds into set of code bricks. The CONSTRAINT ANALYSER module then infer assembly constraints for each code brick, and annotates them with the computed assembly constraints, which ultimately constitute a code brick pool. Finally, the ENGINE FUZZER module assembles the code bricks from the pool based on their assembly constraints to generate test cases and to execute generated cases against the target JS engine.) wherein the parser changes a variable value used for calling a function in the unit test case by generating a test case that calls the function with a randomly modified value(F. Code Brick Assembly, Page 9: The GenBlkBrick function builds a code brick for a block statement from scratch. The PickEmptyBlock function in Line 10 the pool P and the current code brick B maintained by CodeAlchemist as input, and returns a code brick B in P that satisfies the following two conditions: (1)B should contain an empty block statement, which may or may not include a guard, and (2) the precondition of B should meet the postcondition of B. The GetDummyBrick function in Line 11 then extracts a random subset of the postconditions of B and B in order to build a new postcondition c, and then create a dummy code brick B0, where the postcondition of it is c. Next, CodeAlchemist generates a code brick B for the body of the block statement using the Generate function with the dummy code brick B0. Note that the Generate and GenBlkBrick are mutually recursive, and they allow us to generate nested block statements. We limit the nesting depth of a newly generated block by dmax. The RandInt function in Line 12 decides the maximum number of iterations to be used in generating the block body. It returns a random integer from 1 to iblk. Finally, GenBlkBrick merges B and B , and returns the merged one as a new code brick containing a new block statement, the assembly constraint.)
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 Han with regards an external device to the method of Hicks in view of Hu in order to mitigate the requirement of manual effort and mitigate previously unknown security vulnerabilities (Han I. Introduction Page 1-2).
Hicks in view of Hu and Han 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, wherein generating the second test case comprises,
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 Hu and ( in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
Hicks in view of Hu, Han, Kotler does not disclose:
generating the second test case by manipulating the first test case with a randomly generated data type and value by changing code snippets included in the first test case into randomly generated data types and values, or generating the second test case by combining an unpreprocessed unit test case with the first test case.
However, Thompson teaches generating the second test case by manipulating the first test case with a randomly generated data type and value by changing code snippets included in the first test case into randomly generated data types and values, or generating the second test case by combining an unpreprocessed unit test case with the first test case. (¶0020-0023: Figure 3 depicts one embodiment of a parametric extraction and regeneration system 300 for effectuating the ATG debugging operation 232 illustrated in Figure 2. As will be explained in more detail hereinbelow, the seed 206, profile settings 212, and command line settings 308 form extraction files 320 which serve as reconstituted input parameters to the random number generator 204 and event probability generator 210 such that the random number sequence 208 and probability profile 214 originally provided may be presented again to the ATG 202 to facilitate its debugging. In order to generate the modified test case 316 that corresponds to the original test case, however the modified ATG 314 must be supplied with the same random number sequence 208 and probability profile 214. );
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 Thompson with regards to violation to security policy to the method of Hicks in view of Hu, Han, and Kotler in order to minimize labor associated with reconstructing inputs and enable efficient testing (Thompson ¶0003 & ¶0012).
With respect to claim 4, the combination of Hicks in view of Hu, Han, Kotler, and Thompson 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 Hu, Han, and Thompson 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 Hu, Han, Kotler, and Thompson 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: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the apparatus to, (Abstract: The method further includes executing the penetration test and detecting an unauthorized access being performed during the penetration test. );
generate 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. );
generate 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.);
detect a vulnerability of the software system by executing the second test case, wherein preprocessing the unit test case comprises, (¶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:
collect, via a crawler, a unit test case for the software system from an external device and preprocessing the unit test case;
However, Hu teaches collect, via a crawler, a unit test case for the software system from an external device (¶0037: As seen in Figure 1, the application crawler 122 interacts with the application 110 to test various features 11 from a user interaction perspective based on contents of the test suite 114. During the execution of the application 110, the application crawler 122 collects metadata produced by the application 110. From the metadata, the application runner 120 produces a set of artifacts 124. The set of artifacts 124 includes data that is organized to enable investigation into multiple types of issues pertaining to operation of the application.) and preprocessing the unit test case; (¶0046: The application crawler 122 interacts with the application executor 306 so that the multiple test cases 302 can be applied to the execution of the application 110. To do so, the application crawler 122 receives the test cases 302 from the test suite interface 304. In effect, the test suite interface 304 obtains the test suite 114 and forwards the multiple test cases 302 to the application crawler 122 (collecting preprocessing unit test cases) .);
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 Hu with regards an collecting by a crawler to the method of Hicks in view of in order to better address/discover issues by providing support for rapid improvements and reliable updates (Hu ¶0006).
Hicks in view of Hu does not disclose:
classifying, via a classifier, code snippets included in the unit test case into at least one of classes, functions, annotations, and variables; and
combining or changing, via a parser, the unit test case based on the classified code snippets to generate a preprocessed unit test case,
wherein the parser changes a variable value used for calling a function in the unit test case by generating a test case that calls the function with a randomly modified value,
However, Han teaches classifying, via a classifier, code snippets included in the unit test case into at least one of classes, functions, annotations, and variables; and (A. Semantics-aware Assembly, Page 4: The primary challenge of CodeAlchemist is to generate test cases i.e., JS code snippets that are both syntactically and semantically valid. To address the challenge, we propose semantics-aware assembly, a novel test case generation algorithm for JS engine fuzzing. The key intuition behind our approach is to fragmentize JS seeds into a set of combinable building blocks that we call code bricks. A code brick represents a valid JS Abstract Syntax Tree (AST). Therefore, a code brick (code snippet) itself can be evaluated by a JS engine (classifier) . For example, a JS statement can become a code brick, and a block of statements (BlockStatement) can also become a code brick. A precondition is a set of variable symbols as well as their types that are required to be defined to execute the code brick without a runtime error. postcondition describes what kinds of variables are available, i.e., defined, at the end of the code brick after evaluating it.);
combining or changing, via a parser, the unit test case based on the classified code snippets to generate a preprocessed unit test case, (B. CodeAlchemist Architecture , Page 5: Figure 5 depicts the architecture of CodeAlchemist. At a high level it takes an input a JS engine under test, a set of seed files, and a set of user-configurable parameters and it outputs a set of three major components: SEED PARSER, CONSTRAINT ANALYZER, and ENGINE FUZZER. The SEED PARSER module breaks given JS seeds into set of code bricks. The CONSTRAINT ANALYSER module then infer assembly constraints for each code brick, and annotates them with the computed assembly constraints, which ultimately constitute a code brick pool. Finally, the ENGINE FUZZER module assembles the code bricks from the pool based on their assembly constraints to generate test cases and to execute generated cases against the target JS engine.)
wherein the parser changes a variable value used for calling a function in the unit test case by generating a test case that calls the function with a randomly modified value, (F. Code Brick Assembly, Page 9: The GenBlkBrick function builds a code brick for a block statement from scratch. The PickEmptyBlock function in Line 10 the pool P and the current code brick B maintained by CodeAlchemist as input, and returns a code brick B in P that satisfies the following two conditions: (1)B should contain an empty block statement, which may or may not include a guard, and (2) the precondition of B should meet the postcondition of B. The GetDummyBrick function in Line 11 then extracts a random subset of the postconditions of B and B in order to build a new postcondition c, and then create a dummy code brick B0, where the postcondition of it is c. Next, CodeAlchemist generates a code brick B for the body of the block statement using the Generate function with the dummy code brick B0. Note that the Generate and GenBlkBrick are mutually recursive, and they allow us to generate nested block statements. We limit the nesting depth of a newly generated block by dmax. The RandInt function in Line 12 decides the maximum number of iterations to be used in generating the block body. It returns a random integer from 1 to iblk. Finally, GenBlkBrick merges B and B , and returns the merged one as a new code brick containing a new block statement, the assembly constraint.)
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 Han with regards an external device to the method of Hicks in view of Hu in order to mitigate the requirement of manual effort and mitigate previously unknown security vulnerabilities (Han I. Introduction Page 1-2).
Hicks in view of Hu and Han does not disclose:
wherein the testing whether the software system violates a security policy 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 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 generating the second test case comprises, manipulating the first test case with a randomly generated data type and value by changing code snippets included in the first test case into randomly generated data types and values; or combining an unpreprocessed unit test case with the first test case.
However, Thompson teaches wherein generating the second test case comprises, manipulating the first test case with a randomly generated data type and value by changing code snippets included in the first test case into randomly generated data types and values; or combining an unpreprocessed unit test case with the first test case. (¶0020-0023: Figure 3 depicts one embodiment of a parametric extraction and regeneration system 300 for effectuating the ATG debugging operation 232 illustrated in Figure 2. As will be explained in more detail hereinbelow, the seed 206, profile settings 212, and command line settings 308 form extraction files 320 which serve as reconstituted input parameters to the random number generator 204 and event probability generator 210 such that the random number sequence 208 and probability profile 214 originally provided may be presented again to the ATG 202 to facilitate its debugging. In order to generate the modified test case 316 that corresponds to the original test case, however the modified ATG 314 must be supplied with the same random number sequence 208 and probability profile 214. );
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 Thompson with regards to violation to security policy to the method of Hicks in view of Hu, Han, and Kotler in order to minimize labor associated with reconstructing inputs and enable efficient testing (Thompson ¶0003 & ¶0012).
With respect to claim 10, the combination of Hicks in view of Hu, Han, Kotler, and Thompson 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 Hu, Han, and Thompson in order to protect against sophisticated malware and to secure against vulnerabilities to breaches from malware (Kotler ¶0006 & ¶0015).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
/MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights