DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
2. 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.
3. 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.
4. Claims 1-6, 8-10, 12, and 14-21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Plamondon et al. (US 2007/0206615 A1, hereinafter “Plamondon”).
Regarding claim 1, Plamondon teaches in a computer system (figs. 1A-4, 7A, 7B), a method of managing delivery of a given packet flow according to a reliable transport protocol (¶ [0224], the first device may transmit the first packet via a transport layer connection such as a TCP or UDP connection), the method comprising: sending, from a sender to a receiver across a network, a last transport-layer flow packet of a flowlet, wherein the flowlet is a burst of multiple transport-layer flow packets from the given packet flow, followed by an idle interval, the multiple transport-layer flow packets ending with the last transport-layer flow packet (figs. 3, 4, ¶ [0221], systems and methods for using transaction boundaries to reduce timeout penalties. ¶ [0222], The first device transmits the first packet to a receiver (step 703), and determines that the first packet is likely to be the last packet of a transaction (step 705). The first device then generates, responsive to the determination, at least one additional packet (step 707); and transmits the additional packet to the receiver after the first packet has been transmitted (step 709), ¶ [0225], ¶ [0157], ¶ [0158], ¶ [0219]); after the sending the last transport-layer flow packet but before satisfaction of a timeout condition for the last transport-layer flow packet, sending one or more end-of-flowlet ("EOF") packets (figs 7A, 7B, ¶ [0221], after detecting a transaction boundary, a device may generate and transmit an additional packet following the transmission of the transaction. The additional packet may be configured to generate an ACK from the receiver which will indicate whether the last packet of the transaction was successfully received. Many protocols, such as TCP, may use a retransmission timeout (RTO) to discover and correct cases where the last packet of a transaction has been dropped. In some protocols, RTOs can be very expensive, such as TCP, where the RTO is by default a full second. The systems and methods of FIGS. 7A and 7B may be used to attempt to avoid such RTO delays by early discovery of dropped last packets. ¶ [0228]); receiving, at the sender from the receiver, feedback metadata for the one or more EOF packets (figs. 7A, 7B, ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711). ¶ [0230]), wherein the feedback metadata indicates a given sent transport-layer flow packet, among the sent transport-layer flow packets, has been received (figs. 7A, 7B, ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received (step 713). The received acknowledgement may comprise any type of acknowledgement and may contain any indication that a data packet has not been received. ¶ [0145], ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); at the sender, updating a tracking window based at least in part on the feedback metadata for the one or more EOF packets (figs. 7A, 7B. ¶ [0129], The send window is similar to the receive window, in that it consumes buffer space (though on the sender). The sender's send window consists of all data sent by the application that has not been acknowledged by the receiver. This data must be retained in memory in case retransmission is required. Subsequent reception of acknowledgements will free send-window. ¶ [0130], ¶ [0145], As the sender transmits data packets, the sender maintains a data structure of acknowledged instances of data packet transmissions. When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost.), wherein the reliable transport protocol supports multi-path delivery of the multiple transport-layer flow packets over multiple paths of the network (¶ [0139], ¶ [0140]), wherein the tracking window is an out-of-order ("OOO") tracking window that tracks n packets, n being greater than 1 (¶ [0145], ¶ [0150], TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received), and wherein the updating the tracking window includes changing an indicator bit, in the OOO tracking window, for the given sent transport-layer flow packet (figs. 7A, 7B, ¶ [0145], When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost. ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0154], when the retransmit algorithm (using the transmit numbers) declares a packet lost, the sender considers the packet to be only conditionally lost, as it is possible that the SACK packet identifying the reception of this packet was lost rather than the data packet itself. The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); and selectively resending, from the sender to the receiver across the network, one or more unacknowledged transport-layer flow packets, according to the updated OOO tracking window, among the sent transport-layer flow packets (figs. 7A, 7B, ¶ [0129], ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711), ¶ [0231]), wherein the selectively resending includes identifying the one or more unacknowledged transport-layer flow packets in the updated OOO tracking window (¶ [0150], ¶ [0154], The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted ¶ [0158], Responsive to detecting a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver to cause acknowledgements therefrom. The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet. In one embodiment, the last packet or packets of the transaction are simply retransmitted. ¶ [0159], to avoid a timeout when the acknowledgements for the last data packets in a transaction are dropped. When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted).
Regarding claim 18, Plamondon teaches one or more non-transitory computer-readable media having stored thereon computer-executable instructions for causing one or more processing units (figs. 1A-3, 7A, 7B, ¶ [0067], ¶ [0068]) when programmed thereby, to perform operations to manage delivery of a given packet flow
according to a reliable transport protocol (¶ [0224], the first device may transmit the first packet via a transport layer connection such as a TCP or UDP connection), the operations comprising: sending, from a sender to a receiver across a network, a last transport-layer flow packet of a flowlet, wherein the flowlet is a burst of multiple transport-layer flow packets from the given packet flow, followed by an idle interval, the multiple transport-layer flow packets ending with the last transport-layer flow packet (figs. 3, 4, ¶ [0221], systems and methods for using transaction boundaries to reduce timeout penalties. ¶ [0222], The first device transmits the first packet to a receiver (step 703), and determines that the first packet is likely to be the last packet of a transaction (step 705). The first device then generates, responsive to the determination, at least one additional packet (step 707); and transmits the additional packet to the receiver after the first packet has been transmitted (step 709), ¶ [0157], ¶ [0225], ¶ [0158], ¶ [0219]); after the sending the last transport-layer flow packet but before satisfaction of a timeout condition for the last transport-layer flow packet, sending one or more end-of-flowlet ("EOF") packets (figs 7A, 7B, ¶ [0221], after detecting a transaction boundary, a device may generate and transmit an additional packet following the transmission of the transaction. The additional packet may be configured to generate an ACK from the receiver which will indicate whether the last packet of the transaction was successfully received. Many protocols, such as TCP, may use a retransmission timeout (RTO) to discover and correct cases where the last packet of a transaction has been dropped. In some protocols, RTOs can be very expensive, such as TCP, where the RTO is by default a full second. The systems and methods of FIGS. 7A and 7B may be used to attempt to avoid such RTO delays by early discovery of dropped last packets. ¶ [0228]); receiving, at the sender from the receiver, feedback metadata for the one or more EOF packets (figs. 7A, 7B, ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711). ¶ [0230]), wherein the feedback metadata indicates a given sent transport-layer flow packet, among the sent transport-layer flow packets, has been received (figs. 7A, 7B, ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received (step 713). The received acknowledgement may comprise any type of acknowledgement and may contain any indication that a data packet has not been received. ¶ [0145], ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); at the sender, updating a tracking window based at least in part on the feedback metadata for the one or more EOF packets (figs. 7A, 7B. ¶ [0129], The send window is similar to the receive window, in that it consumes buffer space (though on the sender). The sender's send window consists of all data sent by the application that has not been acknowledged by the receiver. This data must be retained in memory in case retransmission is required. Subsequent reception of acknowledgements will free send-window. ¶ [0130], ¶ [0145], As the sender transmits data packets, the sender maintains a data structure of acknowledged instances of data packet transmissions. When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost.), wherein the reliable transport protocol supports multi-path delivery of the multiple transport-layer flow packets over multiple paths of the network (¶ [0139], ¶ [0140]), wherein the tracking window is an out-of-order ("OOO") tracking window that tracks n packets, n being greater than 1 (¶ [0145], ¶ [0150], TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received), and wherein the updating the tracking window includes changing an indicator bit, in the OOO tracking window, for the given sent transport-layer flow packet (figs. 7A, 7B, ¶ [0145], When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost. ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0154], when the retransmit algorithm (using the transmit numbers) declares a packet lost, the sender considers the packet to be only conditionally lost, as it is possible that the SACK packet identifying the reception of this packet was lost rather than the data packet itself. The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); and selectively resending, from the sender to the receiver across the network, one or more unacknowledged transport-layer flow packets, according to the updated tracking window, among the sent transport-layer flow packets (figs. 7A, 7B, ¶ [0129], ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711), ¶ [0231]), wherein the selectively resending includes identifying the one or more unacknowledged transport-layer flow packets in the updated OOO tracking window (¶ [0150], ¶ [0154], The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted ¶ [0158], Responsive to detecting a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver to cause acknowledgements therefrom. The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet. In one embodiment, the last packet or packets of the transaction are simply retransmitted. ¶ [0159], to avoid a timeout when the acknowledgements for the last data packets in a transaction are dropped. When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted).
Regarding claim 19, Plamondon teaches a network interface device (figs. 1A-3, 7A, 7B, ¶ [0158], the sender or flow control module 220, ¶ [0224], the first device) configured to perform operations to manage delivery of a given packet flow according to a reliable transport protocol (¶ [0224], the first device may transmit the first packet via a transport layer connection such as a TCP or UDP connection), the operations comprising: sending, from a sender to a receiver across a network, a last transport-layer flow packet of a flowlet, wherein the flowlet is a burst of multiple transport-layer flow packets from the given packet flow, followed by an idle interval, the multiple transport-layer flow packets ending with the last transport-layer flow packet (figs. 3, 4, ¶ [0221], systems and methods for using transaction boundaries to reduce timeout penalties. ¶ [0222], The first device transmits the first packet to a receiver (step 703), and determines that the first packet is likely to be the last packet of a transaction (step 705). The first device then generates, responsive to the determination, at least one additional packet (step 707); and transmits the additional packet to the receiver after the first packet has been transmitted (step 709), ¶ [0225], ¶ [0157], ¶ [0158], ¶ [0219]); after the sending the last transport-layer flow packet but before satisfaction of a timeout condition for the last transport-layer flow packet, selectively resending one or more of the sent transport-layer flow packets that have not yet been acknowledged as received according to a tracking window (figs 7A, 7B, ¶ [0221], after detecting a transaction boundary, a device may generate and transmit an additional packet following the transmission of the transaction. The additional packet may be configured to generate an ACK from the receiver which will indicate whether the last packet of the transaction was successfully received. Many protocols, such as TCP, may use a retransmission timeout (RTO) to discover and correct cases where the last packet of a transaction has been dropped. In some protocols, RTOs can be very expensive, such as TCP, where the RTO is by default a full second. The systems and methods of FIGS. 7A and 7B may be used to attempt to avoid such RTO delays by early discovery of dropped last packets. ¶ [0226], the additional packet may comprise a duplicate of the first packet. ¶ [0228], In one embodiment, the device may transmit the additional packet immediately following the first packet); receiving, at the sender from the receiver, feedback metadata (figs. 7A, 7B, ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711). ¶ [0230]), wherein the feedback metadata indicates a given sent transport-layer flow packet, among the sent transport-layer flow packets, has been received (figs. 7A, 7B, ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received (step 713). The received acknowledgement may comprise any type of acknowledgement and may contain any indication that a data packet has not been received. ¶ [0145], ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); at the sender, updating the tracking window based at least in part on the feedback metadata (figs. 7A, 7B. ¶ [0129], The send window is similar to the receive window, in that it consumes buffer space (though on the sender). The sender's send window consists of all data sent by the application that has not been acknowledged by the receiver. This data must be retained in memory in case retransmission is required. Subsequent reception of acknowledgements will free send-window. ¶ [0130], ¶ [0145], As the sender transmits data packets, the sender maintains a data structure of acknowledged instances of data packet transmissions. When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost.), .), wherein the reliable transport protocol supports multi-path delivery of the multiple transport-layer flow packets over multiple paths of the network (¶ [0139], ¶ [0140]), wherein the tracking window is an out-of-order ("OOO") tracking window that tracks n packets, n being greater than 1 (¶ [0145], ¶ [0150], TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received), and wherein the updating the tracking window includes changing an indicator bit, in the OOO tracking window, for the given sent transport-layer flow packet (figs. 7A, 7B, ¶ [0145], When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost. ¶ [0150], implement TCP SACK to determine what packets have or have not been received. This technique allows the sender to determine unambiguously a list of packets that have been received by the receiver as well as an accurate list of packets not received. ¶ [0151], ¶ [0152], ¶ [0154], when the retransmit algorithm (using the transmit numbers) declares a packet lost, the sender considers the packet to be only conditionally lost, as it is possible that the SACK packet identifying the reception of this packet was lost rather than the data packet itself. The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet); and selectively resending, from the sender to the receiver across the network, one or more unacknowledged transport-layer flow packets, according to the updated tracking window, among the sent transport-layer flow packets (figs. 7A, 7B, ¶ [0129], ¶ [0222], The first device may then receive an acknowledgement corresponding to the additional packet (step 711), determine that a previously transmitted data packet has not been received (step 709), and retransmit the data packets not received (step 711), ¶ [0231]), wherein the selectively resending includes identifying the one or more unacknowledged transport-layer flow packets in the updated OOO tracking window (¶ [0150], ¶ [0154], The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted ¶ [0158], Responsive to detecting a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver to cause acknowledgements therefrom. The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet. In one embodiment, the last packet or packets of the transaction are simply retransmitted. ¶ [0159], to avoid a timeout when the acknowledgements for the last data packets in a transaction are dropped. When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted).
Regarding claim 2, Plamondon teaches the method of claim 1, further comprising: determining a metric that quantifies activity level; and comparing the metric to a threshold, wherein the sending the one or more EOF packets is contingent on the metric satisfying the threshold (figs. 7A, 7B, ¶ [0221], ¶ [0225], The first device may determine that the first packet is likely to be the last packet of a transaction. ¶ [0226], The first device may then send, in response to the determination, at least one additional packet. If the connection has a high loss rate, the device may send a plurality of duplicate packets. ¶ [0227], the device may include any additional factors in the decision to transmit one or more additional factors. These factors may include, without limitation the connection loss rate, latency, available bandwidth, current load on the device, and a priority or QoS level assigned to the connection. ¶ [0236], ¶ [0237], if the loss rate is above a given threshold, the device may determine an additional retransmission is necessary).
Regarding claim 3, Plamondon teaches the method of claim 2, wherein the metric depends on amount of data ready to send at the sender to the receiver for the given packet flow (¶ [0218], ¶ [0221], ¶ [0225], The first device may determine that the first packet is likely to be the last packet of a transaction. ¶ [0226] The first device may then send, in response to the determination, at least one additional packet).
Regarding claim 4, Plamondon teaches the method of claim 1, wherein the feedback metadata for the one or more EOF packets includes selective acknowledgement metadata for one or more of the sent transport-layer flow packets,
(figs. 7A, 7B, ¶ [0145], ¶ [0150], ¶ [0151], ¶ [0152], ¶ [0158], The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet).
Regarding claim 5, Plamondon teaches the method of claim 1, wherein each of the one or more EOF packets is a transport-layer flush packet having a header and a payload (¶ [0226], The additional packet may comprise any type of packet and may comprise any payload. In some embodiments, the additional packet may comprise a duplicate of the first packet).
Regarding claim 6, Plamondon teaches the method of claim 5, wherein the sending the one or more EOF packets sends up to n EOF packets so as to flush the OOO tracking window (¶ [0150], ¶ [0154], Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. ¶ [0158], Responsive to detecting a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver to cause acknowledgements therefrom. The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet. In one embodiment, the last packet or packets of the transaction are simply retransmitted. ¶ [0159], to avoid a timeout when the acknowledgements for the last data packets in a transaction are dropped. When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted).
Regarding claim 8, Plamondon teaches the method of claim 5, wherein the payload of the flush packet is nominal or empty (¶ [0226], In other embodiments, the additional packet may comprise a duplicate of a portion of the first packet. In still other embodiments, the additional packet may be generated according to any forward error-correction techniques).
Regarding claim 9, Plamondon teaches the method of claim 1, wherein each of the one or more EOF packets is a transport-layer query packet having a header and a payload, and wherein an indicator in the header of the query packet marks the query packet as a special class of packet that requests delivery state information from the receiver (¶ [0157], the setting of the PSH (TCP Push) bit by the sender in the TCP header may indicate a transaction boundary. ¶ [0226], The additional packet may comprise any type of packet and may comprise any payload. In some embodiments, the additional packet may comprise a duplicate of the first (last/boundary with PSH bit) packet. In other embodiments, the additional packet may comprise a duplicate of a portion of the first packet. In still other embodiments, the additional packet may be generated according to any forward error-correction techniques. ¶ [0229], the additional packet may comprise a TCP packet intended to provoke a TCP acknowledgement).
Regarding claim 10, Plamondon teaches the method of claim 9, wherein the sending the one or more EOF packets periodically sends, according to a query interval, one of the one or more EOF packets until all of the sent transport-layer flow packets have been acknowledged as received (¶ [0226], In some cases, the device may send multiple additional packets. For example, if the connection has a high loss rate, the device may send a plurality of duplicate packets. ¶ [0228], the device may wait any time interval after the transmission of the first packet before sending the additional packet. In another embodiment, the device may wait a period of time such that the first packet and the additional packet are unlikely to both be lost in a single loss event. ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received. ¶ [0231], The first device may then retransmit the packet or packets that were not received. The first device may also transmit one or more additional packets after the retransmissions.).
Regarding claim 12, Plamondon teaches the method of claim 9, wherein the payload of the query packet is nominal or empty (¶ [0226], In other embodiments, the additional packet may comprise a duplicate of a portion of the first packet. In still other embodiments, the additional packet may be generated according to any forward error-correction techniques).
Regarding claim 14, Plamondon teaches the method of claim 1, wherein the sender sends an initial EOF packet among the one or more EOF packets less than a target time after sending the last transport-layer flow packet, and wherein the target time is less than a round trip time expected for the multiple transport-layer flow packets (¶ [0228], The first device may transmit, after the first packet has been transmitted to the receiver, the at least one additional packet to the receiver via the connection in any manner (step 709). The device may wait any time interval after the transmission of the first packet before sending the additional packet. In one embodiment, the device may transmit the additional packet immediately following the first packet. In another embodiment, the device may wait a period of time such that the first packet and the additional packet are unlikely to both be lost in a single loss event. ¶ [0143]).
Regarding claim 15, Plamondon teaches the method of claim 1, wherein a given EOF packet, among the one or more EOF packets, has a payload of a given sent transport-layer flow packet among the sent transport-layer flow packets, that has not been acknowledged as received, wherein the feedback metadata indicates the given sent transport-layer flow packet or the given EOF packet has been received (figs. 7A, 7B, ¶ [0226], In some embodiments, the additional packet may comprise a duplicate of the first packet. ¶ [0228],The first device may transmit, after the first packet has been transmitted to the receiver, the at least one additional packet to the receiver via the connection. ¶ [0229], the additional packet may comprise a TCP packet intended to provoke a TCP acknowledgement. ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received. ¶ [0159], When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted. ¶ [0145], ¶ [0153]).
Regarding claim 16, Plamondon teaches the method of claim 1, wherein the selectively resending includes: evaluating a condition using the updated OOO tracking window; and responsive to determining that the condition is satisfied, resending the one or more unacknowledged transport-layer flow packets from the sender to the receiver.( ¶ [0122], The appliance 200 may determine whether retransmission is required as a sender would in a traditional system, for example, determining that a packet is lost if an acknowledgement has not been received for the packet after a predetermined amount of time. ¶ [0145], ¶ [0153], ¶ [0221]).
Regarding claim 17, Plamondon teaches the method of claim 1, wherein the selectively resending includes: evaluating a condition using the updated OOO tracking window; and responsive to determining that the condition is not satisfied, skipping resending the one or more unacknowledged transport-layer flow packets from the sender to the receiver (¶ [0122], The appliance 200 may determine whether retransmission is required as a sender would in a traditional system, for example, determining that a packet is lost if an acknowledgement has not been received for the packet after a predetermined amount of time. It is implicit that in a traditional system, the appliance 200 would skip retransmission in response to determining that an acknowledgement has been received for the packet within a predetermined amount of time. ¶ [0153], ¶ [0221]).
Regarding claim 20, Plamondon teaches the network interface device of claim 19, wherein the one or more of the sent transport-layer flow packets that have not yet been acknowledged as received are resent so as to fill any holes in the out-of-order tracking window more quickly (¶ [0150], ¶ [0153], ¶ [0154], Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. ¶ [0158], Responsive to detecting a transaction boundary, the sender or flow control module 220 transmits additional data packets to the receiver to cause acknowledgements therefrom. The additional data packets should therefore be such that the receiver will at least generate an ACK or SACK in response to receiving the data packet. In one embodiment, the last packet or packets of the transaction are simply retransmitted. ¶ [0159], to avoid a timeout when the acknowledgements for the last data packets in a transaction are dropped. When the sender or flow control module 220 receives the acknowledgements for these additional data packets, the sender can determine from these additional acknowledgements whether the last data packets have been received or need to be retransmitted).
Regarding claim 21, Plamondon teaches the one or more non-transitory computer-readable media of claim 18, wherein each of the one or more EOF packets is: a transport-layer flush packet having a header and a payload, the payload of the flush packet being nominal or empty (¶ [0226], The additional packet may comprise any type of packet and may comprise any payload. In some embodiments, the additional packet may comprise a duplicate of the first packet. In still other embodiments, the additional packet may be generated according to any forward error-correction techniques); or a transport-layer query packet having a header and a payload, wherein an indicator in the header of the query packet marks the query packet as a special class of packet that requests delivery state information from the receiver, the payload of the query packet being nominal or empty (¶ [0157], the setting of the PSH (TCP Push) bit by the sender in the TCP header may indicate a transaction boundary. ¶ [0226], The additional packet may comprise any type of packet and may comprise any payload. In some embodiments, the additional packet may comprise a duplicate of the first (last/boundary with PSH bit) packet. In other embodiments, the additional packet may comprise a duplicate of a portion of the first packet. In still other embodiments, the additional packet may be generated according to any forward error-correction techniques. ¶ [0229], the additional packet may comprise a TCP packet intended to provoke a TCP acknowledgement).
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
9. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Plamondon.
Regarding claim 11, Plamondon teaches the method of claim 10.
Plamondon does not explicitly teach wherein the query interval is set to be half an expected round trip time for the multiple transport-layer flow packets.
However, Plamondon teaches sending one or more EOF packets immediately or sending one or more EOF packets after a period of time until all of the sent transport-layer flow packets have been acknowledged as received (¶ [0226], In some cases, the device may send multiple additional packets. For example, if the connection has a high loss rate, the device may send a plurality of duplicate packets. ¶ [0228], the device may wait any time interval after the transmission of the first packet before sending the additional packet. In another embodiment, the device may wait a period of time such that the first packet and the additional packet are unlikely to both be lost in a single loss event. ¶ [0230], The first device may then receive an acknowledgement corresponding to the additional packet (step 711) and determine that one or more previously transmitted data packets have not been received. ¶ [0231], The first device may then retransmit the packet or packets that were not received. The first device may also transmit one or more additional packets after the retransmissions.).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to set the query/wait interval/period to be half an expected round trip time for the multiple transport-layer flow packets in the system of Plamondon. The motivation for doing this is a matter of design choice.
10. Claim 13 rejected under 35 U.S.C. 103 as being unpatentable over Plamondon in view of Shoens et al. (US 2018/0167168 A1, hereinafter “Shoens”).
Regarding claim 13, Plamondon teaches the method of claim 1.
Plamondon does not explicitly teach wherein the multiple transport-layer flow packets and the one or more EOF packets are ordered by packet sequence number in a packet sequence, the one or more EOF packets immediately following the last transport-layer flow packet in the packet sequence
Shoens teaches wherein the multiple transport-layer flow packets and the one or more EOF packets are ordered by packet sequence number in a packet sequence, the one or more EOF packets immediately following the last transport-layer flow packet in the packet sequence (fig. 6).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to order the multiple transport-layer flow packets and the one or more EOF packets by packet sequence number in a packet sequence, the one or more EOF packets immediately following the last transport-layer flow packet in the packet sequence in the system of Plamondon to further improve industrial
applicability.
Response to Arguments
11. Applicant's arguments filed on May 13, 2026 have been fully considered but they are not persuasive.
12. Applicant argues “…Plamondon does not address out-of-order delivery of data packets and, in any case, SACK packets are an acknowledgement mechanism. Use of SACK packets (as in Plamondon) does not indicate any specific mechanism at a sender for tracking out-of-order delivery of data packets. Although Plamondon describes a sender adding data packets to a "list of potentially lost packets, called the presumed lost list" (Plamondon, I 154), the list is not an out-of-order tracking window as recited in claims 1, 18, and 19, respectively. Plamondon is even further from teaching or suggesting operations to update and use an out-of-order tracking window as recited in claims 1, 18, and 19, respectively, including:…”
Examiner respectfully submits that although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In this case, Plamondon addresses out-of-order delivery of data packets (e.g., fig. 7A, where additional packet 732’ is delivered out-of-order (i.e., before the packet 732). ¶ [0145], As the sender transmits data packets, the sender maintains a data structure of acknowledged instances of data packet transmissions. Each instance of a data packet transmission is referenced by its sequence number and transmit number. By maintaining a transmit number for each packet, the sender retains the ordering of the transmission of data packets. When the sender receives an ACK or a SACK, the sender determines the highest transmit number associated with packets that the receiver indicated has arrived (in the received acknowledgement). Any outstanding unacknowledged packets with lower transmit numbers are presumed lost. ¶ [0153], the ranges between the second and subsequent ranges in the SACK information are "holes" in the received data, the data therein known not to have been delivered. Using this method, the receiver may indicate to the sender a range of data packets that have not yet been received by the receiver. ¶ [0154], The sender thus adds this packet to a list of potentially lost packets, called the presumed lost list. Each time a SACK packet arrives, the known missing ranges of data from the SACK packet are compared to the packets in the presumed lost list. Packets that contain data known to be missing are declared actually lost and are subsequently retransmitted. In this way, the two schemes are combined to give the sender better information about which packets have been lost and need to be retransmitted. In other words, the sender keeps track of whether the packets were received in the order they were transmitted or out-of-order (i.e., “holes” in the packets received by the receiver)).
Therefore, the amended claims 1, 18 and 19 are anticipated by Plamondon, as set forth above.
Conclusion
13. 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.
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477
Prosecution Insights