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 .
Status of Claims
Claims 1-6, 8-14, 16 are pending. Claims 7, 15 are cancelled.
Claim Objections
Claims 1, 9 are objected to because of the following informalities:
Claims 1 and 9 contain the following: “at least one of asset, topology, network or authentication vulnerabilities”; it is unclear whether “asset, topology, network” are referring to vulnerabilities, or whether “authentication vulnerabilities” is its own category. For the purposes of art rejection, “authentication vulnerabilities” will be considered as its own category.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
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-2, 4-6, 8-10, 12-14, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lin et al (US 11,503,061), and further in view of Gurtu et al (PGPUB 2021/0266341).
Regarding Claims 1 and 9:
Lin teaches a security system and a method for assessing a cyber-risk and loss in a cloud infrastructure (abstract, machine learned exploitability risk model that predicts, based on the characteristics of a set of machines, a normalized risk score quantifying the risk that the machines are exploitable by a set of attacks; col 7 line 27-54, cloud), comprising:
a memory (col 23 line 42-54, system memory);
a processor that is configured to (col 23 line 42-54, one or more processors):
derive, using at least one specific connector, at least one of asset, topology, network or authentication vulnerabilities of a cloud infrastructure (col 5 line 36-45, training data collection system 120 is configured to collect data from different machine sets 110; each machine set 110 may include one or more machines 112a-d or assets, which may be connected in a network; col 5 line 46-col 6 line 5, data collection component 122 is tasked with collecting machine characteristics data 124 from the different machine sets 110; the machine characteristics data 124 may include data about the machines that are relevant to cybersecurity assessments, such as the machines' hardware components, software components, data contents, configuration setting, operational states and metrics, event logs, and other information);
generate a technology risk machine learning model and a technology risk index by normalizing, using a first machine learning model, the at least one of asset, topology, network or authentication with vulnerabilities of the cloud infrastructure (col 3 line 14-26, the exploitability risk (ER) model may accept as input a set of machine characteristics about assets (e.g., hardware, software, configuration, usage, and environment data about a machine or group of machines), and produce as output a normalized risk score indicting how susceptible the assets are to a set of cyberattacks; col 3 line 27-36, the ER model may be trained using a machine learning technique (e.g. via a form of supervised training), where the model is trained using a set of training data that are labeled with truth labels; col 3 line 48-59, to obtain truth data for the ER model, embodiments of the model training system disclosed herein will employ an exploitation testing system (e.g. the METASPLOIT penetration testing framework) to simulate attacks against assets), wherein the technology risk machine learning model comprises technology risk information that is categorized based on a type of at least one of data, a network, computation or authentication of the cloud infrastructure (col 3 line 27-36, the ER model may be trained using a machine learning technique (e.g. via a form of supervised training), where the model is trained using a set of training data that are labeled with truth labels; col 3 line 48-59, to obtain truth data for the ER model, embodiments of the model training system disclosed herein will employ an exploitation testing system (e.g. the METASPLOIT penetration testing framework) to simulate attacks against assets, i.e. “data”);
generate a compliance risk machine learning model and a compliance risk by processing the technology risk machine learning model comprising at least one of the categorized data, network, computation or authentication of the cloud infrastructure or the technology risk index (col 4 line 45-col 5 line 11, the remediation planning system may be configured to enumerate different permutations of remediation actions as potential remediation plans, and implement these plans to an instance of characteristics data for a set of machine(s) to generate additional instances of characteristics data; the plans are applied to the characteristics data only, without actually updating the set of machines; the additional instances of the characteristics data are then provided as input to a trained ER model to determine their respective risk scores for attacks; in this manner, the remediation planning system can simulate different remediation plans to quickly determine the relative effectiveness of the plans by comparing risk score reductions caused by each plan);
generate a ransomware machine learning model and a business risk by processing (i) the compliance risk machine learning model and the compliance risk, (ii) a business input comprising asset information, cash flow, or a value of the asset (col 4 line 45-col 5 line 11, the remediation planning system may associate a cost with each remediation action or action plan; the cost of a remediation action may reflect different types of cost factors such as the amount of work needed to carry out the action, a dollar amount associated with the action (e.g. an additional licensing cost), an amount of time needed to carry out the action, a functional or business impact on the machine(s) caused by the action, etc.; these cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost);
determine, using at least one of the technology risk machine learning model, the compliance risk machine learning model or the ransomware machine learning model, an asset's [malware] risk and loss by correlating a compliance risk index with parameters including asset value, cash flow, and asset criticality to generate a [malware] risk score normalized between 0 and 1, and deriving a corresponding loss value representing the potential impact on the risk (col 6 line 15-41, the exploitation testing component 130 may be tasked with performing exploitation tests 134 on the machine sets 110; another simulated attack may attempt to infect a machine with a particular type of malware; col 13 line 23-55, the inner function is a linear function that combines the components X.sub.1, X.sub.2, . . . X.sub.n of and input vector X 440 to generate a target variable Y; the input variables X.sub.1, X.sub.2, . . . X.sub.n represent different characteristics of a given set of machine(s), i.e. “asset value/asset criticality”, and the target variable Y is a binary value (0 or 1) that indicates whether a given set of machines is exploitable by the set of attacks; the logistic regression model 450 can be tuned to produce a model output 460 that indicates a fairly accurate probability 462 of whether the given machine(s) is exploitable by the set of attacks being modeled; because the output of the model 460 is a probability value, it is bounded between 0 and 1 and normalized for different types of asset types and asset group sizes, i.e. “risk score”; col 18 line 12-47, Field 824 shows the resulting risk scores that were obtained after application of each remediation plan; for example, by applying the first plan (just action [A]), the risk score of the XYZ server fleet will be reduced from 0.88 to 0.32; Fields 826 and 828 indicate different types of cost metrics associated with the remediation plans, i.e. “cash flow”; for example, field 826 indicates how many man hours each remediation plan will take to implement, and field 828 indicates the downtime to the fleet that will be caused by each plan; in some embodiments, these costs may be computed based on cost metadata stored in the remediation action library, and calculated by the remediation planning system 220; col 4 line 45-col 5 line 11, the remediation planning system may associate a cost with each remediation action or action plan; the cost of a remediation action may reflect different types of cost factors such as the amount of work needed to carry out the action, a dollar amount associated with the action (e.g. an additional licensing cost), an amount of time needed to carry out the action, a functional or business impact on the machine(s) caused by the action, etc.; these cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost), i.e. “loss value representing potential impact on the risk”); and
automatically enabling one or more actions to mitigate the asset's [malware] risk and loss, wherein the one or more actions comprises at least one of fixing misconfigurations, upgrading software using an API of cloud infrastructure, automatically generating notifications to administrators or providing at least one option to normalize the vulnerabilities associated with the technical risk, the ransomware risk, or the business risk (col 6 line 15-41, the exploitation testing component 130 may be tasked with performing exploitation tests 134 on the machine sets 110; another simulated attack may attempt to infect a machine with a particular type of malware; col 18 line 12-60, GUI 800 also includes a remediation plans section 820; the remediations plans shown in the table are generated, scored, and ranked by a planning system such as the remediation planning system 220 of FIG. 2; depending on the type of attack risk, many types of remediation actions may be indicated; for example, possible remediation actions may include applying a patch to the machines, disabling a feature provided by the machines, removing user access privileges from the machines, updating configuration settings on the machines, or isolating certain machines from the larger networks, among other measures; portions of the workflow may be generated or even executed automatically based on the remediation plans selected by the remediation planning system).
Lin does not explicitly teach wherein [malware] is ransomware.
However, Gurtu teaches the concept wherein [malware] is ransomware (abstract, methods for providing automated actions in handling security threats; [0023] machine learning engine 113 generates responses using analytics and trains itself via algorithms and/or predictive models 222 (e.g., deep learning architectures such as, for example, but not limited to, one or more of deep neural networks, convolutional deep neural networks, deep belief networks, recurrent neural networks, etc.) to learn and determine the behavior of the user; in addition, machine learning engine 113 may train a set of rules, algorithms, and/or predictive models with skills for responding to or handling security threats, alerts or knowledge; [0033] analysis and context logic 204 may retrieve or receive information from data store 223 and/or use predictive/behavioral models 222 to perform analytics based on the invoked action; for example, if the user input is “Am I at risk from Ransomware?” analysis and context logic 204 may search database 221 for the active Ransomware targeting user's industry and geo-location then analyzing if the user has simulated those attack or if there are any alerts seem for these ransomware attacks within their organization; [0043] actions may be presented to the user for selection, such as available actions 406, possible actions 407, and/or probable actions 408; available actions 406 can be security actions performed by security technologies or products that are available and enabled within an external system (e.g., systems 103-104) to resolve (e.g., eliminate or mitigate) a detected threat on such external system).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the ransomware threat learning engine of Gurtu with the assessing a cyber-risk and loss teachings of Lin. Lin already teaches a system which detects risks related to various strains of malware, and develops remediation plans related to said malware. It would therefore be obvious to incorporate means of detecting and remediation specific types of malware, such as ransomware, to secure an enterprise against the threats these specific forms of malware represent, such as widespread data loss or ransom expenditures.
Regarding Claims 2 and 10:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9. In addition, Lin teaches wherein the processor is configured to generate the technical risk machine learning model by training the first machine learning model using at least one of data associated with (a) security standards, (b) security vulnerabilities (col 3 line 48-59, model training system disclosed herein will employ an exploitation testing system (e.g. the METASPLOIT penetration testing framework) to simulate attacks against assets; the results of the exploitation tests are used to populate the target variable), (c) a location associated with the cloud infrastructure, (d) cloud storages and resources (col 7 line 27-54, cloud; data is therefore associated with cloud resources), (e) misconfiguration of security parameters, (f) identity management vulnerabilities, (g) absence of disaster recovery, (h) absence of backup, (i) absence of incidence response, (j) misconfigured or missing network security components, (k) vulnerability scan results, or (l) static and dynamic code analysis results.
Regarding Claims 4 and 12:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9. In addition, Lin teaches wherein the processor is configured to generate the ransomware risk machine learning model by training a third machine learning model with a compliance risk index that is generated by the compliance risk machine learning model (col 4 line 45-61, the remediation planning system may be configured to enumerate different permutations of remediation actions as potential remediation plans, and implement these plans to an instance of characteristics data for a set of machine(s) to generate additional instances of characteristics data; the plans are applied to the characteristics data only, without actually updating the set of machines; the additional instances of the characteristics data are then provided as input to a trained ER model to determine their respective risk scores for attacks).
Regarding Claims 5 and 13:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9. In addition, Lin teaches wherein the processor is configured to derive at least one of data associated with business to determine business risks associated with assets or cash-flow (col 4 line 45-col 5 line 11, the remediation planning system may associate a cost with each remediation action or action plan; the cost of a remediation action may reflect different types of cost factors such as the amount of work needed to carry out the action, a dollar amount associated with the action (e.g. an additional licensing cost), an amount of time needed to carry out the action, a functional or business impact on the machine(s) caused by the action, etc.; these cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost); determine, using at least one of the technology risk machine learning model, the compliance risk machine learning model or the ransomware machine learning model, the business risk associated with the assets or the cash-flow based on the derived data and inputs associated with the business and industries (col 4 line 45-col 5 line 11, the remediation planning system may associate a cost with each remediation action or action plan; the cost of a remediation action may reflect different types of cost factors such as the amount of work needed to carry out the action, a dollar amount associated with the action (e.g. an additional licensing cost), an amount of time needed to carry out the action, a functional or business impact on the machine(s) caused by the action, etc.; these cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost); determine, at least one of the technology risk machine learning model, the compliance risk machine learning model or the ransomware machine learning model, ranks for the technical risk, the compliance risk, the ransomware risk or the business risk (col 4 line 62-col 5 line 11, cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost); the remediation planning system may then use the ranking metric to rank candidate remediation plans or recommend selected plans to the user); enable at least one action to resolve at least issues assessed using the technical risk, the compliance risk, the ransomware risk or the business risk based on the determined ranks (col 6 line 15-41, the exploitation testing component 130 may be tasked with performing exploitation tests 134 on the machine sets 110; another simulated attack may attempt to infect a machine with a particular type of malware; col 18 line 12-60, GUI 800 also includes a remediation plans section 820; the remediations plans shown in the table are generated, scored, and ranked by a planning system such as the remediation planning system 220 of FIG. 2; depending on the type of attack risk, many types of remediation actions may be indicated; for example, possible remediation actions may include applying a patch to the machines, disabling a feature provided by the machines, removing user access privileges from the machines, updating configuration settings on the machines, or isolating certain machines from the larger networks, among other measures; portions of the workflow may be generated or even executed automatically based on the remediation plans selected by the remediation planning system).
Regarding Claims 6 and 14:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9. In addition, Lin teaches wherein the processor is configured to determine ranks for at least one of the technical risks, the compliance risk, the ransomware risk or the business (col 4 line 62-col 5 line 11, cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost); the remediation planning system may then use the ranking metric to rank candidate remediation plans or recommend selected plans to the user); and prioritize at least one actions to normalize the vulnerabilities associated with the technical risk, the compliance risk, the ransomware risk or the business risk based on the determined ranks (col 4 line 62-col 5 line 11, cost factors may be combined with the risk score reduction of individual remediation action plans to calculate a ranking metric for the plan (e.g. a security gain per unit of cost); the remediation planning system may then use the ranking metric to rank candidate remediation plans or recommend selected plans to the user; in this manner, the remediation planning system is able to use the ER model to programmatically determine remediation plans with the optimal balance of security gains and associated costs).
Regarding Claims 8 and 16:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9. In addition, Lin teaches wherein the processor is configured to determine the security vulnerabilities by deriving data associated with at least one of (i) Common Vulnerability Scoring System (CVSS) score, (ii) security standards, (iii) location, (iv) storage or compute resource (col 5 line 46-col 6 line 5, data collection component 122 is tasked with collecting machine characteristics data 124 from the different machine sets 110; the machine characteristics data 124 may include data about the machines that are relevant to cybersecurity assessments, such as the machines' hardware components, software components, data contents, configuration setting, operational states and metrics, event logs, and other information), (v) misconfigured security parameters, network security components, (vi) identity management, (vii) absence of disaster recovery, back-up, incidence response systems, (viii) vulnerability scan results or (ix) static or dynamic code analysis results.
Claim(s) 3, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lin in view of Gurtu, and further in view of Margolin et al (PGPUB 2023/0196243).
Regarding Claims 3 and 11:
Lin in view of Gurtu teaches the security system of claim 1 and the method of claim 9.
Neither Lin nor Gurtu teaches wherein the processor is configured to generate the compliance risk machine learning model by training a second machine learning model with a technical risk index that is generated by the technical risk machine learning model.
However, Margolin teaches the concept wherein a processor is configured to generate a compliance risk machine learning model by training a machine learning model with a technical risk index that is generated by a technical risk machine learning model (abstract, techniques for determining risk assessment predictions and decisions are disclosed; [0039] neural network module 210 may fine tune (e.g., “train”) itself and refine its parameter(s) to provide accurate predictions of categories for the labelled training dataset input into the neural network module; after one or more refinements (e.g., training steps), one or more trained parameters may be determined by neural network module 210; the trained parameter(s) (e.g., classifier(s)) may be, for example, operating parameters for neural network module 210 that generate a predictive score that is as close to the score input on the known labels as possible; these trained parameters may then be implemented by neural network module 110 (shown in FIG. 1) or another machine learning algorithm to classify datasets and provide a predictive output (e.g., a risk prediction output)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the training of a model with the output of another model teachings of Margolin with the assessing a cyber-risk and loss teachings of Lin in view of Gurtu, with the benefit of iteratively training a learning model based on previous outputs to calibrate the model towards accurate determination of known results, thereby improving the ability of the model to obtain a predictive result in unknown circumstances.
Response to Arguments
Applicant's arguments filed 1/29/2026 have been fully considered but they are not persuasive.
Regarding the claim objections:
Claims 1 and 9 were objected to for being unclear as to whether "asset, topology, network" are referring to vulnerabilities, or whether "authentication vulnerabilities" is its own category. Applicant has not remedied this lack of clarity in the claim itself. Therefore, this objection is maintained.
All other claim objections have been overcome by amendment and are therefore withdrawn.
Regarding the rejection of claims under 35 USC 112(b):
Applicant’s amendments have overcome the previous 35 USC 112(b) rejections, which are therefore withdrawn.
Regarding the rejection of claims under 35 USC 103:
Examiner’s response to applicant’s arguments, page 13 paragraph 3-page 15 paragraph 2: Applicant’s arguments appear to consist of the mere assertion that Lin fails to teach each and every limitation of claim 1. However, applicant provides no evidence or argument as to why the teachings of Lin, recited for the above elements of claim 1, do not correspond to the claimed features, which examiner notes are claimed with a high degree of generalization, e.g. “technology risk information that is categorized based on a type of at least one of data, a network, computation or authentication of the cloud infrastructure”. Further, as shown above, Lin does teach (i) malware-specific risk modelling (e.g. col 6 line 15-41), (ii) correlating compliance risk index with business parameters (e.g. col 18 line 12-47), (iii) generating a malware risk score normalized between 0 and 1 (e.g. col 13 line 23-55), and (iv) deriving an asset-level financial loss value (e.g. col 4 line 45-col 5 line 11) (examiner notes that cloud-infrastructure-specific API-based automated fixes are claimed as an optional feature). With regard to ransomware specifically, Lin recites the broad category of malware generally, of which ransomware may be considered a member; examiner argues that a person of ordinary skill in the art, familiar with different types of malware, would at once envisage applying the teachings of Lin to ransomware in addition to other types of malware. However, even if it were not the case, examiner cites Gupta as teaching risk detection and remediation in a ransomware context specifically.
Examiner’s response to applicant’s arguments, page 15 paragraph 6-page 16 paragraph 4: Features such as “correlating compliance risk indices with financial or business parameters such as asset value, cash flow, or asset criticality to determine [malware] risk and loss” and “integrating compliance data or financial context” are already features taught by Lin. Gurtu shows similar methods of threat detection and remediation applied to ransomware, thus providing evidence that ransomware is a specific member of the broader malware genus. It is not necessary for Gurtu to show that which is already taught by Lin.
Applicant further asserts that applicant’s claimed system is not for detecting threats; however, as noted above, applicant's claimed system determines technology risk, compliance risk, ransomware risk, and financial loss and predicts weak spots, checks rule compliance, measures how likely ransomware is, and even estimates the money loss if an attack happens, i.e. “predictive threat analysis”. The system of Gurtu, as noted by applicant, above, is also centered around predictive threat analysis. Therefore, the examiner is of the opinion that the two technologies are in the same field of endeavor.
Examiner’s response to applicant’s arguments, page 16 paragraph 5-page 17 paragraph 2: The argued features (e.g. automatically enabling mitigation actions using an API of cloud infrastructure or normalizing vulnerabilities across multiple risk domains, automatically generating notifications to administrators and providing at least one option to normalize the vulnerabilities associated with the technical risk, the compliance risk, the ransomware risk or the business risk), are each presented as alternatives. Lin already teaches wherein the one or more actions comprises fixing misconfigurations (e.g. col 18 line 12-60), as well as the other limitations cited above for the malware genus; Gupta’s teachings further establish the ransomware species as a member of the malware genus.
Examiner’s response to applicant’s arguments, page 17 paragraph 3-page 18 paragraph 1: Lin specifically teaches collecting data from networked machine sets, i.e. obtaining the data using a “connector”. Lin further specifically teaches that the networked environment is a cloud environment (e.g. col 7 line 27-54). Further elements that applicant recites, such as “technology, compliance, and ransomware machine-learning models” are undefined, and limited only by the general categories of data they (optionally) produce, e.g. “technology risk information that is categorized based on a type of at least one of data, a network, computation or authentication of the cloud infrastructure”. The exploitability risk model of Lin could certainly be seen as incorporating “technology risk information” categorized based on a “type of data”. Applicant merely asserts that the combination of Lin and Gupta do not teach these elements. Further, applicant argues that Lin and Gupta are directed to identifying and prioritizing vulnerabilities, threat detection, threat classification, vulnerability identification, and alert generation, and thus lacks the applicant's risk-loss computational framework and automated mitigation capability. However, Lin is specifically directed at a risk-loss computation framework and automated mitigation capability: Lin provides methods to build a machine learned exploitability risk model that predicts, based on the characteristics of a set of machines, a normalized risk score quantifying the risk that the machines are exploitable by a set of attacks (abstract), calculating the cost of remediation (i.e. “loss”, col 4 line 45-col 5 line 11), and automated mitigation capability (col 18 line 48-60, “portions of the workflow may be generated or even executed automatically based on the remediation plans selected by the remediation planning system”).
Examiner’s response to applicant’s arguments, page 18 paragraph 2-page 19 paragraph 1: However, as shown above, the combination of Lin and Gurtu teaches each and every element of claim 1.
Examiner’s response to applicant’s arguments, page 19 paragraph 2: In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “hierarchical risk modeling or financial correlation”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Examiner’s response to applicant’s arguments, page 19 paragraph 3: As shown above, Lin teaches each and every limitation required by the claim (note: mitigation actions through a cloud infrastructure API is presented as an optional alternative) with regard to the broader malware genus. Gurtu teaches similar predictive risk evaluation with regard to ransomware as a specific example of the genus. Therefore, combining the references would apply the system of Lin to ransomware explicitly, as a member of the malware genus, as well as enabling other threat prediction and mitigation features as taught by Gurtu. Lin explicitly teaches correlating compliance risk indices with business and financial parameters such as estimated remediation cost. Therefore, combining the references would provide a reasonable expectation of success.
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 FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights