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 .
Claim Status
Applicant’s amendment to claim 11 overcomes the 112(b) and 112(a) rejections to claims 11-20.
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.
Claim(s) 1, 5-6, 11, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree (US 20170126712 A1) in view of Banzhof (US 20060101517 A1).
Regarding claim 1, Crabtree teaches a method comprising:
receiving, by communications hardware, first system data associated with a first system, wherein the first system data includes operational data and context data; ([0011]: retrieve a plurality of cybersecurity related data from a plurality of network data sources. [0012]: The time series data retrieval and storage module: monitors cybersecurity related data from a plurality of sources. [0034]: any time series data encountered by the system such as but not limited to enterprise network usage data, component and system logs, performance data, network service information captures.)
determining, by a modeling engine and based at least on the operational data and a security ontology, that the first system is undergoing a security issue that corresponds to a historical security issue associated with a second system; ([0010]: a system for detection, mitigation and remediation of cyberattacks employing cyber-decision platform. In a typical embodiment, the advanced cyber decision platform, a specifically programmed usage of the business operating system, continuously monitors a client enterprise's normal network activity for behaviors such as but not limited to normal users on the network, resources accessed by each user, access permissions of each user, machine to machine traffic on the network, sanctioned external access to the core network and administrative access to the network's identity and access management servers in conjunction with real-time analytics informing knowledge of cyberattack methodology. When suspicious activity at a level signifying an attack is determined, the system issues action-focused alert information to all predesignated parties specifically tailored to their roles in attack mitigation or remediation and formatted to provide predictive attack modeling based upon historic, current, and contextual attack progression analysis.)
identifying, by a mitigation engine and using the security ontology, a solution implementation used for the second system based on the historical security issue; ([0010]: First, the advanced computational analytics and simulation capabilities of the system are used to provide immediate disclosure of probable digital access points both at the network periphery and within the enterprise's information transfer and trust structure and recommendations are given on network changes that should be made to harden it prior to or during an attack. Second, the advanced cyber decision platform continuously monitors the network in real-time both for types of traffic and through techniques such as deep packet inspection for pre-decided analytically significant deviation in user traffic for indications of known cyberattack vectors.)
generating, by the mitigation engine, a modified solution implementation based at least on the context data; and ([0010]: When suspicious activity at a level signifying an attack is determined, the system issues action-focused alert information to all predesignated parties specifically tailored to their roles in attack mitigation or remediation and formatted to provide predictive attack modeling based upon historic, current, and contextual attack progression analysis.)
performing, by the mitigation engine, an action set for the first system based at least on the modified solution implementation. ([0037]: present preventative recommendations to the enterprise decision makers for network infrastructure changes, physical and configuration-based to cost effectively reduce the probability of a cyberattack and to significantly and most cost effectively mitigate data exposure and loss in the event of attack. [0039]: actionable recommendations on repelling the intrusion and mitigating the damage. [0041]: the system's predictive capabilities may be employed to assist in creation of a plan for changes of the IT infrastructural that should be made that are optimal for remediation of cybersecurity risk.)
Crabtree does not explicitly disclose wherein generating the modified solution implementation comprises modifying the solution implementation to include a different countermeasure based on a difference in resiliency between the first system and the second system.
However, Banzhof teaches wherein generating the modified solution implementation comprises modifying the solution implementation to include a different countermeasure based on a difference in resiliency between the first system and the second system. ([0056]: the action pack effectively uses the results of a query for a device type or a specific characteristic of device type to determine whether or not to apply a given remediation signature (or set of remediation signatures). For example, two different operating systems may have the same vulnerability, but different remediation signatures (defining different approaches to remediating the vulnerability) may be determined to have best effect for the different respective operating systems. Hence in querying for a device type (such as personal computer workstation) the action pack might further query for a device type of Windows, UNIX, or Mac, and the choose to apply a signature because the device is a workstation, and select which signature to apply based on the operating system.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree to include above limitations. One would have been motivated to do so because two different operating systems may have the same vulnerability, but different remediation signatures (defining different approaches to remediating the vulnerability) may be determined to have best effect for the different respective operating systems. As taught by Banzhof, [0056].
Regarding claim 5, Crabtree and Banzhof teach the method of claim 1.
Crabtree teaches wherein the operational data comprises one or more of log data, network traffic data, performance data, and user behavior data. ([0034]: any time series data encountered by the system such as but not limited to enterprise network usage data, component and system logs, performance data, network service information captures.)
Regarding claim 6, Crabtree and Banzhof teach the method of claim 1.
Crabtree teaches wherein the context data comprises configuration data and defense data of the first system. ([0013]: a portion of baseline data analyzed by a directed computational graph analysis module is network equipment logs, network equipment configuration parameters, network topology information and network resident server logs are inspected for the purpose of predictively uncovering network vulnerabilities. [0041]: Upon the detection of a cyberattack by the system 401 all available information about the ongoing attack and existing cybersecurity knowledge are analyzed, including through predictive simulation in near real time 402to develop both the most accurate appraisal of current events and actionable recommendations concerning where the attack may progress and how it may be mitigated.)
Same rationales apply to claim 11 (apparatus) because it is substantially similar to claim 1 (method).
Same rationales apply to claim 15 (apparatus) because it is substantially similar to claim 5 (method).
Same rationales apply to claim 16 (apparatus) because it is substantially similar to claim 6 (method).
Claim(s) 2, 8-10, 12, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree (US 20170126712 A1) in view of Banzhof (US 20060101517 A1), and in view of Iwanir (US 20180034835 A1).
Regarding claim 2, Crabtree and Banzhof teach the method of claim 1.
Crabtree and Banzhof do not explicitly disclose determining, by the mitigation engine and based on the security ontology, a first resource associated with the historical security issue; causing, by the mitigation engine and based on the first resource, deployment of a decoy resource within the first system.
However, Iwanir teaches determining, by the mitigation engine and based on the security ontology, a first resource associated with the historical security issue; causing, by the mitigation engine and based on the first resource, deployment of a decoy resource within the first system. ([0007]: The system assesses whether a change to a file appears to be malicious in that the change may be caused by ransomware. When the change to the file appears to be malicious, the system performs a countermeasure to prevent synchronization of files of the client device with other client devices and with the cloud service to prevent the propagating of files from the client device, which is undergoing a ransomware attack. [0023]-[0024]: the ARC system may download one or more honeypot files (e.g., decoy resource) to the client device. A honeypot file is a file that is stored on the client device solely for the purpose of detecting a malicious change to the file. In some embodiments, the ARC system may deploy honeypots (e.g., decoy resource) for a cloud storage account (e.g., first resource), continuously monitor for indicators of ransomware, automatically respond by restoring affected files to their pre-attack state, and take actions to prevent future attacks.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree and Banzhof to include above limitations. One would have been motivated to do so because it is well-known to a person having ordinary skill in the art that a Honeypot is to act as a decoy, luring cyber attackers with fake, vulnerable-looking systems to distract them from real assets, detect their presence, and gather intelligence on their tactics, tools, and motivations.
Regarding claim 8, Crabtree and Banzhof teach the method of claim 1.
Crabtree and Banzhof do not explicitly disclose wherein performing the action set for the first system based at least on the modified solution implementation comprises: automatically causing, by the communications hardware, deployment of a resource set to the first system.
However, Iwanir teaches wherein performing the action set for the first system based at least on the modified solution implementation comprises: automatically causing, by the communications hardware, deployment of a resource set to the first system. ([0007]: The system assesses whether a change to a file appears to be malicious in that the change may be caused by ransomware. When the change to the file appears to be malicious, the system performs a countermeasure to prevent synchronization of files of the client device with other client devices and with the cloud service to prevent the propagating of files from the client device, which is undergoing a ransomware attack. [0023]-[0024]: the ARC system may download one or more honeypot files (e.g., decoy resource) to the client device. A honeypot file is a file that is stored on the client device solely for the purpose of detecting a malicious change to the file. In some embodiments, the ARC system may deploy honeypots (e.g., decoy resource) for a cloud storage account (e.g., first resource), continuously monitor for indicators of ransomware, automatically respond by restoring affected files to their pre-attack state, and take actions to prevent future attacks.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree and Banzhof to include above limitations. One would have been motivated to do so because it is well-known to a person having ordinary skill in the art that a Honeypot is to act as a decoy, luring cyber attackers with fake, vulnerable-looking systems to distract them from real assets, detect their presence, and gather intelligence on their tactics, tools, and motivations.
Regarding claim 9, Crabtree, Banzhof and Iwanir teach the method of claim 8.
Iwanir teaches wherein the resource set comprises instructions to quarantine one or more components of the first system. [0023]-[0024]: the ARC system may download one or more honeypot files (e.g., to quarantine) to the client device. A honeypot file is a file that is stored on the client device solely for the purpose of detecting a malicious change to the file. In some embodiments, the ARC system may deploy honeypots (e.g., to quarantine) for a cloud storage account (e.g., first resource), continuously monitor for indicators of ransomware, automatically respond by restoring affected files to their pre-attack state, and take actions to prevent future attacks.)
Regarding claim 10, Crabtree, Banzhof and Iwanir teach the method of claim 8.
Iwanir teaches wherein the resource set comprises one or more decoy resources. [0023]-[0024]: the ARC system may download one or more honeypot files (e.g., decoy resources) to the client device. A honeypot file is a file that is stored on the client device solely for the purpose of detecting a malicious change to the file. In some embodiments, the ARC system may deploy honeypots (e.g., decoy resources) for a cloud storage account (e.g., first resource), continuously monitor for indicators of ransomware, automatically respond by restoring affected files to their pre-attack state, and take actions to prevent future attacks.)
Same rationales apply to claim 12 (apparatus) because it is substantially similar to claim 2 (method).
Same rationales apply to claim 18 (apparatus) because it is substantially similar to claim 8 (method).
Same rationales apply to claim 19 (apparatus) because it is substantially similar to claim 9 (method).
Same rationales apply to claim 20 (apparatus) because it is substantially similar to claim 10 (method).
Claim(s) 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree (US 20170126712 A1) in view of Banzhof (US 20060101517 A1), and in view of Iwanir (US 20180034835 A1), and further in view of Ferguson-Walter (US 11934948 B1).
Regarding claim 3, Crabtree, Banzhof and Iwanir teach the method of claim 2.
Crabtree, Banzhof and Iwanir do not explicitly disclose receiving, by the communications hardware, attack interaction data associated with the decoy resource, wherein generating the modified solution implementation is further based on the attack interaction data.
However, Ferguson-Walter teaches receiving, by the communications hardware, attack interaction data associated with the decoy resource, wherein generating the modified solution implementation is further based on the attack interaction data. (Col 3 line 61- Col 4 line 6: In general, the goal of placing a honeypot on a network is to lure an attacker into interacting with it instead of another real computer system. Another goal of these technologies is to learn more about an attacker through observations of their interactions with honeypots and honeynets. Col 31 lines 16-28: Whereas F is used to optimize PD by adapting configurations, generating new deception device configurations, and adapting existing deception device configurations, G is used to test various deception configurations which are produced by F to validate their suitability for the production network and for the particular attacker who is interacting with devices on the production network.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree, Banzhof and Iwanir to include above limitations. One would have been motivated to do so because in general, the goal of placing a honeypot on a network is to lure an attacker into interacting with it instead of another real computer system. A honey-network or “honeynet” is an extension of this same methodology in which many honeypot systems are placed onto a network. By placing many fake systems into their own network, cyber defenders hope to entice an attacker into interacting with multiple systems over a longer period of time. A primary goal of these technologies is to tempt an attacker by looking more attractive or more vulnerable than nearby real systems. Another goal of these technologies is to learn more about an attacker through observations of their interactions with honeypots and honeynets. The collected information is then examined at a later time. As taught by Ferguson-Walter, Background.
Regarding claim 4, Crabtree, Banzhof, Iwanir and Ferguson-Walter teach the method of claim 3.
Ferguson-Walter teaches updating, by the modeling engine, the security ontology based on the attack interaction data. (Col 22 lines 53-54: Data is received and updated, and adaptions are performed as new data is consumed. Col 22 line 66- Col 23 line 1: The autonomic reasoning system 504 a allows continuous analysis of the collection of models 903 as the models are being constructed and updated.)
Same rationales apply to claim 13 (apparatus) because it is substantially similar to claim 3 (method).
Same rationales apply to claim 14 (apparatus) because it is substantially similar to claim 4 (method).
Claim(s) 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Crabtree (US 20170126712 A1) in view of Banzhof (US 20060101517 A1), and in view of Cabot (US 20160127388 A1).
Regarding claim 7, Crabtree and Banzhof teach the method of claim 1.
Crabtree and Banzhof do not explicitly disclose wherein determining that the first system is undergoing the security issue that corresponds to the historical security issue associated with the second system comprises: generating, by the modeling engine, a feature vector set based on the operational data; processing, by the modeling engine, the feature vector set using a plurality of models to produce model output data; comparing, by the modeling engine, the feature vector set to one or more historical issues stored by the security ontology to produce a similarity score set, wherein determining that the first system is undergoing the security issue is based at least on the model output data and the similarity score set.
However, Catbot teaches wherein determining that the first system is undergoing the security issue that corresponds to the historical security issue associated with the second system comprises:
generating, by the modeling engine, a feature vector set based on the operational data; processing, by the modeling engine, the feature vector set using a plurality of models to produce model output data; ([0039]-[0042]: The analyzers may process a received sample and generate a result including information about the sample such as, for example, any malware or metadata associated with the sample. The respective outputs (e.g., results) of analyzers are provided in JavaScript Object Notation (JSON). JSONs output from analyzers may be converted by creating a list of each parent-child pair (e.g., two-level) in the respective JSON and turning each pair into a string. For example, {“a”: [“b”, “c”]} in a JSON may be converted to a set of strings {‘“a”: “b”’, ‘“a”: “c”’} in the form of key-value vectors. A hashing process may be performed to convert the sets of strings into feature vectors prior to performing a similarity analysis by similarity determiner.)
comparing, by the modeling engine, the feature vector set to one or more historical issues stored by the security ontology to produce a similarity score set, wherein determining that the first system is undergoing the security issue is based at least on the model output data and the similarity score set. ([0016]: perform a similarity analysis on two or more malware samples to determine whether the two or more malware samples are similar. The similarity analysis may be performed on a previously unknown sample and a known sample to identify the unknown sample and/or an authorship of the unknown sample. [0031]: provide a system for processing malware and/or detecting malware that is similar to known malware. [0055]: identification, if available, of the malware samples, a similarity score of the malware samples based on the determined similarity distance.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Crabtree and Banzhof to include above limitations. One would have been motivated to do so because malware, or malicious software, may refer to software that is used to disrupt computer systems and networks. Malware may be analyzed to study and detect threats of malware. However, existing malware analysis services suffer from several deficiencies. For instance, malware analysis services may not be able to keep pace with the rapidly evolving nature of malicious software. Therefore a faster and more efficient method is needed to process files to detect malware. In addition, because numerous malware are generated on a daily basis, a method to prioritize malware samples for analysis is also needed. As taught by Catbot, [0003].
Same rationales apply to claim 17 (apparatus) because it is substantially similar to claim 7 (method).
Response to Arguments
Applicant’s arguments, see page 7, filed 06/16/2026, with respect to the rejection(s) of claims 1-20 under 35 U.S.C. § 102 and 35 U.S.C. § 103 have been fully considered but are moot in view of new ground(s) of rejection.
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 ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455
Prosecution Insights