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
This non-final action is responsive to application filed on 04/25/2024. In this application, claims 1-20 are pending, with claims 1, 8 and 15 being independent.
Claim Rejections - 35 USC § 103
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 of this title, 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, 6, 8-9, 13, 15-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahbod et al. (US 2015/0207823, Pub. Date: Jul. 23, 2015), in view of Nandan et al. (US 2020/0210301, Pub. Date: Jul. 2, 2020), in view of Shaw et al. (US 2019/0149398, Pub. Date: May 16, 2019), in view of Patil (US 2019/0260859, Pub. Date: Aug. 22, 2019), in view of Nakahara et al. (US 2004/0111492, Pub. Date: Jun. 10, 2004).
As per claim 1, Mahbod discloses a method for managing network request failures (Mahbod para. [0003], A client transmits a request for resources to a server and then waits for a response from the server. Client software often specifies a maximum time for which the client will wait for a response from a server. If the maximum wait time is reached, the client will deem the request as failed and retransmit the request. Typically, client software also specifies a maximum number of request retries, and if the maximum number of retries is reached without the client receiving the requested resource from the server, the client may deem the resource to be unavailable or take other remedial action), comprising:
identifying, by a drill-down manager of a client (Mahbod fig. 3, network communication management engine 311 and para. [0041], The network communication management engine 311 is configured to control and manage the connections initiated by the client 101 through the network interface 303), a network request failure (Mahbod fig. 5, Transmit Request at 502 and Response Received Prior to Socket Timeout? at 504[Wingdings font/0xE0] No; Mahbod para. [0003], If the maximum wait time is reached, the client will deem the request as failed and retransmit the request), wherein the network request is sent by the client to a target through a network (Mahbod fig. 5 and para. [0057], At 502, the client 101 transmits a request to the server 103);
in response to the identification (Mahbod fig. 5, Response Received Prior to Socket Timeout? at 504[Wingdings font/0xE0] No):
making a determination that a retry limit is exceeded (Mahbod fig. 5, Number of Retries Exceeded? At 506[Wingdings font/0xE0]YES);
in response to the determination (Mahbod fig. 5, Number of Retries Exceeded? At 506[Wingdings font/0xE0]YES):
initiating network request failure remediation (Mahbod para. [0003], client software also specifies a maximum number of request retries, and if the maximum number of retries is reached without the client receiving the requested resource from the server, the client may deem the resource to be unavailable or take other remedial action).
Mahbod does not explicitly disclose:
pausing other retry methods and network requests;
after pausing:
triggering network tracing for network requests;
performing a retry of the failed network request with the network tracing;
after performing the retry:
resuming other network requests and retry methods;
filtering tracing information obtained from the network tracing to obtain packets associated with the failed network request;
identifying a retry stream identifier associated with retry stream responses of the network request retry;
performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative;
storing the error narrative in a log repository; and
initiating network request failure remediation using the error narrative.
Nandan teaches:
pausing operations (Nandan para. [0012], In response to encountering a breakpoint or other halt command, the debug control can instruct one or more schedulers (e.g., pipeline schedulers) to halt execution of tasks associated with one or more active pipelines to allow investigation and other debug operations);
after pausing: triggering investigation of a failure (Nandan para. [0012], during investigation of a failure to part of the VISS, the debug control 108 can control the actions of a pipeline in response to command from command interface 106, which can be a halt, step, or resume command. If the command is a halt command, for example, a thread within the VISS processing block can be stopped in order to investigate an issue);
after performing investigation of a failure: resuming normal operations (Nandan para. [0017], after further investigation another command at command interface 106 (e.g., resume command) may be issued to resume execution (e.g., normal operation). A resume command at command interface 106 while in a halted state ends a debug session and resumes execution and functional processing of the processing thread. For example, if a debugging session is complete, the debug control can issue a command to end the halt state, which enables VISS data processing engine and connected components of a pipeline to transition the out of the halted state, resume normal operation and end the debug session).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Mahbod in view of Nandan in order applying technique of Nandan for pausing other retry methods and network requests, after pausing: triggering investigation of a failure, after performing investigation of a failure: resuming other network requests and retry methods.
One of ordinary skill in the art would have been motived because it offers the advantage of investigating an issue (Nandan para. [0017]).
Mahbod-Nandan teaches pausing other retry methods and network requests, after pausing: triggering investigation of a failure. However, Mahbod does not explicitly disclose:
triggering network tracing for network requests;
performing a retry of the failed network request with the network tracing;
after performing the retry:
filtering tracing information obtained from the network tracing to obtain packets associated with the failed network request;
identifying a retry stream identifier associated with retry stream responses of the network request retry;
performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative;
storing the error narrative in a log repository; and
initiating network request failure remediation using the error narrative.
Shaw teaches:
triggering network tracing for network requests (Shaw para. [0067-0068], The system identifies one or more network flows (602) and obtains information about re-transmission of packets associated with the network flows from one or more hosts (604). In some implementations, the system generates information about re-transmission of packets associated with the network flows by tracing, on each host of the one or more hosts, calls to a kernel function used for packet re-transmission);
performing a retry of the failed network request with the network tracing (Shaw para. [0068], the system can trace calls to the tcp_retransmit_skb( ) function used for TCP packet re-transmission in Linux. Subsequently, the system traces are passed to one or more data structures used by the tcp_retransmit_skb( ) function, e.g., struct sock and struct sk_buff data structures, using Linux's tracer function ftrace. The system then maps each call to corresponding TCP-IP flow information using the map provided by the pseudo file procfs:/proc/net/tcp);
after performing the retry (Shaw para. [0068], the system can trace calls to the tcp_retransmit_skb( ) function used for TCP packet re-transmission in Linux):
filtering tracing information obtained from the network tracing to obtain packets associated with the failed network request (Shaw para. [0070-0071], The system computes a total retransmission count for each network flow, e.g., over a specified time window, of the one or more network flows (606) … The system then classifies each network flow (610) based on whether the total retransmission count for the network flow exceeds the threshold; Shaw para. [0068], the system generates information about re-transmission of packets associated with the network flows by tracing, on each host of the one or more hosts, calls to a kernel function used for packet re-transmission and then mapping each call to corresponding identifying information in accordance with a network protocol).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Shaw for after pausing: triggering network tracing for network requests; performing a retry of the failed network request with the network tracing; after performing the retry: filtering tracing information obtained from the network tracing to obtain packets associated with the failed network request.
One of ordinary skill in the art would have been motived because it offers the advantage of detecting sources of computer network failures (Shaw para. [0001]).
Mahbod-Nandan-Shaw does not explicitly disclose:
identifying a retry stream identifier associated with retry stream responses of the network request retry;
performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative;
storing the error narrative in a log repository; and
initiating network request failure remediation using the error narrative.
Patil teaches:
identifying a stream identifier associated with stream responses of the network request retry (Patil para. [0051], The mid-tier device 410 receives (at 450) a publish event from each of the first ingest device 420 and the second ingest device 430. Here again, the publish events are provided in response to the same particular media stream being redundantly uploaded to the first and second ingest devices 420 and 430. Each publish event identifies at least an identifier for the particular media stream (e.g., name or URL));
performing extraction of the packets and the stream responses associated with the stream identifier to obtain an error narrative (Patil para. [0055], the mid-tier device 410 may receive an HTTP 404 "Not Found" error in response to sending the request for the particular media stream segment to the first ingest device 420. Other error messages or response codes may additionally or alternatively be returned to the first ingest device 420 (e.g., HTTP 408 "Request Timeout", HTTP 503 "Service Unavailable", HTTP 504 "Gateway Timeout", etc.); Patil para. [0074], The removal rate can be further controlled by identifying which errors (e.g., HTTP 404 “Not Found”, HTTP 408 “Request Timeout”, and HTTP 504 “Gateway Timeout”) are counted against the threshold. The threshold can also be defined more granularly to specify, for example, a certain number of errors based on requests of a single client device or multiple client devices);
initiating network request failure remediation using the error narrative (Patil fig. 4, trigger failover; Patil para. [0071], Each of the attempts for retrieving the particular media stream parts for the two requests 560 and 570 from the first ingest device results in an error (e.g., HTTP 404 “Not Found”). Each error may cause the mid-tier device 520 to seamlessly failover to the secondary second ingest device).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Patil for identifying a retry stream identifier associated with retry stream responses of the network request retry; performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative and initiating network request failure remediation using the error narrative.
One of ordinary skill in the art would have been motived because it offers the advantage of providing seamless stream failover (see Patil para. [0018]).
Mahbod-Nandan-Shaw-Patil does not explicitly disclose:
storing the error narrative in a log repository.
Nakahara teaches:
storing the error narrative in a log repository (Nakahara fig. 5 and para. [0047], The record of the access log 61-k includes: … an HTTP reply code 612 indicating an error status added to the reply message from the Web server; an error number 613 indicating an error code for the reply of the proxy server 23 to the client 1; Nakahara para. [0050], In both the case of normally returning the reply message to the client and the case of returning the error message, the proxy server 23-n forms the access log record shown in FIG. 5 in accordance with the processing result (S1007). Further, the proxy server 23-n outputs the access log record to the access log file 50 in the disk device 25 (S1008)).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Nakahara for storing the error narrative in a log repository.
One of ordinary skill in the art would have been motived because it offers the advantage of providing session information to server (see Nakahara par. [0013 &0046-0047]).
As per claim 2, Mahbod-Nandan-Shaw-Patil-Nakahara discloses the method according to claim 1, as set forth above, Mahbod-Patil also discloses wherein the error narrative comprises information extracted from the packets and retry stream responses and used in remediating the network request failure (Patil para. [0055], the mid-tier device 410 may receive an HTTP 404 "Not Found" error in response to sending the request for the particular media stream segment to the first ingest device 420. Other error messages or response codes may additionally or alternatively be returned to the first ingest device 420 (e.g., HTTP 408 "Request Timeout", HTTP 503 "Service Unavailable", HTTP 504 "Gateway Timeout", etc.); Patil para. [0071], Each of the attempts for retrieving the particular media stream parts for the two requests 560 and 570 from the first ingest device results in an error (e.g., HTTP 404 “Not Found”). Each error may cause the mid-tier device 520 to seamlessly failover to the secondary second ingest device).
Similar rationale in claim 1 is applied.
As per claim 6, Mahbod-Nandan-Shaw-Patil-Nakahara discloses the method according to claim 1, as set forth above, Mahbod does not explicitly disclose wherein performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative further comprises identifying error messages in the packets and the retry stream responses and analyzing the error messages to obtain failure attributes.
Patil teaches:
identifying error messages in the packets and stream responses (Patil para. [0055], the mid-tier device 410 may receive an HTTP 404 "Not Found" error in response to sending the request for the particular media stream segment to the first ingest device 420. Other error messages or response codes may additionally or alternatively be returned to the first ingest device 420 (e.g., HTTP 408 "Request Timeout", HTTP 503 "Service Unavailable", HTTP 504 "Gateway Timeout", etc.); Patil para. [0071], Each of the attempts for retrieving the particular media stream parts for the two requests 560 and 570 from the first ingest device results in an error (e.g., HTTP 404 “Not Found”). Each error may cause the mid-tier device 520 to seamlessly failover to the secondary second ingest device) and analyzing the error messages to obtain failure attributes (Patil para. [0074], The removal rate can be further controlled by identifying which errors (e.g., HTTP 404 “Not Found”, HTTP 408 “Request Timeout”, and HTTP 504 “Gateway Timeout”) are counted against the threshold. The threshold can also be defined more granularly to specify, for example, a certain number of errors based on requests of a single client device or multiple client devices).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Patil for performing extraction of the packets and the retry stream responses associated with the stream identifier to obtain an error narrative further comprises identifying error messages in the packets and the retry stream responses and analyzing the error messages to obtain failure attributes.
One of ordinary skill in the art would have been motived because it offers the advantage of providing seamless stream failover (see Patil para. [0018]).
Per claims 8-9 and 13, they do not teach or further define over the limitations in claims 1-2 and 6 respectively. As such, claims 8-9 and 13 are rejected for the same reasons as set forth in claims 1-2 and 6 respectively. Mahbod also discloses a non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor enables the computer processor to perform a method for managing network request failures (Mahbod para. [0002], The network traffic management functionality may by implemented by a computer system that comprises instructions stored in a non transitory computer-readable medium and one or more processors that execute the instructions).
Per claims 15-16 and 20, they do not teach or further define over the limitations in claims 1-2 and 6 respectively. As such, claims 15-16 and 20 are rejected for the same reasons as set forth in claims 1-2 and 6 respectively. Mahbod also discloses a system for managing network request failures (Mahbod para. [0002], The network traffic management functionality may by implemented by a computer system that comprises instructions stored in a non transitory computer-readable medium and one or more processors that execute the instructions), comprising: a target (Mahbod fig. 1, server 103); and a client operatively connected to the target (Mahbod fig. 5 and para. [0057], At 502, the client 101 transmits a request to the server 103), wherein the client comprises a processor and memory and the processor is configured to perform a method (Mahbod fig. 3, Processor 301, Memory 302).
Claims 3-5, 10-12 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Mahbod et al. (US 2015/0207823, Pub. Date: Jul. 23, 2015), in view of Nandan et al. (US 2020/0210301, Pub. Date: Jul. 2, 2020), in view of Shaw et al. (US 2019/0149398, Pub. Date: May 16, 2019), in view of Patil (US 2019/0260859, Pub. Date: Aug. 22, 2019), in view of Nakahara et al. (US 2004/0111492, Pub. Date: Jun. 10, 2004), in view of Li et al. (US 10,735,331, Date of Patent: Aug. 4, 2020).
As per claim 3, Mahbod-Nandan-Shaw-Patil-Nakahara discloses the method according to claim 1, as set forth above, Mahbod does not explicitly disclose wherein pausing other network requests comprises pausing all network requests from the client.
Li teaches:
pausing all network packets from the client (Li col. 2 lines 43-47, The forwarding element sends the flow control message to the sending network element(s), requesting that they pause sending packets to the forwarding element. These flow control messages may request that the sender cease sending all packets).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Li for pausing other network requests comprises pausing all network requests from the client.
One of ordinary skill in the art would have been motived because it offers the advantage of improving debugging accuracy.
As per claim 4, Mahbod-Nandan-Shaw-Patil-Nakahara discloses the method according to claim 1, as set forth above, Mahbod does not explicitly disclose wherein pausing other network requests comprises pausing network requests from the client of a request type of request types.
Li teaches:
pausing network packets from the client of a packet type of packet types (Li col. 2 lines 42-47, The forwarding element sends the flow control message to the sending network element(s), requesting that they pause sending packets to the forwarding element. These flow control messages may request that the sender cease sending all packets, packets having the particular priority, or a specific flow or flows; Li col 14 lines 34-40, the forwarding element 1000 generates a flow control message requesting that the recipient cease (at least temporarily) sending packets with priority 2. If the priority values are assigned internally by the ingress pipelines of the forwarding element 1000, these flow control messages may indicate a specific flow or flows for each network element to cease sending to the forwarding element).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Li for pausing other network requests comprises pausing network requests from the client of a request type of request types.
One of ordinary skill in the art would have been motived because it offers the advantage of providing improving accuracy.
As per claim 5, Mahbod-Nandan-Shaw-Patil-Nakahara-Li discloses the method according to claim 4, as set forth above, Li also discloses wherein pausing other network requests further comprises:
pausing requests of a first request type of the request types (Li col. 2 lines 42-47, The forwarding element sends the flow control message to the sending network element(s), requesting that they pause sending packets to the forwarding element. These flow control messages may request that the sender cease sending all packets, packets having the particular priority, or a specific flow or flows; Li col 14 lines 34-40, the forwarding element 1000 generates a flow control message requesting that the recipient cease (at least temporarily) sending packets with priority 2. If the priority values are assigned internally by the ingress pipelines of the forwarding element 1000, these flow control messages may indicate a specific flow or flows for each network element to cease sending to the forwarding element); and
not pausing requests of a second request type of the requests types (Li col. 2 lines 42-47, The forwarding element sends the flow control message to the sending network element(s), requesting that they pause sending packets to the forwarding element. These flow control messages may request that the sender cease sending all packets, packets having the particular priority, or a specific flow or flows).
Similar rationale in claim 4 is applied.
Per claims 10-12 and 17-19, they do not teach or further define over the limitations in claims 3-5 respectively. As such, claims 10-12 and 17-19 are rejected for the same reasons as set forth in claims 3-5 respectively.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mahbod et al. (US 2015/0207823, Pub. Date: Jul. 23, 2015), in view of Nandan et al. (US 2020/0210301, Pub. Date: Jul. 2, 2020), in view of Shaw et al. (US 2019/0149398, Pub. Date: May 16, 2019), in view of Patil (US 2019/0260859, Pub. Date: Aug. 22, 2019), in view of Nakahara et al. (US 2004/0111492, Pub. Date: Jun. 10, 2004), in view of Braverman Masis et al. (US 2025/0307117, filed: Mar. 27, 2024).
As per claim 7, Mahbod-Nandan-Shaw-Patil-Nakahara discloses the method according to claim 1, as set forth above, Mahbod does not explicitly disclose wherein initiating the network request failure remediation using the error narrative comprises identifying a root cause of the network request failure based on the error narrative.
Braverman Masis teaches:
identifying a root cause of the network request failure based on the error narrative (Braverman Masis para. [0020], the action 132 may involve the computing device 102 outputting an indication of the error code 130 to the user device 104. The computing device 102 or a developer may determine a root cause of the error based on the error code 130).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Mahbod in view of Braverman Masis for initiating the network request failure remediation using the error narrative comprises identifying a root cause of the network request failure based on the error narrative.
One of ordinary skill in the art would have been motived because it offers the advantage of providing corrective actions based on error code (see Braverman Masis para. [0033]).
Per claim 14, it does not teach or further define over the limitations in claim 14. As such, claim 14 is rejected for the same reasons as set forth in claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mang et al. (US 20230209113) Predictive Customer Experience Management In Content Distribution Networks;
Manuel-Devadoss et al. (US 20140189435) System And Method To Extend The Capabilities Of A Web Browser Of A Web Application Issue Root Cause Determination Techniques;
Garza et al. (US 20050278706) System, Method, And Computer Program Product For Logging Diagnostic Information.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINH NGUYEN whose telephone number is (571)272-4487. The examiner can normally be reached Monday-Friday: 7:30 AM - 5:30 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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/VINH NGUYEN/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights