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-24
The following claim(s) is/are amended: 1, 5, 7, 12, 15, 19, 21
The following claim(s) is/are cancelled: 6, 16
The following claim(s) is/are new: -
Claim(s) 1-5, 7-15, 17-24 is/are rejected.
Response to Arguments
Applicant’s arguments filed in the amendment filed 2/12/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-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.)
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 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; (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 amends new limitations into each independent and argues at Remarks, pgs. 9-10 that Reybok’s IP-blocking and Lasslo’s enabling of cloud services does not teach the amended features.
Examiner cites Fukuda to teach the amended language. The argument is moot. All claims remain rejected.
Conclusion
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