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-10, 12, and 14-20 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]); 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.); 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]).
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]); 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.); 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]).
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]); 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.); 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]).
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, wherein the feedback metadata indicates a given sent transport-layer flow
packet, among the sent transport-layer flow packets, has been received, and wherein the updating the tracking window includes changing an indicator bit 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], ¶ [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 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), wherein the sending the one or more EOF packets sends up to n EOF packets so as to flush the OOO tracking window, and wherein the selectively resending includes: identifying the one or more unacknowledged transport-layer flow packets in the updated OOO tracking window; and resending the one or more identified transport-layer flow packets (¶ [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 7, Plamondon teaches the method of claim 5, wherein the reliable transport protocol supports single-path delivery of the multiple transport-layer flow packets over a single path of the network, wherein the tracking window is an in-order tracking window, wherein the sending the one or more transport-layer EOF packets sends a single EOF packet so as to flush the in-order tracking window, and wherein the selectively resending includes: determining that the last transport-layer flow packet has been delayed or dropped; and resending the last transport-layer flow packet (figs. 7A, 7B, (¶ [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 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 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, and wherein the updating the tracking window includes changing an indicator bit for the given sent transport-layer flow packet (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 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 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 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 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).
5. Claims 1, 5, 8, 9, 13 and 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Shoens et al. (US 2018/0167168 A1, hereinafter “Shoens”).
Regarding claim 1, Shoens teaches in a computer system (figs. 1-5), a method of managing delivery of a given packet flow according to a reliable transport protocol (¶ [0021], ¶ [0040], Such communication protocols may include TCP/IP, RDMA, iSCSI, NVMe over fabrics, RDMA over fabrics such as InfiniBand, RoCE, and iWARP, and other communication protocols), 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, ¶ [0041], ¶ [0042], In the event that one or more additional message packets is scheduled to be transmitted to the remote device, functionality 400 returns to 420 for the transmission of the message packets from the client device to the remote device. Otherwise, in the event that no additional message packet is scheduled to be transmitted to the remote device, one or more loss detection packets are appended to the last message packet, at 440. Here, the last message packet and the loss detection packets are transmitted to the remote device); after the sending the last transport-layer flow packet but before satisfaction of a
timeout condition for the last transport-layer flow packet (¶ [0021], If the client device 102 pauses in the sending of requests, the loss of the last or second to last packet in the session flow prevents server 116 from receiving the complete request until the TCP/IP retransmit timer expires, typically in hundreds of milliseconds (e.g., 300 ms). As a result, occasional latencies several orders of magnitude (e.g., thousands of times) higher than the usual latency frequently occur. ¶ [0026], If the RSC merges the two loss detection packets or the last packet of the flow with the loss detection packets, the receiving side will not send a sufficient number of duplicate ACK packets to trigger fast retransmit. To overcome this problem, interoperation of the loss detection packets with the RSC requires setting the PSH bit on the last packet of the flow and the two loss detection packets), sending one or more end-of-flowlet ("EOF") packets (figs. 3, 4, 6, ¶ [0026], ¶ [0042], otherwise, in the event that no additional message packet is scheduled to be transmitted to the remote device, one or more loss detection packets are appended to the last message packet, at 440. Here, the last message packet and the loss detection packets are transmitted to the remote device); receiving, at the sender from the receiver, feedback metadata for the one or more EOF packets (figs. 3, 4, 6, ¶ [0037], ¶ [0043], [0043] At 450, functionality 400 further determines whether the last message packet was successfully received by the remote device. Functionality 400 may determine if the loss detection packets were successfully received based on acknowledgment messages); at the sender, updating a tracking window based at least in part on the feedback metadata for the one or more EOF packets (fig. 4, ¶ [0022], ¶ [0043], In the event that the loss detection packet was not successfully received, the retransmit of the last message packet and loss detection packet is executed, at 455. For example, if the client device receives multiple (e.g., three) acknowledgements of the same sequence number, the client device retransmits the message packets that are deemed missing. The last message packet may be retransmitted within 100 microseconds or less of its previous transmission. For example, the retransmit procedure may include TCP/IP fast retransmit. Otherwise, in the event that the loss detection packet was successfully transmitted, functionality 460 terminates the communication session, at 460. ¶ [0028]); 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 (fig. 4, ¶ [0022], ¶ [0043], if the client device receives multiple (e.g., three) acknowledgements of the same sequence number, the client device retransmits the message packets that are deemed missing. The last message packet may be retransmitted within 100 microseconds or less of its previous transmission. ¶ [0048]).
Regarding claim 18, Shoens teaches one or more non-transitory computer-readable media having stored thereon computer-executable instructions for causing one or more processing units (figs. 1, 2, ¶ [0030], ¶ [0031]), when programmed thereby, to perform operations to manage delivery of a given packet flow according to a reliable transport protocol (¶ [0021], ¶ [0040], Such communication protocols may include TCP/IP, RDMA, iSCSI, NVMe over fabrics, RDMA over fabrics such as InfiniBand, RoCE, and iWARP, and other communication protocols), 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, ¶ [0041], ¶ [0042], In the event that one or more additional message packets is scheduled to be transmitted to the remote device, functionality 400 returns to 420 for the transmission of the message packets from the client device to the remote device. Otherwise, in the event that no additional message packet is scheduled to be transmitted to the remote device, one or more loss detection packets are appended to the last message packet, at 440. Here, the last message packet and the loss detection packets are transmitted to the remote device); after the sending the last transport-layer flow packet but before satisfaction of a timeout condition for the last transport-layer flow packet (¶ [0021], If the client device 102 pauses in the sending of requests, the loss of the last or second to last packet in the session flow prevents server 116 from receiving the complete request until the TCP/IP retransmit timer expires, typically in hundreds of milliseconds (e.g., 300 ms). As a result, occasional latencies several orders of magnitude (e.g., thousands of times) higher than the usual latency frequently occur. ¶ [0026], If the RSC merges the two loss detection packets or the last packet of the flow with the loss detection packets, the receiving side will not send a sufficient number of duplicate ACK packets to trigger fast retransmit. To overcome this problem, interoperation of the loss detection packets with the RSC requires setting the PSH bit on the last packet of the flow and the two loss detection packets), sending one or more end-of-flowlet ("EOF") packets (figs. 3, 4, 6, ¶ [0026], ¶ [0042], otherwise, in the event that no additional message packet is scheduled to be transmitted to the remote device, one or more loss detection packets are appended to the last message packet, at 440. Here, the last message packet and the loss detection packets are transmitted to the remote device); receiving, at the sender from the receiver, feedback metadata for the one or more EOF packets (figs. 3, 4, 6, ¶ [0026], ¶ [0042], otherwise, in the event that no additional message packet is scheduled to be transmitted to the remote device, one or more loss detection packets are appended to the last message packet, at 440. Here, the last message packet and the loss detection packets are transmitted to the remote device); at the sender, updating a tracking window based at least in part on the feedback metadata for the one or more EOF packets (fig. 4, ¶ [0022], ¶ [0043], In the event that the loss detection packet was not successfully received, the retransmit of the last message packet and loss detection packet is executed, at 455. For example, if the client device receives multiple (e.g., three) acknowledgements of the same sequence number, the client device retransmits the message packets that are deemed missing. The last message packet may be retransmitted within 100 microseconds or less of its previous transmission. For example, the retransmit procedure may include TCP/IP fast retransmit. Otherwise, in the event that the loss detection packet was successfully transmitted, functionality 460 terminates the communication session, at 460. ¶ [0028]); 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 (fig. 4, ¶ [0022], ¶ [0043], if the client device receives multiple (e.g., three) acknowledgements of the same sequence number, the client device retransmits the message packets that are deemed missing. The last message packet may be retransmitted within 100 microseconds or less of its previous transmission. ¶ [0048]).
Regarding claim 5, Shoens 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 (figs. 3, 6).
Regarding claim 8, Shoens teaches the method of claim 5, wherein the payload of the flush packet is nominal or empty (¶ [0036], inclusion of data load is optional for loss detection packets. ¶ [0037], when the TCP/IP client transmits data packets with the PSH flag set, the TCP/IP communication protocol may append multiple (e.g., two) additional one-byte loss detection packets that the receiving server silently discards. The use of two or more loss detection packets does not hinder network performance due to their small size).
Regarding claim 9, Shoens 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 (figs. 3, 6, ¶ [0024], a push acknowledgement (“PSH”), ¶ [0026], interoperation of the loss detection packets with the RSC requires setting the PSH bit on the last packet of the flow and the two loss detection packets. ¶ [0036], ¶ [0037]).
Regarding claim 13, Shoens teaches the method of claim 1, 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).
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.
Conclusion
10. 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