CTFR 17/861,947 CTFR 81329 Notice of Pre-AIA or AIA Status 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This Office Action is in response to the amendment filed on 2/11/2026. Claims 1-8, 10-14, 17-27, 29-30, and 33-34 have been amended. Claims 1-34 are pending for consideration. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Specification 06-31 AIA The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification. Response to Arguments Applicant’s arguments with respect to claim(s) 1-34 have been considered but are moot. Claim Rejections - 35 USC § 112 07-30-01 AIA 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. 07-31-01 Claims 1-34 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. With regards to claims 1, 10, 20 and 25, the new claim requires receiving incoming data on a software layer and use the incoming data to detect a potential threat at least in part on one or more layers below the software layer; however, the specification is silent with respect to receiving incoming data on a software layer and use the incoming data to detect a potential threat at least in part on one or more layers below the software layer . The specification as originally filed refers to the use of incoming data operated within layer 3 (see paragraphs 0082-0086 of the Applicant’s specification, “incoming traffic 330 (e.g., the inbound data 130 illustrated in FIGS. 1 and 2) is received by the decipher block 310. At least a portion of the decipher block 310 may operate within the network layer (Layer 3) of the OSI model and may categorize the incoming traffic 330 (e.g., data packets) into one or more threat categories”), but do not have adequate support for receiving incoming data on a software layer and using the incoming data to detect a potential threat at least in part on one or more layers below the software layer. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-16, 18-31 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over St. Neitzel et al. (US 20110219449) (hereinafter Neitzel) in view of PENG et al. (CN 113098835) (hereinafter PENG), and further in view of Ramsey et al. (US 9009828) (hereinafter Ramsey) . Regarding claim 1, Neitzel discloses a system comprising: one or more circuits to form at least a portion of a production system to perform one or more production tasks (Neitzel: paragraphs 0007, 0022 and 0032-0033, “for real-time detection of malicious software ("malware"), wherein execution of a suspicious software application may be emulated in a virtual operating system (e.g., Microsoft.RTM. Windows.RTM. compatible) environment in order to observe the behavior characteristics of that application in a "safe" environment. In one embodiment, emulation may occur in response to the suspicious application attempting to execute on the user's electronic device, and before the application is allowed to execute on the actual device (i.e., in "real-time"). If after observing the behavior of the suspicious application in the virtual environment, the simulation and detection system of embodiments described herein determines that the application is malicious, the application may not be permitted to execute on the user's actual device”), the network interface of each of the plurality of computing devices to: receive incoming data as the production system performs at least one of the one or more production tasks (Neitzel: paragraphs 0032-0033, “Upon receiving the indication, the processor 110 may be configured to first determine, at Block 202, whether the application attempting to execute on the user's device looks "suspicious."”), the one or more circuits to perform at least a portion of an emulation of at least some functionality of the production system to obtain information related to the potential threat (Neitzel: paragraphs 0033-0034, “In particular, according to embodiments of the present invention, the processor 110 (e.g., executing the simulation and detection application 126) may be configured to simulate Windows.RTM., or a similar operating system, functionality in order to create a virtual environment in which execution of the suspicious software application can be emulated”… “In one embodiment, the processor 110 may emulate all operating system functionality that is relevant to the suspicious software application including, for example, a registry, a file system, a graphical user interface (GUI), service handling, Internet and communication handling, and/or the like. The process of initializing the simulated operating system environment in accordance with one embodiment of the present invention is discussed in more detail below with regard to FIG. 3.”). Neitzel does not explicitly disclose the following limitation which is disclosed by PENG, the emulation to generate one or more deceptive communications that emulate one or more communications of the production system (PENG: page 5, “it needs to firstly return the correct response content to the requester, can help the requester to finish the RPC attack, so it can use the honey pot attack information, so how to respond is the key of the problem.”… “according to the response rule corresponding to the response rule matched with the response template, generating simulation response content for the RPC request”); and send the one or more deceptive communications to a sender of the incoming data associated with the potential threat to obtain information related to the potential threat (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). Neitzel and PENG are analogous art because they are from the same field of endeavor, network protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Neitzel and PENG before him or her, to modify the system of Neitzel to include performing at least a portion of an emulation of at least some functionality of a production system to communicate with a sender of an incoming data associated with a potential threat and thereby obtain information related to a potential threat of PENG. The suggestion/motivation for doing so would have been to enhance a safety-protection ability of an actual system by a technology and a management means (PENG: see page 2). Neitzel in view of PENG does not explicitly disclose the following limitation which is disclosed by Ramsey, receive incoming data on a software layer (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”); and use the incoming data to detect a potential threat at least in part on one or more layers below the software layer (Ramsey: paragraphs (5), (17) and (27-28), “Using the attack signatures, the IDS 108 is capable of analyzing traffic at all of the Open Systems Interconnection (OSI) network layers that are visible to the customer network… Accordingly, the ability to scan for attacks on all of the relevant OSI layers allows the IDS 108 to provide more comprehensive network protection.”). Neitzel in view of PENG and Ramsey are analogous art because they are from the same field of endeavor, network protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Neitzel in view of PENG and Ramsey before him or her, to modify the system of Neitzel in view of PENG to include incoming data on a software layer and use the incoming data to detect a potential threat at least in part on one or more layers below the software layer of Ramsey. The suggestion/motivation for doing so would have been to perform additional analysis of a network traffic to identify potential attacks (Ramsey: paragraph (17)). Regarding claim 10, the claim 10 discloses a method claim that is substantially equivalent to the system of claim 1. Therefore, the arguments set forth above with respect to claim 1 are equally applicable to claim 10 and rejected for the same reasons. Neitzel as modified further discloses deceiving, by the network interface, a sender of the incoming data sends one or more messages to the sender of the communication to gather data associated with at least one of the sender or the communication (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). Regarding claim 20, the claim 20 discloses a medium claim that is substantially equivalent to the method of claim 10. Therefore, the arguments set forth above with respect to claim 10 are equally applicable to claim 20 and rejected for the same reasons. Regarding claim 25, the claim 25 discloses a system claim that is substantially equivalent to the method of claim 10. Therefore, the arguments set forth above with respect to claim 10 are equally applicable to claim 25 and rejected for the same reasons. Regarding claim 2, Neitzel as modified discloses wherein the one or more circuits are to categorize the incoming data and perform the portion of the emulation when the incoming data is categorized as being a potential threat to the production system (Neitzel: paragraphs 0007, 0022 and 0032-0035, “the simulation and detection application 126 may comprise one or more modules for instructing the processor 110 to perform the operations for simulating an operating system (e.g., Windows.RTM.) environment and for emulating the execution of a suspicious application in the virtual environment in order to determine whether the suspicious application is malicious”). Regarding claim 3, Neitzel as modified discloses wherein the one or more circuits are to determine whether to forward the incoming data to the production system based at least in part on at least one security policy, and the one or more circuits are to modify the at least one security policy based at least in part on the information related to the potential threat (Neitzel: paragraphs 0020, 0037-0038 and 0075, “embodiments of the present invention can be easily and quickly updated as new malicious software applications are discovered.” … “Once the Family Point totals have been updated, the processor 110 may, at Block 409, determine whether this was the last API function call of the suspicious application”). Regarding claim 4, Neitzel as modified discloses wherein individual ones of the plurality of computing devices each comprise a network interface card comprising the network interface of the individual computing device, the network interface card comprises a first connection over which to receive the incoming data, and a second connection over which to forward the incoming data to another component of the individual computing device comprising the network interface card (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 5, Neitzel as modified discloses the network interface comprises a data processing unit connected to the first connection to receive the incoming data therefrom and connected to the second connection to use the second connection to forward the incoming data (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 6, Neitzel as modified discloses wherein the one or more layers comprise at least one of a data link layer or a network layer (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 7, Neitzel as modified discloses wherein the software layer and the one or more layers are each a layer of an Open Systems Interconnection (OSI) model (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 8, Neitzel as modified discloses wherein the network interface is to: receive one or more responses to the one or more deceptive communications from the sender of the incoming data associated with the potential threat (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”); and use the one or more responses to obtain the information related to the potential threat (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 9, Neitzel as modified discloses wherein the information related to the potential threat comprises at least one of an Internet Protocol ("IP") address or a media access control ("MAC") address (PENG: pages 3 and 4, “correspondingly storing the request content of the RPC and the IP of the requester as honey pot log.”… “Optionally, the honey pot server, further adapted to analyze the log honey pot to obtain at least one kind of information as follows: attacker wallet address, IP data, RPC attack method.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 11, Neitzel as modified discloses determining whether to forward the incoming data to the production system based at least in part on at least one security policy, and modifying the at least one security policy based at least in part on the data gathered (Neitzel: paragraphs 0007, 0022 and 0032-0035, “the simulation and detection application 126 may comprise one or more modules for instructing the processor 110 to perform the operations for simulating an operating system (e.g., Windows.RTM.) environment and for emulating the execution of a suspicious application in the virtual environment in order to determine whether the suspicious application is malicious”). Regarding claim 12, Neitzel as modified discloses migrating deception operations to a different second computing device of the plurality of computing devices before deceiving the sender, the different second computing device to be isolated from the production system (PENG: pages 5-6, “In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 13, Neitzel as modified discloses further comprising emulating at least one production task (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 14, Neitzel as modified discloses wherein deceiving the sender comprises creating a breadcrumb to lead a sender to a decoy (PENG: pages 5 and 6, “Although in many cases, it can simulate generating response content by honey pot, but in the other part, the RPC request may be expected to obtain real data, and these data can be verified by other ways, such as blockchain the wallet balance and so on. In these cases, only by responding to the template cannot generate the response content of the deceiving requester, at this time, it is shown as not finding the response rule matched with the RPC request.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 15, Neitzel as modified discloses wherein the one or more messages comprises information to lure the sender to a decoy (PENG: page 4, “The generated simulated response content is returned to the requestor. The beneficial effects of the technical solution are as follows: aiming at the request of the RPC blockchain, and according to the response template for effective response, the request party of the suspected attack is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense .”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 16, Neitzel as modified discloses wherein the one or more messages provide information to the sender that is used to identify an unauthorized access attempt by the sender (PENG: page 4, “The generated simulated response content is returned to the requestor. The beneficial effects of the technical solution are as follows: aiming at the request of the RPC blockchain, and according to the response template for effective response, the request party of the suspected attack is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense .”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 18, Neitzel as modified discloses wherein the software layer corresponds to Layer 7 of an Open Systems Interconnection ("OSI") model (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 19, Neitzel as modified discloses further comprising: receiving, from the sender, one or more responses to the one or more messages (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”); and using the one or more responses to gather the data associated with the at least one of the sender or the incoming data (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 21, Neitzel as modified discloses wherein the computing device performs one or more production processes that comprise one or more production flows or pipes, and the one or more deception processes comprise one or more deception flows or pipes (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 22, Neitzel as modified discloses wherein detecting the potential threat comprises categorizing the particular communication as belonging to a potential threat category or a non-threat category (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claim 23, Neitzel as modified discloses wherein the one or more deception processes implements at least one of a decoy, a breadcrumb, a lure, or a bait (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claim 1 above, applies here. Regarding claims 24 and 26, Neitzel as modified discloses wherein the method further comprises: use the deception strategy to send the at least one communication to the sender to obtain the information (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”); determining whether to forward the particular communication to the production system based at least in part on at least one security policy (PENG: pages 5 and 6); using at least one response to the one or more communications to gather data (PENG: pages 5 and 6); and modifying the at least one security policy based at least in part on the information (PENG: pages 5 – 6 and 8, “Specifically, it can be set with a simulated identification to determine whether to send the real response content or the simulation response content to the requesting party. so as to concurrently process a plurality of RPC request, judging which RPC request is needed to obtain the real response content.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 27, Neitzel as modified discloses wherein when the instructions are executed by the at least one processor, the instructions cause the network interface to: determine whether to forward inbound data to the production system based at least in part on at least one security policy (Neitzel: paragraphs 0037-0038, “If it is determined, at Block 205, that the suspicious software application is malicious, according to one embodiment, the processor 110 may, at Block 206, cause a virus alert to be displayed to the user and prevent the application from executing on the user's device 100. Alternatively, if the processor 110 does not identify the suspicious application as malicious, the processor 110 may, at Block 207, simply allow the application to execute on the user's device 100, as originally initiated”); and modify the at least one security policy based at least in part on information received from at least one of the plurality of computing devices (Neitzel: paragraphs 0037-0038, “If it is determined, at Block 205, that the suspicious software application is malicious, according to one embodiment, the processor 110 may, at Block 206, cause a virus alert to be displayed to the user and prevent the application from executing on the user's device 100. Alternatively, if the processor 110 does not identify the suspicious application as malicious, the processor 110 may, at Block 207, simply allow the application to execute on the user's device 100, as originally initiated”). Regarding claim 28, Neitzel as modified discloses wherein the deception strategy emulates at least one production task performed by the production system (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 29, Neitzel as modified discloses wherein the network interface is to receive the data and determine whether the data represents a potential threat to the production system (Neitzel: paragraphs 0033-0034 and 0048, “If, however, the processor 110 determines that the application is suspicious, the process may continue to Block 203 where a simulated operating system (e.g., Microsoft Windows) environment may be initialized. In particular, according to embodiments of the present invention, the processor 110 (e.g., executing the simulation and detection application 126) may be configured to simulate Windows.RTM., or a similar operating system, functionality in order to create a virtual environment in which execution of the suspicious software application can be emulated. In one embodiment, the processor 110 may emulate all operating system functionality that is relevant to the suspicious software application including, for example, a registry, a file system, a graphical user interface (GUI), service handling, Internet and communication handling, and/or the like”). Regarding claim 30, Neitzel as modified discloses wherein the production system performs at least one or more production tasks on the software layer (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 31, Neitzel as modified discloses wherein the plurality of computing devices comprise first and second computing devices, the first computing device is to implement at least a portion of the production system, the second computing device is to be isolated from the production system, and the plurality of computing devices is to migrate the deception strategy from the first computing device to the second computing device (PENG: pages 5 and 6, “returning the generated simulation response content to the requester. As can be seen, the method shown in FIG. 1, the request for the RPC type to blockchain initiated, and according to the response template to the effective response, the suspected attack request party is deceiving the access is real RPC port, so as to realize the effective obtaining attack information, convenient for subsequent analysis and defense. In one embodiment of the present invention, in the above method, receiving the request sent by the requester RPC request comprises: an all-node client simulating the blockchain monitoring the appointed port of the RPC function in the simulated all-node client, so as to obtain the RPC request. the full node can be understood as the node of all the synchronous data blockchain and correspondingly, only the node of the synchronous part blockchain the data is a light node. Therefore, the RPC attack to the blockchain is mainly generated for the all-node client.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 33, Neitzel as modified discloses wherein the one or more layers comprise at least one of a data link layer or a network layer (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here. Regarding claim 34, Neitzel as modified discloses wherein the software layer and the one or more layer are each a layer of an Open Systems Interconnection (OSI) model (Ramsey: paragraphs (5) and (17), “For example, many known attacks, such as viruses attached to or embedded in an email message or World Wide Web ("Web") traffic occur on OSI layer 7 (the "application" layer)… Many attacks, however, occur on intermediate layers, and therefore would not be detected by a device scanning for signatures only on the application layer.”). The same motivation to modify Neitzel in view of PENG and Ramsey, as applied in claims 1 and 10 above, applies here . 07-21-aia AIA Claim (s) 17 is rejected under 35 U.S.C. 103 as being unpatentable over Neitzel in view of PENG and Ramsey, and further in view of Ludwig et al. (US 20190379696) (hereinafter Ludwig) . Regarding claim 17, Neitzel as modified by PENG and Ramsey does not explicitly disclose the following limitation which is disclosed by Ludwig, wherein detecting the potential threat comprises using at least one artificial intelligence application to categorize the incoming data (Ludwig: paragraphs 0026 and 0042, “The malicious activity response pipeline, as well as the cognitive system in which the malicious activity response pipeline is comprised, is an artificial intelligence application executing on data processing hardware that responds to detected malicious activities. The malicious activity response pipeline receives inputs from various sources including input over a network, a corpus of electronic documents or other data, data from a content creator, information from one or more content users, and other such inputs from other possible sources of input”). Neitzel in view of PENG and Ramsey and Ludwig are analogous art because they are from the same field of endeavor, data protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Neitzel in view of PENG and Ramsey and Ludwig before him or her, to modify the system of Neitzel in view of PENG and Ramsey to include detecting a potential threat in a communication comprises using at least one artificial intelligence application to categorize the communication of Ludwig. The suggestion/motivation for doing so would have been to improve an operation of a malicious activity response system in handling future malicious activity (Ludwig: paragraph 0005) . 07-21-aia AIA Claim (s) 32 is rejected under 35 U.S.C. 103 as being unpatentable over Neitzel in view of PENG and Ramsey, and further in view of KLEYMENOV et al. (US 20230106071) (hereinafter KLEYMENOV) . Regarding claim 32, Neitzel in view of PENG and Ramsey does not explicitly disclose the following limitation which is disclosed by KLEYMENOV, wherein the at least one processor comprises a data processing unit ("DPU") to implement the portion of the deception strategy (KLEYMENOV: paragraphs 0035-0036 and 0043, “the method for automatic aggregating and enriching data from honeypots in a network also comprises storing, in a storage unit of the permanent type operatively connected to the data processing unit, the extracted IoCs, said model samples and the secondary model sample.”). Neitzel in view of PENG and Ramsey and KLEYMENOV are analogous art because they are from the same field of endeavor, data protection. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Neitzel in view of PENG and Ramsey and KLEYMENOV before him or her, to modify the system of Neitzel in view of PENG and Ramsey to include a data processing unit ("DPU") to implement a portion of a deception strategy of KLEYMENOV. The suggestion/motivation for doing so would have been to identify different types of threats (KLEYMENOV: paragraph 0048). Conclusion 07-40 AIA 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 TRANG T DOAN whose telephone number is (571)272-0740. The examiner can normally be reached Monday-Friday 7-4 ET. 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, Lynn D Feild can be reached on (571)272-2092. 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. /TRANG T DOAN/Primary Examiner, Art Unit 2431 Application/Control Number: 17/861,947 Page 2 Art Unit: 2431 Application/Control Number: 17/861,947 Page 3 Art Unit: 2431
Prosecution Insights