DETAILED ACTION
This action is in response to the amendment filed on November 17, 2025. Claims 1 and 5-6 have been amended. Claims 1-6 are pending. Of such, claims 1-4 represent a device, claim 5 represents a method, and claim 6 represents a non-transitory computer readable medium directed to device identification using traffic patterns.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
The objections to the claims have been withdrawn in view of the amendments made to the Claim 1.
Claim Rejections - 35 USC § 112
The rejections to the claims have been withdrawn in view of the amendments made to the Claims 1 and 5-6.
Response to Arguments
Applicant's arguments filed November 17, 2025 have been fully considered but they are not persuasive.
On page 9 of the Remarks, the applicant is arguing that Claim 1 recites a flow similarity module that compares flow values for the unknown device to labeled devices. While the prior art (Mermoud) is merely filling in missing values of one device with references of other devices and there is no comparison of values nor a difference matrix derived from the comparison of values.
This argument is not persuasive.
Mermoud discloses in ¶ 81 a device may compare traffic telemetry data of devices from two networks. Specifically disclosing “In some embodiments, the device may perform the comparison by forming a matrix of traffic characteristics and their corresponding endpoints.” Mermoud directly teaches a comparison is performed on traffic data and based on the comparison of the telemetry data (claimed flow data) a matrix is formed. Further, In ¶ 82, Mermoud discloses the use of the comparison data to identify a networking entity in a particular network.
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-6 are rejected under 35 U.S.C. 103 as being unpatentable by Tian et al. (US 20230231860), hereinafter referred to as Tian, in view of Mermoud et al. (US 20200145288), hereinafter referred to as Mermoud.
Regarding Claim 1, Tian discloses:
An IoT identification server to identify Internet of Things (IoT) devices using traffic, the IoT identification server comprising: a processor; a network interface communicatively coupled to a data communication network and to an enterprise network (In ¶ 58, Tian disclose “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, 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).”); and a memory, communicatively coupled to the processor and storing: a flow monitoring module to collects flow data concerning IoT devices on the data communication network (In ¶ 58, Tian discloses “IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic.”) and construct individual flows of individual devices from the flow data of source and destination IP addresses and ports (In ¶ 59 Tian discloses “IoT server 134 sends device discovery events and session events to IoT module 138.”) and further discloses “Each session that a device has (with other nodes, whether inside or outside the device's network) is described within a session event that summarizes information about the session (e.g., source/destination information, number of packets received/sent, etc.).”); a device similarity module to identify known devices as device candidates from a sum of flow pair values for each candidate device in relation to the unknown device (In ¶ 61 Tian discloses “For each rule, aggregation engine 238 tracks a list of attributes that need to be aggregated (e.g., a list of applications used by a device or a list of destination IP addresses).” and further in ¶ 148 Tian discloses, “During production/operation, events (e.g., as initially provided by data appliance 102 and processed by various components of IoT module 138) will similarly pass through aggregation module 238 and into analytics module 242, which will use the trained models to perform device identification on aggregated events”); and a device identification module to retrieve a device type for each candidate device, and select one of the device types based on at least a closeness or a frequency of each device type to the unknown device (In ¶ 80, Tian discloses “In various embodiments, a pattern ID is a list of attributes or sequence features combined, with their respective probabilities (as importance scores for a feature or behavior category), that forms a distinct network behavior description and can be used to identify the type of an IoT device. The pattern IDs can be stored (e.g., in a database) and used to identify/verify the identity of devices.” And in ¶ 92, Tian further discloses “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.”).
However, Tian does not explicitly disclose the use of matrices when generating the individual flows.
Mermoud discloses:
a flow similarity module to identify flow pair values from flow pairs of labeled devices as candidates by comparing individual flows of the unknown device that surpass a candidate threshold by generating a difference flow matrix from the individual flows of the unknown device and the labeled devices (In ¶ 81, Mermoud discloses “At step 715, as detailed above, the device may compare the traffic telemetry data from a particular one of the networks to the traffic telemetry data from the other networks….. In some embodiments, the device may perform the comparison by forming a matrix of traffic characteristics and their corresponding endpoints.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tian’s approach to utilize Mermoud’s approach of using matrices when analyzing the flow data as the motivation would be to allow for better classification of endpoints by having the ability to add missing entries to a matrix based on similar devices identified through the matrix comparison using machine learning and pattern analysis. (See Mermoud, ¶ 87).
Regarding Claim 2, the combination of Tian and Mermoud disclose:
The IoT identification server of claim 1, wherein the similarly module calculates flow similarity between 0 and 1. (In ¶ 92, Tian further discloses “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.”).
Regarding Claim 3, the combination of Tian and Mermoud disclose:
The IoT identification server of claim 1, wherein the similarity module weighs each flow. (In ¶ 167, Tian discloses “In both inline and offline device classification, device dataset and other traffic are used to train a model (e.g., using logistic regression) and generate a set of coefficients for each device. The set of coefficients for each device can be used as a device behavior signature. The set of coefficients can then be fed into a model to use in device identification.”)
Regarding Claim 4, the combination of Tian and Mermoud disclose:
The IoT identification server of claim 1, wherein the device identification module selects the device types using K-Nearest Neighbors (KNN). (In ¶ 153, Tian discloses “Other types of classifiers can also be used in accordance with techniques described herein (including by using the features described herein), such as a Gaussian naïve Bayes, K nearest neighbor, decision tree, random forest, and/or vector machine.”)
Regarding Claim 5, Tian discloses:
A method in a networking device for identifying Internet of Things (IoT) devices using traffic patterns (In ¶ 58, Tian disclose “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, 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).”), the method comprising the steps of: monitoring flows of network traffic for a specific IoT device network (In ¶ 58, Tian discloses “IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic.”), a network traffic flow comprising a set of data packets with a common source IP, source media access control (MAC), destination IP and destination port (In ¶ 59 Tian discloses “IoT server 134 sends device discovery events and session events to IoT module 138.”) and further discloses “Each session that a device has (with other nodes, whether inside or outside the device's network) is described within a session event that summarizes information about the session (e.g., source/destination information, number of packets received/sent, etc.).”); finding a device similarity as a sum of the flow similarity over shared IP/ports (In ¶ 61 Tian discloses “For each rule, aggregation engine 238 tracks a list of attributes that need to be aggregated (e.g., a list of applications used by a device or a list of destination IP addresses).” and further in ¶ 148 Tian discloses, “During production/operation, events (e.g., as initially provided by data appliance 102 and processed by various components of IoT module 138) will similarly pass through aggregation module 238 and into analytics module 242, which will use the trained models to perform device identification on aggregated events”); and identifying the specific IoT device from the flow similarity and the device similarity using K-Nearest Neighbors (KNN) (In ¶ 80, Tian discloses “In various embodiments, a pattern ID is a list of attributes or sequence features combined, with their respective probabilities (as importance scores for a feature or behavior category), that forms a distinct network behavior description and can be used to identify the type of an IoT device. The pattern IDs can be stored (e.g., in a database) and used to identify/verify the identity of devices.” And in ¶ 92, Tian further discloses “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.” And in ¶ 153, Tian further discloses “Other types of classifiers can also be used in accordance with techniques described herein (including by using the features described herein), such as a Gaussian naïve Bayes, K nearest neighbor, decision tree, random forest, and/or vector machine.), wherein the identification includes device type (In ¶ 81, Tian discloses “The pattern ID can be used to uniquely identify a device type once established.”), device vendor (In ¶ 120, Tian discloses “In various embodiments, various printers from various vendors are included into a group, and a “printer” model is trained for group classification.”), and device model (In ¶ 73, Tian discloses “IoT module 138 can take a variety of actions such as creating a record for whiteboard 146 in database 160 and populating that record with contextual information about whiteboard 146 (e.g., determining its manufacturer, model number, etc.).”); and applying network policies to network traffic of new IOT device based on device type (In ¶ 58, Tian discloses “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).”).
However, Tian does not explicitly disclose the use of matrices when generating the individual flows.
Mermoud discloses:
finding a flow similarity by analyzing patterns of network traffic flows, based on matrices representative of the network traffic flows (In ¶ 81, Mermoud discloses “At step 715, as detailed above, the device may compare the traffic telemetry data from a particular one of the networks to the traffic telemetry data from the other networks….. In some embodiments, the device may perform the comparison by forming a matrix of traffic characteristics and their corresponding endpoints.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tian’s approach to utilize Mermoud’s approach of using matrices when analyzing the flow data as the motivation would be to allow for better classification of endpoints by having the ability to add missing entries to a matrix based on similar devices identified through the matrix comparison using machine learning and pattern analysis. (See Mermoud, ¶ 87).
Regarding Claim 6, Tian discloses:
A non-transitory computer-readable media storing source code in an IoT identification server, implemented at least partially in hardware that, when executed by a processor, performs a method for identifying Internet of Things (IoT) devices using traffic patterns (In ¶ 58, Tian disclose “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, 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).”), monitoring flows of network traffic for a specific IoT device (In ¶ 58, Tian discloses “IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic.”), a network traffic flow comprising a set of data packets with a common source IP, source Media Access Control (MAC), destination IP and destination port (In ¶ 59 Tian discloses “IoT server 134 sends device discovery events and session events to IoT module 138.”) and further discloses “Each session that a device has (with other nodes, whether inside or outside the device's network) is described within a session event that summarizes information about the session (e.g., source/destination information, number of packets received/sent, etc.).”); finding a device similarity as a sum of the flow similarity over shared IP/ports (In ¶ 61 Tian discloses “For each rule, aggregation engine 238 tracks a list of attributes that need to be aggregated (e.g., a list of applications used by a device or a list of destination IP addresses).” and further in ¶ 148 Tian discloses, “During production/operation, events (e.g., as initially provided by data appliance 102 and processed by various components of IoT module 138) will similarly pass through aggregation module 238 and into analytics module 242, which will use the trained models to perform device identification on aggregated events”); Identifying the specific IoT device from the flow similarity and the device similarity using K-Nearest Neighbors (KNN) (In ¶ 80, Tian discloses “In various embodiments, a pattern ID is a list of attributes or sequence features combined, with their respective probabilities (as importance scores for a feature or behavior category), that forms a distinct network behavior description and can be used to identify the type of an IoT device. The pattern IDs can be stored (e.g., in a database) and used to identify/verify the identity of devices.” And in ¶ 92, Tian further discloses “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.” And in ¶ 153, Tian further discloses “Other types of classifiers can also be used in accordance with techniques described herein (including by using the features described herein), such as a Gaussian naïve Bayes, K nearest neighbor, decision tree, random forest, and/or vector machine.), wherein the identification includes device type (In ¶ 81, Tian discloses “The pattern ID can be used to uniquely identify a device type once established.”), device vendor In ¶ 120, Tian discloses “In various embodiments, various printers from various vendors are included into a group, and a “printer” model is trained for group classification.”) and device model (In ¶ 73, Tian discloses “IoT module 138 can take a variety of actions such as creating a record for whiteboard 146 in database 160 and populating that record with contextual information about whiteboard 146 (e.g., determining its manufacturer, model number, etc.).”); and applying network policies to network traffic of new IoT device based on device type identified (In ¶ 58, Tian discloses “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).”).
However, Tian does not explicitly disclose the use of matrices when generating the individual flows.
Mermoud discloses:
finding a flow similarity by analyzing patterns of network traffic flows, based on matrices representative of the network traffic flows (In ¶ 81, Mermoud discloses “At step 715, as detailed above, the device may compare the traffic telemetry data from a particular one of the networks to the traffic telemetry data from the other networks….. In some embodiments, the device may perform the comparison by forming a matrix of traffic characteristics and their corresponding endpoints.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tian’s approach to utilize Mermoud’s approach of using matrices when analyzing the flow data as the motivation would be to allow for better classification of endpoints by having the ability to add missing entries to a matrix based on similar devices identified through the matrix comparison using machine learning and pattern analysis. (See Mermoud, ¶ 87).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang, Feng (US 20210377215) discloses a method for device classification of Internet of Things (IOT) devices using traffic patterns.
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 SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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, Rupal Dharia can be reached at 571-272-3880. 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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492