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 .
Election/Restrictions
Newly submitted claims 17-24 are directed to an invention that is independent or distinct from the invention originally claimed for the following reasons:
As previously indicated in the Restriction Requirement mailed 28 March 2025 and the non-final action mailed 15 July 2025 wherein the restriction requirement was made final, it was found that the subject matter relating to determining an application change in the application behavior, detecting a category change in a content category of the application, and providing an updated traffic action based on the detected change recited within nonelected invention II, limitations not found within the recitations of elected invention I.
Here, Applicant has chosen to reintroduce this subject matter as dependent claims without any indication of which of these subsequently added claims are readable upon the elected invention. Absent any such indication and in accordance with the restriction requirement of record, Examiner finds that claims 17-24 contain subject matter previously held to be directed to a nonelected invention and are hereby held to be distinct from the invention originally elected.
Since applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits. Accordingly, claims 17-24 are withdrawn from consideration as being directed to a non-elected invention. See 37 CFR 1.142(b) and MPEP § 821.03.
To preserve a right to petition, the reply to this action must distinctly and specifically point out supposed errors in the restriction requirement. Otherwise, the election shall be treated as a final election without traverse. Traversal must be timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are subsequently added, applicant must indicate which of the subsequently added claims are readable upon the elected invention. (Examiner’s emphasis added.)
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
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.
Claim 3 is 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.
Claim 3 recites “determining when a predetermined time threshold has passed or a predetermined number of flows has passed the previously stored packet parameters were stored”. This limitation is unclear as it is in improper idiomatic English. Examiner will assume that these limitations recite “determining when a predetermined time threshold has passed or a predetermined number of flows has passed since the previously stored packet parameters were stored” as such would be commensurate with the recitations within claim 9.
Claim Rejections - 35 USC § 102
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 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.
Claim(s) 1 and 7 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 10555040 B2 to Chandrasekhar et al. (“Chandrasekhar”).
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”), wherein the packet parameters comprise an Internet Protocol (IP) address of a server (“server” as a “source”; consider column 4, lines 6-10) and at least one of a port number, a domain name or an IP protocol and an application associated with the server (consider Fig. 4 and column 7, line 31-column 8, line 17, specifically “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.”); (consider 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 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.”)
Claim 7 recites a system that contain substantially the same limitations as recited in claim 1 and is also rejected under 35 USC § 102(a)(1) as being anticipated by the same teachings of Chandrasekhar.
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) 3-5 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekhar in view of US 11689944 B2 to Vasudevan et al. (“Vasudevan”).
Regarding claim 3, Chandrasekhar taught the method of claim 1.
Chandrasekhar 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 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 and Vasudevan taught the method of claim 3.
Chandrasekhar 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 and Vasudevan and the same rationale supporting the conclusion of obviousness.
Regarding claim 5, the combined teachings of Chandrasekhar and Vasudevan taught the method of claim 3.
Chandrasekhar 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 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 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 in view of US 20180152467 A1 to Anderson et al. (“Anderson”).
Regarding claim 6, Chandrasekhar taught the method of claim 1.
Chandrasekhar 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 to include the taught features of Anderson such that the modification includes every element as claimed. Given Chandrasekhar’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 with the teachings of Anderson such that the database containing the previously stored packet parameters as taught in Chandrasekhar 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 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 and Anderson and the same rationale supporting the conclusion of obviousness.
Response to Arguments
Applicant's arguments filed in the instant response have been fully considered but they are not persuasive.
Applicant argues that “Applicant submits that Chandrasekhar relates to flow service classification methods for experience centric cellular scheduling (Column 1, lines 20 to 23). Column 7 lines 43, to 48 detail continuously comparing source and destination IP address as well as port numbers to identify when a new traffic flow is arriving at the network queues. Applicant submits that continuously comparing the source and destination IP to successive packets is not analogous to reviewing the server IP address and at least one other factor in order to classify the application type of the traffic flow as claimed in claim 1.”
However, the claim requires nothing more than more specifically reciting various “packet parameters” to which the parameters within the “new flow” are “determined” to “match any previously stored packet parameters in the database”. Chandrasekhar clearly teaches within the selection applied to claim 2 that “by inspecting the UDP/IP or TCP/IP headers of successive incoming packets”, “the source and destination IP addresses as well as the port numbers” of these “successive incoming packets” can be “compared”. Further within the selection previously provided further teaches that “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.” The selection then also teaches that “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”.
Therefore, given that the claimed database corresponds to the “flow service classifier model” “trained using a training data set” taught in Chandrasekhar, Examiner is unpersuaded that Chandrasekhar fails to teach the more specific packet parameters of “an Internet Protocol (IP) address of a server and at least one of a port number, a domain name or an IP protocol and an application associated with the server” and “determining an application classification for the traffic flow based on the previously stored packet parameters” as required by the claim.
Applicant also appears to argue secondary considerations by stating that “Applicant submits that building the database and classifying traffic flows using the database is intended to save classification costs and detailed in paragraph 85 of the application. As the flows are classified via server profiling there is intended to be cache and processing savings which are not provided in conventional systems (as detailed in paragraph 87). Applicant submits that saving processing and cache costs is a technical solution to a technical problem not considered in the cited art” and “Applicant submits that Chandrasekhar avails itself of conventional classification techniques noted in the current application as requiring further processing and cache costs…As such, Applicant submits that Chandrasekhar does not disclose or suggest server profiling as is claimed in claim 1”.
However, these secondary considerations are irrelevant to 35 U.S.C. 102 rejections and thus cannot overcome a rejection so based. See MPEP § 2131.04.
Therefore, while the rejection is updated to reflect the minor changes from the incorporation of the subject matter from claims 2 and 8 into claims 1 and 7, the thrust of the rejection remains the same and the rejection under Chandrasekhar is maintained.
The rejections with respect to claims 3-5 and 9-11 have also been updated given these amendments, however, the thrust of the rejections remains the same. Applicant’s generic argument regarding claims 3-6 and 9-12 not being anticipated or rendered obvious “for the additional elements claimed therein” amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references and does not comply with the requirements of 37 CFR 1.111. See also MPEP §§ 714.02, 714.04. Absent any persuasive rationales and the claims being clearly open to rejection on the grounds of record, the rejections of these claims is maintained.
Conclusion
An updated search did not reveal additional prior art that is relevant to the claimed invention or to the broader disclosure.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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