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 has amended independent claims 1, 10 & 19 and has cancelled claims 7 & 16 and stated in the Remarks filed on 3/18/2026 that the Applicant has amended independent claims 1 ,10 & 19 with limitations of claims 7 & 16. Examiner respectfully disagreed with this statement as the Applicant has only partially (not fully) incorporated limitations of claims 7 & 16 into claims 1, 10 & 19. The amended limitations that recite providing the normalized security sensor data to a synthetic sensor; wherein the synthetic sensor is configured to: determine that an anomaly exists within the normalized security sensor data; generate an alert based on the determining that the anomaly exists, is not part of claims 7 & 16.
The Applicant argued in the said remarks that Moeller01 is directed to an anti-theft device for vehicle and not directed to methods of detecting cyberattacks and also Moeller01 fails to disclose providing the normalized security sensor data to synthetic sensor. Examiner has found this argument to be moot as Examiner has changed ground.
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 of this title, 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.
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 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.
Claims 1, 5, 10, 14 & 19 are rejected under 35 USC 103 as being unpatentable over Khurana (US 20210103260) in view of Blaser (US20080270066) and Ott (US 20040049698 A1)
Regarding claim 1, Khurana teaches:
a method at a computing device comprising: receiving security sensor data from plurality of sensor devices; [0013] In another example, a system for controlling a building may include e a local building controller and a cloud server. The local building controller may be configured to receive sensor data from one or more sensors of the building]
normalizing, the security sensor data to create normalized security sensor data; [0013] In another…the building. The cloud server may be configured to receive the sensor data from the local building controller, normalize the sensor data,]
determine that an anomaly exists within the normalized security sensor data; [[0013]: In another…sensor data. Compare the normalized sensor data with normalized sensor data from one more other building to identify one or more anomalies associated the building.]
generate an alert based on the determining that the anomaly exists, [0050] The remote device 214 may be any internet connected device including a smart phone, tablet, e-reader, laptop computer, personal computer, etc. The notification may be received by an alert module 216 within the remote device 214. The alert module 216 may receive a recommended action from the controller 204 and display the action on a display or guided user interface (GUI) 218 of the user device 214.]
provide the alert as an insight to an insight consumer. [0050] The remote device …. computer, etc. The notification may be received by an alert module 216 within the remote device 214. The alert module 216 may receive a recommended action from the controller 204 (provide insight to the user/consumer) and display the action on a display or guided user interface (GUI) 218 of the user device 214. (provide insight to the user/consumer)]
Although, Khurana teaches normalizing security sensors data, he does not teach explicitly, however, Blaser teaches normalizing, at a hardware Abstraction Layer (HAL) the sensor data to create normalized sensor data having a common format; [0023] the sensor fusion processor 222 can provide an aggregation of the data received from the sensors 101-104 supported by the physical interface module 202. Particularly, the aggregation includes the normalization of the data and information and a determination of responses to issues in the agent 100 or the sensor middleware system 106. As noted above, the sensor fusion processor 222 can receive information from the fault tolerance processor 220 that can dictate how the sensor fusion processor 222 processes and aggregates the data. In general, normalization provides sensor data in a common form that abstracts hardware differences, such as scaling differences, unit differences and endian differences, so as to ensure a common data format exists for computation and fusion activities. In the agent 100, this data typically relates to relative position, velocity, and attitude. The sensor fusion processor aggregates the data such that the resulting information is superior to sensor data considered individually. The data may be more accurate, more complete, more dependable, or provide an enhanced view, such as stereoscopic vision.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana with the disclosure of Blaser. The motivation or suggestion would have been to implement a system that will provide efficient techniques that utilizes adaptive and fault tolerant and upgradable sensor systems (abstract, para 0001-0003, Blaser)
Although, Khurana and Blaser teach normalizing security sensors data, they do not teach explicitly, however, Ott teaches:
wherein the security data comprises monitoring data from an operating system of at least one processor; [[0024] FIG. 3 shows mobile sensor agents 322 (synthetic sensor) in transit between security server 302 and client computers 304, 306. FIG. 3 also shows a mobile broker agent 324 in transit between security server 302 and network application 318. FIG. 3 thus illustrates the dynamic and mobile nature of the various mobile sensor agents, which are distributed in computer network 300 under the control of security server 302. In response to the changing risk and security status of computer network 300, security server 302 can distribute and/or allocate additional mobile sensor agents to appropriate locations within the network. In addition, security server 302 can activate dormant sensor agents (e.g., mobile sensor agent 326 maintained by client computer 304), deactivate active mobile sensor agents, withdraw mobile sensor agents that are no longer needed, and/or terminate or delete mobile sensor agents that are no longer needed (a deleted or withdrawn mobile sensor agent 328 is shown in connection with client computer 306). Furthermore, the network security system is adaptable to accommodate new sensor agents 330 that detect additional events that are currently unmonitored. For example, in response to new attack signatures or suspected network vulnerabilities, new mobile sensor agents 330 may be installed on security server 302 for managed distribution in computer network 300. In this manner, every client computer in computer network 300 need not be periodically updated to provide protection against new threats. [0025] The various types of mobile sensor agents (e.g., field agents, broker agents, and wandering agents) share many functional characteristics. For example, when deployed in the client computers, a mobile sensor agent resides in the application layer of the host processor, along with a suitable agent server. The mobile sensor agent is configured to communicate directly with the operating system of the host processor, via the kernel layer. The mobile sensor agents detect "low level" data corresponding to abstract events or activities rather than "high level" contextual data or data related to attack signatures (intrusion detection). The mobile sensor agents detect events even if the events themselves are not predefined components of an attack. In other words, rather than detect the occurrence of an attack itself, the mobile sensor agents look for elemental evidence of activities and events that could be a constituent part of an attack. In this regard, the mobile sensor agents can be lightweight in design and they need not consume a large amount of the host processor resources.]
providing the data to a synthetic sensor, [0025] The various types of mobile sensor agents (synthetic sensors) (e.g., field agents, broker agents, and wandering agents) share many functional characteristics. …... The mobile sensor agent (synthetic sensor) is configured to communicate directly with the operating system of the host processor, via the kernel layer. The mobile sensor agents (synthetic sensors) detect "low level" data corresponding to abstract events or activities rather than "high level" contextual data or data related to attack signatures (intrusion detection) The mobile sensor agents detect events even if the events themselves are not predefined components of an attack. In other words, rather than detect the occurrence of an attack itself, the mobile sensor agents look for elemental evidence of activities and events that could be a constituent part of an attack.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser with the disclosure of Ott. The motivation or suggestion would have been to implement a system that will provide efficient and improved techniques installing mobile sensors for monitoring & detecting attack. (abstract, para 0001-0006, Ott)
Regrading claims 5 & 14, Khurana teaches wherein the security sensor data is received from a different computing device or virtual machine within a system. [please see paragraph 0052]
Regarding claims 10 & 19, these claims are interpreted to be as same as claim 1 and rejected for these same reasons as set forth for claim 1.
Claims 2-4 & 11-13 are rejected under 35 USC 103 as being unpatentable over Khurana in view of Blaser, Ott and Rieger (US20210089661)
Regarding claims 2 & 11, although, Khurana and Blaser and Ott teach determination of anomaly, he does not teach explicitly, however, Rieger teaches wherein the determining that the anomaly exists is performed by at least one of a rules service and a machine learning inference service. [please see paragraph 0091]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Rieger. The motivation or suggestion would have been to implement a system that will provide efficient techniques for anomaly detection based on integrated cyber and physical state data and in particular, means for integrating scalable, simplified sets of physical relationships and features into machine learning anomaly detection algorithms. (abstract, para 0004-0006, Rieger)
Regarding claims 3 & 12, although, Khurana and Blaser and Ott teach determination of anomaly, he does not teach explicitly, however, Rieger teaches wherein the rules service compares the normalized security sensor data with a plurality of rules stored at the computing device, the method generating the alert when one of the plurality of rules is triggered. [please see paragraph 0091]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Rieger. The motivation or suggestion would have been to implement a system that will provide efficient techniques for anomaly detection based on integrated cyber and physical state data and in particular, means for integrating scalable, simplified sets of physical relationships and features into machine learning anomaly detection algorithms. (abstract, para 0004-0006, Rieger)
Regarding claims 4 & 13, Khurana and Blaser and Ott do not teach explicitly, however, Rieger teaches wherein the machine learning inference service uses a machine learning model trained on normal and anomalous behavior to create the machine learning inference service. [[0053]:The process…anomaly detection. ML anomaly detection models are typically trained to baseline behavior. Physical state data, however, may vary over time and/or under different “nominal” baseline conditions (e.g., operation in different modes, different conditions, and/or the like). Therefore, even if ML anomaly detection models were trained to fit physical state data associated with a particular baseline, the ML anomaly detection models would still produce false positives during “nominal” operation (e.g., produce false positives as physical state data shifts during operation in different baseline conditions). Furthermore, physical quantities may span large ranges during “nominal” operation (e.g., due to operation under different modes, conditions, baselines, and/or the like); ML anomaly detection models trained to fit such physical quantities may be incapable of providing meaningful anomaly detection information (e.g., may be incapable of distinguishing physical state quantities associated with “nominal” physical behavior from “anomalous” physical behavior due to, inter alia, the large ranges spanned thereby). Moreover, even if an ML anomaly detection model were capable of characterizing certain physical quantities over limited ranges, the models would only indicate whether observed physical quantities conform with previous training data and provide no indication whether the physical quantities represent a valid, “nominal” physical state 115 of the CPC system 101.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Rieger. The motivation or suggestion would have been to implement a system that will provide efficient techniques for anomaly detection based on integrated cyber and physical state data and in particular, means for integrating scalable, simplified sets of physical relationships and features into machine learning anomaly detection algorithms. (Abstract, para 0004-0006, Rieger)
Claims 6, 8-9 & 15, 17-18 are rejected under 35 USC 103 as being unpatentable over Khurana (US 20210103260) in view of Blaser, Ott and Appel (US 20190036948 A1)
Regrading claims 6 & 15, Khurana and Blaser and Ott do not teach explicitly, however, Appel teaches wherein the system comprises a vehicle. [0030] In an embodiment, the vehicle security manager 130 is configured to collect vehicle data from the data sources 170, the fleet manager 160, and the security agent 140. To this end, the data sources 170 store vehicle data such as, but not limited to, events, vehicle states, data traffic, telemetry data (e.g., Controller Area Network messages, sensor readings collected by sensors of a car, etc.), over-the-air (OTA) updates, log analytics, Lidar data, radar data, images, videos, and the like. The data stored in the data sources 170 may be from fleet managers, vehicle control systems, traffic control systems, and other systems configured to monitor and collect data related to vehicle or fleet behavior. Specifically, data from multiple different sources of information may be collected and utilized to detect anomalies, determine root causes, and the like. The vehicle security manager 130 may be configured to normalize the collected vehicle data.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Appel. The motivation or suggestion would have been to implement a system that will provide improved and efficient solutions that would overcome the challenges of hackers interfering with vehicle functions by securing vehicles and connected car service layers against cyber. (abstract, para 0002-0005, Apple)
Regrading claims 8 & 17, although Khurana and Blaser and Ott teach security sensor data they do not teach explicitly, however, Apple teaches a second computing device having an insight consumer registered to listen for any insight from the synthetic sensor. [[0017] The various disclosed embodiments include a method and system for securing connected vehicles and connected vehicle services against cyber-attacks. Thus, the disclosed embodiments provide connected vehicle cybersecurity techniques. Vehicle data from multiple data sources is collected and correlated to monitor vehicle or vehicle service behavior over time and to detect changes in vehicle or vehicle service behavior representing anomalies. The vehicle data includes data related to operation of the vehicle such as, but not limited to, internal data (e.g., engine speed, engine state, etc.), functional data (e.g., vehicle location, speed, etc.), driver data, user data (e.g., when the connected vehicle is controlled remotely), applicative service data (e.g., commands sent to the connected vehicle by a server or user device as part of a connected vehicle service), and the like. The vehicle data indicates information related to behavior of the vehicle such that abnormal vehicle data may represent anomalous behavior that requires mitigation. Please also see paras 0018-0020]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Appel. The motivation or suggestion would have been to implement a system that will provide improved and efficient solutions that would overcome the challenges of hackers interfering with vehicle functions by securing vehicles and connected car service layers against cyber. (abstract, para 0002-0005, Apple)
Regrading claims 9 & 18, Khurana and Blaser and Ott teach security sensor data, they do not teach explicitly, however, Appel teaches wherein the insight consumer is a security operations center for at least one of a vehicle manufacturer, a fleet operator, or a vehicle operator. [0023] The security agent 140 is a network element configured to enable communications with the vehicle security manager 130 via the network 110. The security agent 140 is further configured to receive data from multiple sources including, but not limited to, requests from the user device 120 (e.g., via the app 125), vehicle sensor data, and telematics data, and to detect anomalies based on the received data. The requests may indicate commands that are to be sent to and implemented by the fleet manager 160, by one or more of the vehicle control systems 170, or both. As a non-limiting example, such a command may be “Start_Engine” that was sent to the vehicle control system 170. [0024] Anomalies may be detected based on, but not limited to, receiving a request for a command to be implemented by the fleet manager 160 or one of the vehicle control systems 170 (e.g., a command to lock or unlock a connected vehicle, to turn the connected vehicle on or off, to control driving of the connected vehicle, etc.), an attempt to access data from the fleet manager 160 or the vehicle control system 170, and the like. The security agent 140 is configured to send the detected anomalies to the vehicle security manager 130 for analysis. [0025] The security agent 140 may be further configured to identify a driver of a connected vehicle including or otherwise controlled by the vehicle control system 170 from which a request is received. Based on the requests, the identified driver, the anomalies, commands sent by the vehicle security manager 130, or a combination thereof, the security agent 140 may be configured to update a state of the connected vehicle. The state may indicate a context utilized to determine expected anomalies and commands as described further herein below, and may be, but is not limited to, an allocation of a vehicle to a specific driver, a most recent over-the-air number received by the vehicle, and the like.]
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to combine the teachings of Khurana and Blaser and Ott with the disclosure of Appel. The motivation or suggestion would have been to implement a system that will provide improved and efficient solutions that would overcome the challenges of hackers interfering with vehicle functions by securing vehicles and connected car service layers against cyber. (abstract, para 0002-0005, Apple)
Conclusion
The prior arts made of record and listed on the PTO-892 and not relied upon are
considered pertinent to applicant’s disclosure.
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 SHER A KHAN whose telephone number is (571)272-8574. The examiner can normally be reached M-F 8:00 am-500pm.
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, Eleni A Shiferaw can be reached at 571-272-3867. 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.
/SHER A KHAN/Primary Examiner, Art Unit 2497
Prosecution Insights