Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 11/20/2025 have been fully considered, and when taken as a whole are persuasive. Responsive to the presently amended claims, and after further search and consideration, a new grounds of rejection is presently presented based on a Yadav (US-20160359887-A1) in view of newly cited prior art references Sundararajan (US-20200396141-A1) and Thomas (US-20180276718-A1).
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter for the reasons given below in the 35 USC 112 written description rejection. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), first paragraph:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 23 and 24 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention. Furthermore, Applicant has not pointed out where the new (or amended) claim is supported, nor does there appear to be a written description of the above noted claim limitation in the application as filed.
Regarding claim 23, said claim recites “comparing an observed order and timing of Domain Name System queries”. While pg. 23 line 21 – pg. 24 lines 24 and Fig. 7 generally discuss DNS “traffic pattern analysis”, the specification is devoid of discussion regarding an “observed order” of queries.
Regarding claim 24, said claim recites “telemetry associated with the particular online application across a plurality of distinct user accounts”. The specification lacks discussion regarding “accounts” (or even a singular a recitation of the word “account”), and thus similarly lacks support for a “plurality of distinct user accounts”.
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 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.
Claims 1 – 4, 6 - 8, 11 – 14, 16 – 18 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav (US-20160359887-A1) in view of Sundararajan (US-20200396141-A1) and Thomas (US-20180276718-A1).
Regarding claim 1, Yadav shows: a method, comprising: obtaining, by a device, telemetry data regarding Domain Name System traffic in a network (Fig. 7 steps 92-96 and [22] and [61] discussing “network data (metadata) collected . . .”); associating, by the device and based on the telemetry data, the Domain Name System traffic ([17,23,42] discussing DNS packet consideration and associated metadata); identifying, by the device, a traffic pattern ([21] discussing “suspicious network activity”, - e.g., [22] “varying sizes of text files” or [91], TTL inconsistencies - associated with the DNS traffic) of the Domain Name System traffic based on an anomaly detection model ([21] discussing application of an anomaly detection system) that has been trained ([53-54] discussing an anomaly detection model that can “learn” via “provided examples”). Yadav does not show: consideration of traffic and users associated with a particular online application; making, by the device and based on the traffic pattern, a determination that an application experience of one or more users of the particular online application is degraded; and causing, by the device and based on the determination, selective per-application routing of traffic associated with the particular online application and the one or more users to be rerouted in the network by using a different network connection.
Sundararajan shows: consideration of traffic and users associated with a particular online application ([22-23,25] discussing consideration of healthcare apps, which as [44] discusses can be responsive to application performance reports and as [25,28] note, can focus on hospital staff (the claimed “users”) utilizing, e.g., a remote surgery application) ; making, by the device and based on the traffic pattern, a determination that an application experience of one or more users of the particular online application is degraded ([34] discussing app specific traffic policies being applied, the polices being “based on information obtained from . . . [an] end user” and responsive to, as noted in [35] a particular application “experiencing too much latency”); and causing, by the device and based on the determination, selective per-application routing of traffic ([22] discussing to “enforce the application-specific policies, which as [27] notes, includes enforcement of routing policies) associated with the particular online application (described in [23] as including to “allocate dynamic tunnels between sites for facilitating an application” and the one or more users ([34] discussing consideration of application end users) to be rerouted in the network by using a different network connection ([27-28] discussing application specific (e.g., a “remote surgery” application) that utilizes a feedback cycle to adjust routing policies responsive to observed application performance and user experience).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the DNS-based network monitoring techniques of Yadav with the application and user sensitive network monitoring and routing suggested by Sundararajan in order to ensure sufficient performance for performance sensitive networking environments and applications (such as those related to providing healthcare, e.g., remote surgery) and thus enable utilization of the monitored network for additional types of applications. The above combination does not discuss global training. Thomas suggest global training ([7,22-24,38], with [7] in particular noting training data using “global . . . data from many accounts”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the global training suggested by Thomas in order to ensure the model making evaluations and routing decisions performed in Yadav in view of Sundararajan draw data from a large sampling, thus being better equipped to react to a larger number of factors, and thus providing more useful feedback (that is, using a large pool of training data to generate a better trained model).
Regarding claim 2¸ the above combination further shows wherein the Domain Name System traffic comprises Domain Name System requests (Yadav, [22-24]) sent by clients of the particular online application (Sundararajan, [34-35] discussing application-specific routing policies sensitive to reports from end-user clients the particular application).
Regarding claim 3¸ the above combination further shows wherein making the determination comprises: comparing the traffic pattern to a baseline pattern of Domain Name System traffic (Yadav, [22-24]) associated with the particular online application (Sundararajan, [34-35]).
Regarding claim 4¸ the above combination further shows providing an indication of the traffic pattern (Yadav, [56] discussing discovering of anomalies and [73-76] discussing presentation of anomaly-based alerts; [87] providing discussion of a “pervasive view of the network . . . [and] allows for tracking anomalies”) for display by a user interface (Yadav, Fig. 10 and [73,105]).
Regarding claim 6¸ the above combination further shows wherein making the determination comprises: applying an anomaly detector to the traffic pattern (Yadav, [24] discussing anomaly detection via ML applied to traffic “flagged as suspicious” during an investigation).
Regarding claim 7¸ the above combination further shows wherein the anomaly detector determines that timing between Domain Name System queries in the Domain Name System traffic is anomalous (Yadav, [91]).
Regarding claim 8¸ the above combination further shows wherein the telemetry data is from a specific geographic location (Yadav, [42] discussing a “geo-location of the sensor” and [49] discussing collected “location, state” as part of packet metadata recorded and utilized).
Regarding claim 11, Yadav shows an apparatus, comprising: one or more network interfaces (Fig. 2 item 46); a processor coupled to the one or more network interfaces and configured to execute one or more processes (Fig. 2 item 42); and a memory configured to store a process that is executable by the processor (Fig. 2 items 44 and/or 48), the process when executed configured to:
obtain, by a device, telemetry data regarding Domain Name System traffic in a network (Fig. 7 steps 92-96 and [22] and [61] discussing “network data (metadata) collected . . .”); associate, by the device and based on the telemetry data, the Domain Name System traffic ([17,23,42] discussing DNS packet consideration and associated metadata); identify, by the device, a traffic pattern ([21] discussing “suspicious network activity”, - e.g., [22] “varying sizes of text files” or [91], TTL inconsistencies - associated with the DNS traffic) of the Domain Name System traffic based on an anomaly detection model ([21] discussing application of an anomaly detection system) that has been trained ([53-54] discussing an anomaly detection model that can “learn” via “provided examples”). Yadav does not show: consideration of traffic and users associated with a particular online application; making, by the device and based on the traffic pattern, a determination that an application experience of one or more users of the particular online application is degraded; and causing, by the device and based on the determination, selective per-application routing of traffic associated with the particular online application and the one or more users to be rerouted in the network by using a different network connection.
Sundararajan shows: consideration of traffic and users associated with a particular online application ([22-23,25] discussing consideration of healthcare apps, which as [44] discusses can be responsive to application performance reports and as [25,28] note, can focus on hospital staff (the claimed “users”) utilizing, e.g., a remote surgery application) ; making, by the device and based on the traffic pattern, a determination that an application experience of one or more users of the particular online application is degraded ([34] discussing app specific traffic policies being applied, the polices being “based on information obtained from . . . [an] end user” and responsive to, as noted in [35] a particular application “experiencing too much latency”); and causing, by the device and based on the determination, selective per-application routing of traffic ([22] discussing to “enforce the application-specific policies, which as [27] notes, includes enforcement of routing policies) associated with the particular online application (described in [23] as including to “allocate dynamic tunnels between sites for facilitating an application” and the one or more users ([34] discussing consideration of application end users) to be rerouted in the network by using a different network connection ([27-28] discussing application specific (e.g., a “remote surgery” application) that utilizes a feedback cycle to adjust routing policies responsive to observed application performance and user experience).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the DNS-based network monitoring techniques of Yadav with the application and user sensitive network monitoring and routing suggested by Sundararajan in order to ensure sufficient performance for performance sensitive networking environments and applications (such as those related to providing healthcare, e.g., remote surgery) and thus enable utilization of the monitored network for additional types of applications. The above combination does not discuss global training. Thomas suggest global training ([7,22-24,38], with [7] in particular noting training data using “global . . . data from many accounts”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the global training suggested by Thomas in order to ensure the model making evaluations and routing decisions performed in Yadav in view of Sundararajan draw data from a large sampling, thus being better equipped to react to a larger number of factors, and thus providing more useful feedback (that is, using a large pool of training data to generate a better trained model).
Regarding claim 12, the limitations of said claim are addressed in the analysis of claim 2.
Regarding claim 13, the limitations of said claim are addressed in the analysis of claim 3.
Regarding claim 14, the limitations of said claim are addressed in the analysis of claim 4.
Regarding claim 16, the limitations of said claim are addressed in the analysis of claim 6.
Regarding claim 17, the limitations of said claim are addressed in the analysis of claim 7.
Regarding claim 18, the limitations of said claim are addressed in the analysis of claim 8.
Regarding claim 20, the limitations of said claim are addressed in the analysis of claim 1.
Regarding claim 24¸ the above combination further shows wherein the anomaly detection model (Yadav, [53-54]) is trained on Domain Name System telemetry (Yadav, [91]) associated with the particular online application (Sundararajan, [25,28]) across a plurality of distinct user accounts (Thomas, [7,22-24,38]), of the particular online application (Sundararajan, [25,28]).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Thomas, as applied to claim 1 above, further in view of Acosta Amador (US-9516101-B2).
Regarding claim 9, Yadav in view of Sundararajan and Thomas show claim 1. The above combination does not show: receiving, at the device, an indication from a user interface that the traffic pattern is considered normal and not indicative of the application experience being degraded. Acosta Amador shows receiving, at the device, an indication from a user interface that the traffic pattern is considered normal and not indicative of the application experience being degraded (Figs. 4, 5, 8B).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the user feedback indications suggested by Acosta Amador in order to improve routing decisions and ultimately the perceived user experience, and thus the overall functionality of the network and monitored applications (Acosta Amador, col. 6 lines 49-65).
Regarding claim 19, the limitations of said claim are addressed in the analysis of claim 9.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Thomas, as applied to claim 1 above, further in view of Ackerman (US-20230336575-A1).
Regarding claim 10, Yadav in view of Sundararajan and Thomas show claim 1. The above combination does not show: associating the traffic pattern with a particular action performed within particular online application. Ackerman shows associating the traffic pattern with a particular action performed within particular online application (Figs. 6 – 7, [22,133,135]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the correlation techniques of Ackerman in order to improve detection of malicious activity likely to further impact network performance.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Thomas, as applied to claim 1 above, further in view of Ruan (Ruan, Weizhang, Ying Liu, and Renliang Zhao. "Pattern discovery in DNS query traffic." Procedia Computer Science 17: 80-87. (Year: 2013)).
Regarding claim 23, Yadav in view of Sundararajan and Thomas shows: consideration of a DNS queries (Yadav, [16,22,53-54]) with regards to a per-application (Sundararajan, [34-45]) baseline Domain Name System pattern learned from Domain Name System telemetry (Yadav, [91]) for that application (Sundararajan, [34-45]). The above combination does not show: wherein identifying the traffic pattern comprises comparing an observed order and timing of Domain Name System queries. Ruan shows: wherein identifying the traffic pattern comprises comparing an observed order and timing of Domain Name System queries (pg. 3, Section 3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the traffic analysis techniques of Ruan in order to better extract patterns from the massive data available that is related to DNS traffic (Ruan, Abstract), thus improving the analysis techniques applicable in the combination of Yadav in view of Sundararajan and Thomas.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Ramanath (US-20170295084-A1) and Pasupathy (US-20200382387-A1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5: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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/ Primary Examiner, Art Unit 2454