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 1-9 are pending.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-9 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites “a generative state machine model”. The specification and claims as originally filed contain no reference to a “generative” state machine model, not disclose any apparent equivalent. For this reason, the claim recites new matter. None of claims 2-7 fix this and are therefore rejected for the same reasons. Claims 8 and 9 contain corresponding subject matter and are therefore rejected for corresponding reasons. For the purposes of art rejection “generative” state machine model will be construed as a model which generates something.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-9 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 recites “a generative state machine model”. The specification and claims as originally filed contain no reference to a “generative” state machine model, nor a sufficiently defined equivalent. It is therefore unclear what “generative state machine model” is intended to mean. For this reason, the claim is indefinite. None of claims 2-7 fix this and are therefore rejected for the same reasons. Claims 8 and 9 contain corresponding subject matter and are therefore rejected for corresponding reasons. For the purposes of art rejection “generative” state machine model will be construed as a model which generates something.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 8 recites “a honeypot creating device, comprising at least one processor”. However, a “processor” may be viewed as a “software processor”, i.e. software per se; therefore, despite being claimed as an apparatus, no hardware is described as part of the device. Further, the claim does not appear to be process, manufacture, or composition of matter. To correct this, the examiner suggests incorporating an element of hardware which comprises the device.
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-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 generative 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 generative 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).
Regarding Claim 2:
Luo teaches the method according to claim 1. In addition, Luo teaches 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 2. 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 2. 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 12/24/2025 have been fully considered but they are not persuasive.
Regarding the rejection of claims under 35 USC 112(b) and 101:
Applicant’s amendments have overcome the previous 112(b) and 101 rejections. However, the amendments have introduced new issues, as shown above.
Regarding the rejection of claims under 35 USC 102:
Examiner’s response to applicant’s arguments, page 6 paragraph 2: Examiner disagrees. Applicant appears to argue that Luo’s model is merely a decision-making tool. However, said “decision-making tool” is explicitly described as a model built from states, i.e. “state machine model” (e.g. [0096]). Applicant argues “in state machine learning or machine learning, the state machine of a program or software (i.e. the learning target) is typically not known, but can be learned by observing the resulting output with well-formulated inputs”. This is the approach used by Luo, e.g. [0096]:
…MDP 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. 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.
Therefore, Luo teaches not merely what is claimed, but also what is argued. However, examiner also notes, 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., “in state machine learning or machine learning, the state machine of a program or software (i.e. the learning target) is typically not known, but can be learned by observing the resulting output with well-formulated inputs”) 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).
Examiner’s response to applicant’s arguments, page 6 paragraph 3-page 7 paragraph 1: 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., the algorithms shown in Fig. 2 and 3) 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 recited figures fail to show that the claimed state machine model is “generative” in a defined, meaningful sense, and therefore fail to show how the claimed “generative state machine model” is functionally different from the MDP state model of Luo.
Examiner’s response to applicant’s arguments, page 7 paragraph 2: 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., "makes it possible to improve the mimicking of services by a honeypot without manually inheriting the service characteristics, especially features of a network protocol used for the services. Therefore, a honeypot can be provided that seems realistic, for example without requiring manual implementation of a server for a network protocol (or service) that acts as a proxy. It is in particular possible for a honeypot to automatically adopt a new or updated version of a network protocol. A honeypot can thus not only mimic different versions of a service, but also different implementations of a service," and "superficial adaptations can easily be discovered by creating messages that are only one step further in the protocol handshake. Fingerprinting is moreover also possible for other network protocol applications. To counteract this form of honeypot discovery, a honeypot can be limited to mimicking only a specific version (which limits its use) and manually inheriting all protocol messages, or manually implementing a real SSH server that acts as a proxy for a honeypot (which is laborious and inefficient),") 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 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
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