Remarks
Claims 67-71, 73-81, and 83-88 are pending.
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 Arguments
Applicant's arguments filed 2/12/2026 have been fully considered but they are not persuasive.
Applicant appears to point to 3 limitations of claim 67 and alleges “These added limitations find support in the specification where indicated, but are not found as claimed in the cited prior art, alone or in combination.” However, Applicant fails to even argue any specific reference, let alone provide any reasons as to why Applicant believes any specific reference fails to disclose any specific limitation or portion thereof. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Contrary to Applicant’s general allegations, Meidan discloses the following:
Regarding Claim 67,
Meidan discloses a method of detecting anomalous network traffic implemented in a computer system comprising a processor, memory accessible by the processor and storing computer program instructions and data, and computer program instructions to perform:
Monitoring an operational IoT network, having at least one associated protocol and having associated network security settings, to obtain network traffic data representing events occurring in the monitored operational IoT network, wherein at least a selected one of the events corresponds to a change in a sensor value associated with an IoT device which is connected to the IoT network (Exemplary Citations: for example, Abstract, Sections 1, and 3-5; monitoring IoT network and gathering data, for example. All networks are associated with at least one protocol, such as TCP, UDP, specific protocols for communicating with specific IoT devices (e.g., Ecobee thermostat communicates differently than Samsung SNH 1011 N webcam). Botnet protocols are also associated with IoT networks that have at least one infected device. Moreover, Meidan discusses sensor values changing, such as the Ecobee Thermostat sending such changes across a network, webcams transmitting video (each frame having any changes from the previous frame therein in the visual sensor data), not transmitting video, a person moving in front of the webcam, booting the webcam, etc., Philips B120N/10 baby monitor sending sensor data such as ambient light, temperature, humidity. Moreover, it is noted that IoT devices sending changes in sensor values is extremely well-known, such as temperatures being sent to/from thermostats and baby monitors, as one example);
Extracting data relating to a first plurality of features of the events from the obtained network traffic data, irrespective of the at least one protocol associated with the IoT network (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; extracting features, at least some of the extracting not relying upon any particular protocol or the same protocol as at least some others, for example);
…
In response to the detection of the anomalous event, autonomously halting access of an IoT device to the operational IoT network, based on the network security settings of the operational IoT network (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; automatic isolation of the compromised IoT device from the network, for example); and
…
Therefore, Meidan discloses the limitations being argued by Applicant in the general allegation above.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 67-71, 73-81, and 83-88 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 88 states “wherein at least a selected one of the events corresponds to a change in a sensor value associated with an IoT device which is connected to the IoT network”. However, the application as originally filed does not appear to discuss events corresponding to a change in a sensor value associated with an IoT device which is connected to the IoT network. All independent claims have the same issue and are rejected for the same reasons. All dependent claims are rejected at least based on their dependencies.
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 67-71, 73-75, 77-81, and 83-85 are rejected under 35 U.S.C. 103 as being unpatentable over Meidan (Meidan,Yair, Bohadana,Michael, Mathov,Yael, Mirsky,Yisroel, Breitenbacher,Dominik, ,Asaf, and Shabtai,Asaf. (2018). detection_of_IoT_botnet_attacks_N_BaIoT. UCI Machine Learning Repository. https://doi.org/10.24432/C5RC8J. https://archive.ics.uci.edu/dataset/442/detection+of+iot+botnet+attacks+n+baiot This includes everything at the linked webpages including the webpages themselves, the paper “N-BaIoT: Network-Based Detection of IoT Botnet Attacks Using Deep Autoencoders” (provided in the IEEE journal for pervasive computing, Vol. 13, No. 9, July-September 2018), and the downloadable dataset (which currently includes a .txt file and many other files, totaling ~1.7 GB in zip format). Selections from the above are provided in the attached NPL document, though adding the entirety of the dataset to the USPTO file for this document is unfeasible due to its size. The reader can simply go to the above URL and download the dataset) in view of Sahoo (Sahoo, Doyen et al., “Online Deep Learning: Learning Deep Neural Networks on the Fly”, pp. 2660-2666, Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence (IJCAI-18), 2018, obtained from https://www.ijcai.org/Proceedings/2018/0369.pdf).
Regarding Claim 67,
Meidan discloses a method of detecting anomalous network traffic implemented in a computer system comprising a processor, memory accessible by the processor and storing computer program instructions and data, and computer program instructions to perform:
Monitoring an operational IoT network, having at least one associated protocol and having associated network security settings, to obtain network traffic data representing events occurring in the monitored operational IoT network, wherein at least a selected one of the events corresponds to a change in a sensor value associated with an IoT device which is connected to the IoT network (Exemplary Citations: for example, Abstract, Sections 1, and 3-5; monitoring IoT network and gathering data, for example. All networks are associated with at least one protocol, such as TCP, UDP, specific protocols for communicating with specific IoT devices (e.g., Ecobee thermostat communicates differently than Samsung SNH 1011 N webcam). Botnet protocols are also associated with IoT networks that have at least one infected device. Moreover, Meidan discusses sensor values changing, such as the Ecobee Thermostat sending such changes across a network, webcams transmitting video (each frame having any changes from the previous frame therein in the visual sensor data), not transmitting video, a person moving in front of the webcam, booting the webcam, etc., Philips B120N/10 baby monitor sending sensor data such as ambient light, temperature, humidity. Moreover, it is noted that IoT devices sending changes in sensor values is extremely well-known, such as temperatures being sent to/from thermostats and baby monitors, as one example);
Extracting data relating to a first plurality of features of the events from the obtained network traffic data, irrespective of the at least one protocol associated with the IoT network (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; extracting features, at least some of the extracting not relying upon any particular protocol or the same protocol as at least some others, for example);
Training a machine learning model to classify the events using the extracted data relating to the first plurality of features, the machine learning model comprising a deep neural network model, and wherein training the machine learning model comprises minimizing an anomaly score through a function in the deep neural network model (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; training deep autoencoders until MSE stops decreasing (i.e. is minimized), used to generate the anomaly threshold, for example for example);
Monitoring additional operation of the operational IoT network to obtain additional network traffic data representing additional events occurring in the monitored operational IoT network and extracting additional data relating to a second plurality of features of the additional events from the obtained network traffic data (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; continuous monitoring and extracting data, statistics, features, etc., for example);
Classifying the additional events using the extracted additional data relating to the second plurality of features (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; classifying, for example);
Detecting an anomalous event based on the classification of the additional events (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; anomaly detected, for example);
In response to the detection of the anomalous event, autonomously halting access of an IoT device to the operational IoT network, based on the network security settings of the operational IoT network (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; automatic isolation of the compromised IoT device from the network, for example); and
Generating a plurality of feature vectors from the extracted data relating to the first plurality of features (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; deep autoencoder and feature vectors, for example);
But does not explicitly disclose that the function comprises backpropagation.
Sahoo, however, discloses that the function comprises backpropagation (Exemplary Citations: for example, Abstract, Sections 1, 3-3.3, 4.2, 4.3; backpropagation used to train deep neural network, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the online deep learning techniques of Sahoo into the IoT attack detection system of Meidan in order to effectively update DNN parameters online, allow for dynamically varying a DNN’s capacity, to provide for better learning through back propagation, and/or to allow for online modifications to DNNs to make them more effective.
Regarding Claim 77,
Claim 77 is a system claim that corresponds to method claim 67 and is rejected for the same reasons.
Regarding Claim 68,
Meidan discloses that the first plurality of features comprise network traffic related features and the network traffic related features further comprise protocol type, message type, and message addresses (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; the .txt file also shows this information as well as the webpage and datasets; protocol, channel, socket, IP address, MAC address, etc., as examples).
Regarding Claim 78,
Claim 78 is a system claim that corresponds to method claim 68 and is rejected for the same reasons.
Regarding Claim 69,
Meidan discloses that the first plurality of features comprise statistics related features and the statistics related features further comprise correlation between at least two traffic streams, covariance between at least two traffic streams, root squared sum of at least two variances of traffic stream, root squared sum of at least two means of traffic streams, standard deviation of packet size, and mean deviation of packet size (further comprise protocol type, message type, and message addresses (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; the .txt file also shows this information as well as the webpage and datasets; correlation/pcc, covariance/cov, radius, magnitude, std, mean, for example).
Regarding Claim 79,
Claim 79 is a system claim that corresponds to method claim 69 and is rejected for the same reasons.
Regarding Claim 70,
Meidan discloses that the first plurality of features comprise timing related features and the timing related features further comprise time between repeated messages and time between request messages and response messages (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; the .txt file also shows this information as well as the webpage and datasets; packet jitter information, including time windows, amount of time between packets, etc., as examples).
Regarding Claim 80,
Claim 80 is a system claim that corresponds to method claim 70 and is rejected for the same reasons.
Regarding Claim 71,
Meidan discloses that the machine learning model comprises at least one of a support vector machine model, a random forest model, and a deep neural network model (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; forest, SVM, and deep autoencoder, for example).
Regarding Claim 81,
Claim 81 is a system claim that corresponds to method claim 71 and is rejected for the same reasons.
Regarding Claim 73,
Meidan discloses that the deep neural network model comprises hyperparameters that are tuned and the hyperparameters further comprise at least one of a number of hidden layers in the deep neural network model, dimensions of the hidden layers of the deep neural network model, batch sizes for training of the deep neural network model, the first plurality of features included in the deep neural network model (this option is kept in since it is still in claim 83 as of 7/28/2025), a learning rate of the deep neural network model, and number of time steps to back propagate in the deep neural network model (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; tuning hyperparameters).
Regarding Claim 83,
Claim 83 is a system claim that corresponds to method claim 73 and is rejected for the same reasons.
Regarding Claim 74,
Meidan discloses that detecting the anomalous event comprises determining an anomaly score (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; score/value for an instance or the like, for example); and
Detecting the anomalous event when the anomaly score is greater than a threshold (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4; anomaly threshold above which an instance is considered anomalous, for example).
Regarding Claim 84,
Claim 84 is a system claim that corresponds to method claim 74 and is rejected for the same reasons.
Regarding Claim 75,
Meidan discloses that the anomaly score comprises at least one of a prediction error or a probability of an input vector given a hidden state vector for an IoT device at a given time (Exemplary Citations: for example, Abstract, Sections 1, 3, and 4).
Regarding Claim 85,
Claim 85 is a system claim that corresponds to method claim 75 and is rejected for the same reasons.
Claims 76 and 86 are rejected under 35 U.S.C. 103 as being unpatentable over Meidan in view of Sahoo and Vasseur (U.S. Patent Application Publication 2017/0078170).
Regarding Claim 76,
Meidan may not explicitly disclose that a notification is sent to a user and the IoT device is shut down.
Vasseur discloses that when the anomalous event is detected, a notification is sent to a user and the IoT device is shut down (Exemplary Citations: for example, Abstract, Paragraphs 16, 26-29, 40, 45-48, 52, 53, 58-64, 66-92, and associated figures; notify user, such as admin, restart, etc., as examples). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the anomaly detection and response techniques of Vasseur into the IoT attack detection system of Meidan as modified by Sahoo in order to allow for the detection of subtle, yet harmful, oscillations in a IoT network, to allow the system to generate and provide reports regarding the state of the network, to ensure that the appropriate entities are informed about anomalies, to provide additional countermeasures to remediate anomalous activity, and/or to increase security in the system.
Regarding Claim 86,
Claim 86 is a system claim that corresponds to method claim 76 and is rejected for the same reasons.
Claim 87 and 88 are rejected under 35 U.S.C. 103 as being unpatentable over Meidan in view of Sahoo and Microsoft (Microsoft, “Microsoft Computer Dictionary”, Fifth Edition, 2002, pp. 223, 338, 339).
Regarding Claim 87,
Meidan as modified by Sahoo does not appear to explicitly disclose that the processor comprises a microprocessor.
Microsoft, however, discloses that the processor comprises a microprocessor (Exemplary Citations: for example, pages 338-339, definition of microprocessor; microprocessor, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the microprocessor of Microsoft into the IoT attack detection system of Meidan as modified by Sahoo in order to use an extremely well-known processor, to allow the system to be run on computers using microprocessors, and/or to ensure compatibility with a wide range of processors.
Regarding Claim 88,
Meidan as modified by Sahoo does not appear to explicitly disclose that the processor comprises a FPGA.
Microsoft, however, discloses that the processor comprises a FPGA (Exemplary Citations: for example, page 223, FPGA definition; FPGA, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the FPGA of Microsoft into the IoT attack detection system of Meidan as modified by Sahoo in order to use an extremely well-known processor, to allow the system to be run on computers using FPGAs, to allow for reprogramming for innovations and upgrades, to use a processor that has flexibility and adaptability, and/or to ensure compatibility with a wide range of processors.
Conclusion
THIS ACTION IS MADE FINAL. 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 Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30.
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, Jeffrey Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey D. Popham/Primary Examiner, Art Unit 2432