DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1-5, 7-15, 17-22, 24
The following claim(s) is/are amended: 1, 12, 19
The following claim(s) is/are cancelled: 6, 16, 23
The following claim(s) is/are new: -
Claim(s) 1-5, 7-15, 17-22, 24 is/are rejected. This rejection is FINAL.
Response to Arguments
Applicant’s arguments filed in the amendment filed 7/22/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - 35 USC § 103
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.
Claims 1-5, 7-15, 17-22, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Reybok (US Pub. 2020/0356666) in view of Callaghan (US Pub. 2014/0227976) and further in view of Fukuda (US Pub. 2011/0222098).
With respect to Claim 1, Reybok teaches a computer-implemented method of coordinating threat detection and mitigation among a fleet of trusted devices, the method comprising: transmitting, from at least a first device of the fleet of trusted devices, an events report comprising log data from at least the first device of the fleet of trusted devices; (Fig. 2, paras. 25-28, 39-40; Automated client portal (ACP) clients in different networks all send security event logs to a centralized source. Para. 55; devices or groups may have trust levels which control the actions and messaging with respect to other members of the group. Para. 61; networks working together under common umbrella or common management such as a government or large company.)
receiving, at the first device of the fleet of trusted devices, one or more security-related messages generated based on an analysis of the events report; (Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
generating, via the first device of the fleet of trusted devices, a threat response based on the one or more security-related messages using a threat response profile, (para. 45; client administrators define profiles which include preferences for remedial schemes. paras. 37, 46; central database stores and sends remedial measures in connection with a notification. The central database uses a template to generate an executable for the client network to install to implement a new security configuration such as a command to block a particular IP address. Therefore, the client blocking an IP address is a threat response based on a message using a threat response profile. To the extent that the generation is depicted in these paragraphs as being done by the centralized service, note that Reybok posits an entirely distributed architecture (see, e.g., para. 59) and further identifies that a first network can come up with the remedial solution and report it to the centralized service (see para. 61, 74). Therefore, to the extent it is not anticipated, it would have been obvious to one of ordinary skill prior to the effective filing date to have the first device generate the threat response based on the messages in order to allow a network to protect itself from the threat.)
wherein the threat response profile comprises a plurality of rules for interpreting the one or more security-related messages and generating the threat response; (para. 45; client administrators define profiles which include preferences for remedial schemes. Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
and for one or more of the other devices of the fleet of trusted devices, changing a device configuration setting for the device based on the threat response generated. (para. 37, 46; blocking of IP address.)
But Reybok does not explicitly teach distributing a threat response.
Callaghan, however, does teach distributing, from the first device, the generated threat response to one or more other devices of the fleet of trusted devices via one or more trusted connections between the devices of the fleet of trusted devices; (Reybok already taught a threat response including a remedial solution such as a configuration change. Fig. 1, paras. 10-16, 22-23; device sends device-specific updates to a plurality of other devices based upon the device state of each device. See also Reybok, para. 48, 55, 68; communication via a secure interface or trusted channel.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Reybok with the distribution of a threat response in order to allow for the updating of a configuration for devices that cannot directly access the update source. (Callaghan, para. 26)
But modified Reybok does not explicitly teach re-routing assigned tasks.
Fukuda, however, does teach wherein the threat response includes instructions that cause the one or more other devices to: disable one or more services of the device without discontinuing one or more other services of an unaffected device, (Examiner asserts that modified Reybok teaches on its own through implicit result – Reybok already taught implementing a new security configuration by pushing a security update to the device (see paras. 37, 46) including via blocking an IP address, which is an example of a service disabling. The natural implication in a heterogenous system is that other, differently configured devices may not have the same vulnerability, and therefore would not need to have an update pushed. Regardless, Examiner will cite Fukuda, Fig. 3, paras. 30-31, 41-43; A multifuctional device tracks malfunctions in each unit and stores them in a table. Paras. 51-52; When a first device has errors in its scan, copy and fax functions those functions on that device are disabled, while other functions on the device remain and jobs requiring those functions are sent to other devices, e.g. if Device A cannot print, printing is disabled on Device A, but Device B can still print.)
And re-route an assigned tasks from the device to another device within the fleet of trusted devices. (para. 58; Device B receives a job via fax, but checks with the management apparatus, which allocates the job to Device A, which is a rerouting of an assigned task. It would have been obvious to one of ordinary skill prior to the effective filing date to reroute assigned tasks to another device to avoid threats that have not yet been defeated, see Reybok para. 46.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Reybok with the rerouting of assigned tasks in order to allow the tasks to still be completed by a secure device.
With respect to Claim 2, modified Reybok teaches the computer-implemented method of claim 1, and Fukuda also teaches wherein each trusted device of the fleet of trusted devices is a multi-function printer. (para. 31; multifunction printer with scan, copy, print, and fax functions.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 3, modified Reybok teaches the computer-implemented method of claim 1, and Reybok also teaches wherein the events report is transmitted from at least the first device to a security information and event management system, and wherein the one or more security-related messages are received from the security information and event management system. (Fig. 2, paras. 25-28, 39-40; reporting of data to a centralized cloud service which aggregates the data and sends responses.)
With respect to Claim 4, modified Reybok teaches the computer-implemented method of claim 3, and Reybok also teaches further comprising: analyzing, via the security information and event management system, the events report transmitted from at least the first device to determine the one or more security-related messages. (paras. 27-30, 36-37, 46; central service correlates data, ranks threats, updates storage, identifies remedial measures and ranks them.)
With respect to Claim 5, modified Reybok teaches the computer-implemented method of claim 1, and Reybok also teaches wherein the threat response includes one or more of the following: an instruction to communicate a warning; an instruction to change security settings; an instruction to change file integrity; an instruction to escalate the threat response; an instruction to alert an administrator; and an instruction to request additional information. (para. 37, 46; blocking of IP address.)
With respect to Claim 7, modified Reybok teaches the computer-implemented method of claim 1, and Fukuda also teaches wherein the one or more services includes at least one of a printing service, a scanning service, a faxing service, a copying service, and a file sharing service. (para. 31; multifunction printer with scan, copy, print, and fax functions.)
The same motivation to combine as the parent claim applies here.
With respect to Claim 8, modified Reybok teaches the computer-implemented method of claim 1, and Callaghan also teaches wherein the threat response includes (i) a first threat response for a first affected device of the fleet of trusted devices, and (ii) a second threat response for a second affected device of the fleet of trusted devices, wherein the first threat response is different from the second threat response. (Fig. 1, paras. 10-16, 22-23; device sends device-specific updates to a plurality of other devices based upon the device state of each device.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 9, modified Reybok teaches the computer-implemented method of claim 1, and Callaghan also teaches wherein the threat response generated using the threat response profile includes a device-specific response for each device of the fleet of trusted devices, wherein each device-specific response is customized based on a configuration of each device. (Fig. 1, paras. 10-16, 22-23; device sends device-specific updates to a plurality of other devices based upon the device state of each device.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 10, modified Reybok teaches the computer-implemented method of claim 1, and Reybok also teaches wherein the log data of the events report includes one or more of the following: number of failed logins from a single device; number of firewall-related events from a single IP address; number of IDS alerts from a single IP address; and detection of identifiable malware. (paras. 73-74; IDS alerts. Paras. 38, 77; detection of malware.)
With respect to Claim 11, modified Reybok teaches the computer-implemented method of claim 1, and Reybok also teaches wherein the events report includes log data collected from one or more devices of the fleet of trusted devices in addition to log data collected from the first device of the fleet of trusted devices. (para. 39; ACP forwards all network event data to the central service.)
With respect to Claim 12, Reybok teaches a non-transitory computer-readable storage medium having stored thereon machine-readable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: (para. 41; processor and non-transitory machine readable media storing code)
transmit, from at least a first device of a fleet of trusted devices, an events report comprising log data from at least the first device of the fleet of trusted devices; (Fig. 2, paras. 25-28, 39-40; Automated client portal (ACP) clients in different networks all send security event logs to a centralized source. Para. 55; devices or groups may have trust levels which control the actions and messaging with respect to other members of the group. Para. 61; networks working together under common umbrella or common management such as a government or large company.)
receive one or more security-related messages generated based on an analysis of the events report; (Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
generate a threat response based on the one or more security-related messages using a threat response profile; (para. 45; client administrators define profiles which include preferences for remedial schemes. paras. 37, 46; central database stores and sends remedial measures in connection with a notification. The central database uses a template to generate an executable for the client network to install to implement a new security configuration such as a command to block a particular IP address. Therefore, the client blocking an IP address is a threat response based on a message using a threat response profile. To the extent that the generation is depicted in these paragraphs as being done by the centralized service, note that Reybok posits an entirely distributed architecture (see, e.g., para. 59) and further identifies that a first network can come up with the remedial solution and report it to the centralized service (see para. 61, 74). Therefore, to the extent it is not anticipated, it would have been obvious to one of ordinary skill prior to the effective filing date to have the first device generate the threat response based on the messages in order to allow a network to protect itself from the threat.)
But Reybok does not explicitly teach distributing a threat response.
Callaghan, however, does teach and distribute the generated threat response to one or more other devices of the fleet of trusted devices via one or more trusted connections between the devices of the fleet of trusted devices. (Reybok already taught a threat response including a remedial solution such as a configuration change. Fig. 1, paras. 10-16, 22-23; device sends device-specific updates to a plurality of other devices based upon the device state of each device. See also Reybok, para. 48, 55, 68; communication via a secure interface or trusted channel.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the medium of Reybok with the distribution of a threat response in order to allow for the updating of a configuration for devices that cannot directly access the update source. (Callaghan, para. 26)
But modified Reybok does not explicitly teach re-routing assigned tasks.
Fukuda, however, does teach wherein the threat response includes instructions that cause the one or more other devices to: disable one or more services of the device without discontinuing one or more other services of an unaffected device, (Examiner asserts that modified Reybok teaches on its own through implicit result – Reybok already taught implementing a new security configuration by pushing a security update to the device (see paras. 37, 46) including via blocking an IP address, which is an example of a service disabling. The natural implication in a heterogenous system is that other, differently configured devices may not have the same vulnerability, and therefore would not need to have an update pushed. Regardless, Examiner will cite Fukuda, Fig. 3, paras. 30-31, 41-43; A multifuctional device tracks malfunctions in each unit and stores them in a table. Paras. 51-52; When a first device has errors in its scan, copy and fax functions those functions on that device are disabled, while other functions on the device remain and jobs requiring those functions are sent to other devices, e.g. if Device A cannot print, printing is disabled on Device A, but Device B can still print.)
And re-route an assigned tasks from the device to another device within the fleet of trusted devices. (para. 58; Device B receives a job via fax, but checks with the management apparatus, which allocates the job to Device A, which is a rerouting of an assigned task. It would have been obvious to one of ordinary skill prior to the effective filing date to reroute assigned tasks to another device to avoid threats that have not yet been defeated, see Reybok para. 46.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the medium of modified Reybok with the rerouting of assigned tasks in order to allow the tasks to still be completed by a secure device.
With respect to Claim 13, it is substantially similar to Claim 2 and is rejected in the same manner, the same art and reasoning applying.
With respect to Claim 14, modified Reybok teaches the non-transitory computer-readable storage medium of claim 12, and Reybok also teaches further comprising machine-readable instructions that cause the one or more processors to: change a device configuration setting of one or more devices of the fleet of trusted devices based on the threat response generated. (para. 37, 46; blocking of IP address.)
With respect to Claims 15, 17-18, they are substantially similar to Claims 5, 8-9, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 19, Reybok teaches an electronic device configured to coordinate threat detection and mitigation within a fleet of trusted devices, (Fig. 2, paras. 25-28, 39-40; Automated client portal (ACP) clients in different networks all send security event logs to a centralized source. Para. 55; devices or groups may have trust levels which control the actions and messaging with respect to other members of the group. Para. 61; networks working together under common umbrella or common management such as a government or large company.)
the electronic device comprising: one or more processors; and a memory in communication with the one or more processors, wherein the memory comprises machine-readable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including the following: (para. 41; processor and memory)
generate and/or receive a threat response, wherein generating the threat response comprises generating the threat response based on one or more security-related messages (Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
using a threat response profile stored within the memory of the electronic device, (para. 45; client administrators define profiles which include preferences for remedial schemes. paras. 37, 46; central database stores and sends remedial measures in connection with a notification. The central database uses a template to generate an executable for the client network to install to implement a new security configuration such as a command to block a particular IP address. Therefore, the client blocking an IP address is a threat response based on a message using a threat response profile. To the extent that the generation is depicted in these paragraphs as being done by the centralized service, note that Reybok posits an entirely distributed architecture (see, e.g., para. 59) and further identifies that a first network can come up with the remedial solution and report it to the centralized service (see para. 61, 74). Therefore, to the extent it is not anticipated, it would have been obvious to one of ordinary skill prior to the effective filing date to have the first device generate the threat response based on the messages in order to allow a network to protect itself from the threat.)
the threat response profile comprising a plurality of rules for interpreting the one or more security-related messages and generating the threat response, (para. 45; client administrators define profiles which include preferences for remedial schemes. Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
wherein the threat response includes an instruction to change a device configuration setting for one or more devices within the fleet of trusted devices; (para. 45; client administrators define profiles which include preferences for remedial schemes. paras. 37, 46; central database stores and sends remedial measures in connection with a notification. The central database uses a template to generate an executable for the client network to install to implement a new security configuration such as a command to block a particular IP address. Therefore, the client blocking an IP address is a threat response based on a message using a threat response profile. To the extent that the generation is depicted in these paragraphs as being done by the centralized service, note that Reybok posits an entirely distributed architecture (see, e.g., para. 59) and further identifies that a first network can come up with the remedial solution and report it to the centralized service (see para. 61, 74). Therefore, to the extent it is not anticipated, it would have been obvious to one of ordinary skill prior to the effective filing date to have the first device generate the threat response based on the messages in order to allow a network to protect itself from the threat.)
and change a device configuration setting of the electronic device based on the threat response generated and/or received. (para. 37, 46; blocking of IP address.)
But Reybok does not explicitly teach distributing a threat response.
Callaghan, however, does teach distribute the threat response to one or more other devices within the fleet of trusted devices via one or more trusted connections between the devices of the fleet of trusted devices; (Reybok already taught a threat response including a remedial solution such as a configuration change. Fig. 1, paras. 10-16, 22-23; device sends device-specific updates to a plurality of other devices based upon the device state of each device. See also Reybok, para. 48, 55, 68; communication via a secure interface or trusted channel.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the device of Reybok with the distribution of a threat response in order to allow for the updating of a configuration for devices that cannot directly access the update source. (Callaghan, para. 26)
But modified Reybok does not explicitly teach re-routing assigned tasks.
Fukuda, however, does teach wherein the threat response includes instructions that cause the one or more other devices to: disable one or more services of the device without discontinuing one or more other services of an unaffected device, (Examiner asserts that modified Reybok teaches on its own through implicit result – Reybok already taught implementing a new security configuration by pushing a security update to the device (see paras. 37, 46) including via blocking an IP address, which is an example of a service disabling. The natural implication in a heterogenous system is that other, differently configured devices may not have the same vulnerability, and therefore would not need to have an update pushed. Regardless, Examiner will cite Fukuda, Fig. 3, paras. 30-31, 41-43; A multifuctional device tracks malfunctions in each unit and stores them in a table. Paras. 51-52; When a first device has errors in its scan, copy and fax functions those functions on that device are disabled, while other functions on the device remain and jobs requiring those functions are sent to other devices, e.g. if Device A cannot print, printing is disabled on Device A, but Device B can still print.)
And re-route an assigned tasks from the device to another device within the fleet of trusted devices. (para. 58; Device B receives a job via fax, but checks with the management apparatus, which allocates the job to Device A, which is a rerouting of an assigned task. It would have been obvious to one of ordinary skill prior to the effective filing date to reroute assigned tasks to another device to avoid threats that have not yet been defeated, see Reybok para. 46.)
It would have been obvious to one of ordinary skill prior to the effective filing date to combine the device of modified Reybok with the rerouting of assigned tasks in order to allow the tasks to still be completed by a secure device.
With respect to Claims 20-21, they are substantially similar to Claims 2 and 7, respectively, and are rejected in the same manner, the same art and reasoning applying.
With respect to Claim 22, modified Reybok teaches the electronic device of claim 19, and Reybok also teaches wherein the memory further comprises machine-readable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including the following: transmit an events report to a security information and event management system, wherein the events report comprises log data from at least the electronic device; (Fig. 2, paras. 25-28, 39-40; Automated client portal (ACP) clients in different networks all send security event logs to a centralized source. Para. 55; devices or groups may have trust levels which control the actions and messaging with respect to other members of the group. Para. 61; networks working together under common umbrella or common management such as a government or large company.)
receive, from the security information and event management system, one or more security-related messages generated based on an analysis of the events report; (Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
and generate the threat response based on the one or more security-related messages using a threat response profile. (para. 45; client administrators define profiles which include preferences for remedial schemes. paras. 37, 46; central database stores and sends remedial measures in connection with a notification. The central database uses a template to generate an executable for the client network to install to implement a new security configuration such as a command to block a particular IP address. Therefore, the client blocking an IP address is a threat response based on a message using a threat response profile. To the extent that the generation is depicted in these paragraphs as being done by the centralized service, note that Reybok posits an entirely distributed architecture (see, e.g., para. 59) and further identifies that a first network can come up with the remedial solution and report it to the centralized service (see para. 61, 74). Therefore, to the extent it is not anticipated, it would have been obvious to one of ordinary skill prior to the effective filing date to have the first device generate the threat response based on the messages in order to allow a network to protect itself from the threat.)
With respect to Claim 23, modified Reybok teaches the electronic device of claim 22, and Reybok also teaches further comprising a threat response profile stored within the memory of the electronic device, the threat response profile including a plurality of rules for interpreting one or more security-related messages received from the security information and event management system and generating a threat response for one or more devices of the fleet of trusted devices. (Fig. 2, paras. 25-30, 37; centralized service stores received event data in a database. It sends updates to the reporting ACP including notifications of updated risk, alerts to correlated acts, and updated remedial measures such as antivirus definitions.)
With respect to Claim 24, modified Reybok teaches the electronic device of claim 19, and Reybok also teaches wherein the threat response is received from at least a first device within the fleet of trusted devices via one or more trusted connections between the devices of the fleet of trusted devices. (para. 48, 55, 68; communication via a secure interface or trusted channel.)
Remarks
Applicant argues at Remarks, pg. 9 that “Reybok’s profiles are stored in the central server’s database, not on any client device” and that “Reybok does not teach or suggest a threat response profile that ‘comprises a plurality of rules for interpreting the one or more security-related messages and generating the threat response.’” Applicant further argues “[Examiner] argues Reybok’s discussion of ‘distributed mechanisms’ renders it obvious to move [threat response generation] to the first device. However, Reybok’s paragraph 59 discusses distributed data storage architecture, not distributing the threat response generation function to client devices.”
Reybok renders the two features obvious. Initially, simple substitution is generally obvious when it produces expected results, see MPEP 2143(I)(B). Reybok further specifically teaches a distributed architecture, further rendering the modification of storage location of the profile. While it is true that Reybok, para. 59 discusses a distributed database, Reybok discloses “Note that while the scheme of FIG. 6A involves a centralized database, it is also possible to have distributed mechanisms…In one embodiment, each of the depicted networks (e.g., NET1, NET2 and the organization acting as a central service each has their own version of the information repository 609, as discussed earlier, with a local or distributed query system being used. In other embodiments, a repository can be stored just on client networks (e.g., NET1 and NET2), or just at the central service (603c) or in another manner. That is, the relatively centralized mechanism depicted in FIG. 6A is used to introduce basic concepts only and is exemplary.” Therefore, Reybok is teaching a technique in which a “relatively centralized mechanism” can be “just on client networks” or “just at the central service” or “in another manner” (i.e. some combination of centralized and distributed). A person of ordinary skill would have recognized this is a common act in networked computers and distribution of functionality is the entire point of computer networking. Consequently, the shift in location is obvious as a general matter (under simple substitution), as a computer networking concept, and also as a Reybok-specific teaching.
Further, Examiner provided a motivation – letting the network protect itself from the threat (i.e. instead of relying upon some centralized network). Applicant does not dispute this motivation.
With respect to the “plurality of rules for interpreting a message” Applicant appears to make no real argument against the feature. Applicant does not dispute that Reybok discloses a plurality of preferences. See, e.g., para. 45; “Using such a control plane, each administrator can optionally also define rules (321) used to rank threats for the particular client, rules (323) for sanitization/information sharing, notification preferences or a set of remedial measures or scheme for applying remedial measures…”) nor does Applicant appear to dispute that those preferences control action based upon receipt of security-related messages. See, e.g., para. 25; “In one embodiment, as a client receives a new security event, it launches a query and/or reports this event. The query or reported event can be directed to a central routing service which, for example, optionally sanitizes the provided information, formulates a sanitized query and/or sanitizes response data, and routes this information to one or more other clients based on profile information (e.g., group membership, stored threat indicators, one or more network characteristics known to the service, etc., hereinafter referred to as a profile or profile information).” and para. 37; “For example, as indicated by numeral 113, a particular entity (e.g., a client network security system, and administrator, etc.), can be notified in response to a successful correlation. Per numeral 115, the possible threat can be ranked for risk severity depending on the correlation and/or the entities reporting earlier, matching security events…Per numeral 121, a remedial action can be taken, as introduced earlier; for example, the first network can be sent a security response template that causes an intrusion prevention system (IPS) or intrusion monitoring system (IMS) to automatically block traffic associated with a specific IP address.”). In other words, discovered security events are reported, and each client network has a plurality of preferences that trigger different responses based upon the system receiving that report, which is a plurality of rules for interpreting security-related messages.
Applicant further argues at Remarks, pg. 10 that the “disable one or more services” or “re-route an assigned task” limitations are nonobvious. Examiner cited Fukuda to teach. Applicant does not appear to dispute that Fukuda teaches those acts, but rather argues that those acts are not “in response to a threat response generated from security-related messages using a threat response profile.”
The combination teaches the feature. Examiner previously cited a threat response in Reybok, see ante (para. 37; “automatically block traffic associated with a specific IP address.”). Applicant appears to agree that Fukuda teaches actions in response to malfunctions, simply that the malfunction that suggests the device not be performing services or assigned work is mechanical rather than security in nature. But taking actions in response to security threats was already taught in Reybok, and the combination renders obvious disabling services or rerouting tasks in response to security threats.
Examiner maintains the rejection to all claims.
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 extension fee 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 NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights