DETAILED ACTION
This office action is in response to the Amendments filed on 07/28/2025.
Claims 1-21 have been cancelled.
Claims 22-23, 29-30, and 36-37 are amended.
Claims 22-42 are presented for examination.
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 with respect to the claims in view of 35 USC 103 rejections filed on 07/28/2025 in Remarks pg 8-11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claims 26-27, 33-34, and 40-41 objected to because of the following informalities:
These claims recite in part “the device behavior model”, however each independent claim has been amended to recite “a trained device behavior machine learning model” and “the selected device behavior machine learning model”. Each of these claims should be amended to reflect these changes.
Appropriate correction is required.
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.
Claim(s) 22, 24-25, 27, 29, 31-32, 34, 36, 38-39, 41 are rejected under 35 U.S.C. 103 as being unpatentable over Ren et al. (hereinafter Ren, US 2017/0149937 A1) in view of Srivastava et al. (hereinafter Sri, US 2020/0153846 A1) in view of Mopur et al. (hereinafter Mopur, US 2020/0151619 A1)
Regarding Claim 22, Ren discloses A method of controlling operation of IoT devices (Ren: para.0017 “FIG. 1 is a diagram illustrating an exemplary environment 100 in which an exemplary embodiment of an IoT unifier service and an IoT portal service of an IoT platform may be implemented.”, para.0081 “FIG. 5 is a flow diagram illustrating an exemplary process 500 pertaining to the IoT unifier service of the IoT platform.” Fig. 5. IoT operations are controlled via the iot platform, for example via checking for compliance in step 520.), comprising:
collecting information about at least one IoT device connected to a wireless network (Ren: para.0022 wireless network) (Ren: para.0031 “According to an exemplary embodiment, data inspector 202 includes logic that identifies packets carrying IoT data. …As a result of the packet inspection, depending on the implementation, data inspector 202 may obtain various types of IoT data. For example, data inspector 202 may obtain payload data and, other types of data, such as network protocol data (e.g., source Internet Protocol (IP) address, destination IP address), a device identifier of IoT device 130, and so forth, carried by a packet.” Information about at least one IoT device is obtained. All of the data obtained by data inspector 202 is collected information);
identifying the IoT device or a type of the IoT device based on the collected information (Ren: para.0031 “For example, data inspector 202 may obtain payload data and, other types of data, such as network protocol data (e.g., source Internet Protocol (IP) address, destination IP address), a device identifier of IoT device 130, and so forth, carried by a packet.” Para.0032 “According to an exemplary implementation, the IoT data may include data that indicates the classification. For example, the payload data may include a classification data type field and a value (e.g. Classification: Video camera). According to another exemplary implementation, the IoT data may include attribute data pertaining to the IoT device, which can be mapped to a classification of the IoT device. For example, the IoT data may include a make data type field and a value, and a model type data field and a value (e.g., Make: Company ABC; Model: 324-A).” The device identifier is included in the collected information therefore the system identified the IoT device, as well as using any of the classification information from the collected information in para.0032 to determine a type of device.);
selecting, for the IoT device or for the type of IoT device, a device behavior model (Ren: para.0084 “In block 515, standard data types are selected based on the classification of the IoT device. For example, data type verifier 206 selects the standard data types that correlate with the selected classification of IoT device 130. For example, when the selected classification of IoT device 130 is a parking meter, data type verifier 206 selects the standard data types of an IoT standard format that have been assigned to this class of IoT device by the IoT unifier service.” Para.0026 “ According to an exemplary implementation, the verification service will determine that a received packet carrying IoT data, which includes a data type and a value that is not one of the standard data types, is in compliance with the IoT standard format when the IoT data includes all of the standard data types of the IoT standard format. ” Based on the type of the device, a set of standard data types are obtained, which is used to determine compliant device behavior, i.e. data output.);
applying the device behavior model to the collected information about the IoT device to identify anomalies in the operation of the IoT device (Ren: para.0026 “ For example, assume that the standard data types are A, B, and C. Also assume that a received packet includes data types A, B, C, and D. According to an exemplary implementation, the verification service would determine that the received packet complies with the standard data types since the received packet includes all of the standard data types (i.e., A, B, and C). On the other hand, assume that the received packet includes data types A, B, and D. According to an exemplary implementation, the verification service would determine that the received packet fails to comply with the standard data types of the IoT standard format since the received packet does not include data type C.” anomalous behavior can be detected using the behavior model, i.e. incorrect data format.);
classifying the IoT device, based on the collected information, among at least one domain: functionality domain, wherein the domain specifies different restrictions on operation of associated IoT devices (Ren: para.0038 “ For example, IoT device classification field 222 may store various classifications, such as water meter, parking meter, environmental sensor, traffic sensor, and so forth, or identifications (e.g. numbers) associated therewith.” para.0035 “According to another exemplary embodiment, a classification of the IoT device affords other services. For example, depending on the classification of the IoT device, IoT data unifier 117 may provide varying levels of security, urgency (e.g., transmission delay, resource utilization (e.g., processing power, etc.)), and/or reliability (e.g., package loss, duplication control, etc.), with respect to the packet. For example, a classification of a water meter may be afforded a lower level of security, urgency, and/or reliability than a classification of a traffic sensor.” Examiner notes that in view of applicants specification para.0197-para.0202 and 207, a functionality domain is a grouping of devices that perform similar functions, such as a sewerage functionality domain including water leak sensors and meters, or lighting functionality domain including various sensors and bulbs, and all devices have some functionality domain, but can further be classified into having information security features and human safety features. Similar to a sewerage functionality domain, or a lighting functionality domain, the water meter is classified into a water meter functionality domain based on the collected information or more generally as a meter classification in para.0034, and a traffic sensor is classified into a traffic sensor functionality domain. These categories cause devices to operate with different restrictions, as a traffic sensor class of devices in this case would operate with a higher security urgency and reliability restriction than a water meter functionality domain device.); and
controlling operation of the IoT device based on the identified anomalies and restrictions associated with the classification of the IoT device (Ren: para.0087 “When it is determined that the IoT data does not comply with the standard data types (block 520-NO), an error handling procedure is performed (block 535). For example, data error handler 210 may perform a resolution process and/or an error notification process, as previously described.” para.0035 “According to another exemplary embodiment, a classification of the IoT device affords other services. For example, depending on the classification of the IoT device, IoT data unifier 117 may provide varying levels of security, urgency (e.g., transmission delay, resource utilization (e.g., processing power, etc.)), and/or reliability (e.g., package loss, duplication control, etc.), with respect to the packet.” Based on errors on data output, i.e. anomalies, and restrictions on security urgency and resource utilization, the IoT devices are controlled by error resolution, and error notification, and by providing additional services in aligning with classification restrictions.).
However Ren does not explicitly disclose selecting, for the IoT device or for the type of IoT device, a trained device behavior machine learning model out of a plurality of available machine learning models based on at least one of operating speed and effectiveness of the machine learning model; applying the selected device behavior machine learning model to the collected information about the IoT device to identify anomalies in the operation of the IoT device; classifying the IoT device, based on the collected information, among at least two domains: information security domain and functionality domain, wherein each domain specifies different restrictions on operation of associated IoT devices.
Sri discloses classifying the IoT device, based on the collected information, among at least two domains: information security domain and functionality domain, (Sri: para.0028 “In some embodiments, process 100 can configure separation zones (e.g., subnets) based on functional and/or security requirements. For example, in some embodiments, process 100 can configure one separation zone for each device category, each device type, and/or each device posture.” Based on functional requirements and security requirements, each IoT device is classified into separation zones as seen in Fig. 6.)
wherein each domain specifies different restrictions on operation of associated IoT devices (Sri: para.0049 “In some embodiments, creating a new separation zone can include configuring a new subnet in the network and associating one or more access control policy rules with the new subnet based on functional and/or security requirements.” The functional requirements and the security requirements cause certain access control policy rules to be applied. Para.0026 “For example, in some embodiments, the mechanisms described herein can close a security gap by restricting communication between devices that have no functional requirement to communicate with each other.” A functionality domain is considered for devices of particular types that may not need to communicate with one another, Para.0069 “As another example, in some embodiments, process 400 can receive information indicating that the IoT device is in a vulnerable state, such as when there is a known security issue associated with the IoT device or when the IoT device is not yet updated to a latest version.” Para.0070 “At 404, process 400 can assign the compromised IoT device to an isolation zone (e.g., isolation subnet).” Device may be classified as more vulnerable, and its operation may be more controlled); and
controlling operation of the IoT device based on the restrictions associated with the classification of the IoT device (Sri: para.0023 “The mechanisms described herein can then cause the IoT device to communicate in accordance with a selected separation zone based on the determined device category, device type, and/or device posture in some embodiments. In some embodiments, the mechanisms described herein can control communication among separation zones based on one or more access control policy rules.” Each IoT device is controlled based on its classification and its associated restrictions as described at least in para.0026 for its functionality, and para.0069 on its security as set forth above.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Ren with Sri in order to incorporate classifying the IoT device, based on the collected information, among at least two domains: information security domain and functionality domain.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved security of a network of IoT devices (Sri: para.0025-0026).
However Ren-Sri does not explicitly disclose selecting, for the IoT device or for the type of IoT device, a trained device behavior machine learning model out of a plurality of available machine learning models based on at least one of operating speed and effectiveness of the machine learning model; applying the selected device behavior machine learning model to the collected information about the IoT device to identify anomalies in the operation of the IoT device.
Mopur discloses selecting, for the IoT device or for the type of IoT device, a trained (Mopur: para.0044 “ML model 208 is trained…”) device behavior machine learning model out of a plurality of available machine learning models (Mopur: para.0017 “The IoT devices (such as, 110a, 110b, 111a, 111b) produce an enormous amount of data at IoT edge 110 that is streamed back to the IoT core 120 by computing edge devices (like an edge server) over network 130. IoT core 120 runs a variety of data analytics using ML on the incoming data streams from the IoT endpoints (i.e., computing edge devices 111a, 111b discussed with respect to FIG. 1) and characterize the data, monitor the performance metrics of the ML techniques as prediction or classification accuracy (e.g., recall, precision), to determine whether revisions are necessary to the ML models at the IoT edge 110.” Para.0057 “At operation 302, a plurality of data from an IoT computing edge device is received.” Para.0061 “At operation 308, performance of the deployed production model is analyzed. ” para.0066 “At operation 316, the results of the production model performance of operation 308 and the results of training model performance resulting from operation 314 are compared to determine the best predictive model.” Based on IoT sensor data obtained at an edge, an optimal machine learning model is determined from a group of models applied in step 314 para.0065)
based on at least one of operating speed and effectiveness of the machine learning model (Mopur: para.0017 “characterize the data, monitor the performance metrics of the ML techniques as prediction or classification accuracy (e.g., recall, precision)” the performance of the model is determined, i.e. its effectiveness, in order to determine which model should be deployed for the IoT devices, see also para.0030-0032);
applying the selected device behavior machine learning model to the collected information about the IoT device to identify anomalies in the operation of the IoT device (Mopur: para.0067 “ At operation 318, the best predictive model to address the impact of concept drift is deployed to the IoT computing edge device. In various embodiments, the deployment is performed by an updating engine, such as model updater 224 discussed with respect to FIG. 2.” Para.0015 “For example, IoT edge 110 may include an edge server running one or more data processing and analytics applications. One example of such data processing and ML analytics inference may include predictive analytics of sensors data from machines in factories to monitors such as vibration, temperature for potential anomalies and predictive maintenance. ” The selected model is then deployed to identify anomalies in operation).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ren-Sri with Mopur in order to incorporate selecting, for the IoT device or for the type of IoT device, a trained device behavior machine learning model out of a plurality of available machine learning models based on at least one of operating speed and effectiveness of the machine learning model; applying the selected device behavior machine learning model to the collected information about the IoT device to identify anomalies in the operation of the IoT device.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving existing IoT environments optimize performance of monitoring IoT devices (Mopur: para.0023, para.0010).
Regarding Claim 24, Ren-Sri-Mopur discloses claim 22 as set forth above.
Ren further discloses wherein the collected information includes one or more of: identifier of the IoT device (Ren: para.0031 “For example, data inspector 202 may obtain payload data and, other types of data, such as network protocol data (e.g., source Internet Protocol (IP) address, destination IP address), a device identifier of IoT device 130, and so forth, carried by a packet.” The device identifier is included in the collected information);
duration and/or frequency of operation of the IoT device; average packet size of data transmitted by the IoT device; and/or frequency of data transmissions from the IoT device.
Regarding Claim 25, Ren-Sri-Mopur discloses claim 22 as set forth above.
Ren further discloses wherein controlling operation of the IoT device includes one or more of: control network traffic to/from the IoT device (Ren: para.0087 “When it is determined that the IoT data does not comply with the standard data types (block 520-NO), an error handling procedure is performed (block 535). For example, data error handler 210 may perform a resolution process and/or an error notification process, as previously described.” para.0026 “According to an exemplary implementation, the verification service would determine that the received packet fails to comply with the standard data types of the IoT standard format since the received packet does not include data type C. According to other exemplary implementations, the verification service may make different determinations and/or perform other operations in response to the received packet that includes data types A, B, and D. For example, depending on the standard data type that is missing, the verification service may insert or add the missing data type along with a default value or a dummy value.” Error handling to control network traffic from the iot device can be performed, the packets can further be rejected in para.0027.);
disabling the IoT device; updating firmware of the IoT device; updating software of the IoT device; and/or restoring settings of IoT device from a backup.
Regarding Claim 27, Ren-Sri-Mopur discloses claim 22 as set forth above.
However Ren-Sri does not explicitly disclose wherein the device behavior model includes one of a random forest algorithm, an artificial neural network, or a support vector machine.
Mopur further discloses wherein the device behavior model includes one of a random forest algorithm, an artificial neural network (Mopur: para.0020 “This is acutely relevant for ML techniques such as artificial neural networks, and other types of machine learning subsets commonly referred to as deep learning, which aim to solve problems in a method similar to the human brain.” Artificial neural networks are one of the machine learning models that can be applied.), or a support vector machine.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ren-Sri with Mopur in order to incorporate wherein the device behavior model includes one of a random forest algorithm, an artificial neural network.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improving existing IoT environments optimize performance of monitoring IoT devices (Mopur: para.0023, para.0010).
Regarding Claims 29, 31-32, 34 they teach all of the same steps as claims 22, 24-25, 27, but in A system for controlling operation of IoT devices, comprising: at least one processor configure to: (Ren: para.0068-0071). Therefore the supporting rationale for the rejection to claims 22, 24-25, 27 applies equally as well to that of claims 29, 31-32, 34.
Regarding Claims 36, 38-39, 41 they teach all of the same steps as claims 22, 24-25, 27 but in A non-transitory computer readable medium storing thereon computer executable instructions for controlling operation of IoT devices, including instructions for: (Ren: para.0068-0071, para.0095). Therefore the supporting rationale for the rejection to claims 22, 24-25, 27 applies equally as well to that of claims 36, 38-39, 41.
Claim(s) 23, 30, 37 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ren et al. (hereinafter Ren, US 2017/0149937 A1) in view of Srivastava et al. (hereinafter Sri, US 2020/0153846 A1) in view of Mopur et al. (hereinafter Mopur, US 2020/0151619 A1) in view of Wilson et al. (hereinafter Wilson, US 2020/0356876 A1).
Regarding Claim 23, Ren-Sri-Mopur discloses claim 22 as set forth above.
However Ren-Sri-Mopur does not explicitly disclose the device behavior machine learning model is selected based on one of the following methods: sliding control, cross-validation, Akaike Information Criterion (AIC), Bayesian Information Criterion (BIC), A/B testing, split testing, and stacking.
Wilson discloses the device behavior machine learning model is selected based on one of the following methods: sliding control, cross-validation (Wilson: para.0050 “In certain implementations, the training environment 106 may be implemented at least in part by the SuperLearner platform and may use cross-validation to select the machine learning models 114, 116 as an optimal combination of the candidate models 108, 110.” Cross validation is used to select machine learning models to apply), Akaike Information Criterion (AIC), Bayesian Information Criterion (BIC), A/B testing, split testing, and stacking.
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ren-Sri-Mopur with that of Wilson in order to incorporate the device behavior machine learning model is selected based on one of the following methods: sliding control, cross-validation, Akaike Information Criterion (AIC), Bayesian Information Criterion (BIC), A/B testing, split testing, and stacking.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of selecting optimal machine learning models (Wilson: para.0050).
Regarding Claims 30, 37 they do not teach nor further define over the limitations of claim 23, therefore the supporting rationale for the rejection to claim 23 applies equally as well to that of claims 30 and 37.
Claim(s) 26, 33, 40 are rejected under 35 U.S.C. 103 as being unpatentable over Ren et al. (hereinafter Ren, US 2017/0149937 A1) in view of Srivastava et al. (hereinafter Sri, US 2020/0153846 A1) in view of Mopur et al. (hereinafter Mopur, US 2020/0151619 A1) in view of Adir et al. (hereinafter Adir, US 2021/0160264 A1).
Regarding Claim 26, Ren-Sri-Mopur discloses claim 22 as set forth above.
However Ren-Sri-Mopur does not explicitly disclose wherein the device behavior model is trained and/or re-trained using collected information about operation of IoT devices of the same type.
Adir discloses wherein the device behavior model is trained and/or re-trained using collected information about operation of IoT devices of the same type (Adir: para.0026 “Models may be built using the data to model the behavior of individual devices, types of devices, and/or clusters of devices. Such models may then be used to detect anomalies in behavior of individual devices, types of devices, and/or clusters of device. For example, given a model of behavior of an individual device, anomalous behavior of the device may be detected based on deviation from the modeled behavior.” for an individual IoT device or for a type of IoT device, behavior is collected in steps 202 and 204 to train models for a particular type of device for detection of anomalous device. These models are applied to the collected data of the device in order to detect anomalies, para.0027-0029 training based historical data.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Ren-Sri-Mopur with Adir in order to incorporate wherein the device behavior model is trained and/or re-trained using collected information about operation of IoT devices of the same type.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improved accuracy of anomaly detection based on machine learning and other types of learning based on historical data (Adir: para.0026-0030).
Regarding Claims 33 and 40, they do not teach nor further define over the limitations of claim 26, therefore the supporting rationale for the rejection to claim 26 applies equally as well to that of claims 33 and 40.
Claim(s) 28, 35 and 42 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ren et al. (hereinafter Ren, US 2017/0149937 A1) in view of Srivastava et al. (hereinafter Sri, US 2020/0153846 A1) in view of Mopur et al. (hereinafter Mopur, US 2020/0151619 A1) in view of Tedaldi et al. (hereinafter Tedaldi, US 2021/0335505 A1).
Regarding Claim 28, Ren-Sri-Mopur discloses claim 22 as set forth above.
Ren further discloses when an unknown IoT device cannot be identified based on the collected information (Ren: para.0033 “According to an exemplary embodiment, when the classification is not included in the IoT data, IoT device classifier 204 includes logic to extract particular data (e.g., a particular standard data type) from the IoT data and use the extracted data to perform a lookup (e.g., in a database or a data structure) in order to determine the IoT device classification. ” the collected information may not contain enough information to identify the device, and therefore performs a lookup using the iot data to determine its classification, i.e. cluster of similar iot devices.),
associating the unknown IoT device with the identified cluster of similar IoT devices (Ren: para.0034 “The IoT device classifications may be implemented very generally, such as, for example, meters, or more specifically as water meter, gas meter, a parking meter, and so forth. As described herein, the IoT unifier service converts IoT data transmitted by IoT devices 130 of the same classification into an IoT standard format assigned for that classification.” In the case of a water meter, it can be classified into a classification of similar meters.).
However Ren-Sri-Mopur does not explicitly disclose calculating a digital fingerprint of the unknown IoT device containing data about software and hardware specification of the IoT device; calculating a key feature vector from the digital fingerprint, wherein the key feature vector contains one or more key features identifying the IoT device; identifying a cluster of similar IoT devices by comparing vector distances of the one or more key features of the unknown IoT device with key features of IoT devices in each cluster.
Tedaldi discloses calculating a digital fingerprint of the unknown IoT device (Tedaldi: para.0046, para.0101 iot) containing data about software and hardware specification of the IoT device (Tedaldi: para.0048 “Also as shown in FIG. 4 is a device classification service 408 that may be hosted on one or more of networking devices 406 or be in communication therewith. Service 408 may, for example, be provided through the execution of device classification process 248, described above. In general, device classification service 408 is configured to take as input telemetry data 410 captured by networking device 406 regarding network traffic associated with endpoint device 402 and, based on the captured telemetry, identify the device type 412 of endpoint device 402. For example, device type 412 may indicate the operating system (e.g., iOS, Android, etc.), manufacturer (e.g., Apple, Samsung, etc.), make (e.g., iPhone, etc.), model/version (e.g., 5s, 6, 7, etc.), function (e.g., thermostat, temperature sensor, etc.), or any other information that can be used to categorize endpoint device 402.” Information regarding the IoT device is obtained that identifies the device, including hardware specification such as manufacturer make model and function of the device, and software such as operating system and packed header information in para.0043. All of this information together the digital fingerprint of the IoT device.);
calculating a key feature vector from the digital fingerprint, wherein the key feature vector contains one or more key features identifying the IoT device (Tedaldi: para.0065 “For every device D.sub.i at time t, clustering module 502 may construct a feature vector X.sub.i,t from the telemetry data 508 for the device.” Based on telemetry information gathered, a feature vector is created for the device.);
identifying a cluster of similar IoT devices by comparing vector distances of the one or more key features of the unknown IoT device with key features of IoT devices in each cluster (Tedaldi: para.0065 “Clustering module 502 may then apply a clustering algorithm, such as DB-scan, k-means, k-medoids, etc., to create a set of device clusters 504. Let C.sub.t={C.sub.1,t, . . . , C.sub.K,t} denote these cluster, where C.sub.j,t is the j.sup.th set of devices clustered together at time t. As would be appreciated, the number of clusters K is typically smaller, or at most equal, to the number of points N, and the collection of clusters C defines a partition of the set of devices D. In doing so, each device represented in a device cluster 504 may exhibit similar behaviors as those of the other devices in its cluster.” Similar devices are clustered together based on the similarity in the vectors using a K-means clustering algorithm which compares distances between vectors. Also via distance between points in para.0122.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Ren-Sri-Mopur with Tedaldi in order to incorporate calculating a digital fingerprint of the unknown IoT device containing data about software and hardware specification of the IoT device; calculating a key feature vector from the digital fingerprint, wherein the key feature vector contains one or more key features identifying the IoT device; identifying a cluster of similar IoT devices by comparing vector distances of the one or more key features of the unknown IoT device with key features of IoT devices in each cluster.
One of ordinary skill in the art would have been motivated to combine because of the expected benefit of improvement in rule application that solves issues occurring from inaccurate classification of devices (Tedaldi: para.0004).
Regarding Claims 35, and 42, they do not teach nor further define over the limitations of claim 27, therefore the supporting rationale for the rejection of claim 27 applies equally as well to that of claims 35 and 42.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lie et al. US 2018/0097885 A1 please see para.0020 and Fig. 3 that detects threats to a user and performs tasks automatically.
Shen et al. US 2022/0353130 A1 Fig. 1 and Fig. 7, para.0187 and abstract devices are categorized into multiple groups and controlled using alarms.
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 EUI H KIM whose telephone number is (571)272-8133. The examiner can normally be reached 7:30-5 M-R, M-F alternating.
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, Kamal B Divecha can be reached on 5712725863. 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.
/EUI H KIM/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453