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 .
DETAILED ACTION
Specification Objections
The specification is objected to for the following reasons:
Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. The abstract is specifically objected to for the “is disclosed” language in the first sentence. 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 1 – 20 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.
Claims 1, 11, and 12 each recite mapping “parameters of the (plurality of) web application firewalls to a set of standardized management parameters.” The claims do not say what standard the parameters are “standardized” to. The term can reasonably be read as requiring conformance to an externally promulgated standard, such as an industry or standards-body schema, or as requiring only an internally defined common parameter set. The specification never uses “standardized.” It describes mapping “vendor specific parameters and functionality for WAF policies to generic parameters and functionality in the web application firewall centralized management system 194” (0048) and mapping “application parameters to management system parameters” (0017); see also (0069). The FIG. 2 description runs the mapping in the opposite direction: “Mapped parameters from mapped devices as configured in bridges are identified and retrieved, then they are mapped to application parameters in 206.” (0054). The specification therefore does not settle which parameter sets qualify as “standardized,” and a person of ordinary skill cannot determine the scope of the mapping step with reasonable certainty. MPEP §§ 2173.03, 2173.05(a). Claims 2-10 and 13-20 incorporate this limitation and are rejected for the same reason.
In addition, claim 1 recites “storing, by the management processor, the metadata in a management memory” and then “monitoring, by the management processor via the plurality of bridges, the metadata to detect changes in the security policies.” Claims 11 and 12 recite corresponding language. By antecedent, “the metadata” is the metadata already collected and stored “in a management memory.” The bridges, however, communicate with the network-security devices, not with the management memory. The claims can therefore reasonably be read as requiring either:
monitoring the stored copy in the management memory, which leaves the role of the bridges unclear; or
re-reading, through the bridges, the metadata currently resident on the devices, which is metadata the claims never introduce.
The specification describes reading (ii): “The management processor through the vendor-specific bridges coupled to the management interfaces can automatically scan a portion of the metadata for the policies to detect any changes in the policies in 1022.” (0072). The claim language, however, points to the stored metadata. The claims do not make clear which metadata is monitored. MPEP §§ 2173.03, 2173.05(e). Claims 2-10 and 13-20 incorporate this limitation and are rejected for the same reason.
In addition, claim 11 recites “each vendor-specific bridge in the plurality of vendor-specific bridges facilitates communication with a respective network-security device from a different vendor.” Claim 12 recites “each vendor-specific bridge in the plurality of vendor-specific bridges configured to facilitate communication with a respective network-security device from a different vendor.” The claims do not say what the device’s vendor must be “different” from. The phrase can reasonably be read as:
different from the vendor of the device served by every other bridge, which requires a unique vendor for each bridge/device pair;
different from the vendor of the management processor or the management system; or
indicating only that at least two vendors are represented somewhere in the plurality.
These readings define materially different scopes. The specification does not resolve the ambiguity. It discloses four bridges serving eight devices (“The system 194 includes vendor-specific bridges/ modules 180A, 180B, 180C, 180D, which bridge to load balance/security devices 112-126” (0048)), and states that “For each web application firewall, one or more connectivity bridges are identified in 204” (0054). Neither passage identifies the point of reference for “different.” Claims 13-20 incorporate the claim 12 limitation and are rejected for the same reason.
In addition, claim 7 recites “wherein the monitoring of the metadata includes scanning a subset of the metadata to optimize system performance.” Claim 11 recites “monitoring, by the management processor via the plurality of vendor-specific bridges, a subset of the metadata to detect changes in the security policies while optimizing system performance.” Claim 17 recites “the management processor is further configured to monitor a subset of the metadata to optimize system performance.” “Optimize” is a relative, result-oriented term. The claims give no metric of “performance” (such as latency, throughput, processor load, memory, or bandwidth), no baseline, and no threshold at which performance counts as optimized. The claims also do not identify whose performance is meant: “system” has no antecedent in method claims 7 and 11, and in claim 17 it may refer to the claimed system, the management processor, the network-security devices, or the enterprise network. The specification supplies no objective standard. It states only that “By only retrieving a portion of the meta-data across all of the policies, system performance is not degraded.” (0058). “Not degraded” is a different standard from “optimize,” and it is equally unmeasured. As a result, “optimize(s) system performance” is therefore left to the unconstrained judgment of the person practicing the claim. MPEP §§2173.05(b), 2173.05(g). Claims 8-10 and 18-20 incorporate this limitation and are rejected for the same reason.
In addition, claims 6 and 16 recite “wherein the alerts are generated based on detection of anomalies in the metadata.” Claim 11 recites “generating, by the management processor, alerts based on detection of anomalies in the metadata.” Whether metadata contains an “anomaly” depends on an unstated baseline and an unstated threshold of deviation. The baseline could be other policies in the same group, a historical norm, a business rule, or a threat signature. The specification supplies neither baseline nor threshold. It uses anomalies only as an example of unspecified “business requirements”: “create alerts for the changes based on business requirements such as, for example, detection of anomalies, identification of unprotected virtual IP addresses, or comparison of URLs to an access control list.” (0018); “reports and alerts may be created based on business requirements (e.g., anomalies, unprotected VIPs, URLs, etc.) in 216.” (0055).
The statement that “Common WAF implementations utilize heuristics algorithms, anomaly detection algorithms, and signature-based algorithms” (0007) concerns conventional inspection of packet traffic by a WAF. It does not supply an objective standard for anomalies in policy metadata held by the management processor. A term whose application turns on business preference or subjective judgment is indefinite. MPEP § 2173.05(b), subsection IV. Claims 7-10 and 17-20 incorporate this limitation and are rejected for the same reason.
In addition, claim 5 recites “transmitting, by the management processor, the alerts to a user interface.” Claim 10 depends from claim 5 through claims 6-9. It then introduces, again with the indefinite article, “a management user interface configured to manage the parent policy group, the policy-device associations, and the network-security devices.” The claim does not make clear whether the management user interface of claim 10 is the same interface that receives the alerts in claim 5 or a second, different one. The specification describes a single interface that manages the alerts 0075: “the management processor can also execute a management user interface to manage the global parent policy group, the policies, the policy-name device-pair policy groups, the network-security devices, the virtual IP addresses, and the alerts.”). By contrast, claim 11 consistently recites “the alerts to a management user interface” and then “the management user interface.” MPEP §§ 2173.05(e), 2173.05(o). Suggested correction: recite “a management user interface” in claim 5 and “the management user interface” in claim 10.
In addition, claim 10 recites “displaying, via the management user interface, real-time status updates of the web application firewalls.” Claim 18 recites “the management user interface is further configured to display real-time status updates of the plurality of web application firewalls.” Claim 11 recites “updating, by the management processor, the policy-device associations dynamically based on real-time changes in the inventory.”
“Real-time” and “dynamically” are terms of degree. The claims do not state how quickly an update or display must occur to be “real-time,” or what distinguishes a “dynamic” update from any other update. The specification treats real time as an aspiration of degree (“to protect against threats in as close to real-time as possible” (0008)). It describes monitoring as periodic polling at an unspecified interval (“the method may enter a wait cycle for the next update check or detection of changes in 300” (0058)). A person of ordinary skill in the art therefore cannot tell whether a display refreshed on each polling cycle, every minute, or every second falls within the claims. MPEP § 2173.05(b). In addition, claim 11 has an additional problem. The inventory is only recited as retrieved (“retrieving, by the management processor, an inventory of the web application firewalls”). No step detects “changes in the inventory,” so it is unclear how the “real-time changes in the inventory” arise or how they relate to “the detected changes” in the security policies. MPEP § 2173.05(e). Claims 19 and 20 incorporate the claim 18 limitation and are rejected for the same reason.
In addition, claim 20 recites “analyze, using a machine learning algorithm, historical metadata to predict potential security vulnerabilities.” “Historical metadata” is introduced without an article, and the claim states no relationship between it and “the metadata” that is collected, stored, and monitored in claim 12. It is unclear whether “historical metadata” means that stored metadata, prior versions of it, the “record” logged later in claim 20, or metadata of any kind from any earlier time. “Historical” is also a relative temporal term with no stated reference point. The specification does not use the phrase “historical metadata.” The only analytic data sources it names are “live traffic data from SIEM (security information and event management) enterprise resources, protection rules, and configuration items on WAF(s) systems as well as real-time threat information and cyber security news sources” (0051). In addition, “potential” security vulnerabilities has no stated standard of likelihood, severity, or confirmation that separates a “potential” vulnerability from any configuration at all. MPEP §§ 2173.05(b), 2173.05(e).
In addition, claim 20 recites “adjust, based on the predicted potential security vulnerabilities, the security policies within the policy-device associations; propagate the adjusted security policies from the parent policy group to the plurality of web application firewalls.” The adjusting step changes the security policies “within the policy-device associations,” that is, the member (child) policies. The propagating step then sends those same adjusted policies “from the parent policy group.” Claim 13 recites only that the processor is configured to “assign a parent policy group to the policy-device associations.” No claim recites any act that moves the adjusted member-level policies into the parent policy group, or makes the adjustment at the parent level. The specification describes propagation only from parent to child: “Global parent policy group(s) 184 are umbrella policies that are inherited by all child policies.” and “A change made in a parent group automatically propagates the change to child policies.” (0047). The source of the propagated policies and the order of operations are therefore uncertain. The claim can be read as (i) adjusting at the parent level with inheritance by members, (ii) elevating member adjustments to the parent group and then propagating them, or (iii) using “from the parent policy group” only to identify a set of devices. The claim does not inform one of ordinary skill of its scope with reasonable certainty. MPEP § 2173.03. Applicant is requested to clarify where the adjustment is made and the path by which the adjusted policies reach the parent policy group.
In addition, the “load balancing module…” limitation of claim 12 invokes 35 U.S.C. 112(f). Distributing traffic across servers is a specialized function that requires special programming. It is not a function that any general-purpose computer performs without special programming. In re Katz Interactive Call Processing Patent Litig., 639 F.3d 1303, 1316 (Fed. Cir. 2011). For such a computer-implemented function, the corresponding structure is an algorithm for performing it. Aristocrat Techs. Austl. Pty Ltd. v. Int’l Game Tech., 521 F.3d 1328, 1333 (Fed. Cir. 2008); MPEP § 2181, subsection II.B. The specification states only that the load balancing and security devices “can function as load balancers” (0042) and “can also in 1006 load balance application or server activity for the web applications across the servers” (0068). It identifies vendors, not structure: “Sample devices 112-126 are commercially available from F5, Citrix, Google, AWS, etc.” (0042). The specification discloses no algorithm, in prose, formula, or flowchart, by which the module decides how traffic is distributed. Saying that a known class of product performs the function is not a disclosure of corresponding structure clearly linked to that function. Claim 12 is therefore indefinite. Claims 13-20 incorporate this limitation and are rejected for the same reason. This ground does not apply to method claims 9 and 11, which do not invoke 112(f).
Applicant may:
(a) amend the claim so that the limitation is no longer interpreted under 35 U.S.C 112(f);
(b) amend the written description to expressly recite the corresponding structure, material, or acts that perform the entire claimed function, without introducing new matter (35 U.S.C. 132(a)); or
(c) state on the record what corresponding structure, material, or acts the specification implicitly or inherently discloses and clearly links to the claimed function.
In addition, claim 12 recites “a management processor configured to:” followed by a series of functions (“access,” “retrieve,” “map,” “collect,” “store,” “group,” “monitor,” “synchronize”). The last of these ends “... based on the detected changes; and” and is followed immediately by the noun phrase “a management user interface executed by the management processor configured to manage the policy-device associations and the plurality of network-security devices.” The conjunction “and” joins a noun phrase to a list of functions. As a result, the claim does not particularly point out whether the management user interface is (i) a separate element of the claimed system or (ii) something the management processor is “configured to.” In addition, in the phrase “executed by the management processor configured to manage,” it is unclear whether “configured to manage” modifies “the management processor” or “a management user interface.” These readings yield different claim scopes. MPEP § 2173.02. Claims 13-20 incorporate this language and are rejected for the same reason. Suggested correction: set the management user interface out as a separately indented element of the system, e.g., “...based on the detected changes; and (new element) a management user interface, executed by the management processor, the management user interface being configured to manage”
As a result, the metes and bounds of the claims are not clear enough to search the prior art. Appropriate correction is required.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 4 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description and enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claim 4 recites “wherein the grouping of the security policies and the web application firewalls into the policy-device associations is performed automatically using a machine learning algorithm.” Claim 11 recites “grouping, by the management processor, the security policies and the web application firewalls into policy-device associations using a machine learning algorithm.” Claim 14 recites “wherein the management processor is further configured to group the security policies and the plurality of web application firewalls into the policy-device associations using a machine learning algorithm.” Under BRI, these limitations cover any machine learning algorithm, of any learning type, trained on any data, using any inputs, that results in policies and firewalls being placed into policy-device associations. The limitation is defined by the result (grouping) and the label of a tool (a machine learning algorithm). The specification’s entire disclosure of machine-learning grouping is:
0019: the assignment “can be performed manually, automatically, automatically using machine learning, automatically using supervised machine learning, automatically using semi-supervised machine learning, automatically using unsupervised machine learning, and/or automatically using heuristics.”
0055: “Automatic assignments may be performed using machine learning, heuristics or the like etc. The machine learning may be supervised learning, semi supervised learning, unsupervised learning, based on pattern detection, or other suitable automatic learning processes.”
Paragraph (0046) states that policies “may be grouped by application, environment, region, etc.” Those are grouping criteria that an administrator or a heuristic rule could apply, and the specification lists heuristics as an alternative to machine learning (0019), (0055). What the specification does not describe is any operative machine-learning grouping embodiment:
no model or technique;
no input features or representation of policies and devices;
no training data or labels for the supervised or semi-supervised variants;
no similarity measure or objective for the unsupervised variant;
no way of converting a model output into a policy-device association.
FIG. 2, step 218, is a single box (“manual and/or automatic assignments of policies and web application firewalls to policy groups is performed in 218” (0055)). The specification names the desired result and categories of techniques that might achieve it, but does not describe how the inventor performed the grouping with machine learning. MPEP §§ 2161.01, subsection I, and 2163.03, subsection V. Claims 4, 11, and 14 are rejected under 35 U.S.C. 112(a). Claims 5-10 depend from claim 4, and claims 15-20 depend from claim 14; each is rejected for the same reason.
In addition, the specification describes the inventory only as a starting input to a scan. It states “The inventory of web application firewalls is retrieved in 202. For each web application firewall, one or more connectivity bridges are identified in 204.” (0054), and “The management processor can retrieve an inventory in 1010 of the web application firewalls” (0069). No passage describes monitoring the inventory for changes, detecting that a firewall has been added or removed in real time, or updating an association in response. The only change-detection process described concerns policy metadata: “Based on a detection of changed metadata, policies that have been changed can be loaded in 306.” (0059). The FIG. 8 field “an indication of whether it is decommissioned” (0064) is a displayed attribute, not a description of detecting real-time inventory changes and dynamically updating associations. The claim recites a result without a description of the triggering events or any algorithm for the dynamic update. MPEP §§ 2161.01,
In addition, claim 20 recites that the management processor is further configured to “analyze, using a machine learning algorithm, historical metadata to predict potential security vulnerabilities;” “adjust, based on the predicted potential security vulnerabilities, the security policies within the policy-device associations;” “propagate the adjusted security policies from the parent policy group to the plurality of web application firewalls; and” “log, in the management memory, a record of the detected changes, the generated alerts, and the adjustments to the security policies for audit purposes.”
(a) Prediction. The only machine-learning analysis disclosed apart from grouping is 0051: “The machine language engine-outlier/anomaly detection intelligence component of module 182 uses multiple data sources including live traffic data from SIEM (security information and event management) enterprise resources, protection rules, and configuration items on WAF(s) systems as well as real-time threat information and cyber security news sources to automatically detect gaps in protection and predict and suggest potential security solutions, which can be proactively mitigated using WAF configuration changes.” That passage differs from the claim in both input and output.
Input: the disclosed inputs are live traffic, protection rules, configuration items, and real-time threat and news feeds. The claimed input is “historical metadata,” and no passage describes accumulating or analyzing policy metadata over time.
Output: the disclosed output is detecting “gaps in protection” and suggesting “potential security solutions.” The claimed output is a prediction of “potential security vulnerabilities.”
Algorithm: (0051) discloses no model, features, training, or computation.
A disclosure of a different component, operating on different data to produce a different output, does not describe the claimed combination of input and output. MPEP §§ 2161.01 and 2163.05
(b) Adjustment. Paragraph (0051) contemplates that suggested solutions “can be proactively mitigated using WAF configuration changes,” and (0049-0050) describe deploying configuration updates. The specification does not describe the particular causal chain claimed: the management processor automatically adjusting the security policies within the policy-device associations based on a prediction of vulnerabilities made from historical metadata. MPEP § 2163.
(c) Propagation. Paragraph (0047) describes parent-to-child inheritance generally. The specification does not describe routing the prediction-driven adjustments of limitation (b), which are made to member policies, through the parent policy group as their source. The claimed ordering and origin of the propagation are not described. MPEP§ 2163.05.
(d) Audit record. Paragraph (0052) states that storage 190 “can contain, inter alia, logs, policy backups, threat signature databases, update files” and “tuned policies.” Paragraph (0002) refers generally to “audits.” Neither passage describes the specific combined record claimed, namely a record of the detected changes, the generated alerts, and the prediction-driven policy adjustments, maintained for audit purposes. MPEP § 2163.
For each of reasons (a) through (d), independently, claim 20 is rejected under 35 U.S.C. 112(a).
In addition, the specification names anomalies only as a category of alert trigger (0018), (0055), (0074). It refers to anomalies in policies (“Any anomalous policies can be addressed manually in intervention step 314.” (0059)) and to an outlier/anomaly component that works on traffic, rules, configuration, and threat feeds (0051). It does not describe anomalies in “the metadata,” and it does not describe any baseline, rule, threshold, comparison, or model by which the management processor recognizes an anomaly in policy metadata and triggers an alert. The synchronization engine of (0050), which “checks whether all policies in group ... are similar,” is described as a synchronization function. It is not described as detecting anomalies in metadata for alert generation. The claims recite the function and its result without the algorithm. MPEP §§ 2161.01 and 2163.03,
Claims 6, 11, and 16 are rejected under 35 U.S.C. 112(a). Claims 7-10 and 17-20 incorporate the limitation and are rejected for the same reason.
In addition, the user-interface disclosure (FIGS. 4-9, para 0060 - 0065) describes table-format pages with listed fields. These include “latest scan date, latest signature scan date, and whether signatures are in sync” (0062) and “uptime, modified timestamp” (0064). Those fields describe status attributes as recorded values. No passage describes refreshing, pushing, or streaming those values to the display in real time, or any timing relationship between an event at a web application firewall and its presentation on the interface. The only uses of “real-time” (0008), (0051) do not concern the user interface. The claimed real-time status display is not described. MPEP §§ 2163, 2163.05. Claims 10 and 18 are rejected under 35 U.S.C. 112(a). Claims 19 and 20 incorporate the claim 18 limitation and are rejected for the same reason.
In addition, claims 7,17 and 11 recite “to optimize system performance”/ “while optimizing system performance” and is construed to require that the subset of metadata be selected, or the monitoring performed, according to a criterion that optimizes system performance, the specification does not show possession of that subject matter. The specification never uses “optimize.” Its only performance disclosure is “By only retrieving a portion of the meta-data across all of the policies, system performance is not degraded.” (0058). Avoiding degradation is not optimizing. The specification identifies no metric, baseline, subset-selection rule, or algorithm by which a subset is chosen so that performance is optimized. Claims 7, 11, and 17 are rejected under 35 U.S.C. 112(a). Claims 8-10 and 18-20 are rejected for the same reason.
For the reasons above, the specification does not describe the algorithm that serves as corresponding structure for the § 112(f) limitation “a load balancing module ... configured to distribute traffic across the servers hosting the web applications.” A specification that fails to disclose adequate corresponding structure for a § 112(f) limitation also fails to show possession of the claimed function under 35 U.S.C. 112(a). MPEP §§ 2181, subsection IV, and 2163.03, subsection VI. Claim 12 is rejected under 35 U.S.C. 112(a). Claims 13-20 are rejected for the same reason. This ground does not apply to method claims 9 and 11.
[AltContent: ]Claims 4-11 and 14-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the enablement requirement. The claims contain subject matter that was not described in the specification in a way that enables one skilled in the art to make and use the invention commensurate with the full scope of the claims.
Under the BRI, claim 20 covers any machine learning algorithm, operating on any previously collected policy metadata, that predicts any “potential security vulnerabilities,” together with any automated change to any security policy caused by that prediction, across devices of every vendor. The only disclosure of machine-learning prediction is the single result-oriented sentence of (0051). That sentence describes different inputs and a different output (“predict and suggest potential security solutions”), and it discloses no model, feature, training data, label, output format, or rule for converting a prediction into a policy change. The claim scope therefore exceeds the enabling disclosure.
To practice claim 20 without guidance from the specification, one of ordinary skill would have to:
define the prediction target;
identify which policy-metadata fields predict vulnerabilities;
assemble a historical corpus of policy metadata correlated with known vulnerability outcomes, for which no source is identified;
select, train, and validate a model;
devise rules for converting each prediction into a specific change to specific policies;
adapt those changes to each vendor’s policy constructs; and
test empirically that the changes neither leave the vulnerability open nor block legitimate traffic.
This is open-ended development work, not routine experimentation. Weighing all eight Wands factors, one of ordinary skill would have had to engage in undue experimentation to make and use the full scope of claim 20. Claim 20 is rejected under 35 U.S.C. 112(a) for lack of enablement.
In addition, under BRI claims 4, 11, and 14 cover every machine learning algorithm, of every learning type, that takes any representation of policies and devices from any vendor and outputs policy-device associations. Those associations then drive synchronization and parent-group propagation. The disclosure is limited to the lists of learning categories in (0019) and (0055), the flowchart boxes for automatic assignment (step 218, (0055); step 1018, (0071), and the attribute-based grouping examples of (0046), which the specification presents as an alternative to machine learning. No operative machine-learning grouping embodiment is disclosed. The claim scope exceeds the enabling disclosure.
As a result, the metes and bounds of the claims are not clear enough to search the prior art. Appropriate correction is required.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights