DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in GB on 03/19/2024. It is noted, however, that applicant has not filed a certified copy of the foreign application as required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/17/2025 is being considered by the examiner.
Specification
The abstract of the disclosure is objected to because there appears to be a typographical error “(Fig.1)”.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 3, 5 – 7, 9, 12 – 13 and 18 are objected to because of the following informalities:
Regarding claim 3; the limitation “the created model” lacks proper antecedent basis.
Regarding claims 5 and 6; the limitation “the normal operation” lacks proper antecedent basis.
Regarding claim 7; the limitation “frequently occurred behaviour” should apparently be -- frequently occurring behavior --.
Regarding claim 9; there appears to be a typographical error “applications the computer that run” of -- applications on the computer that run --.
Regarding claims 12 and 13; there appears to be a typographical error “,” of -- ; -- at the end of each method steps of the respective claims. Further, there appears to be a missing “and” at the end of (line 10, claim 12).
Claim 13 is a dependent claim and thus also objected.
Regarding claim 18; the first occurrence of the acronyms “EDR” and “MDR” lack proper antecedent basis.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4, 6 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 contains the trademark/trade name “Applocker”, “Windows Sandbox” and “Microsoft Defender”, and “Application Guard Configurations”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe operating format and, accordingly, the identification/description is indefinite.
Regarding claim 6, the phrase "such as" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
The term “similar” in claim 17 is a relative term which renders the claim indefinite. The term “similar” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 – 14 and 16 – 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pavlyushchik (US 2015/0047046 A1) (hereinafter “Pavlyushchik”).
Pavlyushchik discloses;
Regarding claim 1, a computer-implemented method of threat prevention in a computer or computer network, the method comprising:
collecting data related to the computer and/or computer network, the collected data relating at least to behavior of at least one application [i.e., the collection module 220 is configured to collect information about the operation of applications, and specifically, data about the actions being performed by an application during its operation (page 4, para 0031), (see figures 2 and ref. 350 of figure 3), (page 5, para 0043)];
building a normal model of normal behavior of the at least one application based on the collected data [i.e., compiles a definitive list of typical actions of the application 70 (see ref. 360 of figure 3), (page 2, para 0040), (page 5, para 0043) i.e., Module for Creating a List of Typical Actions (see ref. 280 of figure 2), (page 4, para 0030) Note; there is a disclosure of building a representation of the application’s normal behavior by collecting information regarding actions performed during operation, analyzing the collected information to identify typical actions and compiling the definitive list of typical actions. The resulting list constitutes a model of the application’s typical or normal behavior because subsequent application behavior is compared against the list and actions that do not conform to the list are treated as atypical and blocked];
requesting [i.e., this information may also be collected by querying external information sources 80 (page 4, para 0032), (see figures 1 and 2)] and/or receiving vulnerability information relating to the at least one application [i.e., collect information about vulnerability of software (see ref. 410 of figure 4), (page 5, para 0047)]; and
building a configuration for the at least one application [i.e., generate application restriction rules (see ref. 370 of figure 3), (page 5, para 0043) i.e.., configure restriction rules (see ref. 450 of figure 4), (page 6, para 0048) i.e., a restriction rule formulation module (ref. 160 of figure 1), (page 2, para 0020)] in a case in which the received vulnerability information indicates that the application has a vulnerability [i.e., on the basis of the information about the vulnerability, the module 160 may formulate additional restriction rules for the application (page 5, para 0043), (see figure 4)], wherein the built configuration restricts and/or prevents operation of the application [i.e., the additional restriction rule based on the list of anomalous actions will forbid the applications to perform the actions contained on this list (page 6, para 0048) i.e., control operation of application(s) having vulnerabilities using application restriction rules (see ref. 390 of figure 3), (page 5, para 0043)] in a case in which a deviation is observed between monitored behavior of the at least one application and the built normal model of the at least one application [i.e., analyzing to identify an atypical action that does not conform (i.e., “deviate”) with a typical action performed during execution of the application (page 3, para 0026), (see ref. 370 – 390 of figure 3), (page 3, para 0043)].
Regarding claim 2, the method according to claim 1, wherein the built configuration restricts the operation of the at least one application by only allowing the behavior of the at least one application corresponding to the built normal model of the normal behavior of the at least one application, and/or restricting and/or preventing any other operation of the at least one application [i.e., the restriction rule only permits the performance of actions from the list of typical actions for the particular applications, and all other atypical actions are blocked (page 3, para 0026), (page 5, para 0043), (page 6, para 0048)].
Regarding claim 3, the method according to claim 1, wherein the built configuration allows network connections [i.e., the atypical actions may be network operations (page 4, para 0033)], file write destinations [i.e., file operations (page 4, para 0033)] based on the created model [i.e., permits the performance of actions from the list of typical actions for the particular applications, and all other atypical actions are blocked (page 3, para 0026), (page 5, para 0043), (page 6, para 0048)].
Regarding claim 4, the method according to claim 1, wherein the built configuration comprises process execution [i.e., application control rules restrict action during execution…start process from executable file as an action that can be classified as atypical and controlled (page 2, para 0021)], file write [i.e., identifies “save file” and “save executable files to disk” as an atypical action (page 2, para 0021)], network destination [i.e., block access to the corporate network or internet (page 2, para 0021)], firewall [i.e., block access to the corporate network or internet (page 2, para 0021)], sandbox [i.e., a restriction rule that allow the application to work only in a sandbox (page 5, para 0042)], ApplicationControl [i.e., application control system 100 are design to control applications 70 by means of a list of application control rule (page 2, para 0020), (see figure 1)], Applocker [i.e., application control system 100 are design to control applications 70 by means of a list of application control rule (page 2, para 0020), (see figure 1)], Windows Sandbox [i.e., a restriction rule that allow the application to work only in a sandbox (page 5, para 0042)], Microsoft Defender and/or Application Guard configurations [i.e., application control system 100 are design to control applications 70 by means of a list of application control rule (page 2, para 0020), (see figure 1)].
Regarding claim 5, the method according to claim 1, further comprising:
generating an alert when behavior of the at least one application that is not allowed based on the built normal model of the normal operation of the at least one application is detected [i.e., create a request for the user, which in turn asks for permission to allow the performance of a specific actions or initialize the application (page 5, para 0042).].
Regarding claim 6, the method according to claim 1, wherein in a case in which the at least one application attempts to carry out tasks that are not allowed based on the built normal model of the normal operation of the at least one application, the at least one application is allowed to run in a restricting environment, such as a sandbox [i.e., a restriction rule that allow the application to work only in a sandbox (page 5, para 0042)].
Regarding claim 7, the method according to claim 1, wherein the collected data from which the model of normal behavior of the application is built comprises expected [i.e., compiles a definitive list of typical actions of the application 70 (see ref. 360 of figure 3), (page 2, para 0040), (page 5, para 0043) i.e., Module for Creating a List of Typical Actions (see ref. 280 of figure 2), (page 4, para 0030) and/or frequently occurred monitored behaviour of the application [i.e., an action may be treated as typical if it is identified across the information sources, while an action identified in only 25% or less of the sources may be treated as rare/anomalous (page 4, para 0038)].
Regarding claim 8, the method according to claim 1, wherein the data is collected from the computer, computer network and/or a backend system by at least one security agent module that collects data related to the computer and/or computer network [i.e., the collection module 220 is configured to collect information about the operation of applications, and specifically, data about the actions being performed by an application during its operation (page 4, para 0031), (see figures 2 and ref. 350 of figure 3), (page 5, para 0043)].
Regarding claim 9, the method according to claim 1, wherein the model of normal behavior is built for applications, the computer that run and/or execute at the computer longer than a predefined duration [i.e., determines application popularity based on the frequency of starts, an antivirus server collects the number of starts of application across devices and uses those counts to formulate a popularity rating. It may limit its control/modeling to popular application (page 3, para 0028)].
Regarding claim 10, the method according to claim 1, wherein building the model of normal behavior of the at least one application comprises collecting information relating to usage of the at least one application [i.e., collecting action performed during the user’s working with the given application (page 4, para 0037)].
Regarding claim 11, the method according to claim 1, wherein the vulnerability information concerning the at least one application is received from a server [i.e., antivirus server 80 (page 3, para 0028), (see figure 2)], a service [i.e., antivirus server 80 (page 3, para 0028), (see figure 2)], a backend system [i.e., antivirus server 80 (page 3, para 0028), (see figure 2)], and/or an external source [i.e., this information may also be collected by querying external information sources 80 (page 4, para 0032), (see figures 1 and 2)].
Regarding claim 12, an arrangement for threat prevention in a computer or computer network [i.e., computer system 5 (see figure 5), (page 6, para 0052)], the arrangement comprising:
at least one computer [i.e., CPU (see ref. 15 of figure 5), (page 6, para 0052)], the arrangement is configured to:
collect data related to the computer and/or computer network, the collected data relating at least to behavior of at least one application [i.e., the collection module 220 is configured to collect information about the operation of applications, and specifically, data about the actions being performed by an application during its operation (page 4, para 0031), (see figures 2 and ref. 350 of figure 3), (page 5, para 0043)];
build a normal model of normal behavior of the at least one application based on the collected data [i.e., compiles a definitive list of typical actions of the application 70 (see ref. 360 of figure 3), (page 2, para 0040), (page 5, para 0043) i.e., Module for Creating a List of Typical Actions (see ref. 280 of figure 2), (page 4, para 0030) Note; there is a disclosure of building a representation of the application’s normal behavior by collecting information regarding actions performed during operation, analyzing the collected information to identify typical actions and compiling the definitive list of typical actions. The resulting list constitutes a model of the application’s typical or normal behavior because subsequent application behavior is compared against the list and actions that do not conform to the list are treated as atypical and blocked];
request [i.e., this information may also be collected by querying external information sources 80 (page 4, para 0032), (see figures 1 and 2)] and/or receive vulnerability information relating to the at least one application [i.e., collect information about vulnerability of software (see ref. 410 of figure 4), (page 5, para 0047)]; and
build a configuration for the at least one application [i.e., generate application restriction rules (see ref. 370 of figure 3), (page 5, para 0043) i.e.., configure restriction rules (see ref. 450 of figure 4), (page 6, para 0048) i.e., a restriction rule formulation module (ref. 160 of figure 1), (page 2, para 0020)] in a case in which the received vulnerability information indicates that the application has a vulnerability [i.e., on the basis of the information about the vulnerability, the module 160 may formulate additional restriction rules for the application (page 5, para 0043), (see figure 4)], wherein the built configuration restricts and/or prevents operation of the application [i.e., the additional restriction rule based on the list of anomalous actions will forbid the applications to perform the actions contained on this list (page 6, para 0048) i.e., control operation of application(s) having vulnerabilities using application restriction rules (see ref. 390 of figure 3), (page 5, para 0043)] in a case in which a deviation is observed between monitored behavior of the at least one application and the built normal model of the at least one application [i.e., analyzing to identify an atypical action that does not conform (i.e., “deviate”) with a typical action performed during execution of the application (page 3, para 0026), (see ref. 370 – 390 of figure 3), (page 3, para 0043)].
Regarding claim 13, the arrangement according to claim 12, wherein the arrangement is configured to carry out a method of threat prevention in a computer or computer network, the method comprising:
collecting data related to the computer and/or computer network, the collected data relating at least to behavior of at least one application [i.e., the collection module 220 is configured to collect information about the operation of applications, and specifically, data about the actions being performed by an application during its operation (page 4, para 0031), (see figures 2 and ref. 350 of figure 3), (page 5, para 0043)],
building a normal model of normal behavior of the at least one application based on the collected data [i.e., compiles a definitive list of typical actions of the application 70 (see ref. 360 of figure 3), (page 2, para 0040), (page 5, para 0043) i.e., Module for Creating a List of Typical Actions (see ref. 280 of figure 2), (page 4, para 0030) Note; there is a disclosure of building a representation of the application’s normal behavior by collecting information regarding actions performed during operation, analyzing the collected information to identify typical actions and compiling the definitive list of typical actions. The resulting list constitutes a model of the application’s typical or normal behavior because subsequent application behavior is compared against the list and actions that do not conform to the list are treated as atypical and blocked],
requesting [i.e., this information may also be collected by querying external information sources 80 (page 4, para 0032), (see figures 1 and 2)] and/or receiving vulnerability information relating to the at least one application [i.e., collect information about vulnerability of software (see ref. 410 of figure 4), (page 5, para 0047)], and
building a configuration for the application [i.e., generate application restriction rules (see ref. 370 of figure 3), (page 5, para 0043) i.e.., configure restriction rules (see ref. 450 of figure 4), (page 6, para 0048) i.e., a restriction rule formulation module (ref. 160 of figure 1), (page 2, para 0020)], in a case in which the received vulnerability information indicates that the at least one application has a vulnerability [i.e., on the basis of the information about the vulnerability, the module 160 may formulate additional restriction rules for the application (page 5, para 0043), (see figure 4)], wherein the built configuration restricts and/or prevents operation of the at least one application [i.e., the additional restriction rule based on the list of anomalous actions will forbid the applications to perform the actions contained on this list (page 6, para 0048) i.e., control operation of application(s) having vulnerabilities using application restriction rules (see ref. 390 of figure 3), (page 5, para 0043)] in a case in which a deviation is observed between monitored behavior of the at least one application and the built normal model of the at least one application [i.e., analyzing to identify an atypical action that does not conform (i.e., “deviate”) with a typical action performed during execution of the application (page 3, para 0026), (see ref. 370 – 390 of figure 3), (page 3, para 0043)], and wherein the built configuration restricts the operation of the at least one application by only allowing the behavior of the application corresponding to the build built normal model of the normal behavior of the application, and/or restricting and/or preventing any other operation of the at least one application [i.e., the additional restriction rule based on the list of anomalous actions will forbid the applications to perform the actions contained on this list (page 6, para 0048) i.e., control operation of application(s) having vulnerabilities using application restriction rules (see ref. 390 of figure 3), (page 5, para 0043)].
Regarding claim 14, a non-transitory computer-readable medium on which is stored a computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according to claim 1 [i.e., the method may be stored as one or more instructions or code on a non-transitory computer-readable medium (page 6, page 0053)].
Regarding claim 16, the method of claim 1, wherein the configuration for the at least one application comprises an application control policy for the at least one application [i.e., generate application restriction rules (see ref. 370 of figure 3), (page 5, para 0043) i.e.., configure restriction rules (see ref. 450 of figure 4), (page 6, para 0048) i.e., a restriction rule formulation module (ref. 160 of figure 1), (page 2, para 0020)].
Regarding claim 17, the method of claim 3, wherein actions that are similar to actions that have already been executed on the computer are allowed [i.e., the restriction rules allow system 100 to block actions not conforming to the typical actions of the applications 70 being controlled. The term “typical actions”, as used herein, meant such action that are performed by the application when executing the commands and instructions established during the creation by the manufacturer of the given application and are directed at executing a task corresponding to the given application (page 2, para 0021)].
Regarding claim 18, the method of claim 8, wherein the security agent module is a module of an EDR and/or MDR system, and/or wherein the data is collected at least in part from event telemetry flow [i.e., the collection module 220 and Module for monitoring actions of the application 260 is configured to collect information about the operation of applications, and specifically, data about the actions being performed by an application during its operation (page 4, para 0031), (see figures 2 and ref. 350 of figure 3), (page 5, para 0043)].
Regarding claim 19, the method of claim 10, wherein the information relating to usage of the at least one application comprises frequency of operations and/or types of operations related to the application [i.e., collecting action performed during the user’s working with the given application (page 4, para 0037) i.e., an action may be treated as typical if it is identified across the information sources, while an action identified in only 25% or less of the sources may be treated as rare/anomalous (page 4, para 0038)].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Niemela (US 2011/0083186 A1) discloses monitoring the behaviour of trusted applications running on the computer system and, in the event that one or more unexpected behaviours of an application is detected, identifying a file or files responsible for the unexpected behaviour.
FRANZA (US 2022/0366034 A1) discloses determining information on an expected behavior of the one or more software containers based on respective software components being executed or used within the one or more software containers; determining information on a monitored behavior of the one or more software containers; and determining a fault condition of a software container based on a deviation between the expected behavior of the software container and the monitored behavior of the software container.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432
Prosecution Insights