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 .
Response to Arguments
On pg. 7, applicant responds with respect to the interpretation of claims 1-7 under 35 U.S.C. § 112(f) raised in the previous Office action mailed 05/22/2026, as follows:
“Applicant acknowledges the Office Action’s interpretation under 35 U.S.C. § 112(f).”
Applicant amended claim 1 by replacing the “detector” and “countermeasure execution unit” with a network interface, a memory storing instructions, and a processor configured to execute the recited operations. Applicant also amended claim 7 by replacing the “information output unit” with a processor configured to output the recited information via a user interface. Accordingly, the functional “unit” language upon which the previous interpretation was based is no longer recited in the amended claims. The examiner no longer invokes 35 U.S.C. § 112(f) on any of the pending claims as presently presented.
On pg. 7, applicant argues with respect to the rejection of claims 8-9 under 35 U.S.C. § 112(a) raised in the previous Office action mailed 05/22/2026, as follows:
“The Office Action rejected claims 8 and 9 under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. Without conceding the propriety of the rejections and in an effort to advance prosecution, claims 8 and 9 are amended in a manner believed to comply with the written description requirement. Accordingly, Applicant respectfully requests that the rejections of claims 8 and 9 under 35 U.S.C. § 112(a) be withdrawn.”
Examiner is persuaded by applicant’s argument and hereby withdraws the rejection of claims 8-9 under 35 U.S.C. § 112(a). Applicant amended claims 8 and 9 to claim the disclosed species of detecting malware by transmitting DNS query packets, receiving corresponding DNS response packets, counting name resolution errors during a detection period, and comparing the number of name resolution errors with a threshold. Applicant further amended claims 8 and 9 to require rebooting the electronic apparatus and performing at least one of the recited protective operations after reboot.
On pg. 8-9, applicant argues with respect to the rejection of claims 1-9 under 35 U.S.C. § 103 raised in the previous Office action mailed 05/22/2026, as follows:
“The Office Action rejected claims 1-4 and 6-9 under 35 U.S.C. § 103 as being unpatentable over Xu (US 9,917,852) in view of Ancona (US 8,931,074). Claim 5 was rejected over Xu in view of Ancona, and further in view of Winn (US 2013/0185795).
Without conceding the propriety of the rejections and in an effort to advance prosecution, independent claim 1 is amended to recite, in part:
transmit, via the network interface, Domain Name System (DNS) query packets;
receive, via the network interface, DNS response packets corresponding to the DNS query packets;
count a number of name resolution errors indicated by the DNS response packets received during a detection period;
determine that malware has intruded into the electronic apparatus when the number of name resolution errors is greater than or equal to a threshold;
after the electronic apparatus reboots, perform at least one of the following operations:
(1) change the detection period to a period longer than the detection period used to make the determination;
(2) change the threshold to a value smaller than the threshold used to make the determination;
(3) block transmission of packets destined for Transmission Control Protocol (TCP) port 53 or User Datagram Protocol (UDP) port 53;
(4) disable wireless communication; or
(5) disable wired communication.
(Emphasis added; see ¶ [0025]-[0031] of the specification as originally filed.) Xu, Ancona, and Winn fail to teach or suggest at least the above-recited features of independent claim 1.
Xu is related to detection of malware-related behavior through DNS monitoring, and discloses a security device 102 (e.g., a firewall 118) that monitors DNS protocol network communications and receives passive Domain Name System (DNS) data comprising a plurality of DNS responses. Xu applies a signature to the passive DNS data to detect Domain Generation Algorithm (DGA) behavior, including parsing DNS responses to determine whether one or more responses correspond to a non-existent domain (NXDOMAIN) response. In other words, Xu discloses a security device that receives passive DNS data, applies a signature, and parses DNS responses for NXDOMAIN responses but nowhere discloses transmitting DNS query packets. Since the above-recited features are all related to the DNS query packets, Xu fails to teach or suggest at least the above-recited features of independent claim 1.
Ancona and Winn were not relied upon by the Office Action to cure the deficiencies of Xu. Thus, Xu, Ancona, and Winn, whether considered alone or in combination, fail to teach or suggest every element of independent claim 1. Therefore, Applicant respectfully submits that independent claim 1 is patentable.
Independent claims 8 and 9 include recitations similar to the above-recited features of independent claim 1. Therefore, Applicant respectfully submits that independent claims 8 and 9 are also patentable over Xu, Ancona, and Winn for reasons similar to those set forth above with respect to independent claim 1.
Claims 2-7 depend from independent claim 1. Therefore, Applicant respectfully submits that these dependent claims are also patentable over Xu, Ancona, and Winn for at least the same reasons set forth above with respect to independent claim 1.
Accordingly, Applicant respectfully requests that the rejections of claims 1-9 under 35 U.S.C. § 103 be withdrawn.”
Applicant’s arguments with respect to the rejections of claims 1-9 under 35 U.S.C. § 103 have been fully considered and are persuasive in light of recent amendments. The examiner agrees that the rejection as previously formulated does not adequately address all limitations added to independent claims 1, 8, and 9, including transmitting DNS query packets and performing at least one of the specifically recited protective operations after reboot. Therefore, the rejections over Xu in view of Ancona, and Xu in view of Ancona and further in view of Winn, are withdrawn. However, upon further consideration, new grounds of rejection are made in view of the amended claim language and newly found prior art.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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, 6, and 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Roh et al, (U.S. Pub No. 2021/019,4892 A1, hereinafter Roh) in view of Sella et al (U.S. Pub. No. 2020/002,6852 A1, hereinafter Sella).
As to claim 1, Roh teaches:
An electronic apparatus comprising: a network interface; (see Roh, [¶¶0013, 0048]: “According to an exemplary embodiment, a computer device may include a processor and a memory storing a computer program configured to be executed by the processor. Further, if it is necessary for the processor of the computer to communicate with any computer or server located in a remote place to execute the functions, the code may further include a communication related code about how communication is performed with any computer or server located in a remote place using a communication module of the computer and whether to transmit and receive any information or media upon communication.”);
(Roh’s computer device constitutes the claimed electronic apparatus, and its communication module provides the network interface used to transmit and receive information.)
a memory storing instructions; and a processor configured to execute the instructions to: (see Roh, [¶¶0013, 0047]: “According to an exemplary embodiment, a computer device may include a processor and a memory storing a computer program configured to be executed by the processor. The malware detection method and the method for detecting the DGA according to the specification may be implemented in the form of a computer program, which is written to perform the respective operations and is stored in a computer-readable storage medium.”);
(Roh provides a memory storing a computer program and a processor configured to execute that program to perform the disclosed malware detection operations.)
transmit, via the network interface, Domain Name System (DNS) query packets; (see Roh, [¶¶0025, 0033]: “The monitoring (S100) of the DNS query requests/replies for all the processes may include monitoring a query request for a domain name about which a PC inquires of a DNS server and a result of validity for the query request. The infected PC 200 may transmit a random domain address generated by the DGA to a DNS server 400.”);
(Roh’s PC transmits DGA generated DNS query requests to a DNS server through the computer’s communication module.)
receive, via the network interface, DNS response packets corresponding to the DNS query packets; (see Roh, [¶¶0025, 0033]: “In operation S100, a DNS query request/reply for each process may be monitored to determine whether there is malware. The DNS server 400 may transmit a reply to whether a corresponding DNS query request succeeds or fails to the PC 200.”);
(Roh’s same PC receives success or failure DNS replies corresponding to its transmitted DNS queries.)
count a number of name resolution errors indicated by the DNS response packets received during a detection period; (see Roh, [¶¶0026-0027, 0034]: “The determining (S200) of the malware based on the number of times of failure DNS queries per unit process may be to determine malware depending to whether a specific process requests a DNS query, which failed, over a specified number of times during a specified time. A failure DNS query request count, which is a reference value for determining malware, may be determined based on whether it is performed over a predetermined number of times with a predetermined reference time. A malware determination module 300 according to the present invention may determine cases where a DNS failure reply is greater than or equal to the unit number of times per unit time for each unit process as malware.”);
(Roh counts failed DNS resolutions indicated by DNS failure replies within a specified or predetermined period.)
determine that malware has intruded into the electronic apparatus when the number of name resolution errors is greater than or equal to a threshold; (see Roh, [¶¶0026, 0033-0034]: “The determining (S200) of the malware based on the number of times of failure DNS queries per unit process may be to determine malware depending to whether a specific process requests a DNS query, which failed, over a specified number of times during a specified time. The infected PC 200 may transmit a random domain address generated by the DGA to a DNS server 400. A malware determination module 300 according to the present invention may determine cases where a DNS failure reply is greater than or equal to the unit number of times per unit time for each unit process as malware.”);
(Roh determines that malware is present in the infected PC when its number of DNS failure replies equals or exceeds the applicable threshold.)
Roh does not teach, but Sella teaches:
in response to determining that the malware has intruded into the electronic apparatus, reboot the electronic apparatus; (see Sella, [¶¶0025-0026, 0037]: “In one embodiment, a malicious actor can infiltrate the control system 205 by uploading malicious code into transitory memory in the computing units 210. Put differently, in one embodiment, forcing the computing units 210 to reboot deletes any malicious code that may have been stored in the transitory memory of the computing units 210. The boot controller 450 may be protected or secure so that the control system 415 can guarantee that the reset signal 410 results in one or more of the ECUs 420 rebooting to prevent wireless access to the control system 415, or to remove malicious code.”);
(Sella reboots a compromised computing unit to remove malicious code. In the proposed combination, Roh’s threshold based malware determination triggers Sella’s reboot countermeasure.)
and after the electronic apparatus reboots, perform at least one of the following operations: (1) change the detection period to a period longer than the detection period used to make the determination; (2) change the threshold to a value smaller than the threshold used to make the determination; (3) block transmission of packets destined for Transmission Control Protocol (TCP) port 53 or User Datagram Protocol (UDP) port 53; (4) disable wireless communication; or (5) disable wired communication. (see Sella, [¶¶0033-0034, 0048]: “However, for other threat levels, the wireless interface or interfaces remain deactivated after rebooting the host computing unit. If the wireless interface should remain inactive, the method 300 proceeds to block 320 where the control system instructs the computing unit with the wireless interface to deactivate the interface after rebooting. At block 540, the boot controller resets the ECUs with the wireless interfaces using a special reboot to deactivate the wireless interface after the reboot is complete. That is, unlike in a normal reboot where the functions hosted by the ECUs are restarted or activated, here the boot controller provides an instruction to the ECUs to not reactivate the wireless interfaces after being rebooted.”);
(Sella expressly teaches claimed option (4): disabling wireless communication after reboot by preventing the wireless interface from being reactivated.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to modify Roh’s computer-based malware detection system, which detects malware from DNS failure replies exceeding a threshold during a detection period, to incorporate Sella’s technique of rebooting a compromised computing device and maintaining its wireless interface in a disabled state after reboot. Roh already isolates or blocks a process determined to be malware, while Sella teaches that rebooting removes malicious code from transitory memory and that keeping the wireless interface disabled prevents renewed exploitation. A person of ordinary skill would have been motivated to apply Sella’s known countermeasure upon Roh’s malware determination to remove the detected malware and prevent further malicious communication, producing the predictable result of a more secure electronic apparatus.
As to claim 6,
Sella teaches:
wherein the processor is further configured to execute the instructions to: receive, after the electronic apparatus reboots, an instruction from a user to perform the at least one operation; (see Sella, [¶¶0048, 0050]: “At block 540, the boot controller resets the ECUs with the wireless interfaces using a special reboot to deactivate the wireless interface after the reboot is complete. At block 550, the control system informs the user when the wireless interfaces are reactivated. Nonetheless, if desired, the user can then use the actuator or a touch panel to instruct the control system to keep the wireless interfaces in a disabled state.”);
(Sella reboots the apparatus, subsequently informs the user of the interface status, and then receives a user instruction through an actuator or touch panel to maintain the protective operation.)
and perform the at least one operation in response to receiving the instruction. (see Sella, [¶¶0031-0032, 0050]: “In response to the threat level provided by the user interface, the control system identifies at least one predefined action to take. In another example, the predefined actions may include deactivating the wireless interface (which can be done with or without rebooting the computing unit hosting the wireless interface). Nonetheless, if desired, the user can then use the actuator or a touch panel to instruct the control system to keep the wireless interfaces in a disabled state.”);
(Sella performs the selected protective action maintaining the wireless interface in a disabled state in response to the user instruction.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to configure Roh’s DNS based malware detection apparatus, as modified by Sella, to receive a post-reboot user instruction to maintain the selected protective operation. Sella teaches allowing the user to keep the communication interface disabled after being informed of its post reboot status. A person of ordinary skill would have been motivated to provide this control so that the user could preserve network isolation when suspicious behavior continued following reboot. The combination would predictably receive the post reboot instruction and maintain the selected interface disabling operation in response.
As to claim 8,
Roh teaches:
A control method for an electronic apparatus, comprising: (see Roh, [¶¶0011]: “According to an exemplary embodiment, a malware detection method performed in a computer may include monitoring, by a processor of the computer, domain name system (DNS) query requests for all processes and replies to the query requests and counting, by the processor, the number of times of failure DNS query requests per unit process and determining, by the processor, malware.”);
(Roh’s computer implemented malware detection method constitutes a control method performed by an electronic apparatus.)
Claim 8 recites substantially the same limitations as claim 1 in method form. Accordingly, claim 8 is rejected for the same reasons set forth above with respect to claim 1.
As to claim 9,
Roh teaches:
(Currently amended) A non-transitory computer-readable storage medium storing a program, the program causing a computer of an electronic apparatus to execute: (see Roh, [¶¶0047-0049]: “The malware detection method and the method for detecting the DGA according to the specification may be implemented in the form of a computer program, which is written to perform the respective operations and is stored in a computer-readable storage medium. For the computer to read the program and execute the methods implemented with the program, the above-mentioned program may include a code coded into a computer language such as C/C++, C#, JAVA, Python, or a machine language readable through a device interface of the computer by a processor (CPU) of the computer. The medium may refer to a device-readable medium which stores data on a semipermanent basis rather than a medium, such as a register, a cache, or a memory, which stores data during a short moment.”);
(Roh stores executable program instructions in a non-transitory computer-readable medium and causes the computer’s processor to execute the disclosed malware-detection method.)
Claim 9 recites substantially the same limitations as claim 1 in non-transitory computer-readable-storage-medium form. Accordingly, claim 9 is rejected for the same reasons set forth above with respect to claim 1.
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Roh et al, (U.S. Pub No. 2021/019,4892 A1, hereinafter Roh) in view of Sella et al (U.S. Pub. No. 2020/002,6852 A1, hereinafter Sella) and in further view of Aziz et al (U.S. Pub. No. 2013/003,6472 A1, hereinafter Aziz).
As to claim 2,
Aziz teaches:
wherein the at least one operation includes changing the detection period to a period longer than the detection period used to make the determination. (see Aziz, [¶¶0079, 0082]: “For example, the traffic analysis device 135 may detect a number of IP address scans, or a number of network communications to an invalid IP address, occurring within a predetermined period. The traffic analysis device 135 may analyze communication traffic in the communication network 130 for a predetermined period. For example, the predetermined period can be a number of seconds, minutes, hours, or days. In this way, the traffic analysis device 135 can detect slow propagating computer worms as well as fast propagating computer worms in the communication network 130.”);
(Aziz teaches selecting different detection period lengths according to malware propagation speed, including longer periods of hours or days for detecting slow propagating worms. In the proposed combination, Roh’s configurable detection period is changed to a longer period after Sella’s malware-remediation reboot to improve detection of slow or lingering malware activity.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to modify Roh’s configurable malware detection period, following Sella’s reboot, according to Aziz’s selectable detection period lengths. Aziz recognizes the monitoring period as a result effective variable and teaches using periods ranging from seconds to days to detect both fast and slow propagating worms. A person of ordinary skill would have selected a longer post reboot period to detect slower or lingering malware activity that might not generate enough failures during the shorter period, with the predictable result of increasing detection sensitivity to such activity.
As to claim 3,
Aziz teaches:
wherein the at least one operation includes changing the detection period to a period longer than the detection period used to make the determination. (see Aziz, [¶¶0079-0080]: “The traffic analysis device 135 determines whether the sequence of network communications is characteristic of a computer worm by comparing the number of IP address scans or the number of network communications in the sequence to a heuristics threshold (e.g., one thousand IP address scans per second). The traffic analysis device 135 may lower typical heuristics thresholds of these heuristic techniques to increase the rate of computer worm detection, which can also increase the rate of false positive computer worm detection by the traffic analysis device 135.”);
(Aziz expressly teaches lowering a previously used malware detection threshold to increase the rate of computer worm detection. In the proposed combination, Roh’s configurable threshold is changed to a smaller value after Sella’s malware-remediation reboot.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to lower Roh’s configurable detection threshold following Sella’s malware remediation reboot, as taught by Aziz, to increase sensitivity to continued or recurring malware activity. This modification would predictably increase the malware detection rate, as expressly recognized by Aziz.
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Roh et al, (U.S. Pub No. 2021/019,4892 A1, hereinafter Roh) in view of Sella et al (U.S. Pub. No. 2020/002,6852 A1, hereinafter Sella) and in further view of Zaheer et al (U.S. Pub. No. 2006/017,4342 A1, hereinafter Zaheer).
As to claim 4,
Zaheer teaches:
wherein the at least one operation includes blocking transmission of packets destined for TCP port 53 or UDP port 53. (see Zaheer, [¶¶0018, 0020]: “Yet other techniques perform blocking using protocol ports (e.g., SMTP port 25 for TCP or DNS port 53 for UDP). The filtering module 24 allows a user to shut down (or filter) particular protocol ports during a cyber attack. A network administrator may use the filtering module 24 to block a particular protocol port (e.g., SMTP port 25), stopping any traffic on that port, while keeping other protocol ports open.”);
(Zaheer expressly identifies DNS port 53 for UDP as a protocol port subject to blocking and teaches stopping traffic on a selected protocol port. Because the limitation is disjunctive, Zaheer’s UDP port 53 disclosure satisfies the limitation.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Roh’s DNS based malware detection apparatus, as modified by Sella’s post reboot protection technique, to incorporate Zaheer’s technique of blocking traffic on DNS port 53 during a cyberattack. Roh identifies DNS queries and name resolution error responses as evidence of malware activity, while Zaheer teaches selectively blocking DNS port 53 to stop DNS traffic without blocking traffic on other protocol ports. A person of ordinary skill would have been motivated to apply Zaheer’s targeted filtering after Sella’s reboot to prevent continued malicious DNS communications while preserving other network functionality. The combination would predictably cause the electronic apparatus, after rebooting, to block transmission of packets destined for UDP port 53.
As to claim 5,
Zaheer teaches:
wherein the network interface is configured to perform wireless communication and wired communication, (see Zaheer, [¶¶0026, 0028]: “Thus, a user or the infected device cannot reconnect to the network 16 (e.g., through a wireless connection or at another physical port). Devices at the access layer include end points and connect into a physical port of the network 130 using, for example, an Ethernet card and either wired or wireless connection technology.”);
(Zaheer recognizes endpoint network access through wireless and physical wired connections. Providing an apparatus with both known connection types would have been a predictable network interface configuration.)
and the processor is further configured to execute the instructions to: determine which of the wireless communication and the wired communication was used to transmit a DNS query packet corresponding to a DNS response packet indicating a name resolution error; (see Zaheer, [¶¶0022-0023]: “If the port manager module 22 is in an active state, the port manager module 22 locates (108) the physical port to which the device associated with the suspect IP address is connected. Each router maintains a routing table, which maps IP addresses to the physical ports of the router. When the CAM CC application 20 reaches a switch that shows the device as directly connected and does not provide reference to another switch, the CAM CC application 20 has found the interface that needs to be disabled.”);
(Zaheer determines the particular interface carrying traffic associated with a detected threat. In the proposed combination, the detected traffic is Roh’s DNS query corresponding to the name resolution error response.)
and after the electronic apparatus reboots, disable only the determined one of the wireless communication and the wired communication. (see Zaheer, [¶¶0010, 0024]: “Logical segments of the network can be created so that only particular portions of the network can be shut down. The port manager module 22 instructs switch 124 to block traffic on physical port 23 of the switch 124, which isolates the infected device 126 from the network 16.”);
(Zaheer selectively disables the identified interface while leaving unaffected network portions operational. Sella supplies the requirement that the selected interface remains disabled after reboot.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Roh’s DNS based malware detection apparatus, as modified by Sella’s post-reboot protection technique, to incorporate Zaheer’s technique of identifying the interface associated with detected malicious traffic and selectively disabling that interface. Roh identifies the DNS query and corresponding name resolution error response indicating malware activity, Sella teaches disabling an attack related communication interface after reboot, and Zaheer teaches locating and disabling the particular interface associated with a detected threat. A person of ordinary skill would have been motivated to disable only the interface carrying the suspicious DNS traffic to close the identified attack path while preserving communication through the unaffected interface. The combination would predictably determine whether the suspicious DNS query was transmitted through the wired or wireless connection and, after rebooting, disable only that determined connection.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Roh et al, (U.S. Pub No. 2021/019,4892 A1, hereinafter Roh) in view of Sella et al (U.S. Pub. No. 2020/002,6852 A1, hereinafter Sella) and in further view of Curtis et al (U.S. Pub. No. 2012/021,0434 A1, hereinafter Curtis).
As to claim 7,
Curtis teaches: further comprising: a user interface, wherein an information output unit the processor is further configured to execute the instructions to output, via the user interface, information indicating a demerit of associated with each of change items in the setting change the operations. (see Curtis, [¶¶0028, 0032, 0040-0041]: “A user interface (typically web-based) provides the interface for a user to operate one or more aspects of the platform, from scanning the network to finding vulnerabilities, to selecting countermeasures(s) and providing reports. Preferably, the information identifies (i) an expected cost of implementing the discovered countermeasure, (ii) an expected effectiveness of implementing the discovered countermeasure, and (iii) an indication of whether the discovered countermeasure is available in the computing environment. Each countermeasure is associated with a display of its effectiveness and cost. It may also include opportunity cost of other projects that are not advanced as a result as well as the potential operational impact of deploying the countermeasure (e.g., blocking important legitimate traffic or denying access to a business critical application).”);
(Curtis displays each security countermeasure together with its associated expected cost, which expressly includes adverse operational impacts such as blocking legitimate traffic or denying access to a business-critical application. Such adverse impacts constitute information indicating a demerit of the corresponding countermeasure.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined electronic apparatus of Roh and Sella to apply Curtis’s user interface technique by displaying the expected cost or adverse operational impact associated with each available protective operation. Curtis teaches that displaying this information permits a user to compare security countermeasures and determine an appropriate course of action. The modification would predictably enable an informed selection among the post-reboot protective operations based on their respective disadvantages.
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 ARHAM AHMED whose telephone number is (571)272-3726. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/ARHAM NMN AHMED/ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437
