DETAILED ACTION
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 .
Priority
The Instant Application claims foreign priority to 202541014080, filed 02/18/2025. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Allowable Subject Matter
Claims 4-9 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3 and 10-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Berriel et al. (2026/0095366).
As per claim 1, Berriel et al. teaches a non-transitory, computer-readable medium, comprising computer-readable instructions that, when executed by one or more processors of one or more computers, cause the one or more computers to: receive a set of transmission control protocol indicators of performance issues (TCP IPI) data, wherein the set of TCP IPI data comprises performance metric data associated with a network communication between a client device and an endpoint [paragraphs 0097-0099];
receive queue monitoring data from a plurality of intermediate routing devices on a path of the network communication between the client device and the endpoint [paragraph 0117];
identify, based on the set of TCP IPI data in conjunction with the queue monitoring data, a particular component on the path of the network communication as a cause of a communication issue between the client device and the endpoint [paragraphs 0024, 0075 and 0111]; and
generate and provide an alert indicating the particular component as the cause of the communication issue [paragraphs 0086 and 0101].
As per claim 2, Berriel et al. teaches the non-transitory, computer-readable medium of claim 1 comprising computer-readable instructions that, when executed by the one or more processors of the one or more computers, cause the one or more computers to: select the particular component from a set of network components of the network communication, wherein the set of network components comprises: the plurality of intermediate routing devices on the path, the endpoint of the path, and a service provider associated with the path [paragraph 0117].
As per claim 3, Berriel et al. teaches the non-transitory, computer-readable medium of claim 1 wherein the performance metric data comprises at least one of: a round trip time (RTT) indicated by one or more TCP packets; a receive window size (RWS) of the one or more TCP packets, out port queue cache data of an access switch of the path; an indication of TCP packets being retransmitted; a maximum segment size (MSS) indicated by the one or more TCP packets; or a congestion window reduced (CWR) flag indicated by the one or more TCP packets [paragraph 0150].
As per claim 10, Berriel et al. teaches the non-transitory, computer-readable medium of claim 1, wherein the TCP IPI data is extracted from at least one of: transmission control protocol (TCP) packets or precision time protocol (PTP) packets [paragraph 0133].
Claim 11 has similar limitations as to claim 1 above therefore it is being rejected under the same rationale.
As per claim 12, Berriel et al. teaches the processor-implemented method of claim 11, comprising: identifying the particular component from a set of network components of the network communication, wherein the set of network components comprises: a particular intermediate routing devices of the plurality of intermediate routing devices on the path, the endpoint of the path, and a service provider associated with the path [paragraph 0121].
As per claim 13, Berriel et al. teaches the processor-implemented method of claim 12, comprising: in response to identifying that the particular intermediate routing devices is the particular component, determining that an out port queue (OPQ) of a plurality of OPQs on the particular intermediate routing device as the cause of the communication issue [paragraph 0105].
As per claim 14, Berriel et al. teaches the processor-implemented method of claim 12, wherein the particular component comprises at least two intermediate routing devices of the plurality of intermediate routing devices [paragraph 0096].
As per claim 15, Berriel et al. teaches the processor-implemented method of claim 11, wherein the alert is provided to at least one networking entity with operational control of the particular component, comprising at least one of: an application server associated with the endpoint; a network management service, or an internet service provider [paragraph 0081].
As per claim 16, Berriel et al. teaches the processor-implemented method of claim 11, comprising: determining, from the set of TCP IPI data, that the cause of the communication issue is associated with at least one of: network congestion or network delay [paragraph 0072].
As per claim 17, Berriel et al. teaches the processor-implemented method of claim 16, wherein the alert includes an indication that the cause of the communication issue is associated with the at least one of: the network congestion or the network delay [paragraph 0063].
As per claim 18, Berriel et al. teaches a Network Issue Causation Detection (NICD) system comprising: a processor; and a non-transitory, computer-readable medium comprising computer-readable instructions that, when executed by the processor, cause the processor to: receive a set of transmission control protocol indicators of performance issues (TCP IPI) data, wherein the set of TCP IPI data comprises performance metric data associated with a network communication between a client device and an endpoint [paragraphs 0097-0099];
receive queue monitoring data from a plurality of intermediate routing devices on a network path of the network communication [paragraph 0117];
identify, based on the set of TCP IPI data in conjunction with the queue monitoring data, a particular component on the network path of the network communication as a cause of a communication issue between the client device and the endpoint [paragraphs 0024, 0075 and 0111]; and
generate and provide an alert indicating the particular component as the cause of the communication issue [paragraphs 0086 and 0101].
As per claim 19, Berriel et al. teaches the system of claim 18, wherein the NICD system is configured to: receive a notification of the communication issue from the client device; and in response to receiving the notification of the communication issue from the client device, request the queue monitoring data from the plurality of intermediate routing devices [paragraph 0039].
As per claim 20, Berriel et al. teaches the system of claim 18, wherein the NICD system is configured to: extract the set of TCP IPI data from TCP packets that are transmitted across at least part of the network path between the client device and the endpoint [paragraphs 0029-0030].
There are prior art made of record not relied upon but is considered pertinent to applicant's disclosure. See attached.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANODHI N SERRAO whose telephone number is (571)272-7967. The examiner can normally be reached Monday to Friday 8:00 am to 4:00 pm.
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, John Follansbee can be reached on (571) 272-3964. 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.
Ranodhi N. Serrao
/RANODHI SERRAO/
Primary Examiner, Art Unit 2444