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 5/4/2026 has been entered.
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 103:
Applicant’s amendment is considered to have overcome the applied rejection(s). Therefore, the rejection(s) has/have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Carrier (WO 98/27490 A1).
With respect to the amended claim limitation “at the remote computing system, determining whether the detected vulnerability corresponds to a vulnerability to intrusion for the deployed software program being monitored by the IDS by at least one of (i) determining whether a software version of the software program corresponds to a software version of the deployed software program and (ii) determining whether the software version of the software program predates the software version of the deployed software program” it is disclosed by the combination of Flores and Bettini as below. Specifically, see at least [0037], [0129], and [0136] of Bettini regarding the structure of an in-line filtering device and cloud app analysis system; at least [0043], [0047], [0051], [0076], [0136] of Bettini concerning an queries by the in-line filtering device to the cloud app analysis system for analysis including comparing app version information. For instance, “the platform 116 implements a holistic approach to screening apps, and can automatically analyze apps for mobile devices to determine various properties, such as one or more of the following:… CPU cycles measured and compared with apps in similar categories or other versions of the same app, such as Facebook app version X v. version Y;” “if the platform has already analyzed that app (e.g., that particular version of the app), then the previously determined risk score (e.g., app reputation score and possible additional data) is returned;” “an app query specifies one or more of the following:… app version;” “an app's file name, version, and app size can be compared between the publicly available app and the app submitted by the enterprise. If these fields vary, then these results indicate that the app may have been repackaged, which can also have an impact on overall app risk assessment;” “a match is not determined (e.g., the app was not previously analyzed by the app analysis system or that version of that app was not previously analyzed by the app analysis system).”
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.
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 limitation(s) is/are: “a fuzzing system configured to perform a fuzzing operation” and “a test controller configured to (i) detect… (ii) generate and transmit” in claims 11-19.
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. For instance, [0044] of the instant specification stating that “[p]ortions of the IDS 208 are implemented within the vehicle 204 while other portions of the IDS 208 are implemented on one more remote servers… The fuzzing system, the system under test 220, and the test controller 224 may be considered components of the IDS 208 of the present disclosure” (e.g., FIG. 2 of the instant drawings). Likewise, [0027] of the instant specification recites “dedicated Intrusion Detection Systems (IDSs) implemented on one or more of the ECUs (e.g., on gateway ECUs),” while [0081] states that “[p]rocessor 520 may be configured to read into memory 522 and execute computer- executable instructions residing in non-volatile storage 516 and embodying one or more IDS methodologies of one or more embodiments.” Further, [0042]-[0043] of the instant specification provide example implementations for “a system.”
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 § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 6-12, 14-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flores (“Runtime vulnerability discovery as a service on Industrial Internet of Things (IIoT) systems”) in view of Bettini (US 2013/0347094 A1) and Carrier (WO 98/27490 A1).
Regarding claim 1, Flores discloses: A method of operating an Intrusion Detection System (IDS) for monitoring a device, the method comprising:
performing a fuzzing operation on a software program being executed on a system under test (e.g., “FUZZER” in FIG. 1 and “Fuzzer Layer” in section IV.B of Flores), wherein the software program [corresponds to] a deployed software program (e.g., paragraph 2 in section V of Flores concerning post-deployment monitoring) on the device monitored by the IDS and the system under test is configured to emulate at least one system of the device (e.g., paragraph 3 in section IV and “virtualized environment” in FIG. 1 of Flores), the fuzzing operation comprising (i) supplying fuzzing inputs to the software program being executed on the system under test (e.g., the last paragraph in section II and paragraph 1 in section V.A of Flores), (ii) monitoring outputs of the software program while being executed on the system under test (e.g., sections IV.B and V.B of Flores concerning monitoring after providing fuzzed inputs), and (iii) detecting, based on the outputs, a vulnerability to intrusion in the software program caused by the supplying of the fuzzing inputs to the software program (e.g., sections IV.B and V.B of Flores concerning analysis and vulnerability discovery based on the monitoring);
generating and storing a vulnerability entry corresponding to the detected vulnerability, wherein the vulnerability entry includes information identifying the detected vulnerability (e.g., the last paragraph in section V.B of Flores concerning creating a vulnerability discovery report using STIX); and
updating, based on the vulnerability entry, at least one of (i) a component of the IDS and (ii) a code portion of the deployed software program (e.g., merely updating a vulnerability database as in the last paragraphs of IV.B and V.B is considered to disclose this claim limitation, since “a component of the IDS” may be its vulnerability database; additionally, refer to at least the abstract and section I of Flores with respect to a software patch being produced to fix issues detected during a software test).
Flores does not specify: wherein the system under test is separate from and external to the device monitored by the IDS; the software program corresponding to the deployed software program further comprising that the software program is an emulated version of the deployed software program; wherein the generating and storing the vulnerability entry includes transmitting, from a test controller, the vulnerability entry to a remote computing system that is (i) separate from and external to the device monitored by the IDS and the test controller and (ii) accessible by the IDS; and at the remote computing system, determining whether the detected vulnerability corresponds to a vulnerability to intrusion for the deployed software program being monitored by the IDS by at least one of (i) determining whether a software version of the software program corresponds to a software version of the deployed software program and (ii) determining whether the software version of the software program predates the software version of the deployed software program; performing the updating further in response to determining that the detected vulnerability corresponds to the vulnerability to the intrusion for the deployed software program being monitored by the IDS. However, Flores in view of Bettini discloses: wherein the system under test is separate from and external to the device monitored by the IDS;
Refer to at least FIG. 1 of Bettini with respect to an application screen platform 116, an instrumented emulation engine 108, and monitored devices 120, 122, and 124.
the software program corresponding to the deployed software program further comprising that the software program is an emulated version of the deployed software program.
Refer to at least [0083]-[0084] of Bettini with respect to performing dynamic analysis on an application using run-time emulation. Dynamic analysis can include fuzzing as in [0082] of Bettini.
at the remote computing system (e.g., [0037], [0129], and [0136] of Bettini concerning an in-line filtering device and cloud app analysis system), determining whether the detected vulnerability corresponds to a vulnerability to intrusion for the deployed software program being monitored by the IDS by at least one of (i) determining whether a software version of the software program corresponds to a software version of the deployed software program and (ii) determining whether the software version of the software program predates the software version of the deployed software program;
Refer to at least [0043], [0047], [0051], [0076], [0136] of Bettini concerning an app under analysis at the in-line filtering device which queries the cloud app analysis system for further analysis, wherein “the platform 116 implements a holistic approach to screening apps, and can automatically analyze apps for mobile devices to determine various properties, such as one or more of the following:… CPU cycles measured and compared with apps in similar categories or other versions of the same app, such as Facebook app version X v. version Y;” “if the platform has already analyzed that app (e.g., that particular version of the app), then the previously determined risk score (e.g., app reputation score and possible additional data) is returned;” “an app query specifies one or more of the following:… app version;” “an app's file name, version, and app size can be compared between the publicly available app and the app submitted by the enterprise. If these fields vary, then these results indicate that the app may have been repackaged, which can also have an impact on overall app risk assessment;” “a match is not determined (e.g., the app was not previously analyzed by the app analysis system or that version of that app was not previously analyzed by the app analysis system).”
performing the updating further in response to determining that the detected vulnerability corresponds to the vulnerability to the intrusion for the deployed software program being monitored by the IDS;
Refer to at least 812-814 in FIG. 8, [0126]-[0127], [0132], and [0136]-[0139] of Bettini with respect to performing updates and remedial actions based on a report from the cloud app analysis system.
The teachings of Bettini likewise concern software testing and vulnerabilities, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Flores to further implement a dedicated emulation environment for dynamic analysis because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art and allows for improved malware detection (e.g., [0031] of Bettini; also see paragraph 1 in section III of Flores concerning SAGE). It further would have been obvious to use a cloud app analysis system to validate version information for at least the purpose of version control to prevent classifying different versions as having identical security properties; and to stay up-to-date on app changes as described in the cited portions of Bettini.
Flores-Bettini does not specify: wherein the generating and storing the vulnerability entry includes transmitting, from a test controller, the vulnerability entry to a remote computing system that is (i) separate from and external to the device monitored by the IDS and the test controller and (ii) accessible by the IDS. However, Flores-Bettini in view of Carrier discloses: wherein the generating and storing the vulnerability entry includes transmitting, from a test controller, the vulnerability entry to a remote computing system that is (i) separate from and external to the device monitored by the IDS and the test controller and (ii) accessible by the IDS.
Refer to at least FIG. 12, pg. 18, Ll. 16-19, and pg. 20, Ll. 1-15 of Carrier with respect to version control 512 and test controller 532, where test results are sent to the test controller and checked into the version control system.
The teachings of Carrier likewise concern software testing, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Flores-Bettini to further implement a test controller to provide test results to a version control module because all of the claimed elements were known in the prior art (i.e., test controllers for system under test implementations; a version control module) and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions (sending information between the elements), and the combination would have yielded predictable results to one of ordinary skill in the art at the time of the invention (reporting test results with version information; storing version information).
Regarding claim 2, Flores-Bettini-Carrier discloses: The method of claim 1, wherein supplying the fuzzing inputs includes supplying fuzzing inputs that are configured to cause errors in at least one of a plurality of code portions of the software program.
Refer to at least paragraph 1 in section II, as well as to section VII.A of Flores concerning causing errors via software testing using the fuzzer.
Regarding claim 3, Flores-Bettini-Carrier discloses: The method of claim 1, wherein generating and storing the vulnerability entry includes storing the vulnerability in a vulnerability database.
Refer to at least the last paragraph in section V.B, and to the second paragraph in section VI of Flores concerning data storage and vulnerability reports.
Regarding claim 4, Flores-Bettini-Carrier discloses: The method of claim 1, wherein the vulnerability entry includes at least one of a software version of the software program a hardware version being emulated by the system under test executing the software program, a time and date that the vulnerability was detected, the supplied fuzzing inputs, an identification of a fix for the detected vulnerability, and a hash of one or more values contained in the vulnerability entry.
Refer to at least the second-to-last paragraph in section V.B of Flores concerning the specific fuzz test and pattern that led to anomalous behavior being obtained as part of a procedure to exploit a possible new bug or vulnerability.
Regarding claim 6, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations concerning a software patch).
Regarding claim 7, it is rejected for substantially the same reasons as claims 1 and 3-4 above (e.g., paragraph 2 on page 952 of Flores concerning information of previously executed tests).
Regarding claim 8, Flores-Bettini-Carrier discloses: The method of claim 1, further comprising at least one of (i) generating an alarm in response to detecting the vulnerability and (ii) generating instructions to a user of the device in response to detecting the vulnerability.
Refer to at least section IV.B and the last paragraph in section VIII of Flores with respect to threat reports.
Regarding claim 9, Flores-Bettini-Carrier discloses: The method of claim 1, further comprising, in response to detecting the vulnerability, (i) generating a fingerprint associated with an operating characteristic of the system under test during detection of the vulnerability and (ii) updating the IDS based on the fingerprint.
Refer to at least the first 2 paragraphs of section V.B of Flores with respect to measured parameters that are collected (e.g., events, timings, CPU load, memory consumption, and traffic). This information is passed to the STIX reports as per paragraphs 3-4.
Regarding claim 10, Flores-Bettini-Carrier discloses: The method of claim 1, further comprising: detecting, by the IDS, an intrusion at the device; where the supplying the fuzzing inputs to the software program includes supplying the fuzzing inputs based on the detected intrusion at the device; and updating at least one of (i) the component of the IDS and (ii) the code portion of the deployed software program based on performance of the software program in response to the fuzzing inputs supplied to the software program.
Refer to at least [0158] and [0131] of Bettini with respect to intrusion detection monitoring which “can be used to… communicate with a mobile app analysis system, in order to, for example, identify the transfer of mobile apps on the network that are known or determined to be likely to be/or at risk of being affected by security, privacy, and/or other related issues or policy defined issues, or to identify communications coming from or going to mobile apps, that are affected by these same kinds of issues. Identification of issues of concern can be used by systems of this type to generate alerts or take other corrective or responsive action(s).”
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Flores-Bettini to further implement a multi-stage analysis for at least the purpose of improving detection and reducing computation (i.e., targeted dynamic analysis for more likely true positives).
Regarding independent claim 11, it is substantially similar to elements of independent claim 1 above, and is therefore likewise rejected.
Regarding claims 12-16 and 19, they are substantially similar to elements of claims 1-4 and 6-9 above, and are therefore likewise rejected.
Regarding claim 18, it is substantially similar to elements of claims 11 and 9 above, and therefore likewise rejected.
Regarding independent claim 20, it is substantially similar to elements of independent claim 1 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights