DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicants’ arguments filed 06/03/2026 have been fully considered but they are not persuasive.
-Applicant argued that regarding claim 1 the combination does not disclose:
-"a transmitting window of the first service data stream comprising "a first sub-window" and "a second sub-window," each corresponding to the transmitting stream of the respective link, with transmissions on each link made based on the respective sub-window”.
Examiner respectfully disagrees:
Amend in [0003] discloses Multipath network protocols such as MP-QUIC allow to establish more than one communication flow between a sender and a receiver. Fig. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver… …[0004] discloses on sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like BBR etc….[0005] While on sender side traffic is split across communication paths. The above congestion control methods such as BBR uses congestion window per path that corresponds to sub-window. The mechanism of BBR congestion control is well known in the art. The congestion control determines bandwidth of each link, and RTT corresponding to the links and determining BPD from these values. Using the BPD determines CWND for each corresponding paths to send data.
For instance non-relied up on prior art Amend2 EP4080836A1 in [0034] and fig. 3 discloses how BBR congestion control works. It discloses in [0034] that using, according to an embodiment, BBR allows for a scheduler which enable the process on the right side of Fig. 4…BBR will periodically drain the path of packets so that it may register the minimum RTT (RTTmin), while it will continuously register the throughput of the path (BW); BBR will set its congestion window according to equation 1 where G is a gain factor set to 2:
CWND (sub-window) = RTTmin * BW * Gb (1)
wherein RTTmin is the minimum round-trip time, BW is the bandwidth, and G is a gain. Because the congestion window, CWND, is based on the bandwidth delay product (BPD), the multipath scheduler may adjust how deeply it wishes to fill the bottleneck buffer of each path by adjusting the CWND. Fig. 3 discloses scheduler determines the CWND1 and CWND2 of the respective paths using BBR and transmit data on each path according to corresponding CWNDs determined. Hence the BBR congestion control mechanism taught in Amend teaches the above limitation of determination of sub windows where the CWND of corresponding path corresponds to sub window. Applicant argued that the combination does not disclose “a transmitting window of the first service data stream comprising "a first sub-window" and "a second sub-window," The CWND1 and CWND2 of paths in BBR congestion control protocols as similarly indicated in fig. 3 of Amend2 corresponds to the sub-windows. Mere labeling of these sub windows collectively as a transmitting window is a mere naming or collectively labeling them. The claims or the disclosure does not explicitly disclose how a transmitting window is determined or calculated and how it is associated with each sub-windows. It just merely name determined sub windows of corresponding paths together as a transmitting window. That amounts to a mere naming of independently determined components collectively with one unifying name where the determination of these sub-windows is at the sub-window level. The mere collectively labeling the sub-windows with one unifying name does not amount to an inventive concept and is an obvious variation. Examiner suggests indicating explicitly how transmitting window is calculated or determined and how it is explicit associated with the sub windows. In the current form, the claim does not indicate how the transmission window is determined and how it is associated with each sub windows making the limits and bounds of the claims unclear and indefinite.
Regarding claims 9 and 16, Applicant’s arguments, filed 06/03/2026, with respect to the rejection(s) of claim(s) 9, and 16 under the combination of prior arts have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Connick2 “ Multipath Extensions for QUIC (MP-QUIC) draft-deconinck-quic-multipath-04”.
Allowable Subject Matter
Claim 21 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 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.
Claim 1-5, and 7-8 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 1recites disclose “a transmitting window of the first service data stream comprising "a first sub-window" and "a second sub-window,". The claims or the disclosure does not explicitly disclose how a transmitting window is determined or calculated and how it is associated with each sub-windows. Examiner suggests indicating explicitly how transmitting window is calculated or determined and its explicit associations with the sub windows. In the current form, the claims do not indicate how the transmission window is determined and how it is associated with each sub-windows making the limits and bounds of the claims unclear and indefinite.
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.
Claim(s) 1, 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhu (US pg. no. 20230353455), further in view of Amend (US pg. no. 20240381336).
Regarding claim 1. Zhu discloses a data transmission method, applied to a first apparatus (fig. fig.1 client 101), the method comprising:
transmitting the first data stream from the first apparatus to the second apparatus based on a first transmitting stream of the first link (fig. 1b and fig. 3 disclose client 101 and server 140 are connected in multipath communication using LTE connection and WiFi connection to transmit stream between the devices using the multipath; fig. 6a and fig. 6b discloses setting up MPQUIC connection between the client 101 and server 140 of fig. 1); and
transmitting the second data stream from the first apparatus to the second apparatus based on a first transmitting stream of the second link (fig. 1b and fig. 3 disclose client 101 and server 140 are connected in multipath communication using LTE connection and WiFi connection to transmit stream between the devices using the multipath; fig. 6a and fig. 6b discloses setting up MPQUIC connection between the client 101 and server 140 of fig. 1b).
But, Zhu does not explicitly disclose:
allocating, based on a bandwidth of a first link corresponding to a first physical address of the first apparatus, and a bandwidth of a second link corresponding to a second physical address of the first apparatus, a first data stream of a first service data stream transmitted on the first link and a second data stream of the first service data stream transmitted on the second link, wherein the first link and the second link being links of a quick user datagram protocol Internet connection (QUIC) protocol;
the allocating comprises adjusting a transmitting window of the first service data stream based on the bandwidth of the first link and the bandwidth of the second link, the transmitting window comprising a first sub-window corresponding to a first transmitting stream of the first link and a second sub-window corresponding to a first transmitting stream of the second link;
transmitting the first data stream from the first apparatus to the second apparatus
transmitting the second data stream from the first apparatus to the second apparatus through the first transmitting stream of the second link based on the second sub-window.
However, in the same field of endeavor, Amend discloses allocating, based on a bandwidth of a first link corresponding to a first physical address of the first apparatus, and a bandwidth of a second link corresponding to a second physical address of the first apparatus, a first data stream of a first service data stream transmitted on the first link and a second data stream of the first service data stream transmitted on the second link, wherein the first link and the second link being links of a quick user datagram protocol Internet connection (QUIC) protocol ([0003] Multipath network protocols such as MP-QUIC allow to establish more than one communication flow between a sender and a receiver. Fig. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver… The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel …[0004] On sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link). Using [1]-[3], will gain these values from the employed congestion control approach like New Reno, Cubic, BBR etc….[0005] While on sender side traffic is split across communication paths); and
the allocating comprises adjusting a transmitting window of the first service data stream based on the bandwidth of the first link and the bandwidth of the second link, the transmitting window comprising a first sub-window corresponding to a first transmitting stream of the first link and a second sub-window corresponding to a first transmitting stream of the second link (Amend in [0003] discloses Multipath network protocols such as MP-QUIC allow to establish more than one communication flow between a sender and a receiver. Fig. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver… …[0004] discloses on sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like BBR etc….[0005] While on sender side traffic is split across communication paths. The above congestion control methods such as BBR uses congestion window per path that corresponds to sub-window. The mechanism of BBR congestion control is well known in the art. The congestion control determines bandwidth of each link, and RTT corresponding to the links and determining BPD from these values. Using the BPD determines CWND and adjust old CWND for each corresponding paths to send data.
For instance non-relied up on prior art Amend2 EP4080836A1 in [0034] and fig. 3 discloses how BBR congestion control works. It discloses how BBR congestion control of Amend indicated above works as follow:
in [0034] it discloses that using, according to an embodiment, BBR allows for a scheduler which enable the process on the right side of Fig. 4…BBR will periodically drain the path of packets so that it may register the minimum RTT (RTTmin), while it will continuously register the throughput of the path (BW); BBR will set its congestion window according to equation 1 where G is a gain factor set to 2:
CWND (sub-window) = RTTmin * BW * Gb (1)
wherein RTTmin is the minimum round-trip time, BW is the bandwidth, and G is a gain. Because the congestion window, CWND, is based on the bandwidth delay product (BPD), the multipath scheduler may adjust how deeply it wishes to fill the bottleneck buffer of each path by adjusting the CWND (adjusting CWND of each paths). Fig. 3 discloses scheduler determines the CWND1 and CWND2 of the respective paths using BBR and transmit data on each path according to corresponding CWNDs determined. Hence the BBR congestion control mechanism taught in Amend teaches the above limitation of determination of sub windows where the CWND of corresponding path corresponds to sub window. The claim further claims “a transmitting window of the first service data stream comprising "a first sub-window" and "a second sub-window," The CWND1 and CWND2 of paths in BBR congestion control protocols as similarly indicated in fig. 3 of Amend2 corresponds to the sub-windows. Mere labeling of these sub windows collectively as a transmitting window is a mere naming or collectively labeling them. The claims or the disclosure does not explicitly disclose how a transmitting window is determined or calculated and how it is associated with each sub-windows. It just merely name determined sub windows of corresponding paths together as a transmitting window. That amounts to a mere naming of independently determined components collectively with one unifying name where the determination of these sub-windows is at the sub-window level. The limitation is given broadest reasonable interpretation in light of the disclosure. Examiner suggests indicating explicitly how transmitting window is calculated or determined and its explicit associations with the sub windows to differentiate from prior arts. In the current form, the claim does not indicate how the transmission window is determined and how it is associated with each sub windows making the limits and bounds of the claims unclear and indefinite);
transmitting the first data stream from the first apparatus to the second apparatus fig. 1b and fig. 3 disclose client 101 and server 140 are connected in multipath communication using LTE connection and WiFi connection to transmit stream between the devices using the multipath; fig. 6a and fig. 6b discloses setting up MPQUIC connection between the client 101 and server 140 of fig. 1b; [0004] discloses on sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like BBR etc….[0005] While on sender side traffic is split across communication paths. The above congestion control methods such as BBR uses congestion window per path that corresponds to sub-window. The mechanism of BBR congestion control is well known in the art. The congestion control determines bandwidth of each link, and RTT corresponding to the links and determining BPD from these values. Using the BPD determines CWND for each corresponding paths to send data).
and transmitting the second data stream from the first apparatus to the second apparatus through the first transmitting stream of the second link based on the second sub-window (fig. 1b and fig. 3 disclose client 101 and server 140 are connected in multipath communication using LTE connection and WiFi connection to transmit stream between the devices using the multipath; fig. 6a and fig. 6b discloses setting up MPQUIC connection between the client 101 and server 140 of fig. 1b; 0004] discloses on sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like BBR etc….[0005] While on sender side traffic is split across communication paths. The above congestion control methods such as BBR uses congestion window per path that corresponds to sub-window. The mechanism of BBR congestion control is well known in the art. The congestion control determines bandwidth of each link, and RTT corresponding to the links and determining BPD from these values. Using the BPD determines CWND for each corresponding paths to send data).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of Zhu with Amend. The modification would allow effective scheduling and transmission of stream in a multi-path QUIC based on available link capacity. The modification would allow effective flow distribution system of multi-path transmission for effective communication system.
Regarding claim 7. The combination discloses method according to claim 1.
Amend discloses , further comprising: receiving, through a first receiving stream of the first link, a third data stream transmitted by the second apparatus (fig. 1and [0003] discloses shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver. A generator generates data packets 1 to 15 that pass a sequencing module which assigns each packet a respective sequence number. The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel and are queued in a reorder queue at the receiver side where they arrive at an input of the reorder queue) ;
receiving, through a first receiving stream of the second link, a fourth data stream transmitted by the second apparatus (fig. 1and [0003] discloses G. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver. A generator generates data packets 1 to 15 that pass a sequencing module which assigns each packet a respective sequence number. The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel and are queued in a reorder queue at the receiver side where they arrive at an input of the reorder queue. The receiving device processing the received data corresponds to determining a second service data); and
determining a second service data stream based on the third data stream and the fourth data stream (fig. 1and [0003] discloses G. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver. A generator generates data packets 1 to 15 that pass a sequencing module which assigns each packet a respective sequence number. The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel and are queued in a reorder queue at the receiver side where they arrive at an input of the reorder queue. The receiving device processing the received data corresponds to determining a second service data).
Regarding claim 8. The combination discloses method according to claim 1.
Zhu discloses, wherein a physical address of the second apparatus corresponding to the first link is different from a physical address of the second apparatus corresponding to the second link ([0050] For devices equipped with multiple radio link technologies (or multiple RAT circuitries), such as 5G/NR, LTE, WiFi, etc., MAMS [RFC8743] provides a programmable framework to dynamically select and transmit data simultaneously over multiple radio links for high throughput, low latency, and improved reliability. The physical address for each interface for LTE and WIFI corresponds to distinct physical address).
Claim(s) 2-5, and 11, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Zhu (US pg. no. 20230353455), and Amend (US pg. no. 20240381336), further in view of Coninck, “Multipath Extension for QUICdraft-deconinck-multipath-quic-00”.
Regarding claim 2. The combination discloses method according to claim 1.
Zhu further discloses, wherein before the allocating, based on the bandwidth of a first link and the bandwidth of a second link, a first data stream of a first service data stream transmitted on the first link and a second data stream of the first service data stream transmitted on the second link, the method further comprises:
transmitting a request to link message to the second apparatus (fig. 6a step 3 Mx capability request sent from MX peer 1 to MX peer2; [0128] At step 3, the MX peer 1 sends the MX Capability request (mx_capability_req) message (request to link message ) to MX Peer 2), the request to link message comprising a first connection identification, the first connection identification being a connection identification of the first transmitting stream of the first link, and the request to link message further comprising information indicating whether the first apparatus has capability to support QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the first apparatus ([0128] At step 3, the MX peer 1 sends the MX Capability request (mx_capability_req) message (request to link message ) to MX Peer 2. The MX Capability REQ includes the following parameters: … Number of Delivery Connections. For each delivery connection, the following parameters are included: Connection ID (corresponds to connection ID of the first connection of one of the delivery connections), Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.), MX Convergence Method Support List: MPQUIC that corresponds to capability information to support MPQUIC exchanged in the request);
receiving a feedback message transmitted by the second apparatus (([0130] and fig. 6A discloses In response at step 4, the NCM 236 sends the MX Capability Response (RSP)), the feedback message comprising a second connection identification, the second connection identification being a connection identification of a second transmitting stream of the first link, and the feedback message further comprising information indicating whether the second apparatus has capability to support the QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the second apparatus ([0130] In response at step 4, the NCM 236 (MX peer 2 of fig. 6A) sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: … Number of Delivery Connections (access links that correspond to links for stream from MX peer2 side (second transmitting stream)): For each delivery connection, the following parameters are included: Connection ID (second connection ID); Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc. supported by MX peer2); MX Convergence Method Support List :MPQUIC (MPQUIC support capability information)); and
generating parameter information of the first link based on the feedback message, the parameter information of the first link comprising the first connection identification, the second connection identification(fig. 6a, [00130] In response at step 4, the NCM 236 (MX peer 2 of fig. 6A) sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: … Number of Delivery Connections (access links that correspond to links for stream from MX peer2 side (second transmitting stream)): For each delivery connection, the following parameters are included: Connection ID; Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc. supported by MX peer2); MX Convergence Method Support List :MPQUIC (MPQUIC support capability information); [0134] discloses in response to the MX Capability RSP, at step 7 the CCM 206 sends a confirmation in the MX Capability Acknowledge (mx_capability_ack) message and/or MX UP Setup Confirm (mx_up_setup_conf_cnf) message. The MX Capability ACK includes the following parameters (generated parameters): Unique Session ID: Same identifier as the identifier provided in the MX Capability Response (that corresponds to the second connection identification); Acknowledgment: An indication of whether the client has accepted or rejected the capability exchange phase; MX ACCEPT: The CCM 206 accepts the capability set proposed by the NCM 236; Generating information of respective connections with connection IDs to be used in subsequent MPQUIC communication corresponds to generated parameters of first connection ID and second connection ID).
But, the combination does not explicitly disclose: generating parameter information of the first link based on the feedback message… comprising a link identification of the first link, and the link identification of the first link being a first link identification;
However, in the same field of endeavor, Coninck discloses generating parameter information of the first link based on the feedback message… comprising a link identification of the first link, and the link identification of the first link being a first link identification (fig. 2 discloses MPQUIC communication after transport parameters are negotiated between the phone and the server. The negotiation response from the server during the negotiation corresponds to the feedback response. In the MPQUIC communication from the phone to the server using both paths of WiFi and LTE, each packet comprises CID (connection identification information) information and PID information (link identification information). These are the generated parameters that are being used in communications after hand shake and negotiations are completed that are generated by the phone after handshake and negotiation performed with the server for capability and transport parameters negotiation).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of the combination with Coninck. The modification would allow generating communication information through negotiation and hand shake to enable MPQUIC communication. The modification would allow effective communication system where parameters are used to track packets communicated to reduce packet loss and disorder.
Regarding claim 3. The combination discloses method according to claim 2.
Zhu discloses, further comprising: transmitting a first detection message to the second apparatus via the second link (fig. 6B discloses peer 1 sends MX (re)configuration request message to peer2) , the first detection message comprising a first path detection frame ([0138-0139] discloses the MX Peer 1 (e.g., CCM 206) informs the MX Peer 2 (e.g., NCM 236) about the changes to the MX Peer 1's connections—setup of anew connection, teardown of an existing connection, or update of parameters related to an existing connection. The MX Peer 1 (e.g., client 101) triggers the procedure by requesting an update to the connection configuration, and a response from the MX Peer 2 (e.g., NCM 236); [0139] When the client detects that the link is up/down or the network address (e.g., IP address or the like) changes (e.g., via APIs provided by the client OS), the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra);
receiving, via the second link, a first response message transmitted by the second apparatus, the first response message comprising a first path response frame ([0138-0139] discloses the MX Peer 1 (e.g., CCM 206) informs the MX Peer 2 (e.g., NCM 236) about the changes to the MX Peer 1's connections—setup of anew connection, teardown of an existing connection, or update of parameters related to an existing connection. The MX Peer 1 (e.g., client 101) triggers the procedure by requesting an update to the connection configuration, and a response from the MX Peer 2 (e.g., NCM 236); [0139] When the client detects that the link is up/down or the network address (e.g., IP address or the like) changes (e.g., via APIs provided by the client OS), the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra); and
generating parameter information of the first transmitting stream of the second link based on the first response message, the parameter information of the first transmitting stream of the second link comprising a third connection identification and a link identification of the second link, the third connection identification being a connection identification of the first transmitting stream of the second link, and the link identification of the second link being a second link identification ([0139] the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information (information of based information are included in [0272-0285])discussed infra, The request receiving device sends a response that includes the base information infra. The base information includes information indicated in [0275-0285] such as: [0275] Base information (MXBase): This data type is the base information that every message between the CCM 206 and NCM 236 exchanges has including the following information: [0277] (b) message type: “mx_reconf_req”, “mx_reconf_rsp” etc; [0278] (c) Sequence Number: Sequence number to uniquely identify a particular message exchange that corresponds to link identifier; [0283] Connection Information: This data type provides the mapping of connection ID and connection type. This data type contains the following information: [0284] (a) Connection ID: Unique number or string identifying the connection. [0285] (b) Connection Type: Type of RAT connection associated with the connection ID. Examples of the type of connection include “Wi-Fi”, “5G_NR”, “MulteFire”, “LTE”, “DSL”, etc. The request sending device generating information from the response corresponds to generating and the links and connections used to exchange the messages corresponds to a third connection identification and a link identification of the second link ).
Regarding claim 4. The combination discloses method according to claim 2.
Zhu discloses, further comprising: receiving, via the second link, a second detection message transmitted by the second apparatus, the second detection message comprising a second path detection frame ([0137] and [1390] discloses the MX Peer 1 could be the NCM 236 and/or the MAMS server 140 and the MX Peer 2 may be the CCM 206 and/or the MAMS client 101 (first apparatus); the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra); and
transmitting a second response message to the second apparatus via the second link, the second response message comprising a second path response frame ([0137] and [1390] discloses the MX Peer 1 could be the NCM 236 and/or the MAMS server 140 (second apparatus) and the MX Peer 2 may be the CCM 206 and/or the MAMS client 101 (first apparatus); the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra).
Regarding claim 5. The combination discloses method according to claim 3.
Zhu discloses, further comprising: transmitting a path removal message to the second apparatus through the first transmitting stream of the second link when the first transmitting stream of the first link is invalid, the path removal message comprising the first connection identification ( [0244] MX Session Termination Request (mx_session_termination_req) that corresponds to path removal message: In the event where the NCM 236 or CCM 206 can no longer handle MAMS for any reason, it can send an MX Session Termination Request to the peer. In addition to the base information (MXBase) (base infocmation includes connection ID information see [0272-0285], it contains a Unique Session ID and the reason for the termination such as, for example, “MX_NORMAL_RELEASE”, “MX_NO_RESPONSE”, or “INTERNAL_ERROR”. [0245] MX Session Termination Response (mx_session_termination_rsp): On receipt of an MX Session Termination Request from a peer, the NCM 236/CCM 206 shall respond with MX Session Termination Response on the same delivery path where the request arrived);
Regarding claim 11, The limitations of claim 11 are similar with the limitations of claim 3 where the method steps seen from the other side of the two devices. Although the combination order of prior arts may not be identical, similar arts teach these limitations. Claims 11 rejected on the same prior arts mapping of claim 3.
Regarding claim 13, The limitations of claim 13 are similar with the limitations of claim 5 where the method actions seen from the other side of the two devices. Although the combination order of prior arts may not be identical, similar arts teach these limitations. Claims 13 rejected on the same prior art mapping of claim 5.
Claim(s) 9-10, 12, 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Connick “ Multipath Extensions for QUIC (MP-QUIC) draft-deconinck-quic-multipath-04”, further in view of Zhu (US pg. no. 20230353455).
Regarding claim 9. Connick discloses a data transmission method, applied to a second apparatus, the method comprising:
receiving a request to link message transmitted by a first apparatus, the request to link message comprising a first connection identification (fig. 3 CID A), the first connection identification being a connection identification of a first transmitting stream of a first link the first transmitting stream of the first link being a stream by which the first apparatus transmits data to the second apparatus ((fig. 3 discloses CID A is connection ID of link uniflow ID1):
transmitting a feedback message to the first apparatus based on the request to link message ( fig. 2 discloses server sends feedback), the feedback message comprising a second connection identification different from the first connection identification, the second connection identification being a connection identification of a second transmitting stream of the first link (fig. 3 discloses the response comprises CID D different from CID A of flow ID 1), the second transmitting stream of the first link being a stream by which the second apparatus transmits data to the first apparatus (fig. 3 discloses CID D uniflow ID 1 second transmitting stream of the first link being a stream by which the second apparatus transmits data to the first apparatus) ;
receiving, based on a first receiving stream of a first link, a first data stream transmitted by a first apparatus the first link corresponding to a first physical address of the first apparatus the first receiving stream of the first link being same as the first transmitting stream of the first link (fig. 3 discloses subsequent communication between client and server corresponds to receiving. The data exchanges using similar uniflow ID corresponds to the first receiving stream of the first link being same as the first transmitting stream of the first link);
receiving, based on a first receiving stream of a second link, a second data stream transmitted by the first apparatus, the second link corresponding to a second physical address of the first apparatus (page 8-9 discloses a Multipath QUIC connection consists in one or more uniflow(s) (link) from the client to the server and one or more uniflow(s) from the server to the client. The number of uniflows in one direction can be different from the one in the other direction. The example in Figure 3 shows two uniflows from the client to the server and three uniflows from the server to the client. From the end- hosts' viewpoint, they observe two kinds of uniflows:
* Sending uniflows: uniflows over which the host can send packets
* Receiving uniflows: uniflows over which the host can receive
Packets. Each uniflow is associated with a specific four-tuple and identified
by a Uniflow ID; fig. 4 discloses sending client uses uniflow
1 over UCID B and uses the same uniflow 1 to receive data over UCID Y. The same goes to the server), the first transmitting stream of the second link being identified by a third connection identification different from the first connection identification and the second connection identification (fig. 3 discloses different connection IDs being used that are distinct),
Connick inherently discloses first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol the first link being associated with a first link identification, and the second link being associated with a second link identification different from the first link identification (fig. 3).
determining a first service data stream based on the first data stream and the second data stream (fig. 4 discloses association of CIDs and Uniflow IDs to determine service data based on specific data stream).
But Connick does not explicitly disclose:
first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol;
However, in the same field of endeavor, Zhu explicitly discloses the first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol (fig. 1b discloses MX convergence sublayer of client 101 communicating with MX convergence sublayer of MX server 140 over a plurality of links; [0040] The MX convergence layer is configurable or operable to perform MX-specific tasks in the UP. The MX convergence layer performs such functions as: MPQUIC that corresponds to MX client 101 and MX server 140 communicating over multiple links using MPQUIC); and
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of Connick with Zhu. The modification would allow a multi-path communication system where data can be effectively communicated over a plurality of paths simultaneously.
Regarding claim 10. The combination discloses method according to claim 9,
Connick discloses before the receiving, based on the first receiving stream of the first link, the first data stream transmitted by the first apparatus, the method further comprises:
generating parameter information of the first link, the parameter information of the first link comprising the first connection identification, the second connection identification, and the first link identification ((fig. 4 discloses generated information after negotiated MP-QUIC where each uniflow is associated with a specific four-tuple and identified
by a Uniflow ID, as shown in Figure 4 where association is generated between uniflow 0 of tuple A (link ID) and UCID set A (first connection ID) on sending data and uniflow 0 of tuple x (link ID) and UCID set X (second connection ID).
Zhu discloses wherein the request to link message further comprises information indicating whether the first apparatus has a capability supporting QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the first apparatus( [0128] At step 3, the MX peer 1 sends the MX Capability request (mx_capability_req) message to MX Peer 2. The MX Capability REQ includes the following parameters: MX Feature Activation List: Indicates whether the corresponding feature is supported or not (e.g., lossless switching, fragmentation, concatenation, UL aggregation, DL aggregation, measurement, probing, etc.); Number of Anchor Connections (core networks); for each anchor connection, the following parameters are included: Connection ID, and Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.); Number of Delivery Connections (access links). For each delivery connection, the following parameters are included: Connection ID, Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.), MX Convergence Method Support List: GMA, MPTCP Proxy, GRE Aggregation Proxy, MPQUIC; MX Adaptation Method Support List: UDP without DTLS; UDP with DTLS, IPsec [RFC3948], and/or Client NAT), the feedback message further comprises information indicating whether the second apparatus has a capability supporting the QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the second apparatus ([0130] In response at step 4, the NCM 236 creates a unique identity for the CCM 206 session and sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: MX Feature Activation List: Indicates whether the corresponding feature is enabled or not (e.g., lossless switching, fragmentation, concatenation, UL aggregation, DL aggregation, measurement, probing, etc.). Number of Anchor Connections (core networks): For each anchor connection, the following parameters are included: Connection ID, Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.); Number of Delivery Connections (access links): For each delivery connection, the following parameters are included: Connection ID; Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.); MX Convergence Method Support List: GMA, MPTCP Proxy, GRE Aggregation Proxy, MPQUIC; MX Adaptation Method Support List: UDP without DTLS, UDP with DTLS, IPsec [RFC3948], and/or Client NAT; Unique Session ID: Unique session identifier for the CCM 206 that set up the connection), and
Regarding claim 12. The combination discloses method according to claim 10.
Connick discloses, further comprising: transmitting a second detection message to the first apparatus via the second link, the second detection message comprising a second path detection frame; receiving, via the second link, a second response message transmitted by the first apparatus, the second response message comprising a second path response frame (Connick fig. 3; page 1-15); and
generating parameter information of a second transmitting stream of the second link based on the second response message, the parameter information of the second transmitting stream of the second link comprising a fourth connection identification and second link identification, the fourth connection identification being a connection identification of the second transmitting stream of the second link (fig. 3, fig. 4; fig. 5. Connection ID of subsequent exchanges correspond to the connection IDs).
Regarding claim 14. The combination discloses method according to claim 9.
Connick discloses, further comprising: allocating, based on a bandwidth of the first link and a bandwidth of the second link, a third data stream of a second service data stream transmitted on the first link and a fourth data stream of the second service data stream transmitted on the second link; transmitting the third data stream to the first apparatus based on the second transmitting stream of the first link; and transmitting the fourth data stream to the first apparatus based on second transmitting stream of the second link, the second transmitting stream of the second link being a stream by which the second apparatus transmits data to the first apparatus (fig. 3 discloses MP-QIUC. That system is fully capable of utilizing different connection IDs to transmit data. The mere indexing of subsequent communication as first stream, second stream or corresponding distinct connection is an obvious variation and expected in the MP-QUIC data communication where that would not amount to an inventive concept.).
Regarding claim 15. The method according to claim 9.
The limitations of claim 15 are similar with the limitations of claim 8. Claim 15 rejected on the same analysis of claim 8.
Claim(s) 16-17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Zhu (US pg. no. 20230353455), further in view of Connick “ Multipath Extensions for QUIC (MP-QUIC) draft-deconinck-quic-multipath-04”.
Regarding claim 16. Zhu discloses a method for establishing multiple quick user datagram protocol Internet connection (QUIC) paths, applied to a first apparatus, the method comprising:
transmitting a request to link message to a second apparatus (fig. 6a step 3 Mx capability request sent from MX peer 1 to MX peer2; ([0128] At step 3, the MX peer 1 sends the MX Capability request (mx_capability_req) message (request to link message ) to MX Peer 2), the request to link message comprising a first connection identification, the first connection identification being a connection identification of a first transmitting stream of a first link, the first transmitting stream of the first link being a stream by which the first apparatus transmits data to the second apparatus, and the request to link message further comprising information indicating whether the first apparatus has a capability supporting QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the first apparatus([0128] At step 3, the MX peer 1 sends the MX Capability request (mx_capability_req) message (request to link message ) to MX Peer 2. The MX Capability REQ includes the following parameters: … Number of Delivery Connections. For each delivery connection, the following parameters are included: Connection ID (corresponds to connection ID of the first connection of one of the delivery connections), Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.), MX Convergence Method Support List: MPQUIC that corresponds to capability information to support MPQUIC exchanged in the request); receiving a feedback message transmitted by the second apparatus([0130] and fig. 6A discloses In response at step 4, the NCM 236 sends the MX Capability Response (RSP)), the feedback message comprising a second connection identification different from the first connection identification ([0130] In response at step 4, the NCM 236 creates a unique identity for the CCM 206 session and sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: MX Feature Activation List: Indicates whether the corresponding feature is enabled or not (e.g., lossless switching, fragmentation, concatenation, UL aggregation, DL aggregation, measurement, probing, etc.). Number of Anchor Connections (core networks): For each anchor connection, the following parameters are included: Connection ID, Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.); Number of Delivery Connections (access links): For each delivery connection, the following parameters are included: Connection ID; Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc.); MX Convergence Method Support List: GMA, MPTCP Proxy, GRE Aggregation Proxy, MPQUIC. The connection ID in the response can be different from the connection IDs in the request), the second connection identification being a connection identification of a second transmitting stream of the first link, the second transmitting stream of the first link being a stream by which the second apparatus transmits data to the and the feedback message further comprising information indicating whether the second apparatus has a capability supporting the QUIC protocol-based multipath and/or a quantity of QUIC protocol-based multipaths supported by the second apparatus([0130] In response at step 4, the NCM 236 (MX peer 2 of fig. 6A) sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: … Number of Delivery Connections (access links that correspond to links for stream from MX peer2 side (second transmitting stream)): For each delivery connection, the following parameters are included: Connection ID; Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc. supported by MX peer2); MX Convergence Method Support List :MPQUIC (MPQUIC support capability information)); and
generating parameter information of the first link based on the feedback message, the parameter information of the first link comprising the first connection identification, the second connection identification(fig. 6a, [00130] In response at step 4, the NCM 236 (MX peer 2 of fig. 6A) sends the MX Capability Response (RSP). The MX Capability RSP includes the following information: … Number of Delivery Connections (access links that correspond to links for stream from MX peer2 side (second transmitting stream)): For each delivery connection, the following parameters are included: Connection ID; Connection Type (e.g., WiFi, 5G NR, MulteFire, LTE, etc. supported by MX peer2); MX Convergence Method Support List :MPQUIC (MPQUIC support capability information); [0134] discloses in response to the MX Capability RSP, at step 7 the CCM 206 sends a confirmation in the MX Capability Acknowledge (mx_capability_ack) message and/or MX UP Setup Confirm (mx_up_setup_conf_cnf) message. The MX Capability ACK includes the following parameters (generated parameters): Unique Session ID: Same identifier as the identifier provided in the MX Capability Response (that corresponds to the second connection identification); Acknowledgment: An indication of whether the client has accepted or rejected the capability exchange phase; MX ACCEPT: The CCM 206 accepts the capability set proposed by the NCM 236; Generating information of respective connections with connection IDs to be used in subsequent MPQUIC communication corresponds to first connection ID and second connection ID).
But, the combination does not explicitly disclose:
But, Zhu does not explicitly disclose: generating parameter information of the first link based on the feedback message, the parameter information of the first link comprising the first connection identification, the second connection identification, and a link identification of the first link, the link identification of the first link being different from the first connection identification and the second connection identification, and the link identification of the first link being a first link identification.
However, in the same field of endeavor, Coninck discloses generating parameter information of the first link based on the feedback message, the parameter information of the first link comprising the first connection identification, the second connection identification, and a link identification of the first link, the link identification of the first link being different from the first connection identification and the second connection identification, and the link identification of the first link being a first link identification (fig. 4 discloses generated information after negotiated MP-QUIC where each uniflow is associated with a specific four-tuple and identified by a Uniflow ID (link ID), as shown in Figure 4 where association is generated between uniflow 0 of tupla A (link ID) and UCID set A (first connection ID) on sending data and uniflow 0 of tuple x (link ID) and UCID set X (second connection ID)
Coninck further teaches what Zhu discloses that is receiving a feedback message transmitted by the second apparatus the feedback message comprising a second connection identification different from the first connection identification (fig. 3 discloses client sends a connection ID UCID, and server responds with a different connection ID UCID).
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of the combination with Coninck. The modification would allow generating communication information through negotiation and hand-shake to enable MPQUIC communication. The modification would allow effective communication system where parameters are used to track packets communicated to reduce packet loss and disorder.
Regarding claim 17. The combination discloses method according to claim 16.
transmitting a first detection message to the second apparatus via the second link (fig. 6B discloses peer 1 sends MX (re)configuration request message to peer2) , the first detection message comprising a first path detection frame ([0138-0139] discloses the MX Peer 1 (e.g., CCM 206) informs the MX Peer 2 (e.g., NCM 236) about the changes to the MX Peer 1's connections—setup of anew connection, teardown of an existing connection, or update of parameters related to an existing connection. The MX Peer 1 (e.g., client 101) triggers the procedure by requesting an update to the connection configuration, and a response from the MX Peer 2 (e.g., NCM 236); [0139] When the client detects that the link is up/down or the network address (e.g., IP address or the like) changes (e.g., via APIs provided by the client OS), the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra);
receiving, via the second link, a first response message transmitted by the second apparatus, the first response message comprising a first path response frame ([0138-0139] discloses the MX Peer 1 (e.g., CCM 206) informs the MX Peer 2 (e.g., NCM 236) about the changes to the MX Peer 1's connections—setup of anew connection, teardown of an existing connection, or update of parameters related to an existing connection. The MX Peer 1 (e.g., client 101) triggers the procedure by requesting an update to the connection configuration, and a response from the MX Peer 2 (e.g., NCM 236); [0139] When the client detects that the link is up/down or the network address (e.g., IP address or the like) changes (e.g., via APIs provided by the client OS), the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra); and
generating parameter information of a transmitting stream of the second link based on the first response message, the parameter information of the first transmitting stream of the second link comprising a third connection identification and a link identification of the second link, the third connection identification being a connection identification of the first transmitting stream of the second link, and the link identification of the second link being a second link identification ([0139] the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (detection frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information (information of based information are included in [0272-0285])discussed infra, The request receiving device sends a response that includes the base information infra. The base information includes information indicated in [0275-0285] such as: [0275] Base information (MXBase): This data type is the base information that every message between the CCM 206 and NCM 236 exchanges has including the following information: [0277] (b) message type: “mx_reconf_req”, “mx_reconf_rsp” etc; [0278] (c) Sequence Number: Sequence number to uniquely identify a particular message exchange that corresponds to link identifier; [0283] Connection Information: This data type provides the mapping of connection ID and connection type. This data type contains the following information: [0284] (a) Connection ID: Unique number or string identifying the connection. [0285] (b) Connection Type: Type of RAT connection associated with the connection ID. Examples of the type of connection include “Wi-Fi”, “5G_NR”, “MulteFire”, “LTE”, “DSL”, etc. The request sending device generating information from the response corresponds to generating and the links and connections used to exchange the messages corresponds to a third connection identification and a link identification of the second link ).
Regarding claim 18. The combination discloses method according to claim 16.
Zhu discloses, further comprising: receiving, via the second link, a second detection message transmitted by the second apparatus, the second detection message comprising a second path detection frame ([0137] and [1390] discloses the MX Peer 1 could be the NCM 236 and/or the MAMS server 140 and the MX Peer 2 may be the CCM 206 and/or the MAMS client 101 (first apparatus); the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra); and
transmitting a second response message to the second apparatus via the second link, the second response message comprising a second path response frame ([0137] and [1390] discloses the MX Peer 1 could be the NCM 236 and/or the MAMS server 140 (second apparatus) and the MX Peer 2 may be the CCM 206 and/or the MAMS client 101 (first apparatus); the MX Peer 1 (e.g., CCM 206) sends an MX Reconfiguration Request (REQ) (frame) to setup the connection at step 1a. At step 1b, the MX Peer 2 (e.g., NCM 236) sends an MX Reconfiguration Response (RSP) to confirm receipt of the MX Reconfiguration REQ and includes the base information discussed infra).
Regarding claim 20. In the combination. Zhu discloses an electronic device comprising a processor and a memory, the memory having instructions stored therein (fig. 1B MX client 101), and the instructions, when being run by the processor, causing the processor to perform the method according to claim 16
All other limitations of claim 20 are similar with the limitations of claim 16 above. Claim 20 is rejected on the analysis of claim 16 above.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Zhu (US pg. no. 20230353455), and Connick “ Multipath Extensions for QUIC (MP-QUIC) draft-deconinck-quic-multipath-04”., further in view of Amend (US pg. no. 20240381336).
Regarding claim 19. The combination discloses method according to claim 18.
But, the combination does not explicitly disclose: further comprising: allocating, based on a bandwidth of the first link that corresponds to a first physical address of the first apparatus, and a bandwidth of the second link that corresponds to a second physical address of the first apparatus, a first data stream of a first service data stream transmitted on the first link and a second data stream of the first service data stream transmitted on the second link, the first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol;
transmitting the first data stream to the second apparatus based on the first transmitting stream of the first link; and
transmitting the second data stream to the second apparatus based on the first transmitting stream of the second link.
However, in the same field of endeavor, Amend discloses further comprising: allocating, based on a bandwidth of the first link that corresponds to a first physical address of the first apparatus, and a bandwidth of the second link that corresponds to a second physical address of the first apparatus, a first data stream of a first service data stream transmitted on the first link and a second data stream of the first service data stream transmitted on the second link, the first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol (([0003] Multipath network protocols such as MP-QUIC allow to establish more than one communication flow between a sender and a receiver. Fig. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver… The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel …[0004] On sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like New Reno, Cubic, BBR etc….[0005] While on sender side traffic is split across communication paths);
transmitting the first data stream to the second apparatus based on the first transmitting stream of the first link; and transmitting the second data stream to the second apparatus based on the first transmitting stream of the second link ([0003] Multipath network protocols such as MP-QUIC allow to establish more than one communication flow between a sender and a receiver. Fig. 1 shows a sender, i.e. a transmitting device, and a receiver (receiving device). Multiple paths 1 to n are established between the sender and the receiver… The sequenced data packets are passed to a scheduler which schedules the data packets to the multiple paths of a multipath channel. The data packets ordered in sequence 12, 13, 14 are transmitted over the multipath channel …[0004] On sender side that gives the ability to decide how to schedule the traffic across these communication paths1-n depicted in Fig. 1 . An efficient scheduling is relied on a proper path estimation, which characterizes the transport capabilities of the communication paths like available bandwidth (corresponds to based on respective bandwidths of the first and the second link) or Round-Trip-Time. Using [1]-[3], will gain these values from the employed congestion control approach like New Reno, Cubic, BBR etc….[0005] While on sender side traffic is split across communication paths);
Therefore, it would have been obvious to a person having ordinary skill in the art at the time of the invention was effectively filed to combine the teaching of Zhu with Markus. The modification would allow effective scheduling and transmission of stream in a multi-path QUIC based on available link capacity. The modification would allow effective flow distribution system of multi-path transmission for effective communication system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
- EP4080836A1.
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MESSERET F. GEBRE whose telephone number is (571)272-8272. The examiner can normally be reached 9:00 am-5:30PM.
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, Oscar Louie can be reached at 5712701684. 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.
MESSERET F. GEBRE
Primary Examiner
Art Unit 2445
/MESSERET F GEBRE/Primary Examiner, Art Unit 2445
Prosecution Insights