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 . In communications filed on 08/06/2025. Claims 1, 8, 13, and 15 are amended. Claims 2-4, 7, 9-11, 14, and 16-19 are cancelled. Claims 1, 5-6, 8, 12-13, 15, and 20-21 are pending in this examination.
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. This examination is in response to US Patent Application No. 17/095,884.
Information Disclosure Statement
The listing of references in the specification is not a proper information disclosure statement. In this application there is existing references in the specification (i.e. [0029]). 37 CFR 1.98(b) requires a list of all patents, publications, or other informationsubmitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
Examiner Note
Applicant’s amendment to claims 1, 8, and 15 below obviates previously raised Claims 1, 5-6, 8, 12-13, 15 and 20-21 35 U.S.C .12(b), and (112(a) rejection for limitation “entering in a reduced functionality mode (RFM)”, however examiner still maintains the 112(b) rejection for the limitation “an earlier version” (see section below: Claim Rejections - 35 USC § 112).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 5-6, 8, 12-13, 15 and 20-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
The term “an earlier version" in claims 1, 8, and 15 is a relative term which rendersthe claim indefinite. The term “"an earlier version"” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The language does not define a certainty and metes and bounds of the claim are unascertainable. Moreover, the term " an earlier version" is not defined by the claim, and the specification does not provide enough description for an earlier version.
Claims 5-6, 12-13, and 20-21 do not cure the deficiency of claims 1, 8, and 15 are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claims 1, 8, and 15.
Response to Arguments
Applicant's arguments filed 08/06/2025 have been fully considered but they are not persuasive:
Applicant submits on pages 13-15 of remarks filed on 08/06/2025 that at least "in response to detecting the update, entering in a reduced functionality mode (RFM) that disables functions related to interacting with the computing platform including performing event detection and taking security actions while enabling communicating with a digital security system service to receive updates or configurations to be compatible with the endpoint computing device having the computing platform with the update," as amended claim 1 recites, would not have been obvious in view of Zimmermann, Gassoway, and Xu. Therefore, for at least the reasons presented herein, amended claim 1 would not have been obvious in view of Zimmermann, Gassoway, and Xu. Accordingly, Applicant respectfully requests that the Office withdraw the § 103 rejection of claim 1.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 08/06/2025 on pages 13-15 of remarks.
While Zimmerman discloses: [ ¶13… “suppressing” binaries, as used herein, means refraining from sending one or more binaries, or data related thereto, to one or more host computing devices. Suppression, as used herein, can also include refraining from performing other actions involved with handling binary programs. Such additional actions may include, without limitation, testing actions, storing actions, processing/analyzing actions, loading actions, and/or any other suitable action that utilizes resources while handling binary programs], and [¶23, As will be described in more detail below with reference to the following figures, each of the host computing devices 102 may implement a security agent 108 (See e.g., FIG. 1B), which is a security software program that executes on the computing device 102. The security agent 108 may execute in the kernel mode of the computing device 102. During execution, the security agent 108 observes events, determines actions to take based on those events, and/or sends the events to the remote security system 104 for further processing and analysis], and [¶¶12-13, 15-17, 24, 35-36, 40, 72-75]
Furthermore, Gassoway discloses:
[¶¶32-35, Computer 202 may have two modes of operation, a normal mode and a safe mode. When computer 202 is operating in normal mode, detector 208 may detect any installation attempts and may automatically halt the installation of the software and deny the installation attempt. When computer 202 is operating in safe mode, detector 208 may be able to recognize that computer 202 is operating in safe mode and allow the installation of any software. When computer 202 is operating in normal mode, network interface 206 may be active and may allow an exchange of information between a network and computer 202. When computer 202 is operating in safe mode, network interface 206 may be disabled or otherwise isolated such that information may not pass between a network and computer 202. A user of computer 202 may transition from normal mode to safe mode by activating a reboot process 214. Reboot process 214 may reboot computer 202 into safe mode when computer 202 is operating in normal mode, or reboot process 214 may reboot computer 202 into normal mode when computer 202 is operating in safe mode. When computer 202 is booting into safe mode, detector 208 may recognize that computer 202 is in safe mode (disabling non-essential processes, loads Windows with minimal drivers and services) and may disable network interface 206, or may otherwise disable network communications. In alternative embodiments, detector 208 may not directly disable network communication but network communication may be disabled as part of the functions of reboot process 214. Once computer 202 has been booted into safe mode and network communication has been disabled, detector 208 no longer prohibits software installations and software may be installed on computer 202 by a user of computer 202. By rebooting computer 202 into safe mode. In particular embodiments, reboot process 214 may also reset a startup procedure. The startup procedure may be reset to prohibit a malicious program from automatically executing an installation program when computer 202 is rebooted into safe mode. In other embodiments, all automatic installations may be prohibited in safe mode and only manual installations requiring input from a user of computer 202 may be allowed. In another embodiment, a startup procedure for booting into safe mode may be hard-coded so that a rootkit installer cannot change it. FIG. 5 is a flowchart 700 illustrating a method of prohibiting remote installations of software on a computer 202. In step 702, a detector 208 may monitor computer 202 for an installation attempt. When an installation attempt has been detected, the detector determines whether or not computer 202 is in safe mode. If computer 202 is not in safe mode, the installation attempt may be rejected and a user of computer 202 may be notified of the installation attempt and be notified that in order to install software the user must reboot into safe mode. The user may reboot into safe mode at step 706. If computer 202 is in safe mode, either as determined at step 704 or as rebooted in step 706, then the software may be installed at step 708. Computer 202 may then be rebooted to normal mode at step 710].
Examiner respectfully disagrees with applicant argument for claims 8, and 15 filed on 08/06/2025 on pages 15-16 of remarks. Examiner response to claim 1 argument also applies to claims 8, and 15.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5-6, 8, 12-13, 15 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over (US2019/0065171) issued to Zimmermann, and in view of Gassoway (US2007/0079373), further and in view XU LAIGUANG et al. (CN113268366A) hereinafter referred to as XU.
Regarding claim 1, Zimmerman discloses a computer-implemented method performed by a security sensor deployed to an endpoint computing device, for preventing an unnecessary full-scale upgrade of the security sensor, the computer-implemented method comprising : detecting an update to a computing platform of the endpoint computing device, the endpoint computing device having an earlier version of the security sensor compatible with the computing platform before the update [¶6, FIG. 1B illustrates the example environment of FIG. 1A, showing that the example computing devices are configured to modify a binary program received from the remote security system in order to render the binary program loadable on (or compatible with) its OS kernel version( equated to preventing an unnecessary full-scale upgrade], and [¶16, According to various embodiments disclosed herein, binary modification on a host computing device may occur as follows. A host computing device that runs a particular OS kernel version may receive a binary program that is associated with a software upgrade. Prior to loading the binary program, however, the host computing device may access binary modification information to determine whether any modifications are to be applied to the binary program. If the accessed binary modification information indicates that one or more modifications are to be applied to the binary program, based on the particular OS kernel version, the modification(s) are applied to modify the binary program. The modified binary program is thereby rendered loadable by (or compatible with) the particular OS kernel version running on the host computing device, and the modified binary program is loaded by the particular OS kernel version], and [¶18, Although the type of software upgrades are often described herein, by way of example, to upgrading a security agent executing on a host computing device, it is to be appreciated that the techniques and systems may be applicable to other types of software (and/or firmware), such as non-security software and/or firmware. “Software” as used herein may include software, firmware, or a combination thereof. Furthermore, although OS kernel versions are often described herein with respect to a Linux OS, it is to be appreciated that the techniques and systems described herein may be applicable to other OS types, including Mac OS's, Windows OS's, and the like], and [¶24] The security agent 108 that runs on each of the computing devices 102 may be upgraded, as needed( equated to preventing an unnecessary full-scale upgrade), to provide the security agent 108 with the latest features and functionality, which may be useful for detecting malware attacks on the computing device 102….], and [¶¶12-13, 15, 17, 35-36, 40, 72-75]; and
receiving a configuration file having a compatibility mapping of versions of the security sensor to compatible computing platforms including an updated version of the security sensor built compatible with the computing platform with the update [ ¶17, ... For example, the remote security system need only test the representative binary programs that are sent to host computing devices instead of testing the entire set of binary programs (i.e., suppressed binaries need not be tested) ...], and [¶¶35-39, ... This is because the mappings in the binary modification information 128 may include mappings from each binary 110 in a subset to each of the OS kernel versions that correspond to the binaries 110 in the subset, and it may be wasteful (e.g., in terms of memory resources) to maintain mappings between a binary 110(1) and a particular OS kernel version if that particular OS kernel version is not associated with any of the binaries 110 in the subset with the binary 110(1)], and [ Claims 3-4, wherein the binary modification information comprises: a first mapping between the first binary program and the first OS kernel version, the first mapping having no associated modifications; and a second mapping between the first binary program and the second OS kernel version, the second mapping having associated therewith one or more modifications to be applied to the first binary program to render the first binary program loadable by the second OS kernel version. wherein the one or more modifications associated with the second mapping include a modification to overwrite identification data in the first binary program with different identification data, the different identification data being compatible with the second OS kernel version.], and [ see FIG. 2 and corresponding text for more details], and
in response to determining that the earlier version of the security sensor and the computing platform with the update are compatible based on the compatibility mapping; in response to determining that the earlier version of the security sensor and the computing platform with the update are not compatible based on the compatibility mapping:
[Abstract, a remote security system may generate multiple different binary programs for corresponding operating system (OS) kernel versions that are to receive a software upgrade. A suppression process may then compare code in the code sections between pairs of binary programs and may also compare the data in the data sections between the pairs of binary programs to identify subsets of “identical” binaries. The remote security system may send a representative binary (while suppressing the remaining binaries in a subset of identical binaries) to host computing devices that run different OS kernel versions. On the receiving end, a host computing device that runs a particular OS kernel version may receive a binary program, and prior to loading the binary program, modify the binary program to render the binary loadable by (or compatible with) the particular OS kernel version running on the host computing device], and [¶24, The security agent 108 that runs on each of the computing devices 102 may be upgraded, as needed, to provide the security agent 108 with the latest features and functionality, which may be useful for detecting malware attacks on the computing device 102. To deliver these upgrades, the remote security system 104 is configured to generate and send, to the host computing devices 102, binary programs 110 (sometimes shortened to “binaries” 110). A binary program 110 may, in some embodiments, include a driver corresponding to an upgrade to the security agent 108 software that is installed on the respective computing devices 102. An individual binary program 110 may correspond to a specific OS kernel version for which the binary 110 was generated/created. Thus, the driver of a particular binary program 110 may be configured to execute on host computing devices 102 that run a particular OS kernel version. In some embodiments, a binary 110 may include drivers and headers built from the original source code for a particular upgrade to the security agent 108], and [¶55, At 412, the binary comparator 120 may determine whether the first code in the code section 200(1) of the first binary program 110(1) matches second code in the code section 200(2) of the second binary program 110(2). If the same (or common) code is found in both of the code sections 200(1) and 200(2) of the respective binaries 110(1) and 110(2), the process 400 proceeds by following the “yes” route from block 412 to block 414, where data within the respective data sections 202 of the pair of binaries 110(1) and 110(2) is extracted and compared. For example, at block 414, the binary comparator 120 may compare first data extracted from the data section 202(1) of the first binary 110(1) to second data extracted from the data section 202(2) of the second binary 110(2).], and [¶56, At 416, the binary comparator 120 may determine whether at least a portion (e.g., some, but not all) of the first data in the data section 202(1) of the first binary program 110(1) matches at least a portion (e.g., some, but not all) of the second data in the data section 202(2) of the second binary program 110(2). Notably, the determination at block 416 recognizes that there may be some data that differs between the pair of binaries 110(1) and 110(2), such as data that is unique to a particular OS kernel version 300. However, other data in the respective data sections 202(1) and 202(2) may be the same (or common) between the pair of binaries 110(1) and 110(2), indicating functional equivalence between the pair of binaries 110(1) and 110(2) despite the existence of some differing data], and [ see FIGS 1A-B, 2-4 and corresponding text for more details], and [¶14, 35-39, claims 3-4].
In response to detecting an update entering in a reduced functionality mode RFM that disables functions related to interacting with the computing platform including performing event detection and taking security actions while enabling communicating with a digital security system service to receive updates or configurations to be compatible with the endpoint computing device having the computing platform with the update
While Zimmerman discloses [ ¶13… “suppressing” binaries, as used herein, means refraining from sending one or more binaries, or data related thereto, to one or more host computing devices. Suppression, as used herein, can also include refraining from performing other actions involved with handling binary programs. Such additional actions may include, without limitation, testing actions, storing actions, processing/analyzing actions, loading actions, and/or any other suitable action that utilizes resources while handling binary programs], and [¶23, As will be described in more detail below with reference to the following figures, each of the host computing devices 102 may implement a security agent 108 (See e.g., FIG. 1B), which is a security software program that executes on the computing device 102. The security agent 108 may execute in the kernel mode of the computing device 102. During execution, the security agent 108 observes events, determines actions to take based on those events, and/or sends the events to the remote security system 104 for further processing and analysis], and [¶¶12-13, 15-17, 24, 35-36, 40, 72-75]
Furthermore, Gassoway discloses:
[¶¶32-35, Computer 202 may have two modes of operation, a normal mode and a safe mode. When computer 202 is operating in normal mode, detector 208 may detect any installation attempts and may automatically halt the installation of the software and deny the installation attempt. When computer 202 is operating in safe mode, detector 208 may be able to recognize that computer 202 is operating in safe mode and allow the installation of any software. When computer 202 is operating in normal mode, network interface 206 may be active and may allow an exchange of information between a network and computer 202. When computer 202 is operating in safe mode, network interface 206 may be disabled or otherwise isolated such that information may not pass between a network and computer 202. A user of computer 202 may transition from normal mode to safe mode by activating a reboot process 214. Reboot process 214 may reboot computer 202 into safe mode when computer 202 is operating in normal mode, or reboot process 214 may reboot computer 202 into normal mode when computer 202 is operating in safe mode. When computer 202 is booting into safe mode, detector 208 may recognize that computer 202 is in safe mode (disabling non-essential processes, loads Windows with minimal drivers and services) and may disable network interface 206, or may otherwise disable network communications. In alternative embodiments, detector 208 may not directly disable network communication but network communication may be disabled as part of the functions of reboot process 214. Once computer 202 has been booted into safe mode and network communication has been disabled, detector 208 no longer prohibits software installations and software may be installed on computer 202 by a user of computer 202. By rebooting computer 202 into safe mode. In particular embodiments, reboot process 214 may also reset a startup procedure. The startup procedure may be reset to prohibit a malicious program from automatically executing an installation program when computer 202 is rebooted into safe mode. In other embodiments, all automatic installations may be prohibited in safe mode and only manual installations requiring input from a user of computer 202 may be allowed. In another embodiment, a startup procedure for booting into safe mode may be hard-coded so that a rootkit installer cannot change it. FIG. 5 is a flowchart 700 illustrating a method of prohibiting remote installations of software on a computer 202. In step 702, a detector 208 may monitor computer 202 for an installation attempt. When an installation attempt has been detected, the detector determines whether or not computer 202 is in safe mode. If computer 202 is not in safe mode, the installation attempt may be rejected and a user of computer 202 may be notified of the installation attempt and be notified that in order to install software the user must reboot into safe mode. The user may reboot into safe mode at step 706. If computer 202 is in safe mode, either as determined at step 704 or as rebooted in step 706, then the software may be installed at step 708. Computer 202 may then be rebooted to normal mode at step 710].
remaining in the RFM until receiving the updated version of the security sensor built compatible with the computing platform with the update,
in response to receiving the updated version, updating the security sensor with the updated version,
exiting the RFM, and performing the event detection and taking the security actions associated with the computing platform with the update by utilizing the updated version of the security sensor
exiting the RFM, resuming to perform the event detection and take the security actions associated with the computing platform with the update by continuing to utilize the earlier version of the security sensor.
[ 0033] A user of computer 202 may transition from normal mode to safe mode by activating a reboot process 214. Reboot process 214 may reboot computer 202 into safe mode when computer 202 is operating in normal mode, or reboot process 214 may reboot computer 202 into normal mode when computer 202 is operating in safe mode. When computer 202 is booting into safe mode, detector 208 may recognize that computer 202 is in safe mode (disabling non-essential processes) and may disable network interface 206 or may otherwise disable network communications. In alternative embodiments, detector 208 may not directly disable network communication but network communication may be disabled as part of the functions of reboot process 214. Once computer 202 has been booted into safe mode and network communication has been disabled, detector 208 no longer prohibits software installations and software may be installed on computer 202 by a user of computer 202. By rebooting computer 202 into safe mode
[0035] FIG. 5 is a flowchart 700 illustrating a method of prohibiting remote installations of software on a computer 202. In step 702, a detector 208 may monitor computer 202 for an installation attempt. When an installation attempt has been detected, the detector determines whether or not computer 202 is in safe mode. If computer 202 is not in safe mode, the installation attempt may be rejected and a user of computer 202 may be notified of the installation attempt and be notified that in order to install software the user must reboot into safe mode. The user may reboot into safe mode at step 706. If computer 202 is in safe mode, either as determined at step 704 or as rebooted in step 706, then the software may be installed at step 708. Computer 202 may then be rebooted to normal mode at step 710].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Zimmermann, by incorporating “by operating a computer in normal mode and safe mode”, as taught by Gassoway. One could have been motivated to do so in order to transition a computer from normal mode to safe mode by activating a reboot process and disabling non-essential processes, and disable network interface, or may otherwise disable network communications. [ Gassoway, ¶¶ 32-35].
Zimmerman, and Gassoway,do not explicitly disclose, however,, Xu discloses refraining from receiving the updated version of the security sensor, retaining the earlier version of the security,
[page 9, 2nd paragraph, Fig. 3 shows an example of state transition in the fault-tolerant mechanism. The fault tolerance mechanism can have the following 4 states as shown in the figure:
1，NEW: the initial state of the downloaded new kernel;
2，LOADED: Loaded but not running;
3，RUNNING: running;
4，INVALID: The operation failed. This state is a final state. The new kernel with this state will no longer be loaded.
Specifically, when the new kernel is loaded in the physical memory in step S220, when the startup parameters of the new kernel can be set, a flag string, such as “kernel_patched=1”, can be added to it. Here, the kernel startup parameters can refer to the parameters when the Linux kernel is started and are used to set some parameters of the kernel, which can be viewed through /proc/cmdline after startup. Then, after starting and running the new kernel in step S230, the kernel startup parameters are checked to see if they contain a flag string. If the kernel parameter contains a flag string: it means that the new kernel starts normally, in this case, change the status to RUNNING; if the kernel parameter does not contain a flag string: it means that the new kernel failed to start, and the old kernel was started after the system restarted. In this case, change the status to INVALID].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Zimmermann, and Gassoway by incorporating “refraining from receiving the updated”, as taught by XU. One could have been motivated to do so in order to start the old kernel as the new kernel fails and the kernel parameter contains no flag string [ XU, Pages 1625-1630].
Regarding claims 5, 12, and 20, wherein the configuration file is in form of one of: a text -based file, a serialized file, or a binary file.
Zimmermann discloses this limitation as: [ ¶74, Applying the modification(s) 302 at block 610 may include modifying the binary program 110(1) to include identification data that is compatible with the particular OS kernel version 300(2) running on the host computing device 102(2). The modification(s) applied to the binary 110(1) may “patch up” the binary by making changes (e.g., overwriting) a certain part(s) of the object code of the binary 110(1). In an example, the binary modifier 138 may overwrite the CRC (or some other identification data, or fingerprint) in the received binary 110(1) with a CRC that is compatible with the OS kernel version 300(2) running on the host computing device 102(2) …].
Regarding claims 6, 13 and 21, Zimmermann discloses wherein the configuration file comprises a mapping of the updated operating system kernel with a plurality of deployed security sensors indicating that the plurality of deployed security sensors is compatible with the updated operating system kernel [ Claims 3-4, wherein the binary modification information comprises: a first mapping between the first binary program and the first OS kernel version, the first mapping having no associated modifications; and a second mapping between the first binary program and the second OS kernel version, the second mapping having associated therewith one or more modifications to be applied to the first binary program to render the first binary program loadable by the second OS kernel version. wherein the one or more modifications associated with the second mapping include a modification to overwrite identification data in the first binary program with different identification data, the different identification data being compatible with the second OS kernel version.], and [¶¶35-39], and [ see FIG. 2 and corresponding text for more details].
Regarding claims 8, and 15, this claim is interpreted and rejected for the same rational set forth in claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
HSU (US2009/0077664) [ Abstract, A method for combating malware monitors all attempts by any software executing on a computer to write data to the computer's digital storage medium and records details of the attempts in a system database having a causal tree structure. The method also intercepts unauthorized attempts by executing objects to modify the memory allocated to other executing objects or to modify a selected set of protected objects stored on the digital storage medium, and may also intercept write attempts by executing objects that have a buffer overflow or that are executing in a data segment of memory. The method may include a procedure for switching the computer into a quasi-safe mode that disables all non-essential processes. Preferably, the database is automatically organized into software packages classified by malware threat level. Entire or packages or portions thereof may be easily selected and neutralized by a local or remote user].
Mawari (US2023/0045256) [0075] If each of the retrieved version numbers matches the stored version number, then the vehicle computer 110 can verify that the respective ECUs 114 in the second set 150 of ECUs 114 includes the updated program instructions. Upon verifying that the respective ECUs 114 in the second set 150 of ECUs 114 includes the updated program instructions, the vehicle computer 110 disables the safe mode, i.e., transitions the safe mode from the enabled state to the disabled state. That is, the vehicle computer 110 can actuate one or more vehicle components to move the vehicle 105 based on the respective ECUs 114 in the second set 150 of ECUs 114 operating according to the updated program instructions. The vehicle computer 110 may output a message, e.g., via the HMI, indicating that the installation of the updated program instructions was successful. [0078] If the vehicle computer 110 determines that the third collective status of the ECUs 114 in the second set 150 of ECUs 114 is “reinstalled”, then the vehicle computer 110 can verify that the respective ECUs 114 in the second set 150 of ECUs 114 includes the current program instructions. In this situation, the vehicle computer 110 can disable the safe mode, i.e., transition the safe mode from the enabled state to the disabled state. That is, the vehicle computer 110 can actuate one or more vehicle components to move the vehicle 105 based on the respective ECUs 114 in the second set 150 of ECUs 114 operating according to the current program instructions].
Polar (US10430263) [ Abstract, Apparatuses, systems, and method for validating and upgrading firmware in an intelligent electronic device (IED) are provided. In one aspect of the present disclosure, an IED is provided including at least one processor and at least one memory. The at least one memory includes at least a first firmware and a second firmware, where the second firmware is a version of the first firmware. The at least one processor determines if there is an error associated with the first firmware. If the processor determines there is no error associated with the first firmware, the processor executes first firmware. If the processor determines there is an error associated with the at least one firmware, the processor executes the second firmware].
Roth (US2006/0053272) [ 0046] As one of ordinary skill in the art will appreciate from FIG. 3, a program embodiment provides a kernel configuration mechanism which has the ability to save a backup of a system's kernel configuration prior to a kernel configuration change being applied, thus affording the ability to reverse the change if it should prove undesirable. Each time the system boots, the system administrator will be queried as to whether a kernel configuration backup is desired. However, once a system administrator sets an indicator (e.g., sets a -B flag in the kernel configuration command line) representing an intention to have automatic saving of backup kernel configurations on the system prior to a kernel configuration change, the backups will be made automatically during each subsequent kernel configuration change].
Bashev (US2020/0401415) [ [0004] A kernel is the central part of an operating system providing to applications a coordinated access to computer resources, such as processor time, memory, external hardware, and input and output peripherals. A kernel typically provides file system and network protocol services. A microkernel (μ-kernel) is an operating system kernel with a minimal set of functions].
Handal (US7076770) [ Abstract, A method and an apparatus for adapting for a kernel on a target system a compiled kernel module corresponding to another kernel version which is different from the kernel on the target system are provided. A kernel analyzer extracts from the kernel on the target system an error check measure and a kernel version identification. A module adaptation component inserts in the compiled kernel module an error check parameter corresponding to the error check measure extracted by the kernel analyzer from the kernel on the target system, and replaces a version identification in the compiled kernel module with the kernel version identification extracted by the kernel analyzer from the kernel on the target system].
CN111966383 [The invention claims an operation system kernel compatibility quantization analysis method, system and medium, the invention comprises: obtaining initial version V1 and updating version V2 obtained by compiling the Linux operation system kernel; dividing the kernel module into original version unique; updating version unique, there are three types; determining the compatible rate of the unique kernel module is 0, calculating the corresponding compatible rate MCP according to the difference according to the common kernel module, obtaining the compatible rate MCP [i] of any common kernel module i. The invention is capable of performing full module compiling to the Linux operating system kernel initial version V1 and updating version V2 through comparing module number before and after updating the kernel module version, module, module interface function difference and data difference; giving the quantization result of compatibility between kernel versions; by quantitatively analyzing the compatibility degree between the kernel versions, ensuring the controllability of the kernel upgrade].
Hadal (US7076770) [ Apparatus and Method for Modifying a Kernel Module to Run on Multiple Kernel Versions].
Braemer (US2015/0120809) [ Embodiments relate to management of processes in a computer system, and in particular to an automated process for implementing a kernel change].
Gehtman (US2022/0027484) [ FIG. 4C illustrates an example of utilizing a security agent with a kernel of an operating system].
Stoker (US10747875) [ claims, identifying, at the kernel security module, a script received at the kernel security module for requested execution by the operating system kernel].
WO2017182089A1) [claims: A method for implementing trusted computing, comprising: executing a security module (320) within an operating system kernel (310), wherein the operating system kernel (310) is configured to enforce isolation between kernel applications and user applications; and creating a restricted access area (350) within a storage device (210, 340) in a computing device (200, 330), the created restricted access area (350) being accessible by the security module (320) being executed within the operating system kernel (310)].
(PH 12014500756 B1) [ Fourier Transform and other similar signal processing algorithms known to those skilled in the art of audio and/or pattern recognition. Further, instead of using markers for determination, entire audio clip segments (also known as binary large objects or BLOB) may also be compared to a reference BLOB for pattern recognition and timing comparison, hence, latency determination].
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496