DETAILED ACTION
This nonfinal action is in response to application 18/884,541 filed on 09/13/2024 with priority to foreign application DE102023209243.3 filed on 09/21/2023.
Receipt of applicant’s preliminary amendment filed 10/22/2024 is acknowledged.
Claims 11-19 are pending in the application. Claims 11, 18, and 19 are independent claims.
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 .
Claim Objections
Claims 11, 17, and 18 are objected to because of the following informality:
In claims 11, 17, and 18, “a textual target system specification” should read “a textual specification of the target system” to provide clearer antecedent basis.
Appropriate corrections are required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claims 11, 13-14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mehr (Patent No. US 11050787 B1, “Adaptive Configuration and Deployment of Honeypots in Virtual Networks”, published 06/29/2021) in view of McGrew et al. (Pub. No. US 20240333765 A1, “Method of Using Generative Large Language Models (LLM) For Cybersecurity Deception and Honeypots”, effectively filed 03/31/2023), hereinafter McGrew.
Regarding claim 11, Mehr teaches A method for generating a honeypot for a target system, (“In some embodiments, the system for adaptively configuring and deploying honeypots can create a profile or the user's virtual network (or a portion of the user's virtual network) by scanning the user's virtual network. For example, the system for adaptively configuring and deploying honeypots can interrogate the user's virtual network using discovery protocols to establish identifying information of computing devices in the user's virtual network” [Mehr page 3 col. 3 line 57 – line 64]) comprising:
output[ting], in response to an input that includes a textual target system specification, a honeypot configuration matching the input; (“As another example, network profile database 118 can be an electronic data store having a file system in which profile information (e.g., profile information 116) for various users' virtual networks are stored (e.g., as documents)” [Mehr page 9 col. 14–17]; “In some embodiments, after generating profile information about the user's compute resources, the system for adaptively configuring and deploying honeypots can use the profile information to select one or more honeypots from a group of preconfigured honeypot templates (e.g., implemented as virtual machine images) that are similar to the devices currently deployed in the user's virtual network… In some embodiments, after selecting preconfigured honeypot templates, the system for adaptively configuring and deploying honeypots can further configure the honeypots with properties that are similar to properties of the instance that was analyzed” [Mehr page 11 col. 3 line 57 – col. 4 line 32]; “In some embodiments, if multiple preconfigured honeypot templates are available that match the same properties of the virtual machine instance, honeypot configuration system 120 can determine which among the matching honeypots would arouse the least suspicion from an attacker (i.e., that is the closest match for the virtual machine instance). For example, if there are multiple preconfigured honeypot templates that match the operating system and function of the virtual machine instance, but none match the programming language, honeypot configuration system 120 can select a preconfigured honeypot template that has a programming language that resembles the programming language of the virtual machine instance and/or a programming language that is used by a similar virtual machine instance elsewhere in virtual network” [Mehr page 15 col. 11 lines 37–51]).
receiving the textual specification of the target system; ([Mehr page 11 col. 3 line 57 – col. 4 line 32] as detailed above)
feeding the received textual specification to [a] trained machine learning model; (“In some embodiments, honeypot configuration system 120 can use any suitable technique or combination of techniques to determine which among a variety of potentially matching preconfigured honeypot templates most closely matches a particular virtual machine instance in network 104. For example, in some embodiments, honeypot configuration system 120 can use a trained neural network that identifies a closeness of match between a property of a virtual machine instance and a property of a preconfigured honeypot template” [Mehr page 15 col. 11 line 64 – col. 12 line 7])
generating a honeypot according to the configuration output by the machine learning model in response to the feeding of the received textual specification. (“In some embodiments, the system for adaptively configuring and deploying honeypots can deploy the configured honeypots in connection with the user's virtual network. For example, the system for adaptively configuring and deploying honeypots can send instructions to an API (e.g., exposed by a service that the user can interact with to configure the user's compute resources) that can be called to implement changes to the user's compute resources” [Mehr page 11 col. 4 lines 41-48])
However, although Mehr expresses utilization of a trained neural network to identify appropriate honeypot configuration templates, Mehr does not expressly teach training a machine learning model to output a honeypot configuration in response to a textual target system specification.
In the same field of endeavor, McGrew teaches a system of honeypot generation (“In one aspect, a method for enhancing cybersecurity using Large Language Model (LLM)-generated honeypot schemes, the method includes generating a plurality of deceptive information using an LLM, configured to attract and engage potential attackers, where the plurality of deceptive information includes one or more characteristics referencing vulnerabilities of a network, continuously monitoring for interactions initiated by an interacting party with one or more components of the generated deceptive information, where the interaction is identified as a potential threat to the network, in response to detection of an interaction identified as a potential threat, extracting interaction data associated with the interacting party retrieved during the interaction, and retraining the LLM with the interaction data to create more effective honeypots” [McGrew ¶ 0023]) that train[s] a machine learning model to output a honeypot configuration in response to a textual target system specification. (“At block 302, process 300 generates a plurality of deceptive information using an LLM, configured to attract and engage potential attackers. For example, the threat management service 102 illustrated in FIG. 1 may generate a plurality of deceptive information using an LLM….In some examples, the LLM-generated honeypot schemes can further include a honey pot service configured to prompt the LLM to generate the plurality of deceptive information in accordance with a predetermined script, ensuring consistency with the plurality of deceptive information. The plurality of deceptive information includes one or more fabricated user accounts, files, and administrator accounts configured to engage potential attackers. The threat management service 102 can create Public Key Infrastructure (PKIX) certificates for servers in the network 104. These certificates can be customized by leveraging the LLM's capabilities to modify important elements like the subject and subjectAltName fields of the deceptive information metadata…The threat management service 102 can generate fabricated online personas that can either exist within the enterprise, such as in the corporate directory, or externally on various professional social media platforms like LinkedIn. The LLM can be particularly useful in this context, as it can generate diverse and contextually relevant content based on a set of associated prompts” [McGrew ¶ 0083-0086]; “At block 304, process 300 continuously monitors for interactions initiated by an interacting party with one or more components of the generated deceptive information. For example, the threat management service 102 illustrated in FIG. 1 may continuously monitor for interactions initiated by an interacting party with one or more components of the generated deceptive information…In some examples, the process 300 further includes generating one or more contextual labels in accordance with contextual data related to the interactions to distinguish and identify threatening interactions from non-threatening interactions. For example, the threat research service 112 illustrated in FIG. 1 may generate one or more contextual labels in accordance with contextual data related to the interactions to distinguish and identify threatening interactions from non-threatening interactions. The LLM can be improved by retraining it with one or more contextual labels, which can enhance the accuracy of potential threat detection and the effectiveness of the honeypots. For instance, the threat management service 102 shown in FIG. 1 can retrain the LLM with one or more contextual labels to boost the accuracy of potential threat detection and honeypot effectiveness” [McGrew ¶ 0096-0097]; The LLM generates deceptive information (and associated metadata/configuration information) in accordance with a predetermined script that can ensure consistency/contextual relevance to the target environment based on associated prompt/interaction information, and the LLM is further continually trained on received contextual/interaction information to improve honeypot generation).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated train[s] a machine learning model to output a honeypot configuration in response to a textual target system specification as taught by McGrew into Mehr because they are both directed towards systems of honeypot generation. Given that Mehr already expressly discusses potential utilization of a trained architecture to identify honeypot configuration templates ([Mehr page 15 col. 11 line 60 – col. 12 line 7]), incorporating the teachings of McGrew would further enable implementation of such an architecture trained to execute the intended functionality. Utilization of a large language model as the implemented architecture would further enable generation of more diverse and contextually relevant content [McGrew ¶ 0086].
Regarding claim 13, the combination of Mehr and McGrew teaches the limitations of parent claim 11, and Mehr further teaches wherein the received textual specification in each case include an indication of services and/or protocols to be supported by the honeypot, and/or one or more operating systems to be supported by the honeypot. (“In such an example, 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. In a more particular example, if the virtual machine instance uses a particular operating system, such as Linux, honeypot configuration system 120 can query honeypot repository 122 for preconfigured honeypot templates that use the Linux operating system” [Mehr page 14 col. 10 lines 57-66]). McGrew further teaches wherein the machine learning model is trained on textual specification input ([McGrew ¶ 0083-0086, 0096-0097] as detailed in claim 11 above).
Regarding claim 14, the combination of Mehr and McGrew teaches the limitations of parent claim 11, and McGrew further teaches evaluating the generated honeypot and updating the machine learning model according to the evaluation ([McGrew ¶ 0096-0097] as detailed in claim 11 above).
Regarding claim 16, the combination of Mehr and McGrew teaches the limitations of parent claim 11, and Mehr further teaches wherein the textual specification includes at least one Boolean Expression of target system functionalities and/or target system properties, and wherein at least one Boolean expression is ascertained from the received textual specification (“ In some embodiments, 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. As another example, honeypot configuration system 120 can receive profile information from network scanning system 112… As another more particular example, if the virtual machine instance uses a particular programming language, such as Python, honeypot configuration system 120 can query honeypot repository 122 for preconfigured honeypot templates that use Python…In some embodiments, honeypot configuration system 120 can using structured queries of any suitable complexity to search honeypot repository 122. For example, honeypot configuration system 120 can search for preconfigured honeypot templates having multiple properties, such as a particular combination of operating system, programming language, and function(s)” [Mehr page 14 col. 10 line 27 – page 15 col. 11 line 28]) McGrew further teaches wherein the machine learning model is trained on textual specification input and associated contextual properties ([McGrew ¶ 0083-0086, 0096-0097] as detailed in claim 11 above).
Regarding claim 17, the combination of Mehr and McGrew teaches the limitations of parent claim 11, and McGrew further teaches wherein the machine learning model is a large language model ([McGrew ¶ 0023] as detailed in claim 11 above).
Regarding claims 18 and 19, they are apparatus and product claims that substantially correspond to the method of claim 11, which is already taught by the combination of Mehr and McGrew as detailed above. Mehr further teaches a data processing system and/or non-transitory computer-readable medium configurable to perform the claimed functions (“FIG. 5 shows an example of a general architecture of a physical computing device (e.g., a server) that can be used to provide access to at least a portion of the mechanisms described herein (e.g., as a portion of compute resources 102, as a portion of frontend 110, as a portion of network scanning system 112, as a portion of honeypot configuration system 120, as a portion of honeypot deployment system 126, etc.) to configure and/or deploy customized honeypots in connection with a user's compute resources in accordance with some embodiments of the disclosed subject matter. The general architecture of physical computing device 510 depicted in FIG. 5 includes an arrangement of computer hardware and/or software modules that can be used to implement aspects of the disclosed subject matter. The hardware modules can be implemented with physical electronic devices, as described below, and physical computing device 510 can include many more (or fewer) elements than those shown in FIG. 5.” [Mehr page 20 col. 22 line 55 – page 21 col. 23 line 5]). Consequently, claims 18 and 19 are rejected for the same reasons as claim 11.
Claims 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Mehr and McGrew, as applied to claim 11 above, further in view of Chao et al. (Patent No. US 9912695 B1, “Techniques for Using a Honeypot to Protect a Server”, published 03/06/2018), hereinafter Chao.
Regarding claim 12, the combination of Mehr and McGrew teaches the limitations of parent claim 11.
However, the combination does not expressly teach prior to feeding the received textual specification to the trained machine learning model, removing data to be kept secret according to a confidentiality criterion from the textual specification.
In the same field of endeavor, Chao teaches a system of honeypot generation (“Techniques are disclosed herein for using a honeypot or a honey farm to protect a server. The server can be a content provider that provides access to one or more networked computing services via the Internet and/or other public and/or private network connections. A network security device, such as a web application firewall or other such device, can be configured to protect the server by detecting unauthorized activity on the server and to perform one or more actions in response to detecting such unauthorized activity. The network security device can be configured to provide information to a security system that includes one or more honeypots. The security system can use the information provided to initialize a duplicate user session in a honeypot of the security system that provides a simulated computing environment that mimics the computing environment of the server. The network device can then route network traffic from the unauthorized user to the security system, which can in turn route this traffic to the simulated computing environment” [Chao page 13 col. 4 line 65 – page 14 col. 5 line 17]) that prior to feeding the received textual specification as input, remov[es] data to be kept secret according to a confidentiality criterion from the textual specification (“The content synthesizer 140 can be configured to generate content that does not include any sensitive data and that can be customized based on the unauthorized party's interactions with the service provider 125 and/or the security system 150… The content synthesizer 140 can also be configured to generate synthetic content from sensitive information sources that have been sanitized to remove sensitive information, such as a database of financial, medical, or other sensitive information. The information in the database can be modified to remove sensitive information, such as payment account information, medical records, and/or other such sensitive information and replaced with information that is formatted and appears to be valid sensitive information but contains no actual sensitive information. The content synthesizer 140 can be configured to generate at least a portion of the synthetic content in advance of detecting unauthorized activity on the service provider 125 so that at least some synthetic content can be provided to the honeypot 135 which will be configured to support the duplicate user session to which the unauthorized party is redirected upon detection of the attack… The type of content accessed in the simulated computing environment of the honeypot, the keywords or phrases used in searches through the files system, documents, databases, and/or other synthetic content of the simulated computing environment can also be used to determine what synthetic content should be generated. Synthetic content related to these words and/or phrases can be generated from content” [Chao page 15 col. 8 line 53 – page 16 col. 9 line 29])..
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated prior to feeding the received textual specification as input, removing data to be kept secret according to a confidentiality criterion from the textual specification as taught by Chao into the combination because both Mehr and Chao are directed towards systems of honeypot generation. Incorporating the content synthesis and aggregation system of Chao would allow for a diverse, realistic collection of data upon which to train the LLM to generate synthetic content, while also preventing the model from inadvertently training on actual sensitive information ([Chao page 15 col. 8 line 65 – page 16 col. 9 line 8]).
Regarding claim 15, the combination of Mehr and McGrew teaches the limitations of parent claim 11.
However, the combination does not expressly teach wherein the input on which the machine learning model is trained includes information in the form of a result of a static rule, and wherein the static rule is applied to the textual specification, and the received textual specification is fed together with a result of the application.
In the same field of endeavor, Chao teaches a system of honeypot generation (“Techniques are disclosed herein for using a honeypot or a honey farm to protect a server. The server can be a content provider that provides access to one or more networked computing services via the Internet and/or other public and/or private network connections. A network security device, such as a web application firewall or other such device, can be configured to protect the server by detecting unauthorized activity on the server and to perform one or more actions in response to detecting such unauthorized activity. The network security device can be configured to provide information to a security system that includes one or more honeypots. The security system can use the information provided to initialize a duplicate user session in a honeypot of the security system that provides a simulated computing environment that mimics the computing environment of the server. The network device can then route network traffic from the unauthorized user to the security system, which can in turn route this traffic to the simulated computing environment” [Chao page 13 col. 4 line 65 – page 14 col. 5 line 17]) wherein the input includes information in the form of a result of a static rule, and wherein the static rule is applied to the textual specification, and the received textual specification is fed together with a result of the application (“The content aggregation unit 205 can be configured to automatically collect information by periodically crawling a list of web pages, blogs, discussion forums, newsgroups, and/or social media sites to collect information. The content aggregation unit 205 can be configured to crawl each site at a specified frequency. The content aggregation unit 205 can be configured to allow the administrator to schedule the collection of content from each source to occur on particular days and/or times. The content aggregation unit 205 can be configured to reformat the content found at the sites visited into other formats that can be included in synthetic content. For example, the content aggregation unit 205 can be configured to reformat content obtained from a web page or other site into a document that can be stored in a duplicate user environment instantiated in a honeypot and stored in a database or file system where the document can be “discovered” by an unauthorized user” [Chao page 16 col. 9 line 61 – col. 10 line 22]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated ]) wherein the input includes information in the form of a result of a static rule, and wherein the static rule is applied to the textual specification, and the received textual specification is fed together with a result of the application as taught by Chao into the combination because both Mehr and Chao are directed towards systems of honeypot generation. Incorporating the content synthesis and aggregation system of Chao would allow for a diverse, realistic collection of data upon which to train the LLM to generate synthetic content, while also preprocessing data to be reformatted into a format that would enable analysis by the LLM (e.g., document format) ([Chao page 16 col. 9 line 61 – col. 10 line 22]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIJAY M BALAKRISHNAN whose telephone number is (571) 272-0455. The examiner can normally be reached 10am-5pm EST Mon-Thurs.
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, JENNIFER WELCH can be reached on (571) 272-7212. 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.
/V.M.B./
Examiner, Art Unit 2143
/JENNIFER N WELCH/Supervisory Patent Examiner, Art Unit 2143
Prosecution Insights