DETAILED ACTION
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 7/1/2026 has been entered.
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 1, 3-9 are pending. Claim 2 is cancelled.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3-4, 8-9 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Luo et al (PGPUB 2019/0081980).
Regarding Claims 1, 8, and 9:
Luo teaches a method for creating a honeypot, a honeypot creating device, comprising at least one processor, and a non-transitory computer-readable medium on which is stored instructions for creating a honeypot, the instructions, when executed by a processor, causing the processor to perform the following steps ([0029] novel way to simulate the behavior of IoT devices to build an intelligent-interaction honeypot; [0016] a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor):
sending requests 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);
observing responses of the target system to the requests ([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);
creating, in accordance with the observed responses of the target system, a state machine model comprising a plurality of defined states and state transitions for a behavior of a network protocol according to which the target system responds to requests ([0048] our honeypot generates (i.e. “generative state machine”) the response purely based on the learned knowledge; [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); [0096] Markov decision processes is a model for sequential decision making when outcomes are uncertain, such as computing a policy of actions that maximize some utility with respect to expected rewards; a collection of actions can be performed in that particular state, which actions serve to move the system into a new state; at each decision epoch, the next state will be determined based on the chosen action through a transition probability function; it can be treated as a Markov chain in which a state transition is determined solely by the transition function and the action taken during the previous step, i.e. “comprising a plurality of defined states and state transitions”; the consequence of actions (i.e., rewards) and the effect of policies is not always known immediately; therefore, we utilize mechanisms to control and adjust policy when the reward of the current state space is uncertain; the mechanism is collectively referred as reinforcement learning; [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); and
creating a honeypot that responds to requests in accordance with the state machine model ([0048] our honeypot generates (i.e. “generative state machine”) the response purely based on the learned knowledge; [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);
wherein the state machine model is created by adapting a previously created other state machine model for another target system in accordance with 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 3:
Luo teaches the method according to claim 1. In addition, Luo teaches wherein the other state machine model is created 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 creating the other state machine model in accordance with 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 4:
Luo teaches the method according to claim 1. In addition, Luo teaches wherein the adapting of the other state machine model includes adapting a version of the network protocol the behavior of which models the other state machine model in accordance with the observed responses of the 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); [0048], [0062]-[0063], [0078], [0133] HTTP protocol).
Claim(s) 6 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Luo, and as further evidenced by Hypertext Transfer Protocol (Wikipedia, via archive.org, 10/1/2011) to provide support for inherent features.
Regarding Claim 6:
Luo teaches the method according to claim 1. In addition, Luo teaches wherein the network protocol is an application layer network protocol ([0048], [0062]-[0063], [0078], [0133] HTTP protocol; note HTTP is an application layer protocol, See Hypertext Transfer Protocol [page 2 paragraph 3]).
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) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo, and further in view of Sharifi Mehr (US 11,050,787).
Regarding Claim 5:
Luo teaches the method according to claim 2.
Luo does not explicitly teach 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 to see whether the other state machine model fulfills the functions needed to mimic the target system.
However, Sharifi Mehr teaches the concept 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 to see whether the other state machine model fulfills the functions needed to mimic 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, 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) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luo, and further in view of Hebert et al (PGPUB 2020/0186567)
Regarding Claim 7:
Luo teaches the method according to claim 1.
Luo does not explicitly teach wherein information about the target system to be kept secret according to a confidentiality criterion is removed from the state machine model when the state machine model is created.
However, Hebert teaches the concept wherein information about a target system to be kept secret according to a confidentiality criterion is removed from a [honeypot] model when the [honeypot] model is created ([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. 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.
Response to Arguments
Applicant's arguments filed 7/1/2026 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 112 and 101:
Applicant’s amendments have overcome the previous 112(a), 112(b), and 101 rejections, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 102:
Examiner’s response to applicant’s arguments, page 6 paragraph 2: Examiner disagrees. In response to applicant’s argument that the “’previously created other state machine’ is on a different target system than the new state machine model created”, Examiner notes that this is not the language of the claims. The claims specifically recite the “previously created other state machine model for another target system”. For instance, a honeypot instanced on one system could target other systems, such as other IoT systems. Luo, for instance, teaches installing multiple honeypot instances in a distributed cloud environment (e.g. [0044] honeypot instances 102a-c that we deployed on Amazon AWS and Digital Ocean). Each honeypot instance is for IoT “devices” (e.g. [0152]); therefore, even if all honeypot instances are “for” the same set of multiple IoT devices, each individual honeypot instance can be seen as “for” nonoverlapping target devices. In essence, each honeypot instance is “for” the target system and another target system. Further, as per Luo, [0044], the honeypot instances are implemented using virtual machine instances on a server, the instances emulating various different IoT devices; each separate VM instance can be seen as a target system, thereby teaching a state machine model (i.e. the honeypot instance) on another target system (the respective VM instance). Therefore, Luo teaches a “previously created other state machine model for another target system”.
Examiner’s response to applicant’s arguments, page 6 paragraph 3: Examiner disagrees. As shown above, each honeypot instance can be seen as a previously created other state machine model for another target system. Each honeypot receives requests separately, and responds. This information is synchronized with the IoT-Oracle, which then updates the other honeypot instances. This can be seen as creating “new” state machine models (i.e. honeypots) from previously created honeypots in accordance with observed responses of a target system.
Examiner’s response to applicant’s arguments, page 6 paragraph 4-page 7 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., “base machines are learned for “one or more non-critical target systems” by sending requests to those specific, identified systems and observing their responses”) 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). Applicant’s own citation of Luo further states that Luo’s IoTScanner scans the Internet to perform active probing for any IoT devices that can respond to requests, i.e. “observed responses of a target system”. Regardless of whether or not the IoT device pool is broad, each response can still be seen as a response of a “target” system.
Examiner’s response to applicant’s arguments, page 7 paragraph 3-page 8 paragraph 1: Applicant misconstrues the previous rejection. Examiner has not mapped the IoT-Oracle database to the “previously created other state machine model”. Rather, it is the separate honeypot instances which are mapped to this element. For instance, a first honeypot instance (i.e. “previously created other state machine model”) may receive attack traffic and interact with attackers. The information about the interaction is synchronized with the IoT-Oracle, which is then retrieved by the other honeypot instances and used to update them, thereby creating new machine models (i.e. honeypot instances) adapted from the previously created other honeypot instance. Examiner is not conflating the repository itself with a state machine model. Rather, it is the honeypot instances themselves, updating with information from said repository.
Examiner’s response to applicant’s arguments, page 8 paragraph 2: Examiner disagrees. Applicant describes one aspect of Luo’s system while ignoring other aspects. The honeypot instances receive attacker requests and provide responses, and this information is used to update the repository. However, Luo also teaches that the IoT-Scanner is first used to actively probe target devices and collect their responses, adding them to the repository to build the raw knowledge for the initial honeypot instances (e.g. [0051]). The state machine models, i.e. honeypot instances, are therefore always created “in accordance with the observed responses of [a] target system”. Further, it is the nature of Internet communication that it is performed in accordance with some protocol, as further illustrated by Luo (e.g. [0048], [0062]-[0063] attacks and responses using HTTP protocol).
Examiner’s response to applicant’s arguments, page 9 paragraph 2: Regardless as to whether or not the data-collection exercise is over many “undifferentiated” devices, Luo is sending requests to devices and observing the response; in each case, the device receiving the request is a “target” device in that instance.
Examiner’s response to applicant’s arguments, page 9 paragraph 3: Examiner disagrees. Luo states use of HTTP in receiving requests and providing responses (e.g. [0048], [0062]-[0063], [0078], [0133]). Luo is therefore “adapting a version of the network protocol” to model the appropriate behaviors.
Applicant’s arguments with regard to independent claims 8 and 9 are similar to those regarding claim 1 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
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
Prosecution Insights