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 .
Response to Amendment
This action is responsive to an amendment filed on 07/15/2026. Claims 1, 8, and 14 have been amended. 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 07/15/2026, regarding non-statutory double patenting rejection are fully considered and are persuasive. The terminal disclaimer filed on 07/15/2026 has been reviewed and is accepted. The terminal disclaimer has been recorded. Therefore, double patenting rejection has been withdrawn.
Applicant’s arguments with respect to the rejection of the pending claims under 35 U.S.C. §103 have been fully considered.
Applicant argues that “Cho, upon detection, transmits a warning signal to a preset user terminal and transmits a message to the access devices that data transmission is temporarily suspended, none of these transmissions is a prompt for updated abnormal network traffic detection code, much less a prompt accompanied by a record of the abnormal network traffic sent to an ML chatbot or voice bot to cause the ML model to generate updated detection code, as recited by claim 1.” (Arg./Rem. Page 9)
"The test for obviousness is not whether . . . the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art." In re Keller, 642 F.2d 413, 425 (CCPA 1981) (citations omitted). "Non-obviousness cannot be established by attacking references individually where the rejection is based upon the teachings of a combination of references." In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986) (citing Keller, 642 F.2d at 425). In determining obviousness, furthermore, a reference "must be read, not in isolation, but for what it fairly teaches in combination with the prior art as a whole." Id.
In the current rejection, the Examiner relies on the combined teachings of Cho and Stevens (in combination with the prior art as a whole) to reject the limitations at issue. Cho teaches, in response to detecting abnormal network traffic, recording the corresponding abnormal traffic, specifically teaching that the device “may copy target data for which abnormal traffic is detected and then store (record) it in a buffer.” Stevens teaches an automated feedback process in which the AI system “receives an execution status failure result” including “command operation and output details,” “processes the failure result via NLP model/neural network,” and causes the receiver NLP to “generate instruction steps to resolve the failure,” with the “back and forth process” continuing until successful completion. Stevens further teaches that the NLP/neural network “generates or modifies application or script source code” in response to a prompt, that this process may be “continuously done,” and that “the previous source code gets continuously rewritten to accommodate new end-user command requests.” Therefore, it would have been obvious to apply Stevens's feedback-based code modification to Cho such that, in response to detecting and recording abnormal traffic, the detected abnormal-traffic record is supplied with an update request to the NLP/neural-network chatbot to cause modification of the previously generated abnormal-network-traffic-detection code and return the modified code, thereby permitting the detector to adapt its detection functionality based on abnormal traffic encountered during operation.
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 20250363035 (Stevens).
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): …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 [Page 3, Para 5-6], The data access prevention device can collect target data accessing the data server. For example, target data may be a concept that broadly includes various network signals, packets, files, connection signals, etc. …abnormal traffic can be detected from the target data by inputting the collected target data into a pre-trained artificial intelligence-based detection model. [Page 7, para. 11], when the data access prevention device detects abnormal data access or determines that a hacking attempt has occurred, …sends a notification/warning signal for the situation. It may be a device equipped to receive information from the access prevention device).
Although, Cho teaches detecting abnormal traffic from the target data by inputting it into a pre-trained artificial intelligence-based detection model, an artificial intelligence-based detection model (transformer model) based on learning data including hacking traffic and changes in traffic before and after the hacking traffic. however, Cho does not teach, but Stevens 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 ([¶ 0062] The system may be used in a variety of applications, including chatbots, voice assistants, code generation systems, and automation systems. [¶ 0082], receive user input in the form of natural language instructions. The model or neural network may then use NLP techniques to parse and interpret the instructions and may generate a series of machine level instructions based on the interpreted natural language instructions. [¶ 0222-0223], the natural language processing model or neural network generates or modifies application or script source code to perform the requested action specified by the end-user via prompt and executes the application or script to perform said instructions. …the operating system prompt could be accessed via text-to-speech technology. This would allow an end-user to speak into a microphone connected to or embedded with the system to input prompt requests. [¶ 0124] the natural language instruction can be immediately converted to machine-level code. Thus, Stevens teaches receiving generated executable/source code as a result of processing the prompt by the NLP/neural-network system), in response to detecting the abnormal network traffic, automatically 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 ([¶ 0132] receives an execution status failure result from a node, wherein the result includes command operation and output details. Next, the system processes the failure result via NLP model/neural network, wherein the NLP model/neural network is the receiver NLP. After that, the receiver NLP generates instruction [i.e., updated code] steps to resolve the failure. …the data input/output service delivers the instruction steps to the node. This back and forth process would continue until the task was completed successfully. [0222], the natural language processing model or neural network generates or modifies application or script source code to perform the requested action specified by the end-user via prompt and executes the application or script to perform said instructions. This process can be continuously done with the same or new application or script files. In the case where the same application or script file is being used, the previous source code gets continuously rewritten to accommodate new end-user command requests).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Cho’s AI-based abnormal-network-traffic detection system according to Stevens by implementing the abnormal-traffic detection functionality using source code generated by an NLP/neural-network chatbot or voice interface and by providing detected abnormal-traffic records as feedback to the NLP/neural-network system for generation or modification of the detection code. One of ordinary skill therefore would have been motivated to apply Stevens's automated feedback and code-modification technique to Cho's abnormal-traffic detector so that newly detected abnormal traffic could be used to revise the detection code, thereby adapting the detector to observed abnormal behavior and reducing the need for manual troubleshooting and modification.
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 Stevens and further in view of US 2008/0196099 (Shastri).
Regarding Claim 4, Cho in view of Stevens 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 Stevens, 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 Stevens and further in view of US 2015/0128246 (Feghali et al.).
Regarding Claim 5, Cho in view of Stevens 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 Stevens, because such incorporation would have allowed preventing system from malicious data.
Regarding Claim 6, Cho in view of Stevens 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 Stevens, 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
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 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