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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 27 April 2026 has been entered.
Election/Restrictions
Applicant's traversal of the election by original presentation in the reply filed on 27 April 2026 is acknowledged. The traversal is on the ground(s) that the claims “incorporate all the elements of the claims from which they depend (claim 1 in particular) and therefore as readable on the elected invention” and Applicant points to various parts of the disclosure to support such.
Examiner finds Applicant’s arguments with respect to claims 18 and 22 to be persuasive with regards to the “packet parameters” being part of the elected invention, therefore, Examiner will withdraw the restriction by original presentation as they apply to the subject matter recited in these claims.
However, with respect to claims 19-20 and 23-24, this is not found persuasive because:
MPEP § 818 expressly states that “Election becomes fixed when the claims in an application have received an action on their merits by the Office. If, after receiving an action on the merits of an invention, one or more properly divisible additional inventions are subsequently presented for examination, the examiner may deem the examined invention to be the invention elected by original presentation. See MPEP § 818.02(a).”
37 CFR § 1.145 also requires that “If, after an office action on an application, the applicant presents claims directed to an invention distinct from and independent of the invention previously claimed, the applicant will be required to restrict the claims to the invention previously claimed if the amendment is entered, subject to reconsideration and review as provided in §§ 1.143 and 1.144.”
MPEP § 819 states that “The general policy of the Office is that applicants are not permitted to shift to claim another invention after an election is made and an Office action on the merits is made on the elected invention”. MPEP § 819 also states that “In addition, the applicant cannot, as a matter of right, file a request for continued examination (RCE) on claims that are independent and distinct from the claims previously claimed and examined (i.e., applicant cannot switch inventions by way of an RCE as a matter of right). See MPEP § 706.07(h), subsection VI.(B). When claims are presented which the examiner finds are drawn to an invention other than the one elected, he or she should treat the claims as outlined in MPEP § 821.03.”
Examiner previously held that claims 17-24 were withdrawn from consideration as being directed to a non-elected invention in the final rejection mailed 27 January 2026 for largely the same reasons as explained previously in the restriction requirement previously made final.
Applicant now represents withdrawn claims 19-20 and 23-24. Applicant appears to argue in the instant response that, since claims 19 and 23 depend from the elected invention, the subject matter should be considered to be elected by pointing to the specification to apparently show that merely by way of amendment to “incorporate all the elements of the claims from which they depend (claim 1 in particular)”, they should now be considered to be elected subject matter.
However, the subject matter found in claims 19-20 and 23-24 is substantially similar to nonelected claims 13 and 16. Therefore, Examiner finds Applicant’s traversal of the restriction by original presentation that nonelected subject matter should be examined with elected subject matter merely by way of their being claimed as being dependent from elected subject matter to be unpersuasive and continues to find that claims 19-20 and 23-24 recite a subcombination separately usable and is related but distinct from the invention as originally elected by Applicant.
Applicant has already received an action on the merits for the elected invention, therefore, claims 19-20 and 23-24 remain directed to a nonelected invention.
To the extent such is applicable, Applicant cannot by way of filing an RCE present claims that have been held to be directed to a nonelected invention.
The restriction by original presentation requirement of claims 19-20 and 23-24 is deemed proper and is therefore made FINAL. Claims 19-20 and 23-24 are again hereby withdrawn from consideration.
Claims 1, 3-7, 9-12, 18 and 22 are examined below.
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 18 and 22 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 18 and 22 recite “wherein the packet parameters further comprise: volume of traffic, data rate, location, region, timestamps”. It is unclear whether each and every element is required. Examiner will assume that each and every element is not required (ie. as if the limitation recites “wherein the packet parameters further comprise volume of traffic, data rate, location, region, or timestamps”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 7, 18 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over US 10555040 B2 to Chandrasekhar et al. (“Chandrasekhar”) in view of US 20170111244 A1 to Strater et al. (“Strater”).
Regarding claim 1, Chandrasekhar taught a method for classifying a traffic flow comprising:
initializing a database with packet parameters (“flow service classifier model” “trained using a training data set” with “initial features”), wherein the packet parameters comprise an Internet Protocol (IP) address of a server and at least one of a port number associated with the server, a domain name or an IP protocol associated with the server and an application associated with the server, and at least one type of content associated with the application; (consider column 8, lines 37-41 regarding “relevant information in UDP/IP or TCP/IP headers includes at least one of a total length of IP datagrams, an IP header length, IP flags, a Source Port, a Destination Port, TCP flags or a window scale in the UDP/IP or TCP/IP headers for a predetermined number of IP packets belonging to the traffic flow” and also column 7, line 31-column 8, line 17, specifically “the source and destination IP addresses” and “the port numbers” in “UDP/IP or TCP/IP headers”) (consider further column 9, lines 42-62, “The flow service classifier starts with the initial 248 features and trains a Random Forest classifier on these features. The flow service classifier ranks these features based on the mean decrease in Gini impurity and removes the lowest-ranking feature. The flow service classifier then repeats this process until the flow service classifier is left with m features. Subsequently, the flow service classifier conducts the classification on the traffic flow. A Random Forest classifier is used to classify each flow into an application category. A Random Forest is an ensemble model of decision trees. At each tree, starting from the top node, one feature is compared to a threshold value. The features traverse to one of the child nodes depending on the result of comparison. Once a leaf with no child nodes is reached, the class represented by the leaf is declared the class of the flow. The final decision is an average of the decision of each decision tree. The feature and associated threshold compared at each node of a tree is optimized by maximizing the reduction in Gini impurity. Each tree is trained using a bootstrap sample of the training dataset.”) (consider also column 12, lines 30-40, “The streaming video player state classifier 616 and the streaming video player resolution classifier 618 utilize various machine learning algorithms including one of Random Forest Model, Support Vector Machines (SVM), Logistic Regression, Naïve Bayes Classifier, Boosted Trees, Nearest Neighbor, Neural Networks and a Multilayer Perceptron. The streaming video player state classifier 616 and the streaming video player resolution classifier 618 are trained using training dataset before processing the features extracted from UDP/IP or TCP/IP headers of real-time traffic flows.”)
identifying a new flow (“detecting a start of a traffic flow”); determining packet parameters associated with the new flow; determine whether the packet parameters match any previously stored packet parameters in the database; determining an application classification and possible content categories for the traffic flow based on the previously stored packet parameters. (consider Fig. 4 and column 7, line 31-column 8, line 17, specifically “The system 410 capable of network traffic flow classification includes a base station 420 (e.g., eNB/gNB) and a flow service classifier 430…The internet network 405 streams multimedia content to a client device (or a user equipment) 440 through the base station 420, using Hypertext Transfer Protocol (HTTP) on top of Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). The base station 420 can continuously compare the source and destination IP addresses as well as the port numbers by inspecting the UDP/IP or TCP/IP headers of successive incoming packets. An event is triggered if the base station 420 identifies that a new traffic flow is arriving at the network queues belonging to the user of interest. The triggering condition is when the base station detects change in the IP addresses and/or port numbers across successive packets. Upon the event being triggered, the base station 420 buffers and copies the TCP/IP headers of the first N packets of the traffic flow and send them to the flow service classifier 430. In one embodiment, N can be chosen to be a small number, e.g., 5 packets. The flow service classifier 430 extracts multiple features from the received headers and feeds the features into a flow service classifier model, which outputs an application category to which the current packet flow belongs. The flow service classifier model can employ one of machine learning algorithms and can be trained using a training data set. By applying the extracted features to the trained classifier model, the flow service classifier 430 determines a service type (e.g., YouTube®, FTP, Web-Click®, Skype®) to which the packet traffic for the user of interest belongs to.”)
Chandrasekhar may be interpreted as not expressly teaching determining possible content categories for the traffic flow based on the previously stored packet parameters.
However, in an analogous art relating to packet inspection and classification, Strater taught determining possible content categories in addition to application classifications for a traffic flow based on previously stored packet parameters. (consider paragraphs 0029-0030, “In embodiments, the access point 105 may inspect one or more data packets from each data stream being output from the access point 105 to a client device 110 (e.g., downstream data packets/data stream). It should be understood that one or more upstream data packets (e.g., data packets received by the access point 105 from one or more client devices 110) may be inspected in order to classify one or more sessions associated with the one or more client devices 110. Using deep packet inspection (DPI), the access point 105 may utilize a DPI signature file to classify a data stream as a stream associated with a media session or a stream that is not associated with a media stream. For example, the DPI signature file may be downloaded, updated, and stored at the access point 105. [0030] Using DPI, the access point 105 may retrieve information from one or more client device streams indicating a traffic category (e.g., media, video, gaming, web, mail, etc.), application processing the data stream (e.g., Netflix, Amazon Video, etc.), device type receiving the data stream (e.g., STB, gaming device, mobile device, tablet, computer, etc.), and other characteristics associated with the one or more streams. As an example, a data stream having a traffic classification of ‘Video,’ or ‘Media,’ a data stream being processed by an application such as Netflix or Amazon Video, and/or a data stream being received by a media player (e.g., media player at a mobile device, tablet, etc.) may individually or in combination with each other provide an indication to the access point 105 that the data stream is associated with a media session.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, Examiner finds that, based on the references’ analogous disclosure regarding the usage of modeling to classify traffic flows, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Claim 7 recites a system that contain substantially the same limitations as recited in claim 1 and also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Chandrasekhar and Strater and the same rationale supporting the conclusion of obviousness.
Regarding claim 18, the combined teachings of Chandrasekhar and Strater taught the method of claim 1.
Chandrasekhar taught wherein the packet parameters further comprise: volume of traffic, data rate, location, region, timestamps. (again, consider column 8, lines 37-41 regarding the “features” including “relevant information in UDP/IP or TCP/IP headers includes at least one of a total length of IP datagrams, an IP header length, IP flags, a Source Port, a Destination Port, TCP flags or a window scale in the UDP/IP or TCP/IP headers for a predetermined number of IP packets belonging to the traffic flow”)
Regarding claim 22, the combined teachings of Chandrasekhar and Strater taught the method of claim 1.
Chandrasekhar taught the method of claim 1 wherein the packet parameters further comprise: volume of traffic, data rate, location, region, timestamps. (again, consider column 8, lines 37-41 regarding the “features” including “relevant information in UDP/IP or TCP/IP headers includes at least one of a total length of IP datagrams, an IP header length, IP flags, a Source Port, a Destination Port, TCP flags or a window scale in the UDP/IP or TCP/IP headers for a predetermined number of IP packets belonging to the traffic flow”)
Claim(s) 3-5 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekhar and Strater and in further view of US 11689944 B2 to Vasudevan et al. (“Vasudevan”).
Regarding claim 3, the combined teachings of Chandrasekhar and Strater taught the method of claim 1.
Chandrasekhar and Strater may be interpreted as not expressly teaching the method further comprising determining when a predetermined time threshold has passed or a predetermined number of flows has passed since the previously stored packet parameters were stored; reviewing the previously stored packet parameters with current traffic flows; and updating the previously stored packet parameters with parameters from the current traffic flows.
However, in an analogous art relating to usage of modeling to classify traffic flows, Vasudevan taught determining when a predetermined time threshold has passed or a predetermined number of flows has passed the previously stored packet parameters were stored; reviewing the previously stored packet parameters with current traffic flows; and updating the previously stored packet parameters with parameters from the current traffic flows. (consider column 1, line 45-column 2, line 8, “A classifier can use statistical patterns of data traffic to identify types of data flows that are present, even if the data flows are encrypted. These patterns can include packet-level statistics, such as frequency and consistency of packet transmissions, amounts of packets in a flow, and so on. A machine learning model can be trained, based on examples in a set of training data, to detect common types of data flows, e.g., corresponding to real-time calls (e.g., voice over Internet protocol (VOIP) traffic), web page transfers and other interactive situations, file transfers, media streaming, and so on. However, when the trained machine learning model is deployed and used, the model may encounter data traffic flows that do not fit the types or classes of data flows that the model has been trained to detect. To address this situation and allow the system to learn to detect new types of data, a portion of the system can be configured to detect anomalous data flows. When traffic is identified that differs from previously established data flow types, the data can be labelled and collected, and then provided to one or more other devices for further training of machine learning models. Updated machine learning models can then be provided that can account for the previously unrecognized data flow characteristics. For example, the updated model(s) may be trained to assign the data that was previously unrecognizable to a new class or category of data traffic or to assign the data to an existing class or category that is most appropriate. In this manner, there is a flow of communication between the traffic classifiers and model training system, allowing the classification models to be automatically updated and refined as new traffic patterns are encountered.”) (consider further column 3, lines 12-19, “In some implementations, the communication device is further configured to: periodically send the stored data traffic that the anomaly detector predicts to be different from the observed traffic patterns to a machine learning model update system; and receive an updated anomaly detector and an updated traffic classifier that each have a training state that is updated based on traffic labeled anomalous by the anomaly detector of one or more terminals.”) (consider further column 10, lines 27-41, “To address irregular traffic, the terminal 130 can cache information about irregular traffic that occurs during a time window. For example, the terminal 130 can store, in a cache, log, and or other form, all data for a connection detected as anomalous, as well as associated meta-data, such as the DNS, SNI, and IP address if possible. If the number of anomalous connections in a particular time window exceeds a pre-set threshold, the terminal 130 can save all the traffic and meta-data seen during that time window, including traffic not detected as anomalous. The saved data, whether for all traffic or only anomalous traffic, can be later used to update the training state of the machine learning models in the system, e.g., a real-time machine learning traffic classifier 176, a non-real-time machine learning traffic classifier, and/or the anomaly detector 174.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, Examiner finds that, based on the references’ analogous disclosure regarding the usage of modeling to classify traffic flows, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Regarding claim 4, the combined teachings of Chandrasekhar, Strater and Vasudevan taught the method of claim 3.
Chandrasekhar and Strater may be interpreted as not expressly teaching wherein the previously stored packet parameters are reviewed at predetermined time intervals, however, Vasudevan did teach these limitations. (again, consider column 3, lines 12-19, “In some implementations, the communication device is further configured to: periodically send the stored data traffic that the anomaly detector predicts to be different from the observed traffic patterns to a machine learning model update system; and receive an updated anomaly detector and an updated traffic classifier that each have a training state that is updated based on traffic labeled anomalous by the anomaly detector of one or more terminals.”)
The motivations regarding the obviousness of claim 3 also apply to claim 4, therefore, claim 4 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Chandrasekhar, Strater and Vasudevan and the same rationale supporting the conclusion of obviousness.
Regarding claim 5, the combined teachings of Chandrasekhar, Strater and Vasudevan taught the method of claim 3.
Chandrasekhar and Strater may be interpreted as not expressly teaching wherein the previously stored packet parameters are reviewed after a predetermined number of matched traffic flows, however, Vasudevan did teach these limitations. (consider column 10, lines 27-41, “To address irregular traffic, the terminal 130 can cache information about irregular traffic that occurs during a time window. For example, the terminal 130 can store, in a cache, log, and or other form, all data for a connection detected as anomalous, as well as associated meta-data, such as the DNS, SNI, and IP address if possible. If the number of anomalous connections in a particular time window exceeds a pre-set threshold, the terminal 130 can save all the traffic and meta-data seen during that time window, including traffic not detected as anomalous. The saved data, whether for all traffic or only anomalous traffic, can be later used to update the training state of the machine learning models in the system, e.g., a real-time machine learning traffic classifier 176, a non-real-time machine learning traffic classifier, and/or the anomaly detector 174.”)
The motivations regarding the obviousness of claim 3 also apply to claim 5, therefore, claim 5 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Chandrasekhar, Strater and Vasudevan and the same rationale supporting the conclusion of obviousness.
Claims 9-11 recite a system that contain substantially the same limitations as recited in claims 3-5 respectively and are also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Chandrasekhar, Strater and Vasudevan and the same rationale supporting the conclusion of obviousness.
Claim(s) 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekhar and Strater and in further view of US 20180152467 A1 to Anderson et al. (“Anderson”).
Regarding claim 6, the combined teachings of Chandrasekhar and Strater taught the method of claim 1.
Chandrasekhar and Strater may be interpreted as not expressly teaching wherein the previously stored packet parameters are determined in a lab setting and verified against real time traffic flows.
However, in an analogous art relating to using modeling to classify traffic flows, Anderson taught the use of packet parameters that are determined in a lab setting (“sandbox testing environment”) and verified against real time traffic flows (“synthetic traffic data samples”) for the purposes of initializing a database with said packet parameters and determining classifications from traffic flows. (consider paragraph 0036, “Synthetic data process 248, as described in greater detail below, may operate in conjunction with classifier process 244, to train classifier process 244 using synthetic traffic data. Generally speaking, synthetic traffic data refers to traffic data that is not actually observed in the network, but may be used nonetheless as part of the training data set for classifier process 244. Doing so allows for a more robust classifier that can be deployed to networks/environments that differ from that of the observed training data.”) (consider further paragraph 0046, “Specifically, according to one or more embodiments of the disclosure as described in detail below, a device in a network receives traffic data regarding a plurality of observed traffic flows. The device maps one or more characteristics of the observed traffic flows from the traffic data to traffic characteristics associated with a targeted deployment environment. The device generates synthetic traffic data based on the mapped traffic characteristics associated with the targeted deployment environment. The device trains a machine learning-based traffic classifier using the synthetic traffic data.”) (consider further paragraph 0048, specifically “Generally, synthetic data process 248 may be configured to generate synthetic traffic data based on captured traffic data 402 regarding actual traffic flows observed in one or more environments.”) (consider further paragraph 0049, “In some embodiments, captured traffic data 402 may be captured by one or more devices operating in a sandbox testing environment. For example, to obtain training data regarding malware-related traffic flows, one or more devices in the sandbox environment may be infected with the malware. In turn, traffic data 402 may be captured from any of the resulting traffic flows from the infected devices. Further embodiments provide for captured traffic data 402 to include information regarding traffic flows observed in one or more live environments/networks, as well.”) (consider further paragraph 0051, “Synthetic data process 248 may include a characteristic extractor 404 configured to extract and assess the various traffic characteristics from captured traffic data 402. Generally, characteristic extractor 404 may be configured to distinguish between invariant traffic flow characteristics and system-dependent traffic characteristics in captured traffic data 402.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the teachings of Chandrasekhar and Strater to include the taught features of Anderson such that the modification includes every element as claimed. Given Chandrasekhar and Strater’s disclosure of the previously stored packet parameters, Anderson specifically taught the packet parameters allow “for a more robust classifier that can be deployed to networks/environments that differ from that of the observed training data” (paragraph 0036). Given this specific advantage in Anderson which taught that, one skilled in the art would have been motivated to modify the teachings of Chandrasekhar and Strater with the teachings of Anderson such that the database containing the previously stored packet parameters as taught in Chandrasekhar and Strater may be additionally enhanced with the packet parameters that are determined in a lab setting and verified against real time traffic flows as taught in Anderson so that the previously stored packet parameters are determined in a lab setting and verified against real time traffic flows as claimed. Therefore, such a modification of the teachings of Chandrasekhar and Strater with the teachings of Anderson would have yielded nothing more than predictable results to one of ordinary skill in the art.
Claim 12 recites a system that contains substantially the same limitations as recited in claim 6 and is also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Chandrasekhar, Strater and Anderson and the same rationale supporting the conclusion of obviousness.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-7, 9-12, 18 and 22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. After further search, the newly cited prior art is further directed to packet inspection techniques in conjunction with using previously stored packet parameters as models/signatures.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
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, Tonia Dollinger, can be reached at 571-272-4170. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459
Prosecution Insights