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 .
This office action is in response to applicant’s amendment filed on 12/05/2025.
Claims 1-11 are pending and examined in this office action.
Response to Arguments
Per 101 abstract idea rejection, applicant’s arguments filed on 12/05/2025 have been fully considered, and they are persuasive. The previously issued 101 rejection is withdrawn.
Per 103 rejection, applicant argued the cited prior art do not teach the amended claim limitation of “updating, by the central monitoring unit, the digital twin of the embedded device based on the provided information”. Specifically, applicant stated Singh teaches an external server that updates an embedded device based on the performance of a digital twin. As Singh (para. [0087]) describes, “potential effects of the upgrades or patches on one or more functionalities or features of the local BBMD device 608 can first be tested and monitored for stability on the digital twin 600, before going live on the local BBMD device 608.” Thus, Singh teaches away from the recited steps of claim 1 and does not update the digital twin “based on the provided information,” the provided information being “information about the security-critical software state” of the embedded device. The examiner respectfully disagrees. First, Gottschlich discloses sending the information (security-critical software state) to a central monitor unit for a remedial action (paragraphs [0080][0049]-[0052]; application associated with the fingerprint can be marked as blacklisted when the fingerprint classifier determines that the fingerprint is indicative (the security-critical software state) of a malicious, fraudulent, or harmful application; the fingerprint classifier can initiate an alert to notify an external system regarding the application for a remedial action). Then, Singh discloses applying security patch (a remedial action) to a digital twin device and an actual device (Fig. 5; paragraph [0085][0087]; a system level controller at a server; a digital twin is selected and assigned as a backup BBMD for a local BBMD device that is connected to a local subnet, the digital twin is a replica of a local BBMD device, so that upgrades and patches (e.g., operating system updates, security patches) can first be applied and tested on the digital twin before being applied to the actual local BBMD device). Therefore, the combination of Gottschlich and Singh would teach the claim limitation of “updating, by the central monitoring unit, the digital twin of the embedded device based on the provided information”, because after a malicious software is detected in the embedded device, an alert (security-critical software state) is sent to a central monitor unit for a remedial action. Based on the alert, the central monitor unit provides a remedial action (applying a security patch) to protect the embedded device (which includes applying the security patch to the digital twin first). The rationale for above combination is evidenced in Martini (US PGPUB 2018/0069878; paragraphs [0045][0046]; after detecting a client device is exhibiting anomalous behavior commonly associated with a malware; the anti-malware system applies a corrective action (remedial action), which includes installing a security patch). Therefore, the examiner believes the combination of Gottschlich and Singh would teach the above claim limitation.
The examiner is available for a phone interview with applicant.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11 are rejected under 35 U.S.C. 103 as being unpatentable over Gottschlich et al. (US PGPUB 2019/0319977) hereinafter Gottschlich, in view of GALULA et al. (US PGPUB 2020/0216097) hereinafter GALULA, in view of Singh et al. (US PGPUB 2020/0313925) hereinafter Singh.
Per claim 1, Gottschlich discloses a method for updating a device, comprising the following steps: ascertaining execution traces of at least one software executed on the device, determining an identifier for the executed software based on the ascertained execution traces, wherein the identifier is specific to an identity and/or to enabled functions of the executed software (paragraphs [0080][0049]-[0051]; a fingerprint for the application is extracted by the fingerprint extractor using the processed telemetry event data and performance monitor unit counter information, processed trace data from the trace processor are combined to form into an application fingerprint (the application fingerprint is an identifier that is specific to an identity of the executed application); determining the information about the security-critical software state based on the identifier; providing the information about the security-critical software state for the central monitoring unit via the network connection (paragraphs [0080][0049]-[0052]; application associated with the fingerprint can be marked as blacklisted when the fingerprint classifier determines that the fingerprint is indicative (the security-critical software state) of a malicious, fraudulent, or harmful application; the fingerprint classifier can initiate an alert to notify an external system regarding the application for a remedial action).
Gottschlich does not explicitly teach the device is an embedded device and the embedded device has a network connection to a central monitoring unit for the central monitoring of the embedded device. However, GALULA suggests the above (paragraphs [0027]-[0028]; a network of embedded devices, and a security layer that can communicate to a server for detecting cyber threats). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gottschlich and GALULA to apply Gottschlich’s method of detecting malicious application execution to networked embedded devices, this would increase the usage and versatility of Gottschlich’s invention.
Gottschlich also does not explicitly teach “updating, by the central monitoring unit, the digital twin of the embedded device based on the provided information”. However, Gottschlich discloses sending the information (security-critical software state) to a central monitor unit for a remedial action (paragraphs [0080][0049]-[0052]). Furthermore, Singh discloses applying a remedial action (security patch) to a digital twin device and an actual device (Fig. 5; paragraph [0085][0087]; a system level controller at a server; a digital twin is selected and assigned as a backup BBMD for a local BBMD device that is connected to a local subnet, the digital twin is a replica of a local BBMD device, so that upgrades and patches (e.g., operating system updates, security patches) can first be applied and tested on the digital twin before being applied to the actual local BBMD device). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Gottschlich, GALULA and Singh that an external server (central monitoring unit) provides a digital twins for each embedded device on a network and updating the digital twins with a security update (remedial action) based on provided security information, as the security update can protect the embedded device from a malware, and a digital twins can server as a backup for each embedded device, it provides redundancy in a system in case an embedded device fails.
Per claim 2, Gottschlich further suggests comparing the identifier with at least one specification for determining an identity and/or enabled functions of the executed software, wherein a match of the identifier with at least one of several entries in a database is ascertained (paragraphs [0050][0051][0060]; the fingerprint classifier compares the fingerprint to one or more cluster prototypes stored in the fingerprint database, distances between a fingerprint and one or more fingerprint clusters can be formed into a classification vector used to classify the fingerprint as malicious or benign based on the classification of the closest clusters); detecting, in the event of a deviation of the identifier from each of the entries of the at least one specification, the security-critical software state based on the comparison; defining the information about the security-critical software state based on the comparison and/or the detection, wherein, in the event that the security-critical software state is detected, a security measure is initiated by a response module of the embedded device, wherein the security measure includes at least one of the following actions: restarting the embedded device, updating the executed software, degrading the embedded device, alerting the central monitoring unit (paragraphs [0080][0049]-[0052][0054]; a deviation in a fingerprint being classified triggers the telemetry analyzer to confirm that the fingerprint has deviated from a fingerprint or cluster of fingerprints stored in the fingerprint database should be classified accordingly as benign or malicious; application associated with the fingerprint can be marked as blacklisted (defining the information), when the fingerprint classifier determines that the fingerprint is indicative (the security-critical software state) of a malicious, fraudulent, or harmful application; the fingerprint classifier can initiate an alert to notify an external system regarding the application and its classification).
Per claim 3, Gottschlich further suggests wherein the determining of the information about the security-critical software state is performed by the embedded device by an agent component (paragraphs [0050][0051]; application associated with the fingerprint can be marked as blacklisted when the fingerprint classifier determines that the fingerprint is indicative (the security-critical software state) of a malicious, fraudulent, or harmful application).
Per claim 4, Gottschlich in views of GALULA further suggests wherein the central monitoring unit is configured as a backend that is connected to several further embedded devices (Gottschlich, paragraphs [0080][0049]-[0052]; application associated with the fingerprint can be marked as blacklisted when the fingerprint classifier determines that the fingerprint is indicative of a malicious, fraudulent, or harmful application; the fingerprint classifier can initiate an alert to notify an external system (central monitor) regarding the application and its classification; GALULA, paragraphs [0027][0028]; embedded devices in a network); Singh further discloses wherein the central monitoring unit provides digital twins of the several further embedded devices (Fig. 5; paragraph [0085][0087]; a system level controller at a server; a digital twin is selected and assigned as a backup BBMD for a local BBMD device that is connected to a local subnet, the digital twin is a replica of a local BBMD device, so that upgrades and patches (e.g., operating system updates, security patches) can first be applied and tested on the digital twin before being applied to the actual local BBMD device).
Per claim 5, Gottschlich further suggests wherein the information about the security-critical software state provided for the central monitoring unit includes at least one of the following items of information: the identifier, information about an identity and/or enabled functions of the executed software, a result of comparing the identifier with at least one specification, a result of detecting the security-critical software state based on the comparison (paragraphs [0050]-[0052][0060]; application associated with the fingerprint can be marked as blacklisted when the fingerprint classifier determines that the fingerprint (identifier) is indicative of a malicious, fraudulent, or harmful application; the fingerprint classifier can initiate an alert to notify an external system regarding the application (information about an identity) and its classification (a result of detecting the security-critical software state); The fingerprint classifier compares the fingerprint to one or more cluster prototypes stored in the fingerprint database, distance(s) between a fingerprint and one or more fingerprint clusters can be formed into a classification vector (a result of comparing the identifier with at least one specification) used to classify the fingerprint as malicious or benign based on the classification of the closest cluster).
Per claim 6, Gottschlich further suggests wherein the ascertaining of the execution traces includes at least one of the following steps: ascertaining an access of the executed software to memory addresses of the embedded device, ascertaining a file access of the executed software on the embedded device, ascertaining an access to operating system resources of the executed software on the embedded device (paragraphs [0018][0049]; extract application behavioral fingerprints from hardware telemetry, such as central processing unit (CPU) telemetry or from operating system (OS) telemetry; the dynamic similarity vectors measure how similar a sample behaves to known applications, such as using process genealogy, file and registry accesses (ascertaining file access), network activities).
Per claim 7, Gottschlich further suggests ascertaining an imprint at the hardware or operating system level of the embedded device, the imprint resulting from a software package (paragraph [0018]; extract application behavioral fingerprints from hardware telemetry, such as central processing unit (CPU) telemetry or from operating system (OS) telemetry; Gottschlich does not explicitly the software package is an instrumented software package. However, (official notice), using an instrumented software package to generate application trace is a common practice in the field of the art, as evidenced in Harsha et al. (US PGPUB 2008/0301502, abstract)).
Per claim 8, GALULA further suggests wherein the identifier is specific to imprints from a predefined number of sequential execution steps of the software in order to determine the identifier as a stateful fingerprint (paragraph [0073]; a heuristic engine may detect anomalies based on at least one of the following models: detection of anomalous execution patterns (an execution of a specific sequence of programs (a predefined number of sequential execution steps))).
Claim 9 is rejected under similar rationales as claim 1.
Claim 10 is rejected under similar rationales as claim 1.
Claim 11 is rejected under similar rationales as claim 1.
Conclusion
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 HANG PAN whose telephone number is (571)270-7667. The examiner can normally be reached 9 AM to 5 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, Chat Do can be reached at 571-272-3721. 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.
/HANG PAN/Primary Examiner, Art Unit 2193