DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/11/2026 has been entered. Claims 1-21 remain pending in the application.
Response to Arguments
Applicant’s arguments have been fully considered but are moot because they do not apply to the new combination of references being used in the current rejection, as necessitated by amendment to the claims.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 6, 8, 13, 15 and 20 are rejected under 35 U.S.C. 102(a)(1) & 102(a)(2) as being anticipated by Colegate et al (US 2016/0080944).
Regarding Claim 1, Colegate teaches a computer implemented method for identifying and managing security incidents for IoT devices operating on a cellular network ([0077-0079], [0081], [0084], embodiments are directed toward one or more computer systems capable of carrying out the functionality described herein. The computer system includes one or more processors, such as processor. The processor is connected to a communication infrastructure (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system), the method comprising:
receiving a device hardware identifier from a device operating on a cellular network with a request by the device for data transfer over the cellular network ([0007], a transaction request may be transmitted from/via the mobile device over a mobile network to a trusted certificate authority for verification of a public key associated with the mobile transaction request. The trusted certificate authority may be hosted by the MNO, Registry, Transaction Processor and/or Issuer/Acquirer of the transaction accounts. The device hardware identifier information of the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO. The SIM card hardware identifier information of the SIM card associated with the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO);
in response to receiving the device hardware identifier, retrieving additional device information from the device information storage database ([0006], a unique mobile device hardware identifier of a mobile device may be provided to a registry and/or a registry host. A unique SIM card hardware identifier of a SIM card associated with the mobile device may also be provided to the registry and/or registry host. The registry host may associate a mobile device user identifier with transaction account information of a mobile device user, the unique SIM card hardware identifier of the SIM card of the mobile device, and the mobile device hardware identifier in an electronic registry)
using the received device hardware identifier ([0008], the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. The registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the results are associated with the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device. Similarly, the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. For instance, the registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device and the SIM card hardware identifier information intercepted with the transmitted transaction request message are associated with expected SIM card hardware identifier information stored in the electronic registry associated with the mobile device); and
initiating an action for the device when the retrieved additional device information does not match expected additional device information received from the device with the request ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed),
wherein the expected additional device information is based on the received device hardware identifier ([0011-0012], Aspects of the system may verify that the public key is correct. Aspects of the system may validate the mobile device hardware identifier captured with the transaction request message against expected mobile device hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may validate the SIM card hardware identifier information captured with the transaction request message against expected SIM card hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may verify that the private key data is correct. If multiple factors are correct, transaction account information may be appended to and/or transmitted with the transaction request message. The appended transaction request may be transmitted to a processor for authorization).
Regarding Claim 6, Colegate teaches the computer implemented method of claim 1, wherein the initiating the action for the device comprises at least one of sending an alert to the user interface of an entity managing the device or blocking the device from using the cellular network ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed).
Regarding Claim 8, Colegate teaches a system for identifying and managing security incidents for IoT devices operating on a cellular network ([0081]), the system including a processor and a storage database ([0077-0079], [0084], embodiments are directed toward one or more computer systems capable of carrying out the functionality described herein. The computer system includes one or more processors, such as processor. The processor is connected to a communication infrastructure (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system), wherein the system is configured to:
receive a device hardware identifier from a device operating on a cellular network with a request by the device for data transfer over the cellular network ([0007], a transaction request may be transmitted from/via the mobile device over a mobile network to a trusted certificate authority for verification of a public key associated with the mobile transaction request. The trusted certificate authority may be hosted by the MNO, Registry, Transaction Processor and/or Issuer/Acquirer of the transaction accounts. The device hardware identifier information of the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO. The SIM card hardware identifier information of the SIM card associated with the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO);
in response to receiving the device hardware identifier, retrieve additional device information from the device information storage database ([0006], a unique mobile device hardware identifier of a mobile device may be provided to a registry and/or a registry host. A unique SIM card hardware identifier of a SIM card associated with the mobile device may also be provided to the registry and/or registry host. The registry host may associate a mobile device user identifier with transaction account information of a mobile device user, the unique SIM card hardware identifier of the SIM card of the mobile device, and the mobile device hardware identifier in an electronic registry)
using the received device hardware identifier ([0008], the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. The registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the results are associated with the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device. Similarly, the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. For instance, the registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device and the SIM card hardware identifier information intercepted with the transmitted transaction request message are associated with expected SIM card hardware identifier information stored in the electronic registry associated with the mobile device); and
initiates initiate an action for the device when the retrieved additional device information does not match expected additional device information received from the device with the request ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed),
wherein the expected additional device information is based on the received device hardware identifier ([0011-0012], Aspects of the system may verify that the public key is correct. Aspects of the system may validate the mobile device hardware identifier captured with the transaction request message against expected mobile device hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may validate the SIM card hardware identifier information captured with the transaction request message against expected SIM card hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may verify that the private key data is correct. If multiple factors are correct, transaction account information may be appended to and/or transmitted with the transaction request message. The appended transaction request may be transmitted to a processor for authorization).
Regarding Claim 13, Colegate teaches the system of claim 8, wherein the initiated action for the device comprises at least one of sending an alert to the user interface of an entity managing the device or blocking the device from using the cellular network ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed).
Regarding Claim 15, Colegate teaches a non-transitory computer-readable medium for identifying and managing security incidents for one or more IoT devices operating on a cellular network ([0081]) having executable instructions stored therein that, when executed, cause one or more processors corresponding to a system having a one or more devices operating on a cellular network, a processor, and a storage database ([0077-0079], [0084], embodiments are directed toward one or more computer systems capable of carrying out the functionality described herein. The computer system includes one or more processors, such as processor. The processor is connected to a communication infrastructure (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system) to perform operations comprising:
receiving a device hardware identifier from a device operating on a cellular network with a request by the device for data transfer over the cellular network ([0007], a transaction request may be transmitted from/via the mobile device over a mobile network to a trusted certificate authority for verification of a public key associated with the mobile transaction request. The trusted certificate authority may be hosted by the MNO, Registry, Transaction Processor and/or Issuer/Acquirer of the transaction accounts. The device hardware identifier information of the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO. The SIM card hardware identifier information of the SIM card associated with the mobile device transmitting the mobile transaction request may be captured and/or intercepted by the MNO);
in response to receiving the device hardware identifier, retrieving additional device information from the device information storage database ([0006], a unique mobile device hardware identifier of a mobile device may be provided to a registry and/or a registry host. A unique SIM card hardware identifier of a SIM card associated with the mobile device may also be provided to the registry and/or registry host. The registry host may associate a mobile device user identifier with transaction account information of a mobile device user, the unique SIM card hardware identifier of the SIM card of the mobile device, and the mobile device hardware identifier in an electronic registry)
using the received device hardware identifier ([0008], the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. The registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the results are associated with the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device. Similarly, the intercepted device hardware identifier information and the SIM card hardware identifier may be provided to the registry host for verification. For instance, the registry host may associate the mobile device hardware identifier information intercepted with the transmitted transaction request message and determine if the expected mobile device hardware identifier information stored in the electronic registry associated with the mobile device and the SIM card hardware identifier information intercepted with the transmitted transaction request message are associated with expected SIM card hardware identifier information stored in the electronic registry associated with the mobile device); and
initiating an action for the device when the retrieved additional device information does not match expected additional device information received from the device with the request ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed),
wherein the expected additional device information is based on the received device hardware identifier ([0011-0012], Aspects of the system may verify that the public key is correct. Aspects of the system may validate the mobile device hardware identifier captured with the transaction request message against expected mobile device hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may validate the SIM card hardware identifier information captured with the transaction request message against expected SIM card hardware identifier information stored in the electronic registry and associated with the received public key. Aspects of the system may verify that the private key data is correct. If multiple factors are correct, transaction account information may be appended to and/or transmitted with the transaction request message. The appended transaction request may be transmitted to a processor for authorization).
Regarding Claim 20, Colegate teaches the non-transitory computer-readable medium of claim 15, wherein the initiating the action for the device comprises at least one of sending an alert to the user interface of an entity managing the device or blocking the device from using the cellular network ([0050], In response to the details being incorrect, the MNVO 250 and/or trusted certificate authority 230 may halt transaction and communicate a message to be stored, indicating that the public key 175 was correct but other expected details are wrong. For instance, an message indicating that an incorrect SIM card 260 was used or a SIM card 260 that is not expected for use with this device or with these other details was used. For instance, if a SIM card 260 was swapped into a different device and not updated/registered in the registry 220 the transaction would not be able to proceed).
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 2-5, 7, 9-12, 14, 16-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Colegate et al (US 2016/0080944), in view of De Knijf et al (US 2018/0191746).
Regarding Claim 2, Colegate teaches all aspects of the invention according to Claim 1 above, except the following, which in the same field of endeavor, De Knijf teaches analyzing the received device hardware identifier for the device to determine a device information feature; and using the determined device information feature to retrieve additional device information from the device information storage database ([0037-0038], At block 206, behavior analyzer 124 receives the network device statistics 108 and can store the network device statistics 108 in central database 126. As noted above, the network device statistics 108 can be received from multiple local networks 102. At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group. In some aspects, data stream monitor 106 can calculate a score that reflects how likely it is that the current behavior of an IoT device is in accordance with the normal behavior of its particular group or subgroup. In particular aspects, this score can be calculated by using a statistical test of the current observed data and the statistical normal behavior patterns derived for the different groups or subgroups of the device).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 3, Colegate, modified by De Knijf, teaches the invention of Claim 2, De Knijf further comprising wherein the device information feature include device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 4, Colegate teaches all aspects of the invention according to Claim 1 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the additional device for the device comprises at least one of: device type, device manufacturer, device functionality, subscription identifier for that device, or a combination thereof ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 5, Colegate teaches all aspects of the invention according to Claim 1 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the expected additional device information comprises an expected device type, the expected device type comprising at least one of: an IoT device, a tablet or a phone ([0036-0038], IoT devices and devices of any other kind on the network including media players, smart devices, gaming consoles, IP cameras, etc.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 7, Colegate, modified by De Knijf, teaches the invention of claim 4, De Knijf further comprising grouping device with one or more additional devices into a device group based on one or more grouping parameters, the one or more grouping parameters comprising at least one of: device type, device manufacturer, device functionality, wherein the one or more grouping parameters are retrieved by using device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)); and identifying one or more compromised devices by using an anomaly detection algorithm to analyze network traffic for each device of the device group using network traffic pattern for that device group ([0042], At block 214, data stream monitor 106 on local network 102 monitors the current behavior of IoT devices on the local network 102, [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group, [0044], If the score is above a certain threshold, then at block 218, the device behavior is flagged as malicious. A user or administrator of local network 102 can be alerted to the malicious IoT device. In alternative aspects, the malicious IoT device can be automatically shut down or quarantined to minimize the impact of the malicious behavior).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 9, Colegate teaches all aspects of the invention according to Claim 8 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the system further analyzes the received device hardware identifier for the device to determine a device information feature; and uses the determined device information feature to retrieve additional device information from the device information storage database ([0037-0038], At block 206, behavior analyzer 124 receives the network device statistics 108 and can store the network device statistics 108 in central database 126. As noted above, the network device statistics 108 can be received from multiple local networks 102. At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group. In some aspects, data stream monitor 106 can calculate a score that reflects how likely it is that the current behavior of an IoT device is in accordance with the normal behavior of its particular group or subgroup. In particular aspects, this score can be calculated by using a statistical test of the current observed data and the statistical normal behavior patterns derived for the different groups or subgroups of the device).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 10, Colegate, modified by De Knijf, teaches the invention of claim 9, De Knijf further comprising wherein the device information feature comprises a device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 11, Colegate teaches all aspects of the invention according to Claim 8 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the additional device information from the device information storage database for the one or more devices operating on a cellular network comprises at least one of f: device type, device manufacturer, device functionality, subscription identifier for that device, or a combination thereof ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 12, Colegate teaches all aspects of the invention according to Claim 8 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the expected additional device information comprises an expected device type, the expected device type comprising at least one of: an IoT device, a tablet or a phone ([0036-0038], IoT devices and devices of any other kind on the network including media players, smart devices, gaming consoles, IP cameras, etc.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 14, Colegate, modified by De Knijf, teaches the invention of claim 11, De Knijf further comprising grouping the device with one or more additional devices into a device group based on one or more grouping parameters, the one or more grouping parameters comprising at least one of: device type, device manufacturer, device functionality, wherein the one or more grouping parameters are retrieved by using device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)); and identifying one or more compromised devices by using anomaly detection algorithm to analyze network traffic for each device of the device group using network traffic pattern for that device group ([0042], At block 214, data stream monitor 106 on local network 102 monitors the current behavior of IoT devices on the local network 102, [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group, [0044], If the score is above a certain threshold, then at block 218, the device behavior is flagged as malicious. A user or administrator of local network 102 can be alerted to the malicious IoT device. In alternative aspects, the malicious IoT device can be automatically shut down or quarantined to minimize the impact of the malicious behavior).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 16, Colegate teaches all aspects of the invention according to Claim 15 above, except the following, which in the same field of endeavor, De Knijf teaches analyzing the received device hardware identifier for the device operating on a cellular network to determine device information feature; and using the determined device information feature to retrieve additional device information from the device information storage database ([0037-0038], At block 206, behavior analyzer 124 receives the network device statistics 108 and can store the network device statistics 108 in central database 126. As noted above, the network device statistics 108 can be received from multiple local networks 102. At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group. In some aspects, data stream monitor 106 can calculate a score that reflects how likely it is that the current behavior of an IoT device is in accordance with the normal behavior of its particular group or subgroup. In particular aspects, this score can be calculated by using a statistical test of the current observed data and the statistical normal behavior patterns derived for the different groups or subgroups of the device).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 17, Colegate, modified by De Knijf, teaches the invention of claim 16, De Knijf further comprising wherein the device information feature comprises a device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 18, Colegate teaches all aspects of the invention according to Claim 15 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the additional device information for the device comprises at least one of: device type, device manufacturer, device functionality, subscription identifier for that device, or a combination thereof ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 19, Colegate teaches all aspects of the invention according to Claim 15 above, except the following, which in the same field of endeavor, De Knijf teaches wherein the expected additional device information comprises an expected device type, the expected device type comprising at least one of: an IoT device, a tablet or a phone ([0036-0038], IoT devices and devices of any other kind on the network including media players, smart devices, gaming consoles, IP cameras, etc.).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Regarding Claim 21, Colegate, modified by De Knijf, teaches the invention of claim 18, De Knijf further comprising instructions for: grouping the device with one or more additional devices into a device group based on one or more grouping parameters, the one or more grouping parameters comprising at least one of: device type, device manufacturer, or device functionality, wherein the one or more grouping parameters are retrieved by using device type identifier ([0038], At block 208, the IoT devices can be grouped by device type, and can also be grouped into functional groups. In some aspects, a functional group is a group that performs the same task. For example, one such group can be IP-cameras (of different vendors, with different operating systems). Another group can be media players such as smart speaker systems, smart televisions, and the like. A further group can be game consoles. Those of skill in the art will appreciate that many other groups can exist and such groups are within the scope of the inventive subject matter. A device can be a member of more than one group. For example, a Microsoft Xbox can both belong to the game consoles group as well as to the media player group. Furthermore, a group can have subgroups that can represent multiple granularity layers. For example, IP-cameras can be further divided into subgroups comprising outdoor cameras and indoor cameras. In some aspects, grouping can be further refined by various other additional information. For example, the grouping can be refined base on time zone, country of residence, seasonal influences, time of day, day of week, month, and external events such as sporting events, political events etc. (considers device type, function, and manufacturer)); and identifying one or more compromised devices by using anomaly detection algorithm to analyze network traffic for each device of the device group using network traffic pattern for that device group ([0042], At block 214, data stream monitor 106 on local network 102 monitors the current behavior of IoT devices on the local network 102, [0043], At block 216, data stream monitor 106 determines if the current IoT device behavior is within a threshold for normal device behavior for its device type or group, [0044], If the score is above a certain threshold, then at block 218, the device behavior is flagged as malicious. A user or administrator of local network 102 can be alerted to the malicious IoT device. In alternative aspects, the malicious IoT device can be automatically shut down or quarantined to minimize the impact of the malicious behavior).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the grouping based on device type and other additional device information, as taught in De Knijf, in the system of Colegate, in order to detect malicious devices by making a comparison of a device’s behavior with the behavior profile of a predetermined functional group of devices. (See De Knijf [0006])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARGARET G WEBB whose telephone number is (571)270-7803. The examiner can normally be reached M-F 9:00-6:00 PM.
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, Charles Appiah can be reached at (571) 272-7904. 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.
/MARGARET G WEBB/Primary Examiner, Art Unit 2641
Prosecution Insights