Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "a data center" in line 17. It is unclear if is a new “a data center” or referred back to “a data center” in claim 1 line 15.
Claim 1 recites the limitation "a data node" in line 17. It is unclear if is a new “a data node” or referred back to “a data node” in claim 1 line 15. Similar problem in claim 4, 11.
Claim 1 recites the limitation "the data node" in line 22. It is unclear if is referred back to “a data node” in claim 1 line 15 or line 17. Similar problem in claim 5, 12.
Claim 1 recites the limitation "the data center" in line 17. It is unclear if is referred back to “a data center” in claim 1 line 15 or line 17. Similar problem in claim 5, 9, 11, 12.
Claim 2 recites the limitation "the extended DIO message" in line 1. There is insufficient antecedent basis for this limitation in the claim. It is appeared to be misspelled of “extended DAO” in claim 1 line 16.
Claim 2 recites the limitation "the node type" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "upward path" in line 1. It is unclear if is a new “upward path” or referred back to “upward path” in claim 1 line 14.
Claim 3 recites the limitation "the DIO message receiver" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "the path starting node" in lines 2, 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitation "the formed upward path" in line 3. It is unclear if is referred back to “formed upward path” in claim 1 line 14 or claim 3 line 1.
Claim 3 recites the limitation "a downward path" in line 4. It is unclear if is a new “a downward path” or referred back to “a downward path” in claim 1 line 17.
Claim 6 recites the limitation "a congestion window" in line 2. It is unclear if is a new “a congestion window” or referred back to “a congestion window” in claim 1 line 19. Similar problem in claim 10.
Claim 7 recites the limitation "the retransmit timeout (RTO) timer adaption" in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation "the congestion window update frequency adaption" in line 5. There is insufficient antecedent basis for this limitation in the claim.
Claim 9 recites the limitation "a data node close" in line 3, 7. It is unclear if is a new “a data node close” or referred back to “a data node close” in claim 9 line 1.
Claim 9 recites the limitation "a data node away" in line 8. It is unclear if is a new “a data node away” or referred back to “a data node away” in claim 9 line 3.
Claim 10 recites the limitation "an MPTCP path" in line 3. It is unclear if is a new “an MPTCP path” or referred back to “an MPTCP path” in claim 1 line 12. Similar problem with claim 11, 18.
Claim 11 recites the limitation "the MPTCP path" in line 3. It is unclear if is referred back to “an MPTCP path” in claim 1 line 12 or claim 10 line 3. Similar problem with claim 11. Similar problem in claim 12, claim 13.
Claim 18 recites the limitation "a scheduling round" in line 1. It is unclear if is a new “a scheduling round” or referred back to “a scheduling round” in claim 17 line 15. Similar problem with claim 19.
Regarding claim 19, the phrase "can" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Claim 20 recites the limitation " an MPTCP path PNPt scheduling round " in line 2. It is unclear if is a new “an MPTCP path PNPt scheduling round” or referred back to “an MPTCP path PNPt scheduling round” in claim 19 line 6, 7.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
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.
Claim(s) 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 13, 15, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over KANG et al. (US 20210329528) in view of WANG et al. (US 20110249553), HUI et al. (US 20140269413), PORFIRI et al. (US 20220166549), and SCAHILL et al. (US 10594596).
Regarding claim 1, KANG et al. (US 20210329528) teaches a node device for a heterogeneous wireless communications network including single-link data nodes, multi-link data nodes (par. 5, 112, TCP, MPTCP), data centers (par. 5, 266, data center), and a 5G base station network (par. 112, 5G), wherein the node device comprising:
a transceiver configured to transmit and receive management packets and data packets in the heterogeneous wireless network (fig. 15A, par. 120, 209, wireless network);
a memory configured to store computer executable programs for performing an MPTCP path establishment algorithm (par. 217, The MPTCP protocol stack completes establishment of an MPTCP connection, including establishment of the primary path and a subpath, between the application client and an application server), an MPTCP congestion control algorithm, and an MPTCP path scheduling algorithm for the data packets (fig. 15A, 15B, par. 177, 207, 209, 216, 217, 227, 228, 229, 230, 233);
a processor configured to perform steps of the computer executable programs, wherein the steps comprise:
forming an MPTCP path in the heterogeneous wireless communications network by transmitting and receiving a) message to form a upward path from a data node to a data center (fig. 8, par. 110, (1) The terminal 101 generates a target link establishment request based on an application request initiated by a target application, and sends the target link establishment request to a path selection module. The target application may be any application that runs on the terminal 101. The target link establishment request is used to request the terminal 101 to establish at least one transport layer connection. The path selection module may be an independent function module in the terminal 101, and is configured to implement the “link establishment path selection” function. (2) The path selection module obtains transmission status information of a plurality of available paths. (3) The path selection module selects a target available path with better transmission performance in the plurality of available paths based on the transmission status information of the plurality of available paths, and sends an identifier of the target available path to a transport layer protocol stack), and assigning a path identification data (ID) for a upward path established (par. 109, 110, all connection information (a channel, a destination IP address, selection of a primary path in a case of multipath, and the like));
The transmission status information of each available path of the at least two available paths may further include a packet loss rate, a queuing delay, a congestion window value, or another parameter used to represent transmission performance of the available path (par. 12),
scheduling transmission of the data packets along multiple paths formed from the data node to the data center to ensure the data packets arrive at the data center of the transmission time over multiple paths (par. 142, the target available path with better transmission performance may be selected based on an RTT of each available path).
However, KANG does not teach an MPTCP Adaptive NewReno (A- NewReno) congestion control algorithm;
But, WANG et al. (US 20110249553) in a similar or same field of endeavor teaches a transceiver configured to transmit and receive management packets and data packets in the heterogeneous wireless network (par. 30, wireless network);
a memory configured to store computer executable programs for performing an MPTCP path establishment algorithm (par. 6, 24, 38, 39, In MulTCP, N virtual TCP sessions are utilized to simulate the behavior of multiple actual parallel TCP sessions… multiple parallel virtual TCP connections to fully and fairly utilize the network's bandwidth), an MPTCP Adaptive NewReno (A- NewReno) congestion control algorithm (par. 24, 38, 39, N parallel virtual TCP-Reno connections… The TCP-FIT congestion control 210 may include a mechanism selector 218 that selects an appropriate control mechanism based on the estimated network condition), and an MPTCP path scheduling algorithm for the data packets (par. 26).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by WANG in the system of KANG to manage transmission in MPTCP.
The motivation would have been to provide TCP congestion control mechanism that can fully and fairly utilize the bandwidth in various networks, including high BDP networks as well as wireless networks.
However, KANG does not teach forming an MPTCP path in the heterogeneous wireless communications network by transmitting and receiving an extended destination oriented directed acyclic graph (DODAG) information object (DIO), transmitting and receiving an destination advertisement object (DAO) message in responding to receiving a DIO message to form a downward path from a data center to a data node, and assigning a path identification data (ID) for a upward path established;
But, HUI et al. (US 20140269413) in a similar or same field of endeavor teaches forming an MPTCP path in the heterogeneous wireless communications network by transmitting and receiving an extended destination oriented directed acyclic graph (DODAG) information object (DIO) message to form a upward path from a data node to a data center (par. 35, 36, 37, a DODAG Information Object (DIO) is a type of DAG discovery message that carries information that allows a node to discover a RPL Instance, learn its configuration parameters, select a DODAG parent set, is and maintain the upward routing topology), transmitting and receiving an extended destination advertisement object (DAO) message in responding to receiving a DIO message to form a downward path from a data center to a data node (par. 36, 37, 38, a Destination Advertisement Object (DAO) is a type of DAG discovery reply message that conveys destination information upwards along the DODAG so that a DODAG root (and other intermediate nodes) can provision downward routes.), and assigning a path identification data (ID) for a upward path established (par. 36, 37, 38, A DAO message includes prefix information to identify destinations, a capability to record routes in support of source routing, and information to determine the freshness of a particular advertisement.);
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by HUI in the system of KANG and WANG to use a distance vector routing protocol that builds a Destination Oriented Directed Acyclic Graph (DODAG, or simply DAG).
The motivation would have been to prevent loops and to provide maintaining multiple next-hop routes to improve reliability and latency in the shared-media communication network.
However, KANG does not teach computing a congestion window (cwnd) by determining a minimum congestion window (cwndmin) and a maximum congestion window (cwndmax);
But, PORFIRI et al. (US 20220166549) in a similar or same field of endeavor teaches computing a congestion window (cwnd) by determining a minimum congestion window (cwndmin) and a maximum congestion window (cwndmax) (par. 70, 71, initially the CWND will be set to its minimum size…the retransmission timer T3 has not reached RTO.min being the value where the timer T3 expires, the size of the CWND is increased at each measured RTT until a maximum CWND limit cwndMax is reached reflecting a maximum allowed bandwidth in the network);
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by PORFIRI in the system of KANG, WANG, and HUI to manage contention control window.
The motivation would have been to mitigate the congestion control algorithm to decrease the available bandwidth in order to prevent packet loss due to network congestion.
However, KANG does not teach the order of the transmission time over multiple paths.
But, SCAHILL et al. (US 10594596) in a similar or same field of endeavor teaches scheduling transmission of the data packets along multiple paths formed from the data node to the data center to ensure the data packets arrive at the data center in the order of the transmission time over multiple paths (col. 5 lines 52-col. 6 line 9, The MPTCP stack 35 then allocates the sequence of data packets to the LTE send buffer 39 and the WiFi send buffer 41 in accordance with a pre-stored MPTCP scheduler algorithms… The scheduler decision, i.e. the assignment of a data packet to a sub-flow is be based on several variables, for example, the capacity of the sub-flow or the delay of packets travelling along the sub-flow. Although different MPTCP stacks may implement different schedulers, most schedulers will use sub-flow capacity and or sub-flow delays in the scheduling decision… the MPTCP scheduler will allocate 40% of the data packets to the LTE path and 60% of the data packets to be transmitted to the WiFi path).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by SCAHILL in the system of KANG, WANG, HUI, and PORFIRI to schedule the multiple paths transmission.
The motivation would have been to detect loss and provide reliable transmission.
Regarding claim 2, KANG et al. (US 20210329528) teaches teaches the node device of claim 1, wherein the message additionally contains the path traversed by the message transmitter with 0 indicating single-link node and 1 indicating multi-link node (par. 14, 110, 134, 213, if the path uses a TCP protocol, the MP connection is an MPTCP connection. A start and a termination of a subflow are similar to those of a regular TCP connection. In this specification, one subflow corresponds to one path. The multipath connection may be an MPTCP connection…For a single-path protocol such as TCP or user datagram protocol (UDP), the terminal 101 selects a path to further establish a transport layer connection, for example, a TCP connection. For a multipath protocol such as MPTCP, the terminal 101 selects a primary path).
However, KANG does not teach wherein the extended DIO message additionally contains the path traversed by the DIO message and the node type of DIO message, wherein the extended DAO message additionally contains the path formed and the path ID assigned.
But, HUI et al. (US 20140269413) in a similar or same field of endeavor teaches wherein the extended DIO message additionally contains the path traversed by the DIO message and the node type of DIO message, wherein the extended DAO message additionally contains the path formed and the path ID assigned (par. 34, 36, 37, 38, 48, 51, 52, A DAO message includes prefix information to identify destinations, a capability to record routes in support of source routing, and information to determine the freshness of a particular advertisement…The DAG discovery reply (e.g., DAO) may then be returned from the leaves to the root device(s) (unless unnecessary, such as for UP flows only), informing each successive receiving device in the other direction how to reach the leaves for downward routes. Nodes that are capable of maintaining routing state may aggregate routes from DAO messages that they receive before transmitting a DAO message).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by HUI in the system of KANG, WANG, PORFIRI, and SCAHILL to use a distance vector routing protocol that builds a Destination Oriented Directed Acyclic Graph (DODAG, or simply DAG).
The motivation would have been to prevent loops and to provide maintaining multiple next-hop routes to improve reliability and latency in the shared-media communication network.
Regarding claim 3, HIU et al. (US 20140269413) teaches the node device of claim 2, wherein a upward path is formed by reversing the path contained in DIO message and attaching the DIO message receiver as the path starting node (par. 37), wherein the formed upward path is assigned a path identifier (ID), wherein a downward path configured by the data center using information contained in DAO messages (par. 37, "upward" or "up" paths are routes that lead in the direction from leaf nodes towards DAG roots, e.g., following the orientation of the edges within the DAG. Conversely, "downward" or "down" paths are routes that lead in the direction from DAG roots towards leaf nodes, e.g., generally going in the opposite direction to the upward messages within the DAG.).
Regarding claim 4, KANG does not teach the node device of claim 1, wherein a number of paths threshold (NPt) is defined to limit the number of MPTCP paths formed by a data node in a heterogeneous wireless communications network.
But, WANG et al. (US 20110249553) in a similar or same field of endeavor teaches wherein a number of paths threshold (NPt) is defined to limit the number of MPTCP paths formed by a data node in a heterogeneous wireless communications network (par. 24, 38, 42, the estimated network condition is used be an N adjuster 214 that adjusts the dynamic value of the number of parallel virtual connections that will fairly and fully utilize the network bandwidth).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by WANG in the system of KANG, HUI, PORFIRI, and SCAHILL to manage transmission in MPTCP.
The motivation would have been to provide TCP congestion control mechanism that can fully and fairly utilize the bandwidth in various networks, including high BDP networks as well as wireless networks.
Regarding claim 5, WANG teaches the node device of claim 4, wherein a single-link node can build up to NPt MPTCP paths to the data center (fig. 5, par. 72).
However, KANG and WANG do not teach wherein a multi-link data node builds a one-hop MPTCP path to the data center if the node can directly communicate with the data center or builds a two-hop MPTCP path via base station network to the data center if the node cannot directly communicate with the data center, wherein an MPTCP path of a single-link node can be one-hop or multiple hops.
But, HUI et al. (US 20140269413) in a similar or same field of endeavor teaches wherein a multi-link data node builds a one-hop MPTCP path to the data center if the node can directly communicate with the data center or builds a two-hop MPTCP path via base station network to the data center if the node cannot directly communicate with the data center (par. 48, the node may assign a DAG rank (as shown in FIG. 3 as the first digit of the node numbers, e.g., rank "1" for nodes 11, 12, and 13, rank "2" for nodes 22, 23, and 24, etc.) corresponding to a topological distance to a root node of the first DAG topology 310 (e.g., as in RPL).), wherein an MPTCP path of a single-link node can be one-hop or multiple hops (par. 48, the node may assign a DAG rank (as shown in FIG. 3 as the first digit of the node numbers, e.g., rank "1" for nodes 11, 12, and 13, rank "2" for nodes 22, 23, and 24, etc.) corresponding to a topological distance to a root node of the first DAG topology 310 (e.g., as in RPL).).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by HUI in the system of KANG, WANG, PORFIRI, and SCAHILL to use a distance vector routing protocol that builds a Destination Oriented Directed Acyclic Graph (DODAG, or simply DAG).
The motivation would have been to prevent loops and to provide maintaining multiple next-hop routes to improve reliability and latency in the shared-media communication network.
Regarding claim 6, WANG teaches the node device of claim 1, wherein the Adaptive NewReno congestion control algorithm determines a congestion window (cwnd) for an MPTCP path in a scheduling round (par. 26, 27, 28, 31, 32, Where Cwnd is the value of the congestion window for the actual physical TCP session, consisting of N virtual sessions of congestion window value of cwnd…the number N of virtual parallel Reno-like sessions may be dynamically adjusted).
Regarding claim 7, PORFIRI teaches the node device of claim 6, wherein the Adaptive NewReno congestion control algorithm extends the conventional NewReno algorithm in three aspects: (1) the minimum congestion window (cwndmi,) and the maximum congestion window (cwndmax) adaptation (par. 70, 71, initially the CWND will be set to its minimum size…the retransmission timer T3 has not reached RTO.min being the value where the timer T3 expires, the size of the CWND is increased at each measured RTT until a maximum CWND limit cwndMax is reached reflecting a maximum allowed bandwidth in the network), (2) the retransmit timeout (RTO) timer adaptation (par. 71) and (3) the congestion window update frequency adaptation (par. 71, the retransmission timer T3 has not reached RTO.min being the value where the timer T3 expires, the size of the CWND is increased at each measured RTT until a maximum CWND limit cwndMax is reached reflecting a maximum allowed bandwidth in the network).
Regarding claim 8, WANG teaches the node device of claim 7, wherein the congestion window (cwnd) is a parameter to limits the number of data packets to be scheduled alone an MPTCP path in a scheduling round such that the number of data packets scheduled in a scheduling round cannot exceed the cwnd (par. 29, contention control window (Cwnd), controls how many unacknowledged packets a TCP sender can transmit before waiting for acknowledgments).
Regarding claim 10, WANG et al. (US 20110249553) teaches the node device of claim 1, wherein the data packet scheduling algorithm applies a round trip time (RTT) and a congestion window (cwnd) to determine the number of packets to be transmitted alone an MPTCP path in a scheduling round (par. 26, 27, 28, 31, 32, where curr_rtt and curr_cwnd are the current RTT and congestion window size respectively, min_rtt is the minimal recent RTT observed value used as a reasonable estimate of the propagation delay of the network. curr_rtt-min_rtt represents the estimated value of the queuing delay. Since a TCP session sends cwnd packets in a RTT, (curr_cwnd)/(curr_rtt) may be considered as an estimate of packet transmission rate of current TCP session).
Regarding claim 12, WANG et al. (US 20110249553) teaches the node device of claim 10, wherein the elapsed time is sum of the time spent by the data octet traverses from the data node to the data center alone the MPTCP path and the time spent by the ACK traverses from the data center to the data node alone same MPTCP path (par. 26, RTT, or the return trip time is calculated based on the time between sending a packet and receiving an ACK from the receiver for the corresponding packet).
Regarding claim 13, WANG et al. (US 20110249553) teaches the node device of claim 12, wherein the time spent by the data octet is sum of the time spent by the data octet at all nodes alone the MPTCP path, wherein the time spent by the ACK is sum of the time spent by the ACK at all nodes alone the same MPTCP path (par. 26, RTT, or the return trip time is calculated based on the time between sending a packet and receiving an ACK from the receiver for the corresponding packet).
Regarding claim 15, WANG teaches the node device of claim 14, wherein the random queuing time spent by the data octet or the ACK is computed asNg+1, where Nq is the number of packets in the queue given by equation (8) and p is the packet transmission rate (par. 44, 45, the queuing delay q can be approximated using equation of number of packets in queue and bandwidth or packet transmission rate).
Regarding claim 17, WANG et al. (US 20110249553) teaches the node device of claim 1, wherein the scheduling algorithm schedules packet transmission over multiple MPTCP paths based on the fastest RTT, wherein a MPTCP path with the smaller RTT is scheduled to transmit more data packets in a scheduling, wherein a MPTCP path with the larger RTT is scheduled to transmit fewer data packets in a scheduling round (par. 31, Similar to standard MulTCP, Cwnd of TCP-FIT increases by N.sub.t packets during an RTT. Given the same network conditions, standard MulTCP with N parallel connections can not guarantee that the congestion window is exactly N times that of a single Reno session. Therefore, to improve overall throughput, Cwnd is decreased by a factor of 2/(3N+1) instead of 1/2N as described above when a packet loss occurs; par. 110, 113, 114, 182, the Wi-Fi path experiences capacity degradation at time (about time 15.3), and a data frame delay and an RTT of a data frame transmitted on the Wi-Fi path suddenly increase to 1700 ms. This capacity degradation may cause sudden frame pause lasting for hundreds of milliseconds, which may significantly affect user experience).
Regarding claim 18, WANG et al. (US 20260095493) teaches the node device of claim 17, wherein a scheduling round for an MPTCP path is the time spent to successfully transmit all data packets scheduled, wherein the success of data packet transmission is confirmed by the acknowledgement from the data center (par. 42, 44, 45, If an ACK is received (Yes at 406) the estimate of the network condition is updated (410), namely the RTT, and the number, N, of parallel virtual connections is updated (412). Once the number of parallel virtual connections is updated, the Cwnd is increased according to the control mechanism of the connection as if it were N connections…When these TCP sessions send packet through the network, there are on average M packets traversing the bottleneck).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over KANG et al. (US 20210329528), WANG et al. (US 20110249553), HUI et al. (US 20140269413), PORFIRI et al. (US 20220166549), and SCAHILL et al. (US 10594596) as applied to claim 13 above, and further in view of Mittal et al. (“TIMELY: RTT-based Congestion Control for the Datacenter”) and Gitlin et al. (US 10327123).
Regarding claim 14, KANG does not teach the node device of claim 13, wherein the time spent by the data octet or the ACK at a single-link node (IEEE 802.15.4 node) includes (1) a random queuing time, (2) a random channel access delay time, (3) a fixed reception to transmission turnaround time, (4) a fixed packet transmission time and (5) a fixed MAC layer ACK transmission time, wherein the time spent by the data octet or the ACK at a multi-link node (5G node) includes (1) a random queuing time and (2) a fixed packet transmission time.
But, Mittal et al. (“TIMELY: RTT-based Congestion Control for the Datacenter”) in a similar or same field of endeavor teaches wherein the time spent by the data octet or the ACK at a single-link node (IEEE 802.15.4 node) includes (1) a random queuing time, (3) a fixed reception to transmission turnaround time, (4) a fixed packet transmission time and (5) a fixed MAC layer ACK transmission time, wherein the time spent by the data octet or the ACK at a multi-link node (5G node) includes (1) a random queuing time and (2) a fixed packet transmission time (section 3.1, there is one RTT for the set of packets rather than one RTT per 1-2 packets. There are several delay components: 1) the serialization delay to transmit all packets in the segment, typically up to 64 KB; 2) the round-trip wire delay for the segment and its ACK to propagate across the datacenter; 3) the turnaround time at the receiver to generate the ACK; and 4) the queuing delay at switches experienced in both directions ).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by MITTAL in the system of KANG, WANG, HUI, and PORFIRI, and SCAHILL to determine round trip time.
The motivation would have been to provide accurate round trip time.
However, KANG does not teach (2) a random channel access delay time;
But, Gitlin et al. (US 10327123) in a similar or same field of endeavor teaches a random channel access delay time (col. 11 lines 11-27, the channel access delay is composed of three components, namely: round trip delay, delay due to the attempts for random selection of distinct power levels, and the back-off delay).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by GITLIN in the system of KANG, WANG, HUI, and PORFIRI, SCAHILL, and MITTAL to determine round trip time.
The motivation would have been to provide more accurate round trip time.
Claim(s) 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KANG et al. (US 20210329528), WANG et al. (US 20110249553), HUI et al. (US 20140269413), PORFIRI et al. (US 20220166549), and SCAHILL et al. (US 10594596) as applied to claim 17 above, and further in view of KUCERA et al. (US 20190387451).
Regarding claim 19, KANG does not teach the node device of claim 17, wherein the scheduling algorithm arranges MPTCP paths P1,P2,---, PNPt in RTT ascending order as RTT1RTT2RTTNPt, wherein the corresponding congestion windows is determined as cwndi, cwnd2,..., cwndNPt, respectively, wherein the cwndNPt packets are scheduled for MPTCP path PNPt in a scheduling round, wherein multiple scheduling round can take place for MPTCP paths P1, P2, ---, PNPt-1 within an MPTCP path PNPt scheduling round depending their RTTs and congestion windows.
But, KUCERA et al. (US 20190387451) in a similar or same field of endeavor teaches wherein the scheduling algorithm arranges MPTCP paths P1,P2,---, PNPt in RTT ascending order as RTT1RTT2RTTNPt, wherein the corresponding congestion windows is determined as cwndi, cwnd2,..., cwndNPt, respectively, wherein the cwndNPt packets are scheduled for MPTCP path PNPt in a scheduling round, wherein multiple scheduling round can take place for MPTCP paths P1, P2, ---, PNPt-1 within an MPTCP path PNPt scheduling round depending their RTTs and congestion windows (table 1b, par. 175, LTE path with CWND and maximum data rate (CWND/RTT) and WiFi path with CWND and maximum data rate (CWND/RTT)).
Thus, it would have been obvious to the person of ordinary skill in the art before the effectively filing date of the claimed invention to implement the system or method as taught by KUCERA in the system of KANG, WANG, HUI, PORFIRI, and SCAHILL to manage transmission in MPTCP.
The motivation would have been to track and optimize the transmission over a path in multiple paths.
Regarding claim 20, WANG et al. (US 20260095493) teaches the node device of claim 19, wherein the number of data packets scheduled for an MPTCP path Pi (i=1,2, ..., NPt-1) within an MPTCP path PNPt scheduling round is sum of the data packets scheduled in all multiple rounds (par. 42, 44, 45, If an ACK is received (Yes at 406) the estimate of the network condition is updated (410), namely the RTT, and the number, N, of parallel virtual connections is updated (412). Once the number of parallel virtual connections is updated, the Cwnd is increased according to the control mechanism of the connection as if it were N connections…When these TCP sessions send packet through the network, there are on average M packets traversing the bottleneck).
Allowable Subject Matter
Claim 9, 11, 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LI et al. (US 20210105659) teaches the congestion window size (CWND) indicates a maximum amount of data that the sender 130 can stream into the network before receiving an ACK (par. 14).
(closet to claim 9), WANG et al. (US 20110249553) teaches A potential issue with the above adjustment for increasing Cwnd is that for two MulTCP or TCP-FIT sessions sharing the same bottleneck the session with the longer RTT will have fewer chances to update its Cwnd and therefore will be at a disadvantage, because the value of the Cwnd is updated every RTT (par. 27); Similar to standard MulTCP, Cwnd of TCP-FIT increases by N.sub.t packets during an RTT. Given the same network conditions, standard MulTCP with N parallel connections can not guarantee that the congestion window is exactly N times that of a single Reno session. Therefore, to improve overall throughput, Cwnd is decreased by a factor of 2/(3N+1) instead of 1/2N as described above when a packet loss occurs (par. 31).
(closet to claim 16) Gitlin et al. (US 10327123) in a similar or same field of endeavor teaches a random channel access delay time (col. 11 lines 11-27, the channel access delay is composed of three components, namely: round trip delay, delay due to the attempts for random selection of distinct power levels, and the back-off delay).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THINH D TRAN whose telephone number is (571)270-3934. The examiner can normally be reached mon-fri 9-6.
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, FARUK HAMZA can be reached at 5712727969. 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.
/THINH D TRAN/for /Thinh Tran/, Patent Examiner of Art Unit 2466 05/01/2026
Prosecution Insights