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 .
Status of Claims
Claims 12-26 are pending. Claims 1-11 are cancelled.
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) 12-17, 20-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo et al (PGPUB 2019/0081980), and further in view of Ismael et al (US 9,367,681).
Regarding Claims 12, 20, and 21:
Luo teaches a method for generating a honeypot, a non-transitory computer-readable medium on which are stored commands for generating a honeypot, the commands, when executed by a processor, causing the processor to perform steps, and a device, comprising at least one hardware processor, the at least one hardware processor configured to:
send messages to a target system ([0051] a first step to build an intelligent-interaction IoT honeypot is to collect responses from all types of IoT devices; fortunately, from the Internet, we can generally find all/many of the physical IoT devices that are accessible; therefore, we designed and implemented a module, IoT-Scanner (e.g., IoTScanner 116 as shown in FIG. 1), to actively probe the IoT devices (i.e., the physical IoT devices) on the Internet and collect their responses to several of the requests we have captured from the honeypot; scanned results can be stored in the central database (e.g., IoT Oracle database 104 as shown in FIG. 1) as the ‘raw’ knowledge for the further learning procedure);
observe responses of the target system to the messages ([0051] we designed and implemented a module, IoT-Scanner (e.g., IoTScanner 116 as shown in FIG. 1), to actively probe the IoT devices (i.e., the physical IoT devices) on the Internet and collect their responses to several of the requests we have captured from the honeypot; scanned results can be stored in the central database (e.g., IoT Oracle database 104 as shown in FIG. 1) as the ‘raw’ knowledge for the further learning procedure);
generate, according to the observed responses of the target system, a state machine model for one or more interfaces of the target system ([0085] with the help of IoTScanner (e.g., shown as IoTScanner 116 in FIG. 1), our honeypot can reply by sending a valid response to a client based on the received request instead of responding to the fixed one; in this section, we discuss how to leverage a Markov decision process model to optimize the response selection with the maximal possibility to capture attacks; [0089] in some embodiments, we first randomly select the response from the candidate pool and record the next move from client side; we assume if we happen to select the correct one, attackers will believe our honeypot is the vulnerable target IoT device, and they continue to send the malicious payload (e.g. injected command); therefore, we store each transaction in a session table, and leverage machine learning techniques (MLT) to extract the correct behaviors from the dataset; [0090] FIG. 5 illustrates an architecture of the IoTLearner module in accordance with some embodiments; specifically, the architecture of the IoTLearner module is depicted in FIG. 5 to fetch raw responses 110 from the database 104 and record each transaction to the database 104; [0091] each decision that is made by the selection engine creates a new transaction to extend the current session; all of the session information is stored in the session table (e.g., shown as session info 108 of FIG. 1); [0121] FIG. 6 is a visualization of building a Markov decision process (MDP) state graph from a session table in accordance with some embodiments; in this example, we will use the real world example to explain how we build MDP and calculate the probabilities for each response);
ascertain, for each one or more known vulnerabilities, a corresponding chain of states of the state machine model that, when followed, makes it possible to exploit the vulnerability ([0107] in our context, the immediate reward r(x.sub.t, a.sub.t) reflects the progress we have made during the interaction process when we choose response a.sub.t to request x.sub.t and we move to the next state x.sub.t+1; since the progress can be either negative or positive, the reward function can be negative or positive as well; the heuristics of defining reward is that if the response a is the target device type expected by the attacker and the attack launch the attack by sending the exploit code in the next request, the reward must be positive and huge; on the contrary, if the response is not an expected one (e.g., reflects a is not a vulnerable device version), the attacker may stop the attack and end the session; this leads to the dead end state, and causes the negative reward; in other words, we reward the responses that could lead us to the final attack packet, and punish the ones that lead to the dead end session; [0108] one of our designs is to assign reward as a value equals to the length of the final sessions, since we believe the longer request sent by the attackers, the higher chance the malicious payload is contained; the standard session is two which means after we send our response, there is at least another incoming request from the same IP at the same port; if no further transition is observed, we assign a negative reward for that response; other alternative reward assignments could be based on whether we receive some known exploits packets or not); and
generate a honeypot that responds to messages according to the state machine model ([0090] FIG. 5 illustrates an architecture of the IoTLearner module in accordance with some embodiments; specifically, the architecture of the IoTLearner module is depicted in FIG. 5 to fetch raw responses 110 from the database 104 and record each transaction to the database 104; every incoming request to the honeypot is forwarded to this module, and the selected response is returned to the client based on the Req_Rsp Mapping 508; a core part of the module is a selection engine shown as a selector component 504, which normalizes the request and fetches the potential responses list 110 from the scanning result; in MDP selection mode (as further described below), it first locates the state in the graph from the normalized request using a state locator component 502, and followed by the model to select the best response).
Luo does not explicitly teach removing, for each of the one or more vulnerabilities, at least one state of the corresponding chain from the state machine model.
However, Ismael teaches the concept of removing, for each of one or more vulnerabilities, at least one state of a corresponding chain from a state machine model ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application, the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function and determines that such states should be modified to remove or otherwise squelch this ability).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the state removal teachings of Ismael with the honeypot creation teachings of Luo, in order to create a robust, high-interaction honeypot which stalls, inhibits, or distracts malicious agents for increasing amounts of time, allowing for the malicious agents to be redirected, monitored, identified, blacklisted, etc., while preventing avenues of attack and system destabilization by pruning vulnerable states, thereby maximizing utility and security while minimizing risk.
Regarding Claim 13:
Luo in view of Ismael teaches the method according to claim 12. In addition, Ismael teaches wherein, for each of the one or more vulnerabilities, a state is ascertained in the corresponding chain of states and removed from the state machine model, which prevents the vulnerability from being exploited, wherein a state that is as far back as possible in the chain of states, but, upon reaching of which, damage is not yet caused, is ascertained as the state ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application, the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function and determines that such states should be modified to remove or otherwise squelch this ability).
The rationale to combine Luo and Ismael is the same as provided for claim 12, due to the overlapping subject matter between claims 12 and 13.
Regarding Claim 14:
Luo in view of Ismael teaches the method according to claim 12. In addition, Ismael teaches wherein, for each of the one or more vulnerabilities, a state upon reaching of which communication with a third-party system is carried out is ascertained in the corresponding chain of states and removed from the state machine model ([col 18 line 39-col 19 line 23] FIG. 10 shows an embodiment of a method flow for instrumenting an application so as to prevent it from performing unwanted actions; as observed in FIG. 10, one or more unwanted actions are identified and presented to the explorer component 1001; a representation of the application, such as a control flow graph or other structure that describes the application's states and state transitions is created by the application representation generation unit 415 from the abstracted application instance and submitted to the explorer component 1003; the explorer component studies the specified unwanted action(s) to be prevented and the code's representation and defines changes to be made to the application's code to remove from the application any ability to perform the unwanted action(s) 1004; for example, if the unwanted action is the sending of certain sensitive information outside the application (i.e. “communication with a third-party system”), the explorer may define all possible “exit points” of information from the application; alternatively or in combination the explorer may simply remove certain blocks of code from the application in order to remove the unwanted function from the application; in a first embodiment, certain device functions are disabled; for example, the audio function (e.g., the ability of an application to “turn-on” the microphone of a mobile device so it can internally process the audio information near it (such as a conversation)) of a mobile device may be disabled; according to one approach, the explorer determines any states within the application that could cause a command to be sent to the hardware and/or OS to turn on the device's audio function (i.e. “communication with a third-party system)) and determines that such states should be modified to remove or otherwise squelch this ability).
The rationale to combine Luo and Ismael is the same as provided for claim 12, due to the overlapping subject matter between claims 12 and 14.
Regarding Claim 15:
Luo in view of Ismael teaches the method according to claim 12. In addition, Luo teaches wherein the state machine model is generated by adapting a previously generated other state machine model for another target system according to the observed responses of the target system ([0044] in this example implementation, there are four major components running separately but sharing the data to each other during the learning process; IoT-Oracle 104 is a central database that stores information that we obtained regarding the IoT devices; a honeypot module includes honeypot instances 102a-c that we deployed on Amazon AWS and Digital Ocean; the honeypot instances receive the traffic of attack and interact with attackers to allure them to perform the real exploitation; they will periodically synchronize with IoT-Oracle 104 to push newly received raw requests to the table raw request 106 associated with the session information stored in the session information table 108, and retrieve the IoT knowledge table 112 for up-to-date knowledge information of IoT devices; EXAMINER’S NOTE: previous honeypot instances (i.e. “state machine models”) are therefore used to update future honeypot models).
Regarding Claim 16:
Luo in view of Ismael teaches the method according to claim 15. In addition, Luo teaches wherein the other state machine model is generated by sending the requests and/or other requests to the other target system, observing responses of the other target system to the requests or the other requests, and generating the other state machine model according to the observed responses of the other target system ([0044] as above, honeypot instances are used to update honeypot instances with up-to-date knowledge information of IoT devices; [0045] the module, IoTScanner 116, which includes a filter 118, leverages captured attack's requests as the seed knowledge, and scans the Internet 128 to perform active probing (126) for any IoT devices that can respond to these requests; the collected responses will be stored in the table raw response 110 for further analysis; the module, IoTLearner 120, which includes an IoT-ID component 122 and machine learning (ML) component 124, utilizes a machine learning algorithm to train a model based on the feedback (114) from attackers with given responses; after several round of learning iterations, our high-interaction IoT honeypot can optimize a model to reply to attackers (e.g., nefarious actors/hackers targeting IoT devices)).
Regarding Claim 17:
Luo in view of Ismael teaches the method according to claim 15. In addition, Luo teaches wherein the adapting of the other state machine model includes adapting, according to the observed responses of the target system, a version of the one or more interfaces whose behavior is modeled by the other state machine model ([0044] as above, honeypot instances are used to update honeypot instances with up-to-date knowledge information of IoT devices; [0045] the module, IoTScanner 116, which includes a filter 118, leverages captured attack's requests as the seed knowledge, and scans the Internet 128 to perform active probing (126) for any IoT devices that can respond to these requests; the collected responses will be stored in the table raw response 110 for further analysis; the module, IoTLearner 120, which includes an IoT-ID component 122 and machine learning (ML) component 124, utilizes a machine learning algorithm to train a model based on the feedback (114) from attackers with given responses; after several round of learning iterations, our high-interaction IoT honeypot can optimize a model to reply to attackers (e.g., nefarious actors/hackers targeting IoT devices); [0048], [0062]-[0063], [0078], [0133] HTTP protocol).
Regarding Claim 22:
Luo in view of Ismael teaches the method according to claim 12. In addition, Luo teaches wherein the one or more known vulnerabilities comprise a plurality of known vulnerabilities ([0131] utilizing intelligent-interaction honeypots, we have captured more crafted malicious requests from attackers; using the session information, we also identified 50 pre-attack checks in various protocols for different types of IoT devices (e.g., IPCam, Router, and Projector) from the MDP state graph; we highlight several cases in this part).
Regarding Claim 23:
Luo in view of Ismael teaches the method according to claim 12. In addition, Ismael teaches wherein generating the state machine model comprises carrying out dynamic tests and static checks to check whether the state machine model models a corresponding complex system correctly ([col 11 line 21-37] the explorer function receives a representation 630 of the application that describes the application's different states 631_1 to 631_28 and various input stimuli needed to transition the application from one state to another state; each state typically has an associated “basic block” of the application's instructions that ends with a branch of some kind (e.g., conditional branches, unconditional jumps, etc.); in reality, depending on implementation, the representation 630 as received from the application representation unit may not contain a description of all or even any stimuli needed to cause a particular state transition; [col 11 line 61-col 12 line 18] with the application's current state eventually recognized at state 631_3, the explorer is next able to identify a section of the application's code as being “of interest”; in the present example, assume the explorer identifies code region 632 as being “of interest”; here, the ability to identify a section of code as being of interest may be derived from any of the aforementioned rules (i.e. static checks); for example, the aforementioned user provided rules 107 may identify an item of data as being particularly sensitive; in this case, the explorer might recognize that basic blocks of code region 632 are written to process or otherwise use this item of data; as another example, which may work in combination with the aforementioned example, the aforementioned machine learning rules 106 and/or platform specific rules 128 may identify a specific combination of states and associated basic blocks that correspond to the operation of improperly behaving code; additionally or in the alternative, the behavior and logic engine 103_1 may determine that, based on its observations of the application, that it may contain certain types of improperly performing code and notify the explorer component of these determinations (i.e. dynamic testing)).
The rationale to combine Luo and Ismael is the same as provided for claim 12 due to the overlapping subject matter between claims 12 and 23.
Regarding Claim 24:
Luo in view of Ismael teaches the method according to claim 12, further comprising:
selecting vulnerabilities that further entice attackers, and incorporating, into the state machine model, one or more states corresponding to the selected vulnerabilities, without enabling actual exploitation thereof ([0044] the honeypot instances receive the traffic of attack and interact with attackers to allure them to perform the real exploitation (i.e. vulnerability); [0048] for high-interaction honeypots, they usually deploy the real system or emulator in the virtual machine (VM) to react to attackers (e.g. responding to requests or executing uploaded/injected script); our honeypot generates the response purely based on the learned knowledge, but not running it; [0157] at 1004, active probing of the plurality of physical IoT devices on the Internet by sending a request to receive a plurality of responses from each of the plurality of physical IoT devices on the Internet is performed; for example, various requests can be sent to each of the plurality of physical IoT devices on the Internet based on different types of attacks targeting various IoT devices to determine responses to potentially allure attackers to perform a real exploitation as similarly described above).
Regarding Claim 25:
Luo in view of Ismael teaches the method according to claim 12. In addition, Luo teaches the method, further comprising:
prioritizing, based on information about previous honeypot findings and logs and traces of actual attacks, components and functionalities that are to be simulated in the honeypot ([0059] among the 65535 ports, IoT devices may only listen to a relatively small portion of them for interaction; one of the most popular ports is port 7547 for TR-069 service, which is a SOAP-based protocol for remote management of end-user devices; it is commonly used by IoT devices such as modems, gateways, routers, VoIP phones, and set-top boxes; another example is port 1900 for Universal Plug and Play (UPnP) protocol, and 67% of routers open this port to facilitate devices and programs to discovery routers and their configuration accordingly; for the IoT devices providing remote configuration through an embedded web server, they usually expose certain ports, such as ports 80, 8080, 81, etc.; we also monitor and scan the ports used by the protocols that are heavily utilized by IoT device, including port 5222 for XMPP, port 5683 for CoAP, and port 1883/8883 for MQTT; Table 2 highlights the port list we have identified from our analysis and prior survey [16] (NSFOCUS, Analysis on Exposed IoT Assets in China, available at http://blog.nsfocus.net/wp-content/uploads/2017/05/Analysis-on-Exposed-IoT-Assets-in-China-0521.pdf, 2017), and we can prioritize to scan the traffic on these ports first).
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Ismael, and further in view of Sharifi Mehr (US 11,050,787).
Regarding Claim 18:
Luo in view of Ismael teaches the method according to claim 15.
Neither Luo nor Ismael explicitly teaches wherein the other state machine model is selected from a set of other state machine models for the other target system or one or more other target systems, based on a check as to whether the other state machine model fulfills functions required for imitating the target system.
However, Sharifi Mehr teaches the concept wherein an other state machine model is selected from a set of other state machine models for an other target system, or one or more other target systems, based on a check as to whether the other state machine model fulfills functions required for imitating the target system ([abstract] adaptively configuring and deploying honeypots in user compute resources; [col 10 line 27-44] honeypot configuration system 120 can use at least a portion of profile information for a virtual network (e.g., profile information 116 generated by network scanning system 112) to identify one or more honeypot configurations that may be suitable for deployment into network 104; for example, honeypot configuration system 120 can access at least a portion of profile information (e.g., profile information 116) about network 104 from network profile database 118, and can use the information to identify potentially suitable configurations; [col 10 line 45-col 11 line 9] honeypot configuration system 120 can retrieve information from a repository of available honeypot configurations 122 using the profile information; honeypot repository 122 can include information about preconfigured honeypot templates that can be used to provide a honeypot customized for network 104, and/or information that can be used to deploy the preconfigured honeypot templates (e.g., virtual machine images, software images, an executable file, source code, machine code, etc.); honeypot configuration system 120 can use properties of one or more virtual machine instances (e.g., which type of function(s) are being performed) being used in network 104 to query a database for honeypot configurations that are compatible with the virtual machine instance; software images can, for example, represent the entire state of a software application at the time it was imaged, such that the software application can be restored to that point by restoring/launching the software image; additionally, virtual machine images can, for example, represent the entire state of a virtual machine instance at the time it was imaged).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine suitability check teachings of Sharifi Mehr with the honeypot creation teachings of Luo in view of Ismael, with the benefit of improving system efficiency and security by checking and selecting the most suitable honeypot configuration to use as a baseline, thereby preventing misconfiguration and targeting expected attacks.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Ismael, and further in view of Hebert et al (PGPUB 2020/0186567)
Regarding Claim 19:
Luo in view of Ismael teaches the method according to claim 12.
Neither Luo nor Ismael explicitly teaches wherein, when generating the state machine model, information about the target system that is to be kept confidential according to a confidentiality criterion is removed from the state machine model.
However, Hebert teaches the concept wherein, when generating a [honeypot] model, information about a target system that is to be kept confidential according to a confidentiality criterion is removed from the [honeypot] model ([abstract] fake data is subsequently used to seed and enable a honeypot so that access to such honeypot and fake data can be monitored and/or logged; [0018] differential privacy as provided herein allows for diverse anonymization techniques for building usable data for generating honeypot data and/or by running diverse analytics tasks, while removing any user sensitive data); and
Luo teaches wherein the [honeypot] model is the state machine model ([0121] FIG. 6 is a visualization of building a Markov decision process (MDP) state graph from a session table in accordance with some embodiments; in this example, we will use the real world example to explain how we build MDP and calculate the probabilities for each response).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the sensitive data removal teachings of Hebert with the honeypot creation teachings of Luo in view of Ismael. A honeypot is a security concept which is designed to act as a decoy, providing a target for attackers to waste effort on while the rest of the system remains secure; providing a honeypot which comprised (accidentally or otherwise) sensitive data would be counterproductive, resulting in a failure to protect sensitive data; it would therefore be obvious to remove such data to prevent leakage.
Claim(s) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo in view of Ismael, and further in view of Dalke et al (US 12,739,271).
Regarding Claim 26:
Luo in view of Ismael teaches the method according to claim 12.
Neither Luo nor Ismael explicitly teaches wherein the one or more known vulnerabilities are obtained from a database of security gaps comprising vulnerabilities for different types of operating systems.
However, Dalke teaches the concept wherein the one or more known vulnerabilities are obtained from a database of security gaps comprising vulnerabilities for different types of operating systems ([col 18 line 49-61] the system 800 includes a server 802 connected to multiple repositories 804(1) to 804(N) (N>0) via one or more networks 806; each of the repositories 804, such as a representative repository 804(N), may include information about various vulnerabilities, such as a vulnerability 808(1) to a vulnerability 808(M) (M>0); the representative repository 804(N) may include attributes associated with each vulnerability; for example, the vulnerability 808(1) has associated attributes 810(1) and the vulnerability 808(M) has associated attributes 810(M); [col 19 line 63-col 20 line 18] data associated with vulnerabilities, including attributes associated with the vulnerabilities, is gathered; each attribute may include details associated with each vulnerability, such as the operating system(s), operating system versions, a type of application that may include the vulnerability, the attack vectors, network access details, information from the CVE system, a score from the CVSS, details underlying the CVSS score, and other details; after collecting data associated with vulnerabilities, a subset of those vulnerabilities that are known to be exploited is identified, e.g., using the DHS CISA Known Exploited Vulnerabilities (KEV) database and other similar databases).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the vulnerability repository teachings of Dalke with the honeypot creation teachings of Luo in view of Ismael, in order to incorporate a large volume of external information about known vulnerabilities and the relevant attributes thereof, thereby allowing creation of more accurate baseline models, reducing the overall number of iterations required to create accurate response models thus improving efficiency of generating a honeypot and the resulting believability of said honeypot.
Response to Arguments
Applicant's arguments filed 7/7/2026 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 112 and 35 USC 101:
Applicant’s amendments have overcome the previous 35 USC 112 and 101 rejections, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 103:
Examiner’s response to applicant’s arguments, page 7 paragraph 2: Examiner disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “identify or label chains of states as corresponding to specific, named vulnerabilities; structure the model around vulnerability-specific exploitation paths”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claim recites “ascertaining, for each one or more known vulnerabilities, a corresponding chain of states of the state machine model that, when followed, makes it possible to exploit the vulnerability”. Luo, e.g. [0085], [0089], [0090], recites a method for building a decision tree to maximize the likelihood that an attacker exploits a vulnerability; Luo, [0107] recites “we reward the responses that could lead us to the final attack packet, and punish the ones that lead to the dead end session”. In other words, the system builds a chain of states that leads to exploitation of the vulnerability. Therefore, Luo’s reward system discloses “ascertaining, for each one or more known vulnerabilities, a corresponding chain of states of a state machine model”.
Examiner’s response to applicant’s arguments, page 7 paragraph 3-page 8 paragraph 1: Examiner disagrees. Luo’s system is building a Markov Decision Process, which Luo defines as a model for sequential decision making, i.e. “chain of states” (e.g. [0096]). Luo’s system models a series of request/response states throughout an entire attack session (e.g. [0107]). Luo therefore builds a chain of states to make it possible for an attacker to exploit a particular vulnerability.
Examiner’s response to applicant’s arguments, page 8 paragraph 3: Examiner disagrees. Luo’s system explicitly uses simulated responses from IoT devices by probing the devices on the Internet with IoTScanner to learn their expected behaviors to inputs (e.g. [0051]). This is the very definition of modeling the devices’ interfaces. It then builds the “chain of states” modeling the expected IoT device responses to attacker requests. With regard to “generating the state machine model” and “generating the honeypot”, the honeypot itself is a state machine model. Each update of the MDP in Luo can be seen as generating a new honeypot, which collects more responses, which updates the database to update the MDP again, thereby “generating a new honeypot”.
Examiner’s response to applicant’s arguments, page 8 paragraph 4-page 9 paragraph 1: Examiner disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “taking a named vulnerability as a structured operational input to the MDP and tracing, prospectively and vulnerability-by-vulnerability, which sequence of states in the model enables its exploitation”, “taking each known vulnerability and ascertaining the particular chain of states in the model that, when followed, makes exploitation of that vulnerability possible”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Luo teaches what is claimed, i.e. ascertaining, for each one or more known vulnerabilities, a corresponding chain of states of the state machine model that, when followed, makes it possible to exploit the vulnerability, as shown above.
Examiner’s response to applicant’s arguments, page 9 paragraph 2-page 10 paragraph 1: Examiner disagrees. To begin with, a honeypot is a live application, executing code. Preventing a system from performing unwanted actions is applicable to any system by definition: the actions are unwanted. Applicant argues that eliminating dangerous execution states from Luo’s chain of states renders Luo’s honeypot ineffective for its intended purpose, however the opposite is true: Luo seeks responses that lead to the final attack packet (e.g. [0107]); Luo explicitly highlights the dangers of running the final attack request (e.g. [0048]): “For high-interaction honeypots, they usually deploy the real system or emulator in the virtual machine (VM) to react to attackers (e.g. responding to requests or executing uploaded/injected script). Our honeypot generates the response purely based on the learned knowledge, but not running it.” Ismael teaches a method of avoiding executing unwanted actions: by pruning the execution state from a chain of states (e.g. [col 18 line 39-col 19 line 23). Therefore, Luo and Ismael are compatible.
Applicant’s arguments with regard to independent claims 20 and 21 are similar to those regarding claim 12 and are therefore responded to in a similar way.
Applicant further argues that the dependent claims are allowable due to depending on an allowable independent claim. However, as shown above, the independent claims are not allowable.
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 FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
