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 4/27/2026 have been fully considered, and when taken as a whole are persuasive. However, after further search and consideration, a new grounds has been made further in view of Shitrit (US-20180351976-A1).
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 10, 14, 19, and 20 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. Regarding claim 10, said claim further limits “the particular action” introduced in parent claim 1. However, parent claim 1 recites two alterative possibilities: association with a “particular web page” or association with a “particular action”. Claim 10 is directed solely to the “particular action” embodiment, but to fails to note that the “particular action” option is the only operable choice (e.g., via initially reciting “where the traffic pattern is associated with the particular action performed . . .”). Thus the currently presented form of claim 10 is presented as further limiting claim 1, when in fact it only further limits one of two embodiments of claim 1. When the “particular web page” embodiment of claim 1 is the operable embodiment, claim 10 thus fails to limit its parent claim. The resultant ambiguity as to the impact of claim 10 on the overall scope of claim 1 renders the claim unclear and indefinite in scope. Regarding claim 14, said claim references a determination based on detection of a “permanent change”. Whether something is permanent is effectively a term of degree (as something is considered permanent is based on one’s perspective). However, after review of the specification for guidance on how to evaluate the term of degree (i.e., “permanent”), the Examiner has been unable to locate guidance for its evaluation. The use of the term “permanent” thus renders the claim scope unclear and indefinite, as there is no guidance regarding how to evaluate whether something would be considered “permanent”. In order to perform a complete examination, the “permanent change” is considered analogous to a change that is “considered normal” (as is recited in claim 11) or otherwise not cause for alarm or concern.
Regarding claim 19, said claim recites reception of information from an “expert” user. Whether a user is considered an “expert” corresponds to use of a term of degree (as evaluation of a person as an “expert” is a subjective evaluation). However, after review of the specification for guidance on how to evaluate the term of degree (i.e., “expert”), the Examiner has been unable to locate guidance for its evaluation. The use of the term “expert” thus renders the claim scope unclear and indefinite, as there is no guidance regarding how to evaluate when a user is considered an “expert”. In order to perform a complete examination, the “expert” user is considered any user with permission or capability to issue or otherwise provide the claimed “indication from the user interface” recited in claim 19.
Regarding claim 19, said claim has been amended to recite, when concluding on page 6 and continuing on claim 7, the language: “wherein the traffic pattern is based on Domain Name System processing times in the Domain Name System logs used as a proxy for application experience of one or more users of the particular online application”.
The “used as a proxy for” language is rendered unclear and indefinite by the lack of clarity regarding what exactly is “used a proxy for application experience”; i.e., the “traffic pattern” or the DNS “processing times”? Or a combination of both?
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, 2, 3, 6, 7, and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav (US-20160359887-A1) in view of Sundararajan (US-20200396141-A1) and Shitrit (US-20180351976-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 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, while discussing consideration of a particular online application when evaluating traffic (e.g., Sundararajan, [58,64]) does not show: identifying, by the device, a traffic pattern of the Domain Name System traffic associated with a particular endpoint, wherein identifying the traffic pattern comprises determining whether timing between Domain Name System queries in the Domain Name System traffic is anomalous relative to a baseline Domain Name System traffic pattern associated with the particular endpoint. Shitrit shows: identifying, by the device, a traffic pattern of the Domain Name System traffic associated with a particular endpoint (e.g., the content located at a particular accessed domain, such as the content at www.google.com, as discussed in [28]), wherein identifying the traffic pattern comprises determining whether timing between Domain Name System queries in the Domain Name System traffic is anomalous relative to a baseline Domain Name System traffic pattern associated with the particular endpoint (Fig. 5, [33-35,66]).
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 the above combination with the attack detection of Shitrit in order to improve the ability of the resultant disclosure to detect both anomalies and attacks, and thus improve the stability and reliability of the monitored network.
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 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 corresponding to the particular web page (Shitrit, [28,31,53,62] discussing the content corresponding to a URL such as “www.google.com”) or the particular action is anomalous (Sundararajan, [34-35]) 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).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Shitrit, as applied to claim 1 above, further in view of Garvey (US-20200267057-A1).
Regarding claim 4, the above combination shows claim 1, including 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]).
The above combination does not show providing an indication of the traffic pattern and the baseline traffic pattern. Garvey suggests providing an indication of the traffic pattern and the baseline traffic pattern (Fig. 9C, [139-140]).
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 the above combination with the baseline condition awareness and information display techniques of Garvey in order to provide addition information to the system administrator, enabling more informed decisions regarding system status.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Shitrit, as applied to claim 1 above, further in view of Acosta Amador (US-9516101-B2).
Regarding claim 9, the above combination shows 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).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Shitrit, as applied to claim 1 above, further in view of Bates (US-20170061307-A1).
Regarding claim 10, the above combination shows claim 1. The above combination does not show: where the particular action is a user-initiated action performed within the particular online application.
Bates shows where the particular action is a user-initiated action performed within the particular online application ([19,27,46,58,65] discussing monitoring user actions such as link clicks in a network application).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the monitoring and anomaly detection techniques of the above combination with the Internet application awareness of Bates in order to facilitate anomaly detection across additional web-accessible resources, thus enabling monitoring and protection of those additional resources.
Claims 11 – 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan, Shitrit, Garvey, and Shemer (US-20220029902-A1).
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 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 based on the telemetry data, the Domain Name System traffic ([17,23,42] discussing DNS packet consideration and associated metadata); identify an observed 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. Yadav does not show: consideration of traffic associated with a particular online application; make, based on the observed traffic pattern, a determination that an application experience of one or more users of the particular online application is degraded.
Sundararajan shows: consideration of traffic 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) ; make, based on the observed 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
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, while discussing consideration of a particular online application when evaluating traffic (e.g., Sundararajan, [58,64]) does not show: where the identification is an observed traffic pattern of the Domain Name System traffic associated with a particular endpoint and a baseline domain system traffic pattern associated with the particular endpoint, making based on the observed traffic pattern relative to the baseline Domain Name System traffic pattern, a determination. Shitrit shows: where the identification is an observed traffic pattern of the Domain Name System traffic associated with a particular endpoint and a baseline domain system traffic pattern associated with the particular endpoint, making based on the observed traffic pattern relative to the baseline Domain Name System traffic pattern, a determination ([33-35,48,53] and Fig. 5, discussing making a determination that an attack is occurring based on comparing observed DNS traffic with baseline traffic).
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 the above combination with the attack detection of Shitrit in order to improve the ability of the resultant disclosure to detect both anomalies and attacks, and thus improve the stability and reliability of the monitored network.
The above combination does not show to provide an indication of the observed traffic pattern and the baseline pattern for display by a user interface. Garvey shows to provide an indication of the observed traffic pattern and the baseline pattern for display by a user interface (Fig. 9C, [139-140]).
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 the above combination with the baseline condition awareness and information display techniques of Garvey in order to provide addition information to the system administrator, enabling more informed decisions regarding system status.
The above combination does not show: receive an indication from the user interface that the observed traffic pattern is considered normal and not indicative of the application experience being degraded, and adjust one or more parameters of an anomaly detector based on the indication received from the user interface.
Shemer shows: receive an indication from the user interface that the observed traffic pattern is considered normal and not indicative of the application experience being degraded ([72] and Fig. 4, and adjust one or more parameters of an anomaly detector based on the indication received from the user interface ([72-73,76,82] and Fig. 4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring techniques of the above combination with the user feedback of Shemer in order to provide system users an intuitive mechanism for providing feedback to the detection and alert system, thus improving the ability of the resultant system to provide alerts at the appropriate times.
Regarding claim 12¸ 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 13¸ the above combination further shows wherein making the determination comprises: comparing the traffic pattern to the baseline Domain Name System traffic pattern (Yadav, [22-24] and Shitrit, Fig. 5 and [33-36,66]) associated with a particular web page of the particular online application (Sundararajan, [34-35] and Shitrit, [28]) or with a particular action performed within the particular online application.
Regarding claim 14¸ the above combination further shows wherein the process when executed is further configured to: determine whether the observed traffic pattern is due to a permanent change to the particular online application (Shemer, [72] and Fig. 4); and responsive to determining that the observed traffic pattern is due to the permanent change, recompute the baseline Domain Name System traffic pattern and an anomaly detection model (Shemer, [15-16,89,104]) for the particular online application (Sundararajan, [34-35] and Shitrit, [28]).
Regarding claim 16¸ 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 17¸ the above combination further shows wherein the anomaly detector determines that timing between Domain Name System queries in the Domain Name System traffic is corresponding to the particular web page (Shitrit, [28,31,53,62] discussing the content corresponding to a URL such as “www.google.com”) or the particular action is anomalous (Sundararajan, [34-35]) is anomalous (Yadav, [91]).
Regarding claim 18¸ 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 19¸ the above combination further shows to: receive the indication from the user interface from an expert user or administrator that the observed traffic pattern is considered normal and not indicative of the application experience being degraded (Shemer, [72,76,78,82])
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Sundararajan and Arnell (US-10686814-B2).
Regarding claim 20, Yadav shows a tangible, non-transitory, computer-readable medium storing program instructions that cause a device to execute a process comprising: obtaining, by the device, telemetry data comprising Domain Name System logs from one or more domain name system servers or domain name system services regarding Domain Name System traffic in a network (Fig. 7 steps 92-96 and [22] and [61] discussing “network data (metadata) collected . . .” which, as [16-17] notes, includes “Domain Name System (DNS) exchanges within the network); 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.
Yadav does not show: consideration of traffic associated with a particular online application; based on identification/consideration of traffic associated with the particular online application, identifying a traffic pattern that is based on logs used as a proxy for application experience of one or more users of the 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);
based on identification/consideration of traffic associated with the particular online application, identifying a traffic pattern that is based on logs used as a proxy for application experience of one or more users of the particular online application ([34-35]); 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 show where the traffic pattern is based on Domain Name System processing times in the Domain Name System logs. Arnell shows where the traffic pattern is based on Domain Name System processing times in the Domain Name System logs (Figs. 1 and 3, col. 9 lines 1-20 and col. 10 lines 14-33).
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 and application analysis of the above combination with the DNS analysis techniques suggested by Arnell in order to more fully utilize the existing DNS data collected by the above combination and provide more detailed reports, while also ensuring better and more through detection and reporting of network anomalies (Arnell, Abstract).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
Prosecution Insights