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 .
This application has been examined. Claims 1-24 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
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 3, 5 and 9 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention.
• Claims 3, 5 and 9 each recite that “a service provider comprises a server and/or a container.” The “and/or” construction, combined with the dependent limitations that follow (which separately recite operations “on each of the servers” and “on… a container”), renders the metes and bounds of the claimed “service provider” unclear. It cannot be determined whether the claim requires a server, a container, or both, and the antecedent basis for “the servers” and “the container” in the subsequent limitations is correspondingly ambiguous. Clarification is required. See MPEP 2173.05(b) and 2173.05(c).
3. Claim 5 is further rejected under 35 U.S.C. 112(b). Claim 5 recites “updating the deployed data collecting service, the deployed monitoring and alerting service, and the deployed data visualizing and analyzing service.” Claim 5 depends from claim 4, which depends from claim 3, which depends from claim 2. Claim 2 already recites “updating a deployed data collecting service…” The claim is indefinite as to whether “the deployed data collecting service” of claim 5 refers to the same service introduced in claim 2 or a further service, given the intervening “first” and “second” data collecting services introduced in claim 4.
4. Claim 10 recites “the big data cluster comprises a plurality of service providers, wherein the plurality of service providers comprise servers and/or containers.” The term “service provider” lacks antecedent basis in claim 1, from which claim 10 depends (claim 1 does not introduce a “service provider”). Appropriate correction or an amendment establishing antecedent basis is required.
Examiner's note: The above are informalities readily correctable by amendment and do not preclude examination on the prior art below, which applies the claims under a broadest-reasonable-interpretation consistent with the specification.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13, 17-24 are rejected under 35 U.S.C. 103 as being unpatentable over Ayyaswami (US 10,643,181 B2) in view of Applicant's Admitted Prior Art (“AAPA,” ¶[0054]-[0063], [0112], [0128]).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Ayyaswami and AAPA references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Ayyaswami teaches a method for deploying a big data cluster, comprising: deploying a data collecting service, a monitoring and alerting service, and a data visualizing and analyzing service for the big data cluster (as shown in Fig. 1, which is reproduced below for ease of reference and convenience, Ayyaswami discloses a method for a big data analytics framework deployed over a big-data hub expressly including Hadoop (Ayyaswami, Summary: “built-in adapters for… processing engines such as Hadoop and Storm”; claim 1). The applicant's own ¶[0004] confirms a “big data cluster” is deployed to run services for high-speed computation and storage. Ayyaswami teaches web-based framework whose customization layer comprises “data collection, analysis engine, operations controller” plus “visualization tool kits,” and which is expressly “equipped with monitoring, management and control of service setup, software and hardware setup… by means of web-based portals” (Ayyaswami, col. 4:60-5:20; FIG. 1; claim 4). Modules are “deployed… based on the request” (claim 3);
PNG
media_image1.png
497
697
media_image1.png
Greyscale
collecting, by the data collecting service, operational data of the big data cluster, and uploading, by the monitoring and alerting service, the operational data to the data visualizing and analyzing service (in Ayyaswami, collects data via its data-collection layer and passes it to the visualization tool kits (Ayyaswami, col. 4:60-5:20; FIG. 1), and mandates monitoring of service / software/hardware setup (claim 4); and
displaying, by the data visualizing and analyzing service, a monitoring interface according to the operational data, wherein the monitoring interface is configured to display operational status of the big data cluster in a graphical manner (in Ayyaswami: visualization tool kits “represent data in a visual format,” pushing “graphs and charts” for interactive graphical analysis (Ayyaswami, col. 4:60-6:35; FIG. 1, FIG. 9). But Ayyaswami does not expressly disclose: name three discrete deployed services that are a data collecting service, a monitoring and alerting service, and a data visualizing and analyzing service; collecting the cluster's own operational data and uploading it, via a monitoring/alerting service, to the visualizer; graphical display is cluster operational status. In the same field of endeavor, AAPA admittedly teaches name three discrete deployed services that are a data collecting service, a monitoring and alerting service and a data visualizing and analyzing service (AAPA, supplies these as the admittedly-conventional Exporter data-collecting service (¶[0056]-[0057], [0112]), the Prometheus monitoring-and-alerting system (¶[0055]), and the Grafana data-visualizing-and-analyzing suite (¶[0054]);
collecting the cluster's own operational data and uploading it, via a monitoring/alerting service, to the visualizer (in AAPA supplies this: the Exporter/Node Exporter “collect[s] server-level running indicators” and container/CPU/memory/disk/IO usage (¶[0056]-[0057]); Prometheus scrapes and “transmit[s] crawled data to the Grafana service” (¶[0055], [0131]); and
graphical display is cluster operational status (in AAPA supplies graphical display of operational status: Grafana “create[s] a monitoring dashboard to achieve visualization of the monitoring data” with “fast and flexible visualization” (¶[0054]); physical-layer and component-layer monitoring interfaces display server/container operational data (¶[0160], [0166]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to implement Ayyaswami's expressly-recited framework monitoring (Ayyaswami, claim 4) using the admittedly-conventional Exporter/Prometheus/Grafana stack (AAPA). The motivation to combine comes directly from the primary reference: Ayyaswami mandates monitoring of “service setup, software and hardware setup” over “web-based portals” but leaves the implementation open, and a skilled artisan seeking to carry out that mandate would select the off-the-shelf, industry-standard monitoring stack the applicant admits was already dominant for exactly this purpose. The result is the graphical visualization of cluster operational status over a Hadoop cluster which is the predictable output of using a known technique to improve a similar system in the way it was already used. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007); MPEP 2143(A), (C), (D). The combination is further supported by the fact that AAPA's stack and Ayyaswami's framework operate on the same base technology (Hadoop-based clusters), so their combination involves no change in the respective functions of either and yields no unexpected result.
In regard to claim 2, Ayyaswami teaches wherein deploying the data collecting service, the monitoring and alerting service, and the data visualizing and analyzing service for the big data cluster comprises:
according to a deployed service provider in the big data cluster, deploying the data collecting service, the monitoring and alerting service, and the data visualizing and analyzing service for the deployed service provider in the big data cluster (in Ayyaswami: modules are deployed for the servers/service providers of the framework and scale by “dynamic addition of servers”; monitoring/visualization deployed for the framework (Ayyaswami, claims 1, 4; col. 4:60-6:20). AAPA confirms services deployed per deployed service provider (¶[0123]); and
in response to an update operation on the deployed service provider in the big data cluster, updating a deployed data collecting service, a deployed monitoring and alerting service, and a deployed data visualizing and analyzing service in the big data cluster, wherein the update operation on the deployed service provider comprises deleting the deployed service provider and deploying a new service provider (in Ayyaswami: modules “are created, tested, initiated, stopped, restarted, upgraded, modified, deleted, deployed, and un-deployed based on the request” (Ayyaswami, claim 3), i.e., update by deleting and deploying). But Ayyaswami does not tie that update to reconfiguring a monitoring data-source list. AAPA supplies modifying the Prometheus first configuration file (target list) upon adding/deleting a server or container (¶[0136], [0148]-[0151], [0174]-[0180]). Same rationale/motivation to combine as claim 1.
In regard to claim 3, Ayyaswami teaches wherein a service provider comprises a server and/or a container, the big data cluster comprises servers, and the servers comprise a management server (in Ayyaswami: framework runs over servers accessed via a communication network and cloud service providers, with dynamic addition of servers (Ayyaswami, FIG. 1; spec re scalability). AAPA: cluster includes multiple servers and a management server acting as the core device (¶[0105], [0124]);
according to the deployed service provider in the big data cluster, deploying the data collecting service, the monitoring and alerting service, and the data visualizing and analyzing service for the deployed service provider in the big data cluster comprises:
according to servers and containers in the big data cluster, deploying the data collecting service on each of the servers of the big data cluster, and deploying the monitoring and alerting service and the data visualizing and analyzing service on the management server of the big data cluster (in AAPA: “deploying the data collecting service on each of the servers… and deploying the monitoring and alerting service and the data visualizing and analyzing service on the management server” (¶[0125]); Prometheus and Grafana deployed once on the management server (¶[0126]). AAPA supplies this centralized management-server deployment (¶[0124]-[0126]). Same rationale/motivation to combine as claim 1.
In regard to claim 4, AAPA teaches wherein the data collecting service comprises a first data collecting service and a second data collecting service, wherein the first data collecting service is used to collect operational data of a server, and the second data collecting service is used to collect operational data of a container;
according to the servers and the containers in the big data cluster, deploying the data collecting service on each of the servers of the big data cluster comprises:
deploying the first data collecting service and the second data collecting service on the management server, and deploying the first data collecting service on each of the servers except the management server (in AAPA: physical-layer (first) vs. component-layer (second) data collecting services for servers vs. containers (¶[0118]); first + second on management server, first on each other server (¶[0127]). Same rationale/motivation to combine as claim 1.
In regard to claim 5, AAPA teaches wherein the service provider comprises a server and/or a container, and the monitoring and alerting service corresponds to a first configuration file;
in a case where the update operation on the deployed service provider comprises deploying a new service provider, in response to the update operation on the deployed service provider in the big data cluster, updating the deployed data collecting service, the deployed monitoring and alerting service, and the deployed data visualizing and analyzing service in the big data cluster comprises at least one of:
in response to addition of a new server in the big data cluster, deploying the first data collecting service on the new server, and modifying the first configuration file corresponding to the monitoring and alerting service according to a new service provider, to enable the deployed monitoring and alerting service and the deployed data visualizing and analyzing service in the big data cluster to provide services for the new server; or
in response to addition of a new container in the big data cluster, modifying the first configuration file corresponding to the monitoring and alerting service according to a new server, to enable the deployed second data collecting service, the deployed monitoring and alerting service, and the deployed data visualizing and analyzing service in the big data cluster to provide services for the new container (in AAPA: Prometheus maintains a first configuration file recording data-source targets; on adding a server, deploy Node-Exporter and modify the file (¶[0134]-[0138], [0174]-[0180]); on adding a container, modify the file (¶[0140]). Same rationale/motivation to combine as claim 1.
In regard to claim 6, AAPA teaches wherein, in a case where the update operation on the deployed service provider comprises deleting the deployed service provider, in response to the update operation on the deployed service provider in the big data cluster, updating the deployed data collecting service, the deployed monitoring and alerting service, and the deployed data visualizing and analyzing service in the big data cluster comprises at least one of:
in response to deletion of a deployed server in the big data cluster, deleting the first data collecting service corresponding to a deleted server, and modifying the first configuration file corresponding to the monitoring and alerting service according to the deleted server, to enable the deployed monitoring and alerting service and the deployed data visualizing and analyzing service in the big data cluster no longer to provide services for the deleted server; or
in response to deletion of a deployed container in the big data cluster, modifying the first configuration file corresponding to the monitoring and alerting service according to a deleted server, to enable the deployed second data collecting service, the deployed monitoring and alerting service, and the deployed data visualizing and analyzing service in the big data cluster no longer to provide services for the deleted server (in AAPA: on deletion of a server, delete the first data collecting service and modify the config file (¶[0148]-[0149]); on deletion of a container, modify the config file (¶[0150]-[0151]). Same rationale/motivation to combine as claim 1.
In regard to claim 7, AAPA teaches wherein the data collecting service, the monitoring and alerting service, and the data visualizing and analyzing service are located in one Overlay network, the data collecting service comprises an Exporter service, the monitoring and alerting service comprises a Prometheus service, and the data visualizing and analyzing service comprises a Grafana service (in AAPA: Prometheus server, Grafana, and all Exporters set up in the same Overlay network (¶[0153]-[0156]); Exporter=data collecting, Prometheus=monitoring/alerting, Grafana=visualizing/analyzing (¶[0112]). Same rationale/motivation to combine as claim 1.
In regard to claim 8, AAPA teaches wherein the first data collecting service comprises a Node- Exporter service; in a case where the container corresponds to an HDFS component or a YARN component, the second data collecting service comprises a Hadoop Exporter service; in a case where the container corresponds to a Clickhouse component, the second data collecting service comprises a Clickhouse Exporter service (in AAPA: Node Exporter for servers; Hadoop Exporter for HDFS/YARN containers; Clickhouse Exporter for Clickhouse containers (¶[0057], [0119], [0129]). Same rationale/motivation to combine as claim 1.
For each of claims 4-8, Ayyaswami does not disclose the specific Overlay-network arrangement or the component-specific Exporter/configuration-file mechanics; these limitations are supplied entirely by AAPA as admitted conventional practice, cited above. The motivation to combine is the same as stated for claim 1 as the use of the admitted, off-the-shelf Prometheus/Exporter/Grafana mechanics to implement Ayyaswami's expressly-recited monitoring function, with predictable results (KSR; MPEP 2143(A)).
In regard to claim 9, AAPA teaches wherein a service provider comprises a server and/or a container; for servers in the big data cluster, the operational data comprises disk space usage data, network traffic data, CPU usage data, memory usage data, or any combination thereof; and for containers in the big data cluster, the operational data comprises big data service usage data, container status data, or a combination thereof (in AAPA: for servers, operational data includes disk space, network traffic, CPU, memory usage; for containers, big data service usage and container status data (¶[0128]). Same rationale/motivation to combine as claim 1.
In regard to claim 10, AAPA teaches wherein the big data cluster comprises a plurality of service providers, wherein the plurality of service providers comprise servers and/or containers; displaying the monitoring interface according to the operational data comprises at least one of:
according to the operational data of servers in the big data cluster, displaying a physical- layer monitoring interface, wherein the physical-layer monitoring interface is configured to display the operational data of the servers in the big data cluster; or according to the operational data of containers in the big data cluster, displaying a component-layer monitoring interface, wherein the component-layer monitoring interface is configured to display the operational data of the containers in the big data cluster (in AAPA: physical-layer monitoring interface displays server operational data (¶[0160]); component-layer monitoring interface displays container operational data (¶[0166]). Ayyaswami provides graphical/visual monitoring and visualization views (Ayyaswami, claim 4; col. 4:60-6:35; FIG. 1, FIG. 9). Same rationale/motivation to combine as claim 1.
In regard to claim 11, AAPA teaches further: in response to an anomaly in the operational data collected by the data collecting service, transmitting alerting information by the monitoring and alerting service (in AAPA: “if there is an abnormality in the operational data… an alarm message can be transmitted through the monitoring and alerting service” (¶[0187]); Prometheus is an “alerting system” (¶[0055]). Same rationale/motivation to combine as claim 1.
In regard to claim 12, Ayyaswami teaches wherein the big data cluster comprises servers, and the servers comprise a management server;
the method further comprises:
displaying a deployment interface, and displaying a management node corresponding to the management server in the deployment interface; and
the method further comprises:
in response to a drag and drop operation on the management node in the deployment interface, copying configuration data of the management server to a destination server indicated by the drag and drop operation (in Ayyaswami: web-based deployment interface with graphical/visual programming and drag-oriented module manipulation (Ayyaswami, col. 4:60-6:18; FIG. 5)). Ayyaswami does not disclose a management node dragged to copy configuration data to a destination server. AAPA/specification supplies displaying a management node and, in response to a drag-and-drop, copying the management server's configuration data to the drag-target destination server (¶[0212]-[0215]). Same rationale/motivation to combine as claim 1.
In regard to claim 17, AAPA teaches further: deploying a gateway proxy service for the big data cluster, wherein the gateway proxy service is configured to provide an access function for a user outside the big data cluster (in AAPA: gateway proxy service “can be a Knox service” providing external access (¶[0188]-[0191]); Apache Knox admittedly “provide[s] access to Apache Hadoop through an HTTP resource proxy” (¶[0058]). Ayyaswami provides external client access to the framework over a network with identity management, policy-driven access control and OAuth-level authentication (Ayyaswami, claim 5; FIG. 1). Same rationale/motivation to combine as claim 1.
In regard to claim 18, AAPA teaches wherein the big data cluster comprises servers, and the servers comprise a management server;
deploying a gateway proxy service for the big data cluster comprises:
deploying the gateway proxy service on the management server; and
in response to addition of a new service provider in the big data cluster, deploying the gateway proxy service for the new service provider (in AAPA: gateway proxy deployed on management server; updated for newly added server/container (¶[0192]-[0195]). Same rationale/motivation to combine as claim 1.
In regard to claim 19, AAPA teaches further:
displaying a deployment interface and displaying an information viewing control in the deployment interface, wherein the information viewing control is configured to provide a viewing function for a network address of a container; and
in response to a triggering operation of the information viewing control, displaying the network address of the container displayed in the deployment interface (in AAPA: “Connection Information” control in the deployment interface returns the container network address (Knox proxy URL / JDBC URL) (¶[0199]-[0206]). Same rationale/motivation to combine as claim 1.
In regard to claim 20, AAPA teaches wherein the deployment interface comprises a deployment resource pool region, wherein the deployment resource pool region is configured to display a node corresponding to a deployed container on a server of the big data cluster; and displaying the information viewing control in the deployment interface comprises: displaying the information viewing control in the deployment resource pool region of the deployment interface; and in response to the triggering operation of the information viewing control, displaying the network address of the container displayed in the deployment interface comprises: in response to the triggering operation of the information viewing control, displaying the network address of the container displayed in the deployment resource pool region (in AAPA: information viewing control set in the deployment resource pool region; container network address displayed there (¶[0200]). Same rationale/motivation to combine as claim 1.
In regard to claim 21, AAPA teaches wherein a service provider deployed in the big data cluster is deployed according to a drag and drop operation on a node in a deployment interface (in AAPA: containers deployed by drag-and-drop of nodes from the temporary resource pool to physical pools (¶[0091]-[0095], [0107]). Ayyaswami: visual/graphical deployment interface (Ayyaswami: col. 4:60-6:20; FIG. 5). Same rationale/motivation to combine as claim 1.
Claim 22 (apparatus) recites the same operative limitations as method claim 1. The change in claim format from method to apparatus does not confer patentability where the underlying operations are identical to those taught by the applied references. See MPEP § 2114; In re Bernhart, 417 F.2d 1395 (CCPA 1969). The element-by-element mapping set forth for claim 1 applies with equal force to claims 22.
In regard to claim 23, AAPA teaches a computer device comprising a memory, a processor and a computer program stored on the memory and runnable on the processor, wherein the processor, when executing the program, achieves the method according to any one of claims 1 to 21 (in Ayyaswami discloses a data processing system with processor(s) and memory executing the method (Ayyaswami: col. 4:60-5:20; “a typical data processing system… processors… memory”; ); AAPA ¶[0299]. Same rationale/motivation to combine as claim 1.
In regard to claim 24, Ayyaswami teaches a computer-readable storage medium, wherein the storage medium stores a program, and the program when executed by a processor achieves the method according to any one of claims 1 to 21 (in Ayyaswami discloses a signal-bearing/recordable medium (Ayyaswami “a recordable-type medium such as a floppy disk, a hard disk drive, a CD, a DVD…”); AAPA ¶[0300] (non-transitory forms). Same rationale/motivation to combine as claim 1.
Claims 23-24 fall for the reasons given for the corresponding method limitations. Where claim 23 and 24 recite “any one of claims 1 to 21,” the rejection applies to the claim scope inclusive of the rejected dependent claims.
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Allowable Subject Matter
Claims 13-16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is an Examiner's statement of reasons for the indication of allowable subject matter:
Claim 13-14 (and, to the extent of the corresponding limitations, claims 15 and 16, and the virtual-IP-switchover portion of claim 13) recite, in the context of migrating services from a management server to a destination server: initiating services corresponding to the copied configuration data on the destination server, and only in response to determining that each of the services on the destination server is initiated normally — deleting the preset virtual IP address for the management server and configuring that virtual IP address to the destination server. The prior art of record (AAPA + Ayyaswami and the additional references cited below) discloses conventional Prometheus/Grafana/Exporter monitoring and drag-based deployment, but does not teach or suggest the specific start-verification-gated virtual-IP switchover i.e., conditioning the ARP-based virtual-IP handover on prior confirmation that every migrated service has started normally on the destination server — which achieves user-imperceptible service migration (see specification ¶[0228]-[0239]).
Claims 15 and 16 depend from claim 13 and recite further migration-prompt and node-deletion detail. Claim 14 depends from claim 13. To be allowable, the start-verification-gated virtual-IP-switchover limitation of claim 14 would need to be placed in independent form including all of the limitations of the base claim and any intervening claims, and the § 112 issues noted for claim 3 (from which the chain ultimately depends only through claim 1) do not affect this chain (claims 12-16 depend from claim 1). Applicant is invited to rewrite claim 14 (with the verified normal-start condition) in independent form.
Examiner's honest assessment: The core three-service monitoring architecture of independent claims 1, 22, 23 and 24 is not allowable and it is squarely the applicant's own admitted Prometheus/Grafana/Exporter prior art applied to a big-data framework of the Ayyaswami type. The patentable weight, if any, resides in the virtual-IP start-verified migration of claims 13(part)/14. No claim is being characterized as allowable merely to be generous; the indication is limited to the specific migration limitation for which the search did not return a teaching.
Conclusion
Claims 1-12, 17-24 are rejected. Claims 13-16 are objected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Babu et al., US 2016/0239399, teach Hadoop cluster-level monitoring “Ops Central” with deep events, live alerts, and visual resource-usage breakdowns which is pertinent to claims 1, 10, 11 (cluster-level graphical monitoring and alerting of a Hadoop cluster).
Furuhashi et al., US 9,582,528, teach Hadoop-based big-data platform with a web-console graphical query/visualization interface which is pertinent to claims 1, 19 (graphical interface over a Hadoop cluster; web console access).
Giannetti et al., US 11,579,941, teach control cluster with a unified dashboard visualizing monitoring data, cluster status, and unified alerts for multiple containerized clusters; workload deployment to selected clusters which is pertinent to claims 1, 10, 11, 17 (centralized monitoring / deployment for container clusters).
Ko et al., US 2017/0371718 teach distribution and execution of analytics workloads across distributed data nodes which is pertinent to claims 2, 3, 4 (per-node service deployment).
Rosca et al., US 2020/0089182, teach distributed data collection and management with visualization which is pertinent to claims 1, 9 (operational-data collection types and visualization).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
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 hop://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).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights