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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 30, 2026 has been entered.
Response to Amendment
This action is responsive to an amendment filed on 01/30/2026. Claims 1, 4, 8, 11, 14 and 17 have been amended. Claims 3, 10 and 16 have been canceled. Claims 1-2, 4-9, 11-15 and 17-20 are pending for examination.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 01/30/2026, with respect to the rejection of the pending claims under 35 U.S.C. §103 have been fully considered but they are not persuasive.
Applicant argues that updating the model using the new data does not disclose or suggest updating code previously generated by the model. To this end, claim 1 additionally recites that "a record of the abnormal network traffic" detected by the original abnormal network traffic detection code is input to the ML chatbot or voice bot. Polleri does not disclose a similar record being input to a ML chatbot or voice bot." (Arg./Rem. Page 8)
Examiner respectfully disagrees. Polleri expressly teaches generating executable code for a machine learning application through a chatbot-driven interface. Polleri further teaches executing, testing, monitoring, and modifying the generated machine learning application in response to feedback, performance metrics, and additional data inputs. Polleri discloses that: The model composition engine can receive inputs from a user through chatbot and can output one or more machine learning applications as executable code that be run on various infrastructure through the infrastructure interfaces [¶¶ 0050-0051]. Polleri additionally teaches prompt the user to locate other/additional data, …leverage the second user identified information, the data, and the library components to determine the one or more output metrics that can be predicted by the machine learning application …monitoring values on ongoing basis…inform the user of the monitored values…variables of the model can be adjusted based on the output values…providing controls to adjust model. The controls can be executed through a Chatbot, a graphical user interface, or one or more user selectable menus. Controls allow a user to adjust the outcome of the model by adjusting the variables used for the selected algorithm…the values of the algorithm can be automatically adjusted to achieve a desired QoS/KPI outcome….compiling model into a machine learning application. the model can be compiled into stand-alone executable code [¶¶ 0091-0099]. A person of ordinary skill in the art would have understood that modifying the generated machine learning application in response to feedback and additional data necessarily entails updating the previously generated executable code implementing the machine learning application. Polleri repeatedly describes generating, compiling, testing, adjusting, and regenerating executable machine learning applications using selected pipelines, software modules, microservices, and infrastructure modules. The resulting updated machine learning application therefore constitutes updated code corresponding to the previously generated code. Under a broad but reasonable interpretation, regenerating or modifying executable machine learning application code based on additional data and feedback satisfies the claimed “update the code” limitation. Accordingly, Polleri teaches or at least renders obvious updating previously generated code based on additional data and execution feedback.
Therefore, the Examiner remains unpersuaded and maintains that the applied references, Cho and Polleri, collectively teach all of the limitations of the applicant’s claim.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8 and 14 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 13 of U.S. Patent No. 12461841. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, recite analogous limitations, and they achieve the same overall result of generating and updating executable code using ML model. Therefore, the claims of the present application are considered obvious variant of US Patent 12461841.
The table below shows comparison between the instant application and the reference US Patent 12461841.
18/216,035 (instant application)
US 12461841 (reference US Patent)
Claim 1. A computer system for detecting abnormal network traffic and providing updated abnormal network traffic detection code, the computer system comprising:
one or more processors;
a memory storing executable instructions thereon that, when executed by the one or more processors, cause the one or more processors to:
transmit a prompt for abnormal network traffic detection code to a machine learning (ML) chatbot or voice bot to cause an ML model to generate the abnormal network traffic detection code, receive the abnormal network traffic detection code from the ML chatbot or voice bot,
wherein the abnormal network traffic detection code comprises additional instructions that, when executed by the one or more processors, cause the one or more processors to:
detect abnormal network traffic, and
report the abnormal network traffic to a user;
transmit a prompt for updated abnormal network traffic detection code and a record of the abnormal network traffic to the ML chatbot or voice bot to cause the ML model to generate the updated abnormal network traffic detection code, and
receive the updated abnormal network traffic detection code from the ML chatbot or voice bot.
Claim 1. A computer system for network security vulnerability inspection, the computer system comprising:
one or more processors;
a memory storing executable instructions thereon that, when executed by the one or more processors, cause the one or more processors to:
transmit a prompt for a network security vulnerability testing code to a machine learning (ML) chatbot to cause an ML model to generate the network security vulnerability testing code, and receive the network security vulnerability testing code from the ML chatbot,
wherein the network security vulnerability testing code comprises further instructions that, when executed by the one or more processors, cause the one or more processors to:
scan a network to identify network computing devices, scan one or more of the network computing devices to identify security vulnerabilities and vulnerable network computing devices, and
communicate an identification of the security vulnerabilities and/or the vulnerable network computing devices to a user
…transmit a prompt for updated network security vulnerability testing code and the security vulnerability announcement to the ML chatbot to cause the ML model to generate the updated network security vulnerability testing code,
receive the updated network security vulnerability testing code from the ML chatbot, …
Claims 8 and 14 of the instant application correspond respectively to claims 8 and 13 of U.S. Patent No. 12461841.
Claims 1, 7-8, 13-14 and 20 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 7-8, 14-15 and 20 of co-pending Application No. 18/216,226. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, recite analogous limitations, and they achieve the same overall result of generating and updating executable code using ML model. Therefore, the claims of the present application are considered obvious variant of co-pending application No. 18/216,226. This is a provisional non-statutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
The table below shows comparison between the instant application and the reference co-pending application no. 18/216,226.
18/216,035 (instant application)
18/216,226 (co-pending application)
Claim 1. A computer system for detecting abnormal network traffic and providing updated abnormal network traffic detection code, the computer system comprising:
one or more processors;
a memory storing executable instructions thereon that, when executed by the one or more processors, cause the one or more processors to:
transmit a prompt for abnormal network traffic detection code to a machine learning (ML) chatbot or voice bot to cause an ML model to generate the abnormal network traffic detection code,
receive the abnormal network traffic detection code from the ML chatbot or voice bot,
wherein the abnormal network traffic detection code comprises additional instructions that, when executed by the one or more processors, cause the one or more processors to:
detect abnormal network traffic, and
report the abnormal network traffic to a user;
transmit a prompt for updated abnormal network traffic detection code and a record of the abnormal network traffic to the ML chatbot or voice bot to cause the ML model to generate the updated abnormal network traffic detection code, and
receive the updated abnormal network traffic detection code from the ML chatbot or voice bot.
Claim 1. A computer system for enforcing a privacy policy by scanning unstructured data using a machine learning (ML) chatbot, the computer system comprising:
one or more processors; and
a memory storing executable instructions thereon that, when executed by the one or more processors, cause the one or more processors to:
send a privacy policy and a prompt for privacy enforcement code to a ML chatbot to cause an ML model to generate the privacy enforcement code,
receive the privacy enforcement code from the ML chatbot,
wherein the privacy enforcement code comprises further instructions that, when executed by the one or more processors, cause the one or more processors to:
scan a set of unstructured data, detect one or more potential violations of the privacy policy in the set of unstructured data,
communicate the one or more potential violations to a user,…
send a prompt that includes the privacy policy and the new privacy law or regulation to the ML chatbot to cause the ML model to generate updated privacy enforcement code that complies with the new law or regulation, and
receive the updated privacy enforcement code from the ML chatbot.
Claims 7, 8, 13, 14 and 20 of the instant application correspond respectively to claims 7, 8, 14, 15 and 20 of Co-pending application 18/216,226.
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 1-2, 7-9, 13-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KR 102619905 (Cho) in view of US 2021/0081819 (Polleri et al.).
Regarding Claim 1, Cho teaches a computer system for detecting abnormal network traffic ([Page 2, Para. 7] Detecting abnormal traffic from target data by inputting it into an artificial intelligence-based detection model), the computer system comprising: one or more processors; a memory storing executable instructions thereon that, when executed by the one or more processors, cause the one or more processors to ([Page 11, Para. 9] artificial intelligence-based abnormal data access prevention method according to an embodiment of the present application may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium):…wherein abnormal network traffic detection code comprises additional instructions that, when executed by the one or more processors, cause the one or more processors to: detect abnormal network traffic, and report the abnormal network traffic to a user ([Page 6, Para. 3, 7] an artificial intelligence-based abnormal data access prevention device according to an embodiment of the present application includes a collection unit that collects target data accessing a predetermined data server, and inputs the target data into a previously learned artificial intelligence-based detection model. It may include a detection unit that detects abnormal traffic from the target data, and a control unit that stops transmission of data associated with the data server when the abnormal traffic is detected …if the control unit determines that the target data is data corresponding to the hacking attempt, it may transmit a warning signal to a preset user terminal).
However, Cho does not teach, but Polleri teaches transmit a prompt for abnormal network traffic detection code to a machine learning (ML) chatbot or voice bot to cause an ML model to generate the abnormal network traffic detection code, and receive the abnormal network traffic detection code from the ML chatbot or voice bot ([¶¶ 0049-0051] A machine learning platform can generate highly customizable applications. …The model composition engine can receive inputs from a user through an interface. The interface can include various graphical user interfaces with various menus and user selectable elements. The interface can include a chatbot (e.g., a text based or voice based interface). The user can interact with the interface to identify one or more of: a location of data, a desired prediction of machine learning application, and various performance metrics for the machine learning model. The model composition engine can output one or more machine learning applications. The machine learning applications can be stored locally on a server or in a cloud-based network. The model composition engine can output the machine learning application as executable code [i.e., abnormal network traffic detection code], that be run on various infrastructure through the infrastructure interfaces. Note: Although, Polleri alone does not explicitly disclose the abnormal network traffic detection code, Cho provides that functionality, and Polleri provides the mechanism (chatbot prompting and code generation) to generate such code), transmit a prompt for updated abnormal network traffic detection code and a record of the abnormal network traffic to the ML chatbot or voice bot to cause the ML model to generate the updated abnormal network traffic detection code, and receive the updated abnormal network traffic detection code from the ML chatbot or voice bot ([¶¶ 0091-0099] prompt the user to locate other/additional data, …leverage the second user identified information, the data, and the library components to determine the one or more output metrics that can be predicted by the machine learning application …monitoring values on ongoing basis…inform the user of the monitored values…variables of the model can be adjusted based on the output values…providing controls to adjust model. The controls can be executed through a Chatbot, a graphical user interface, or one or more user selectable menus. Controls allow a user to adjust the outcome of the model by adjusting the variables used for the selected algorithm…the values of the algorithm can be automatically adjusted to achieve a desired QoS/KPI outcome….compiling model into a machine learning application. the model can be compiled into stand-alone executable code. [¶ 0284], the models trained using machine learning or artificial intelligence algorithms may be (optionally) revised (or tuned) based on additional relevant data received…if an open source library or other external code base was recently updated, the machine learning models may be tuned to include a temporary weighted preference against using the recently updated library based on concerns for stability and backwards compatibility. [¶ 302], When new data from a new client/supplier/domain is added to the data store, a matching service will automatically detect which features should be fed to the machine learning solution, based on the weighted list previously computed. The pre-processing of features allows the machine learning problem to be executed far more quickly. Based on the features found for the new client/supplier/domain, the weighted list gets updated to improve the machine learning model. This weighted list is regularly updated based on new data intake and used to improve feature selection of existing clients. Therefore, it would be realized that Polleri teaches or at least renders obvious transmitting a prompt for updated code and execution-result feedback to a chatbot ML model to cause generation of updated code and receiving the updated code therefrom).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Polleri’s chatbot-bot based code generation framework to create executable code and feedback based updating technique into Cho’s abnormal network traffic detection model, because such combination would have yielded the predictable result of using a known AI-based model for generation executable code for detecting abnormal network traffic and revises the code based on execution results in order to improve accuracy, usability, and efficiency of automatically generate d code.
Regarding Claim 2, Cho teaches the computer system of claim 1 wherein the additional instructions, when executed by the one or more processors, further cause the one or more processors to examine, during a learning mode, network traffic to identify normal network traffic, wherein detecting abnormal network traffic comprises comparing network traffic to the identified normal network traffic ([Page 8, Para. 8-10], a detection model can be learned to distinguish between normal traffic and hacking traffic…the data access prevention device collects learning data, which is time series data including hacking traffic and changes in traffic before and after the hacking traffic, and a transformer module that converts the data type of the collected learning data. Based on this, a detection model can be trained. In other words, the detection model of the data access prevention device can be repeatedly learned to understand the meaning of the hacking traffic by individually comparing the time series characteristics of the hacking traffic collected as learning data).
Regarding Claim 7, Cho teaches The computer system of claim 1, wherein the instructions, when executed by the one or more processors, further cause the one or more processors to: train the ML model with a training dataset, and validate the ML model with a validation dataset, wherein the training dataset and the validation dataset comprise a set of normal network traffic and/or a set of abnormal network traffic ([Page 8, Para. 7-8], learn an artificial intelligence-based detection model based on learning data including hacking traffic and changes in traffic before and after the hacking traffic. For example, hacking traffic may be data prepared (secured) in advance to include abnormal traffic in order to build an artificial intelligence based detection model, and the learning data for building a detection model is normal before and after the time the hacking traffic occurred).
Regarding Claims 8-9 and 13, the claim limitations are identical and/or equivalent in scope to claims 1-2 and 7, therefore, Claims 8-9 and 13 are rejected under the same rationale as claims 1-9 and 7.
Regarding Claims 14-15 and 20, the claim limitations are identical and/or equivalent in scope to claims 1-2 and 7, therefore, Claims 14-15 and 20 are rejected under the same rationale as claims 1-2 and 7.
Claims 4, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Cho in view of Polleri and further in view of US 2008/0196099 (Shastri).
Regarding Claim 4, Cho in view of Polleri do not explicitly teach, however, Shastri teaches the computer system of claim 1 wherein the additional instructions, when executed by the one or more processors, further cause the one or more processors to block the abnormal network traffic by transmitting a first transmission control protocol reset (TCP RST) packet to a source of the abnormal network traffic, and transmitting a second TCP RST packet to a destination of the abnormal network traffic ([¶¶0069-0075] an enforcer can be configured to maintain the state of all, e.g., TCP and UDP connections within an organization's network. This can be useful for determining the protocol of a network packet, … rules based enforcement can be performed on the packet. Rules based enforcement allows the user to define one or more rules that governs the actions taken by the enforcer. …the enforcer can comprise mechanisms to "enforce" or terminate TCP and UDP connections that an identified packet is participating in. These mechanisms can include sending a TCP RST (reset) packet to the source and destination IP address. This action can be continued until both sides of the connection are terminated. Another mechanism can be placing the IP address within the organization in a network blackout for a brief period of time. The Enforcer will send TCP RST packets to the source and destination IP address of any machine communicating with the machine in the network blackout).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shastri’s teachings of terminating connection using TCP RST packet to the combined teachings of Cho and Polleri, because such incorporation would have allowed preventing system from hacking.
Regarding Claims 11 and 17, the claim limitations are identical and/or equivalent in scope to claim 4, therefore, Claims 11 and 17 are rejected under the same rationale as claim 4.
Claims 5, 6, 12, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Cho in view of Polleri and further in view of US 2015/0128246 (Feghali et al.).
Regarding Claim 5, Cho in view of Polleri do not explicitly teach, however, Feghali teaches the computer system of claim 1 further comprising a first network interface and a second network interface, wherein the first network interface is operable to receive the abnormal network traffic, and wherein the additional instructions, when executed by the one or more processors, further cause the one or more processors to block the abnormal network traffic by preventing the second network interface from forwarding the abnormal network traffic ([¶¶ 0028-0031] A firewall devices positioned between the corporate network and the Internet, typically inserted on each connection to the external network. Firewall's function is to examine network traffic coming into and going out of the corporate network, and determining whether such traffic should be allowed to pass through. The firewall makes such determinations typically by examining part or all of the traffic and applying a set of rules that have been configured into the firewall. The outcomes of rule-based decisions typically include forwarding a packet to its intended destination, rejecting it with notification to the sender, or silently dropping it ("blocking" it). The firewall interface that connects to the corporate network may be called the "LAN side," and the firewall interface that connects to the Internet may be called the "WAN side." The purpose of the firewall is to protect corporate devices and information on the LAN side from attackers on the WAN side. A secondary purpose may be to prevent malicious users of the corporate network from sending corporate information to entities outside the corporate network. [¶ 0040], incoming traffic on the WAN side is being blocked from going out on the LAN side by the firewall, and incoming traffic on the LAN side is being blocked from going out on the WAN side).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Feghali’s firewall interfaces to block malicious data to the combined teachings of Cho and Polleri, because such incorporation would have allowed preventing system from malicious data.
Regarding Claim 6, Cho in view of Polleri do not explicitly teach, however, Feghali teaches the computer system of claim 1 wherein the additional instructions, when executed by the one or more processors, further cause the one or more processors to block the abnormal network traffic by communicating a security policy change to a network firewall ([¶ 0029], Firewall's function is to examine network traffic coming into and going out of the corporate network, and determining whether such traffic should be allowed to pass through. The firewall makes such determinations typically by examining part or all of the traffic and applying a set of rules [i.e., security policy] that have been configured into the firewall. The outcomes of rule-based decisions typically include forwarding a packet to its intended destination, rejecting it with notification to the sender, or silently dropping it ("blocking" it)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Feghali’s firewall to the combined teachings of Cho and Polleri, because such incorporation would have allowed preventing system from malicious data.
Regarding Claims 12 and 19, the claim limitations are identical and/or equivalent in scope to claim 6, therefore, Claims 12 and 19 are rejected under the same rationale as claim 6.
Regarding Claim 18, the claim limitations are identical and/or equivalent in scope to claim 5, therefore, Claim 18 is rejected under the same rationale as claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights