DETAILED ACTION
1. Claims 1-20 have been presented for examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 2/13/23 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the Examiner has considered the IDS as to the merits.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
4. Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by Dreger, Holger, et al. "Dynamic application-layer protocol analysis for network intrusion detection." 15th USENIX security symposium. USENIX Association, 2006.
Regarding Claim 1: The reference discloses A method of operating a traffic generation tool to simulate a multi-tiered application having at least one frontend service and a plurality of backend services, the method comprising:
loading configuration files specifying a behavior of each of the at least one frontend service and the plurality of backend services; (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
with a client, sending a client request to the at least one frontend service; (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
in response to receiving the client request, sequencing a chain of additional requests involving one or more different network protocols to the plurality of backend services. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
Regarding Claim 2: The reference discloses The method of claim 1, wherein sequencing the chain of additional requests comprises sending a set of concurrent requests to two or more backend services in the plurality of backend services. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “performing parallel multiple forms of protocol analysis (e.g., decoding in parallel with computing packet-size distributions)”. Examiner notes that the parallel decoding reads on the claimed concurrent requests)
Regarding Claim 3: The reference discloses The method of claim 1, wherein sequencing the chain of additional requests comprises sending at least three requests in series to three or more backend services in the plurality of backend services. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol and which shows multiple requests representing each protocol analyzer including at least e.g. IP, TCP, SMTP, etc..)
Regarding Claim 4: The reference discloses The method of claim 1, wherein sequencing the chain of additional requests comprises: triggering a set of concurrent requests to two or more backend services in the plurality of backend services; and serially triggering at least two requests to two or more backend services in the plurality of backend services. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “dealing with multiple network substacks (e.g., IP-within-IP tunnels)”. Examiner notes that the IP-within-IP decoding reads on the claimed serial requests. See also, Page 271, right column, first sentence “analyzers to work in parallel(e.g., to perform independent analyses of the same data),or in series(e.g., to decapsulate tunnels).)”
Regarding Claim 5: The reference discloses The method of claim 4, wherein triggering the set of concurrent requests comprises sending a first request to a first backend service in the plurality of backend services via a first link established using a first network protocol and simultaneously sending a second request to a second backend service in the plurality of backend services via a second link established using a second network protocol different than the first network protocol. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1a for second network protocol via a second link seen in the separate links for TCP and Interact.)
Regarding Claim 6: The reference discloses The method of claim 4, wherein serially triggering at least two requests comprises: sending a first request to a first backend service in the plurality of backend services via a first link established using a first network protocol; and subsequent to the first backend service responding to the first request, sending a second request to a second backend service in the plurality of backend services via a second link established using a second network protocol different than the first network protocol. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1a for second network protocol via a second link seen in the separate links for TCP and Interact.)
Regarding Claim 7: The reference discloses The method of claim 4, further comprising: simulating traffic between two or more backend services in the plurality of backend services. (Page 260, left 4th paragraph, “Table 3 shows how often a different protocol appears on the standard ports of HTTP, IRC, FTP and SMTP.” Examiner Notes: The table shows the traffic represented by the number of connections on a plurality of protocols including HTTP, IRC, FTP and SMTP)
Regarding Claim 8: The reference discloses The method of claim 1, wherein the configuration files comprise a client configuration file that specifies an address and a port of a server to which the client can send the client request, a type of network protocol used to convey the client request to the server, and a response field that determines how the client behaves when receiving a corresponding response from the server. (Page 261, Table 2, showing the port, the type of network protocol, and the successful use of the port as well as the signature on the expected port or on another port. See also page 268, right column, 1st full paragraph noting the addresses logged.)
Regarding Claim 9: The reference discloses The method of claim 1, wherein the configuration files comprise an application configuration file that specifies a port for monitoring the client request, a type of network protocol used for communicating with the client, first servers to which concurrent backend requests are sent, second servers to which serial backend requests are sent, and a response field that determines how the frontend service behaves when receiving corresponding responses from the first and second servers. (Page 261, Table 2, showing the port, the type of network protocol, and the successful use of the port as well as the signature on the expected port or on another port. See also page 268, right column, 1st full paragraph noting the addresses logged.)
Regarding Claim 10: The reference discloses The method of claim 1, wherein the configuration files comprise a backend configuration file that specifies a port for monitoring a backend request from the frontend service and a type of network protocol used for communicating with the frontend service. (Page 261, Table 2, showing the port, the type of network protocol, and the successful use of the port as well as the signature on the expected port or on another port. See also page 268, right column, 1st full paragraph noting the addresses logged.)
Regarding Claim 11: The reference discloses A method of emulating traffic in a multi-tiered application, the method comprising: sending a request from a client in a first tier of the multi-tiered application to a service in a second tier of the multi-tiered application; (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol) and in response to receiving the request at the service in the second tier, automatically triggering a chain of requests from the service in the second tier to a plurality of backend services in a third tier of the multi-tiered application. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
Regarding Claim 12: The reference discloses The method of claim 11, wherein triggering the chain of requests comprises issuing parallel requests to two or more backend services in the plurality of backend services in the third tier. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “performing parallel multiple forms of protocol analysis (e.g., decoding in parallel with computing packet-size distributions)”. Examiner notes that the parallel decoding reads on the claimed parallel requests)
Regarding Claim 13: The reference discloses The method of claim 11, wherein triggering the chain of requests comprises issuing requests in series to two or more backend services in the plurality of backend services in the third tier. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “dealing with multiple network substacks (e.g., IP-within-IP tunnels)”. Examiner notes that the IP-within-IP decoding reads on the claimed serial requests. See also, Page 271, right column, first sentence “analyzers to work in parallel(e.g., to perform independent analyses of the same data),or in series(e.g., to decapsulate tunnels).)”
Regarding Claim 14: The reference discloses The method of claim 11, further comprising: loading configuration files that specify a behavior of each endpoint in the client in the first tier, the service in the second tier, and the plurality of backend services in the third tier. (Page 265, left column, “Towards these ends, our implementation uses bidirectional signatures [38], which only match if both end points of a connection appear to participate in the protocol.” See Table 4 with Config A, A’, B, and C)
Regarding Claim 15: The reference discloses The method of claim 14, wherein the configuration files comprise a first type of configuration files for specifying client-only functionality for endpoints in the first tier, a second type of configuration files for specifying server-only functionality for endpoints in the third tier, and a third type of configuration files for specifying both client and server functionality for endpoints in the second tier. (Page 265, left column, “Towards these ends, our implementation uses bidirectional signatures [38], which only match if both end points of a connection appear to participate in the protocol.” See also Table 4 showing Standard configuration, Standard + sigs, TCP, TCP +sigs, and TCP + sigs + reass which represents the multiple types of configurations for client/server functionality based on request to endpoint analysis)
Regarding Claim 16: The reference discloses The method of claim 11, further comprising: in response to receiving a request at a given backend service in the plurality of backend services, automatically triggering an additional request from the given backend service in the third tier to another backend service in a fourth tier of the multi-tiered application. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
Regarding Claim 17: The reference discloses A non-transitory computer-readable storage medium storing one or more programs configured to be executed by computing equipment running a traffic generation tool for mimicking traffic in a multi-tiered application, the one or more programs including instructions for: sending a request from a client to a web server; (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol) in response to receiving the request at the web server, directing the web server to initiate traffic with one or more first backend servers; (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol) and in response to receiving one or more response from the one or more first backend servers, directing the web server to initiate traffic with one or more second backend servers. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol)
Regarding Claim 18: The reference discloses The non-transitory computer-readable storage medium of claim 17, wherein the instructions for directing the web server to initiate traffic with one or more first backend servers comprise instructions for directing the web server to send concurrent requests to the first backend servers using two or more different network communications protocols. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “performing parallel multiple forms of protocol analysis (e.g., decoding in parallel with computing packet-size distributions)”. Examiner notes that the parallel decoding reads on the claimed concurrent requests)
Regarding Claim 19: The reference discloses The non-transitory computer-readable storage medium of claim 17, wherein the instructions for directing the web server to initiate traffic with one or more second backend servers comprise instructions for directing the web server to send concurrent requests to the second backend servers using two or more different network communications protocols. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol. Page 262, below Figure 1 where one type of analysis is “performing parallel multiple forms of protocol analysis (e.g., decoding in parallel with computing packet-size distributions)”. Examiner notes that the parallel decoding reads on the claimed concurrent requests)
Regarding Claim 20: The reference discloses The non-transitory computer-readable storage medium of claim 17, further comprising: in response to receiving one or more response from the one or more second backend servers, directing the web server to initiate traffic with one or more third backend servers. (Page 262, Section 4, “In this section we develop a framework for performing dynamic application-layer protocol analysis. Instead of a static determination of what analysis to perform based on port numbers, we introduce a processing path that dynamically adds and removes analysis components. The scheme uses a protocol detection mechanism as a trigger to activate analyzers (which are then given the entire traffic stream to date, including the portion already scanned by the detector), but these analyzers can subsequently decline to process the connection if they determine the trigger was in error. Currently, our implementation relies primarily on signatures for protocol detection, but our design allows for arbitrary other heuristics.” See Figure 1 whereby the frontend/client service request enters from the left of the Figure into the chain of various network protocols representing the backend/server services on the right of the arrow including e.g. IP, TCP, SMTP, etc.. and the configuration is based on analyzing the path based on the respective network protocol.)
Conclusion
5. All Claims are rejected.
6. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
i) Offutt, Jeff, and Sunitha Thummala. "Testing concurrent user behavior of synchronous web applications with Petri nets." Software & Systems Modeling 18.2 (2019): 913-936
ii) Catal, Faruk, et al. "Visualization of traffic flows in a simulated network environment to investigate abnormal network behavior in complex network infrastructures." Procedia Computer Science 151 (2019): 279-286.
iii) Duggirala, Vedavyas, and Srinidhi Varadarajan. "Open network emulator: A parallel direct code execution network simulator." 2012 ACM/IEEE/SCS 26th Workshop on Principles of Advanced and Distributed Simulation. IEEE, 2012.
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Saif A. Alhija whose telephone number is (571) 272-8635. The examiner can normally be reached on M-F, 10:00-6:00.
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, Renee Chavez, can be reached at (571) 270-1104. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Informal or draft communication, please label PROPOSED or DRAFT, can be additionally sent to the Examiners fax phone number, (571) 273-8635.
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).
SAA
/SAIF A ALHIJA/Primary Examiner, Art Unit 2186
Prosecution Insights