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 Arguments
Applicant's arguments “Remarks” filed 11/25/2025 have been fully considered but are not persuasive.
Regarding the 103 rejections, applicant's arguments filed with respect to Miettinen have been fully considered but they are not persuasive.
Alleged no teaching of generating a second dataset of transformed feature-poor characteristics from feature-rich dataset
In Remarks/Arguments pg. 11, applicant contends:
“Likewise, Miettinen does not teach, suggest, or disclose generating a second
dataset of transformed feature-poor device characteristics from a feature-rich dataset as called for in the claims (as amended) of the present application, nor does it disclose collecting an additional real-world dataset of feature-poor characteristics for comparison.”
The relevant claim limitations appear to be: transforming, by a processor executing program instructions, a first data set of feature-rich device characteristics of devices with known device identities to a second data set of transformed device characteristics comprising feature-poor device characteristics with the known device identities; in claim 1. As noted in the previous Office Action, Miettinen teaches:
(Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic. It leverages the specificity of smart home devices that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure…When a new device identified by a newly observed MAC address starts communicating with the gateway, the latter records n packets {p1, p2, p3,...,pn} received from it during its setup phase. The end of the setup phase can be automatically identified by a decrease in the rate of packets sent. We extract 23 features, giving a vector representation for each packet pi = {f1,i, f2,i, f3,i,...,f23,i} where i ∈ {1,...,n}.”).
In other words, Miettinen teaches transforming a first data set of feature-rich device characteristics of devices with known device identities to a second data set of transformed device characteristics comprising feature-poor device characteristics with the known device identities. Miettinen shows a system that first collects network traffic data that includes IoT device data and then new device features are extracted from the network traffic which creates a subset of features from the network traffic thus the second set of transformed device characteristics. Under the broadest reasonable interpretation, selecting a subset of features is interpreted as taking a larger selection of features, the first data set which has more features thus richer, and reducing the larger selection of features into a smaller subset of features, the second data set which has less features thus poorer. Therefore, applicant’s arguments are not persuasive.
Alleged no teaching of statistical model that trains using weights or evaluation metrics by considering factors between transformed device characteristics to a real-world feature-poor dataset
In Remarks/Arguments pg. 11, applicant contends:
“And, Miettinen similarly does not teach, suggest, or disclose deriving a statistical model that reflects divergence between two datasets, or using distinguishing factors between the datasets to derive evaluation metrics or statistical weights as called for the in claims of the present application. Furthermore, Miettinen does not teach applying statistical adjustments during model training that are specifically derived from comparing transformed device characteristics to a real-world feature-poor dataset”
The relevant claim limitations appear to be: wherein deriving the statistical model comprises comparing the second data set of transformed device characteristics to the third data set of feature-poor device characteristics to identify distinguishing factors and to derive evaluation metrics or weights to account for those distinguishing factors…wherein the device identification model comprises a feature-poor environment model trained using the second data set of transformed device characteristics together with the derived statistical adjustments, in claim 1. As noted in the previous Office Action, Miettinen teaches:
(Miettinen, pg. 2178 col. 2, “Based on device fingerprints provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type. Ground truth information for training the models can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
In other words, Miettinen teaches a statistical model that compares the second data set of transformed device characteristics to the third data set of feature-poor device characteristics to identify distinguishing factors and to derive evaluation metrics or weights to account for those distinguishing factors and then training a model with the metrics and weights. Miettinen shows that a machine learning classification process is used to create classifiers for IoT devices using device fingerprints and ground truth information. The device fingerprints are interpreted as the second data set of transformed device characteristics as the device fingerprints are the input data that the classifiers are trying to identify. The ground truth information is interpreted as the third data set of feature-poor characteristics as this is the labeled information of the IoT devices that the classifiers are trained to identify. The device classifiers are interpreted as the statistical models that have evaluation metrics or weights derived from comparing the second and third datasets. One of ordinary skill of the art would know that classification learning is derived from comparing the input data to the labeled ground truth data to determine whether the model data correctly identifies the input data and adjusting weights based on the result of the comparison. Therefore, applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 112: Indefiniteness
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-6 and 15-16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 4, the claim recites the limitation further comprising training a second device identification model. The claim is indefinite as it is unclear whether the “a second device identification model” is the same second device identification model in claim 1 or this is an additional device identification model. For the purposes of examination, the “a second device identification model” is interpreted as the second device identification model in claim 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 4 also recites the limitation the trained second device identification module. There is insufficient antecedent basis for this limitation in the claim because the term “the trained second device identification module” lacks antecedent basis. For purposes of examination, the “the trained second device identification module” is interpreted as being the second device identification module in claim 1.
Regarding claims 5-6, they are rejected for at least their dependence to claim 4.
Regarding claim 15, the claim recites the limitation to train a second device identification model. The claim is indefinite as it is unclear whether the “a second device identification model” is the same second device identification model in claim 13 or this is an additional device identification model. For the purposes of examination, the “a second device identification model” is interpreted as the second device identification model in claim 13. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 also recites the limitation the trained second device identification module. There is insufficient antecedent basis for this limitation in the claim because the term “the trained second device identification module” lacks antecedent basis. For purposes of examination, the “the trained second device identification module” is interpreted as being the second device identification module in claim 13.
Regarding claim 16, the claim is rejected for at least its dependence to claim 15.
Claim Rejections - 35 USC § 103
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-7, 9, 11-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miettinen, et al., Non-Patent Literature “IoT SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT” (“Miettinen”) in view of Brownlee, et al., Non-Patent Literature “A Gentle Introduction to Cross-Entropy for Machine Learning” (“Brownlee”) and further in view of Du, et al., US Patent Publication 11115799B1 (“Du”).
Regarding claim 1, Miettinen discloses:
A method of identifying network devices, comprising: transforming, by a processor executing program instructions, a first data set of feature-rich device characteristics of devices with known device identities to a second data set of transformed device characteristics comprising feature-poor device characteristics with the known device identities; (Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic. It leverages the specificity of smart home devices that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure [transforming…a first data set of feature-rich device characteristics of devices with known device identities]…When a new device identified by a newly observed MAC address starts communicating with the gateway, the latter records n packets {p1, p2, p3,...,pn} received from it during its setup phase. The end of the setup phase can be automatically identified by a decrease in the rate of packets sent. We extract 23 features; extracting features is interpreted as creating a second dataset of feature-poor characteristics as the extracted features is a subset of the original feature-rich characteristics (i.e. to a second data set of transformed device characteristics comprising feature-poor device characteristics with the known device identities;), giving a vector representation for each packet pi = {f1,i, f2,i, f3,i,...,f23,i} where i ∈ {1,...,n}.” and Miettinen, pg. 2181 col. 1, “implemented with a Linux Laptop running Kali Linux [by a processor executing program instructions,].”).
collecting, by monitoring and querying local network devices, a third data set of feature-poor device characteristics of devices with known identities; (Miettinen, pg. 2178 col. 2, “Based on device fingerprints provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type. Ground truth information for training the models can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service; crowdsourced ground truth data for IoT devices is interpreted as collecting a third dataset of feature-poor characteristics (i.e. collecting, by monitoring and querying local network devices, a third data set of feature-poor device characteristics of devices with known identities;).”).
deriving a statistical model comprising one or more adjustments to the second set of transformed device characteristics, the statistical model reflecting a difference…between one or more characteristics of the second data set of transformed device characteristics and one or more corresponding and/or related characteristics of the third data set of feature-poor device characteristics, (Miettinen, pg. 2180 col. 1, “First, we train a single classifier for each device-type; making a classifier for each device is interpreted as a statistical model adjusting to the transformed data set of device info (i.e. deriving a statistical model comprising one or more adjustments to the second set of transformed device characteristics,). Each classifier provides a binary decision whether the input fingerprint matches the device-type or not. An unknown fingerprint can be accepted by several classifiers and thus match several device-types…The device classification is operated using the fixed length fingerprints F. Let’s assume we have a set of fingerprints S for several device-types. We select the subset of n fingerprints SDi = {F 1,i, F 2,i,..., F n,i} for the device-type Di. The remaining fingerprints of the set are for device-types Dx [not equal] Di. These fingerprints belong to the complement of SDi in S: Sc Di. A classifier Ci is trained for identifying the device-type Di; using a classifier to determine whether a fingerprint is of a device-type is interpreted as comparing a difference between a second dataset feature to a third dataset feature because the device-type, or ground truth data is interpreted as the third dataset (i.e. the statistical model reflecting a difference…between one or more characteristics of the second data set of transformed device characteristics and one or more corresponding and/or related characteristics of the third data set of feature-poor device characteristics,)”).
wherein deriving the statistical model comprises comparing the second data set of transformed device characteristics to the third data set of feature-poor device characteristics to identify distinguishing factors and to derive evaluation metrics or weights to account for those distinguishing factors, (Miettinen, pg. 2178 col. 2, “Based on device fingerprints [wherein deriving the statistical model comprises comparing the second data set of transformed device characteristics] provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type. Ground truth information [to the third data set of feature-poor device characteristics] for training the models; training a classification model is interpreted as using evaluation metrics or weights to update the model to account for distinguishing factors between the input data and the ground truth data (i.e. to identify distinguishing factors and to derive evaluation metrics or weights to account for those distinguishing factors,) can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
wherein the statistical model comprises evaluation metrics or weights derived to account for distinguishing factors between the transformed data set and the third data set; (Miettinen, pg. 2178 col. 2, “Based on device fingerprints [between the transformed data set] provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type. Ground truth information [and the third data set;] for training the models; training a model is interpreted as using evaluation metrics to update the model to account for distinguishing factors (i.e. wherein the statistical model comprises evaluation metrics or weights derived to account for distinguishing factors) can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
and training a device identification model based on the second data set of transformed device characteristics and the statistical model adjustments, (Miettinen, pg. 2178 col. 2, “Based on device fingerprints [based on the second data set of transformed device characteristics] provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type [and training a device identification model based]. Ground truth information for training the models [and the statistical model adjustments,] can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
wherein the device identification model comprises a feature-poor environment model trained using the second data set of transformed device characteristics together with the derived statistical adjustments, (Miettinen, pg. 2178 col. 2, “Based on device fingerprints [using the second data set of transformed device characteristics] provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type [wherein the device identification model comprises a feature-poor environment model]. Ground truth information for training the models; training a classification model is interpreted as using evaluation metrics or weights to update the model to account for distinguishing factors between the input data and the ground truth data (i.e. trained using the second data set of transformed device characteristics together with the derived statistical adjustments,) can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
and wherein training the feature-poor environment model comprises applying the evaluation metrics or weights as statistical adjustments to the transformed second data set during model training, (Miettinen, pg. 2178 col. 2, “Based on device fingerprints provided by Security Gateways, the IoTSSP uses machine learning-based classification models to classify devices according to their device-type [the feature-poor environment model]. Ground truth information for training the models; training a classification model is interpreted as using evaluation metrics or weights to update the model to account for distinguishing factors between the input data and the ground truth data (i.e. and wherein training the feature-poor environment model comprises applying the evaluation metrics or weights as statistical adjustments to the transformed second data set during model training,) can be gathered by crowdsourcing device fingerprints from customers of the IoT Security Service.”).
wherein the trained device identification model comprising the feature-poor environment model is operable to use feature-poor device characteristics to simultaneously identify multiple types of network devices from monitored traffic in real time. (Miettinen, pg. 2180 col. 1, “In order to be scalable and applicable for an evolving number of device-types, we propose a two-fold identification technique [wherein the trained device identification model comprising the feature-poor environment model is operable]. First, we train a single classifier for each device-type [to simultaneously identify multiple types of network devices from monitored traffic in real time.]. Each classifier provides a binary decision whether the input fingerprint [to use feature-poor device characteristics] matches the device-type or not.”).
While Miettinen teaches the classifying devices from feature poor environments, Miettinen does not explicitly teach:
difference in statistical distribution
and wherein a second device identification model is trained using the second data set of transformed device characteristics without the statistical adjustments for deployment in feature-rich environments,
Brownlee teaches difference in statistical distribution (Brownlee, pg. 7, “Each example has a known class label with a probability of 1.0, and a probability of 0.0 for all other labels. A model can estimate the probability of an example belonging to each class label. Cross-entropy can then be used to calculate the difference between the two probability distributions [Difference in statistical distribution].”).
Miettinen and Brownlee are both in the same field of endeavor (i.e. classification). It would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen and Brownlee to teach the above limitation(s). The motivation for doing so that training a classifier with cross-entropy loss improves training times (cf. Brownlee, pg. 7, “using the cross-entropy error function instead of the sum-of-squares for a classification problem leads to faster training as well as improved generalization.”).
While Miettinen in view of Brownlee teaches the classifying devices from feature poor environments, the combination does not explicitly teach:
and wherein a second device identification model is trained using the second data set of transformed device characteristics without the statistical adjustments for deployment in feature-rich environments,
Du teaches:
and wherein a second device identification model is trained using the second data set of transformed device characteristics without the statistical adjustments (Du, col 18 lines 22-46, “In pipeline 504, a fast path feature engineering is performed (508) to identify applicable static and sequence features of the device. A fast path prediction is performed (510) using pattern IDs or previously built models; using pre-trained models is interpreted as training a second model without statistical model adjustments (i.e. and wherein a second device identification model is trained using the second data set of transformed device characteristics without the statistical adjustments) (e.g., models based on top important features and built using offline processing pipeline 506). A confidence score for the device matching a particular pattern is determined (512). If the confidence score for a device meets a pre-trained threshold (e.g., based on the overall prediction accuracy of module 138 or components thereof, such as 0.9), a classification can be assigned to the device (in device database 516) or updated as applicable.
for deployment in feature-rich environments, (Du, col. 9 lines 28-42, “In various embodiments, data appliance 102 includes an IoT server 134. IoT server 134 is configured to identify IoT devices within a network (e.g., network 110), in some embodiments, in cooperation with IoT module 138 of security platform 140. Such identification can be used, e.g., by data appliance 102; using the security platform inside the data appliance is interpreted as deploying the second device identification model to a feature-rich environment as a data appliance has a firewall (i.e. for deployment in feature-rich environments,), to help make and enforce policies regarding traffic associated with IoT devices, and to enhance the functionality of other elements of network 110 (e.g., providing contextual information to AAA 156). In various embodiments, IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic. One example way to provide such network sensor functionality is as a tap interface or switch mirror port. Other approaches to monitoring traffic can also be used (in addition or instead) as applicable.”).
Miettinen, in view of Brownlee, and Du are both in the same field of endeavor (i.e. network device identification). It would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen, in view of Brownlee, and Du to teach the above limitation(s). The motivation for doing so is that using pre-trained models for classification improves training efficiency (cf. Du, col. 18 lines 34-38, “An advantage of this approach is that data appliance 102 can begin applying policies to the device's traffic very quickly (e.g., within a few minutes of module 138 identifying the device as new/unclassified).”).
Additionally, it would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen, Brownlee, and Du to teach the above limitation(s). The motivation for doing so is that applying an identification model to a data appliance improves traffic policy decisions (cf. Du, col. 9 lines 32-36, “Such identification can be used, e.g., by data appliance 102, to help make and enforce policies regarding traffic associated with IoT devices, and to enhance the functionality of other elements of network 110 (e.g., providing contextual information to AAA 156).”).
Regarding claim 2, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1. Miettinen further teaches further comprising deploying the trained device identification model to a feature-poor environment (Miettinen, pg. 2177 col. 2, “We introduce a device-type identification technique tailored for IP-enabled IoT devices [further comprising deploying the trained device identification model to a feature-poor environment] (Sect. III). Device-type identification, in conjunction with information from vulnerability databases can pinpoint vulnerable devices in a network.”).
Regarding claim 3, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 2. Miettinen further teaches wherein the feature-rich environment comprises an end user computing device. (Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic [wherein the feature-rich environment]. It leverages the specificity of smart home devices [comprises an end user computing device.] that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure.”).
Regarding claim 4, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1.
Du further teaches further comprising training a second device identification model based on the second data set of transformed device characteristics without the statistical model adjustments, the trained second device identification module operable to use feature-poor device characteristics to identify network devices. (Du, col 18 lines 22-46, “In pipeline 504, a fast path feature engineering is performed (508) to identify applicable static and sequence features of the device. A fast path prediction is performed (510) using pattern IDs or previously built models; using pre-trained models is interpreted as training a second model without statistical model adjustments (i.e. further comprising training a second device identification model based on the second data set of transformed device characteristics without the statistical model adjustments,) (e.g., models based on top important features and built using offline processing pipeline 506). A confidence score for the device matching a particular pattern is determined (512). If the confidence score for a device meets a pre-trained threshold (e.g., based on the overall prediction accuracy of module 138 or components thereof, such as 0.9), a classification can be assigned to the device (in device database 516) or updated as applicable; identifying IoT devices using feature engineering from IoT device features is interpreted as using feature-poor characteristics as feature engineering reduces the amount of data used (i.e. the trained second device identification module operable to use feature-poor device characteristics to identify network devices.). Initially, the confidence score will be based on the near-real time fast path processing. An advantage of this approach is that data appliance 102 can begin applying policies to the device's traffic very quickly (e.g., within a few minutes of module 138 identifying the device as new/unclassified). Appliance 102 can be configured to fail-safe (e.g., reduce/restrict the device's ability to access various network resources) or fail-danger (e.g., allow the device broad access) pending a classification verdict from system 140. As additional information becomes available (e.g., via the slow path processing), the confidence score can be based on that additional information, as applicable (e.g., increasing the confidence score or revising/correcting mistakes made during fast path classification).”).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Du with the teachings of Miettinen and Brownlee for the same reasons disclosed in claim 1.
Regarding claim 5, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 4. Du further teaches further comprising deploying the trained second device identification model to a feature-rich environment (Du, col. 9 lines 28-42, “In various embodiments, data appliance 102 includes an IoT server 134. IoT server 134 is configured to identify IoT devices within a network (e.g., network 110), in some embodiments, in cooperation with IoT module 138 of security platform 140. Such identification can be used, e.g., by data appliance 102; using the security platform inside the data appliance is interpreted as deploying the second device identification model to a feature-rich environment as a data appliance has a firewall (i.e. further comprising deploying the trained second device identification model to a feature-rich environment), to help make and enforce policies regarding traffic associated with IoT devices, and to enhance the functionality of other elements of network 110 (e.g., providing contextual information to AAA 156). In various embodiments, IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic. One example way to provide such network sensor functionality is as a tap interface or switch mirror port. Other approaches to monitoring traffic can also be used (in addition or instead) as applicable.”).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Du with the teachings of Miettinen and Brownlee for the same reasons disclosed in claim 1.
Regarding claim 6, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 5. Du further teaches wherein the feature-rich environment comprises a router, a gateway, or a network security device. (Du, col. 7 lines 28-34, “As shown, data appliance 102 comprises a firewall [wherein the feature-rich environment comprises a router, a gateway, or a network security device.], and includes a management plane 212 and a data plane 214. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.”).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the present application to combine the teachings of Du with the teachings of Miettinen and Brownlee for the same reasons disclosed in claim 5.
Regarding claim 7, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1. Du further teaches further comprising collecting the first data set of feature-rich device characteristics from at least one router, gateway, or network security device. (Du, col. 6 lines 16-25, “In various embodiments, data appliance 102 stores (whether in RAM 204, storage 210, and/or other appropriate locations) information used in monitoring enterprise network 110 and implementing disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname/URL categorization information, malware profiles, machine learning models, IoT device classification information, etc.” [further comprising collecting the first data set of feature-rich device characteristics from at least one router, gateway, or network security device.]).
Miettinen, in view of Brownlee, and Du are both in the same field of endeavor (i.e. network device identification). It would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen, in view of Brownlee, and Du to teach the above limitation(s). The motivation for doing so is that collecting network information improves setting up network security policies (cf. Du, col. 4 lines 31-39, “Examples of such policies include ones governing traffic shaping, quality of service, and routing of traffic. Other examples of policies include security policies such as ones requiring the scanning for threats in incoming (and/or outgoing) email attachments, web site content, files exchanged through instant messaging programs, and/or other file transfers. In some embodiments, data appliance 102 is also configured to enforce policies with respect to traffic that stays within enterprise network 110.”).
Regarding claim 9, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1. Miettinen further teaches wherein transforming the first data set of feature-rich device characteristics to the second data set of transformed device characteristics comprises reducing the feature-rich data set to produce the second set of transformed device characteristics. (Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic. It leverages the specificity of smart home devices that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure [wherein transforming the first data set of feature-rich device characteristics]…When a new device identified by a newly observed MAC address starts communicating with the gateway, the latter records n packets {p1, p2, p3,...,pn} received from it during its setup phase. The end of the setup phase can be automatically identified by a decrease in the rate of packets sent. We extract 23 features; extracting features is interpreted as creating a second dataset of feature-poor characteristics as the extracted features is a subset of the original feature-rich characteristics (i.e. to the second data set of transformed device characteristics comprises reducing the feature-rich data set to produce the second set of transformed device characteristics.), giving a vector representation for each packet pi = {f1,i, f2,i, f3,i,...,f23,i} where i ∈ {1,...,n}.”).
Regarding claim 11, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1. Miettinen further teaches wherein at least one of the feature-rich or feature-poor characteristics comprise network protocols, network services, open ports, traffic types, network traffic, and network packet content. (Miettinen, pg. 2179, see Table 1 below,
PNG
media_image1.png
333
591
media_image1.png
Greyscale
[wherein at least one of the feature-rich or feature-poor characteristics comprise network protocols, network services, open ports, traffic types, network traffic, and network packet content.]).
Regarding claim 12, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1. Miettinen further teaches wherein the feature-poor characteristics comprise at least partially a subset of the feature-rich characteristics. (Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic. It leverages the specificity of smart home devices that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure [feature-rich characteristics]…When a new device identified by a newly observed MAC address starts communicating with the gateway, the latter records n packets {p1, p2, p3,...,pn} received from it during its setup phase. The end of the setup phase can be automatically identified by a decrease in the rate of packets sent. We extract 23 features; extracting features is interpreted as reducing a feature-rich dataset into an feature-poor dataset because the extracted features is a subset of the original feature-rich characteristics (i.e. wherein the feature-poor characteristics comprise at least partially a subset of the feature-rich characteristics.), giving a vector representation for each packet pi = {f1,i, f2,i, f3,i,...,f23,i} where i ∈ {1,...,n}.”).
Regarding claim 13, the claim is similar to claim 1. Miettinen further teaches the additional limitations comprising: a processor and a memory, a nonvolatile storage operable to store program instructions executable on the processor when loaded into memory; and machine-readable instructions stored on the nonvolatile memory, (Miettinen, pg. 2181 col. 1, “implemented with a Linux Laptop running Kali Linux [comprising: a processor and a memory, a nonvolatile storage operable to store program instructions executable on the processor when loaded into memory; and machine-readable instructions stored on the nonvolatile memory,].”).
Regarding claim 14, Miettinen in view of Brownlee Du teaches the computerized network device of claim 13. Miettinen further teaches the machine-readable instructions when executed further operable to identify one or more network devices using the trained device identification model. (Miettinen, pg. 2179 col. 1, “In this section we introduce fingerprints specifically designed to discriminate smart home device-types. A two-fold classification system fed with these fingerprints determines the type of unknown devices. The system is tailored for IoT scenarios being able to scale and adapt with minimal cost to a large and variable set of device-types [the machine-readable instructions when executed further operable to identify one or more network devices using the trained device identification model.].”).
Regarding claims 15 and 16, they are similar to claims 4 and 5 and thus rejected under the same rationales.
Regarding claim 17, Miettinen in view of Brownlee Du teaches the computerized network device of claim 13. Miettinen further teaches the machine-readable instructions when executed further operable to collect the first data set of feature-rich device characteristics. (Miettinen, pg. 2179 col. 1, “Our fingerprint is based on passively observed network traffic. It leverages the specificity of smart home devices that need to be inducted into the home network and associated to the gateway by following a device/vendor specific procedure [the machine-readable instructions when executed further operable to collect the first data set of feature-rich device characteristics.].”).
Regarding claims 18 and 20, they are similar to claims 9 and 11 and thus rejected under the same rationales.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Miettinen, et al., Non-Patent Literature “IoT SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT” (“Miettinen”) in view of Brownlee, et al., Non-Patent Literature “A Gentle Introduction to Cross-Entropy for Machine Learning” (“Brownlee”) and further in view of Du, et al., US Patent Publication 11115799B1 (“Du”) and Meidan, et al., Non-Patent Literature “Detection of Unauthorized IoT Devices Using Machine Learning Techniques” (“Meidan”).
Regarding claim 8, Miettinen in view of Brownlee Du teaches the method of identifying network devices of claim 1. However, the combination does not explicitly teach wherein the devices with known identities comprise devices that have been classified by an expert or have been classified by expert-derived rules or classifications.
Meidan teaches wherein the devices with known identities comprise devices that have been classified by an expert or have been classified by expert-derived rules or classifications. (Meidan, pg. 3 col. 2, “Given a set of authorized device types D (i.e., the white list) and a structured set of traffic data, we treat the task of IoT device type identification as a multi-class classification problem. That is, we wish to map each IP stream to the type of IoT device that is most likely to have produced it. We rely on the assumption that every device type di on the white list D is sufficiently represented in the (labeled) dataset; a white list is interpreted as expert labeled data (i.e. wherein the devices with known identities comprise devices that have been classified by an expert or have been classified by expert-derived rules or classifications.). This way, a classifier C can be induced by means of supervised ML, which captures the behavior of every authorized device type. In turn, this classifier can be continuously applied to new streams of (unlabeled) traffic data for device type identification and white listing.”).
Miettinen, in view of Brownlee and Du, and Meidan are both in the same field of endeavor (i.e. network device identification). It would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen, in view of Brownlee and Du, and Meidan to teach the above limitation(s). The motivation for doing so is that white listing labels enables stronger security posture (cf. Meidan, pg. 2 col. 2, “Once deployed, an automated IoT device type white listing system can feed a SIEM (security information and event management) system. Subsequently, (near) real-time network segmentation and access control can be implemented, e.g., by using software defined networks (SDN).”).
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Miettinen, et al., Non-Patent Literature “IoT SENTINEL: Automated Device-Type Identification for Security Enforcement in IoT” (“Miettinen”) in view of Brownlee, et al., Non-Patent Literature “A Gentle Introduction to Cross-Entropy for Machine Learning” (“Brownlee”) and further in view of Du, et al., US Patent Publication 11115799B1 (“Du”) and Luger, et al., US Pre-Grant Publication 2019/0349407A1 (“Luger”).
Regarding claim 10 and analogous claim 19, Miettinen in view of Brownlee and Du teaches the method of identifying network devices of claim 1…wherein the first data set of feature-rich device characteristics…and the third data set comprising feature-poor device characteristics as seen in claim 1. Du further teaches wherein the first data set of feature-rich device characteristics comprises a data set associated with at least one network security appliance, (Du, col. 6 lines 16-25, “In various embodiments, data appliance 102 stores (whether in RAM 204, storage 210, and/or other appropriate locations) information used in monitoring enterprise network 110 and implementing disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname/URL categorization information, malware profiles, machine learning models, IoT device classification information, etc.”; monitoring network traffic by collecting the above data is interpreted as being associated with a network security appliance (i.e. wherein the first data set of feature-rich device characteristics comprises a data set associated with at least one network security appliance,)).
Miettinen, in view of Brownlee, and Du are both in the same field of endeavor (i.e. network device identification). It would have been obvious for a person having ordinary skill in the art before the effective filing date of the claimed invention to combine Miettinen, in view of Brownlee, and Du to teach the above limitation(s). The motivation for doing so is that collecting network security information improves setting up network security policies (cf. Du, col. 4 lines 31-39, “Examples of such policies include ones governing traffic shaping, quality of service, and routing of traffic. Other examples of policies include security policies such as ones requiring the scanning for threats in incoming (and/or outgoing) email attachments, web site content, files exchanged through instant messaging programs, and/or other file transfers. In some embodiments, data appliance 102 is also configured to enforce policies with respect to traffic that stays within enterprise network 110.”).
However, Miettinen in view of Brownlee and Du does not explicitly teach the third data set comprising feature-poor device characteristics comprises a data set associated with a device antimalware application.
Luger teaches the third data set comprising feature-poor device characteristics comprises a data set associated with a device antimalware application. (Luger, ⁋244, “In an embodiment, an endpoint device 1802 broadly represents any type of computing device from which forensic data can be collected including, for example, a desktop computer, workstation, laptop computer, tablet computer, mobile device, and so forth. In other examples, an endpoint device 1802 may also include other types of computing devices, such as network devices (e.g., routers, switches, a network tap, etc.), various types of servers (e.g., web servers, file servers, email servers), or various types of security devices and applications (e.g., devices or applications providing firewall services, user identity management services, antimalware [comprises a data set associated with a device antimalware application.] and antivirus application services, etc.).”).
A person having ordinary skill in the art would reasonably find the teachings of Luger to solve the problem of collecting data from an antimalware application present in Miettinen, in view of Brownlee and Du. In view of the teachings of Luger it would have been obvious for a person of ordinary skill in the art to apply the teachings of Luger to Miettinen, in view of Brownlee and Du, before the effective filing date of the claimed invention in order to identify potential malware indicators to improve endpoint device security of the network (cf. Luger, ⁋248, “the analyst may use a network security application to create a data collection package identifying particular file system information, file name information, process information, etc., which may be useful in diagnosing the presence of a potential malware infections.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Konda, et al., US20240283674 discloses detecting a device that deceptively misidentifies itself on a home network by using device identification classification data.
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 NICHOLAS S WU whose telephone number is (571)270-0939. The examiner can normally be reached Monday - Friday 8:00 am - 4:00 pm EST.
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, Michelle Bechtold can be reached on 571-431-0762. 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.
/N.S.W./Examiner, Art Unit 2148 /MICHELLE T BECHTOLD/Supervisory Patent Examiner, Art Unit 2148