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 .
General Remarks
1/ Claims 1, 9, 16 and 20 are independent
2/ claims 1-20 are pending
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, 6-9, and 15 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;
However, in the same field of endeavor, Markus 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);
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 6. The combination discloses method according to claim 1.
Amend discloses, wherein 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 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 and a second sub-window ([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. The above congestion control methods such as New Reno, Cubic, BBR uses congestion window per path that corresponds to sub-window), the first sub-window corresponding to a transmitting stream of the first link, and the second sub-window corresponding to a transmitting stream of the second link ([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. New Reno, Cubic, BBR uses congestion window for each path that corresponds to sub-window);
transmitting the first data stream through the first transmitting stream of the first link based on the first sub-window; and transmitting the second data stream through the first transmitting stream of the second link based on the second sub-window ([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. The above congestion control methods such as New Reno, Cubic, BBR);
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).
Regarding claim 9. Zhu discloses a data transmission method, applied to a second apparatus, the method comprising:
receiving, based on a first receiving stream of a first link, a first data stream transmitted by a first apparatus (fig. 1b 101), the first link corresponding to a first physical address of the first apparatus (fig. 1B and [0032] discloses the multi-radio UE 101 is capable of establishing a 3GPP access link 105A with the eNB/gNB 111A (e.g., Uu interface or the like), and capable of establishing a WiFi access link 105B (The physical address of the WiFi interface corresponds to the first physical address> The WiFi link corresponds to the first link). The eNB/gNB 111A communicates with the server 140 via a 3GPP backhaul link 106A and the AP 111B communicates with the server 140 via a WiFi backhaul link 106B. fig. 1b discloses MX client is configures to communicate with MX server 140 over different links);
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 (fig. 1B and [0032] discloses the multi-radio UE 101 is capable of establishing a 3GPP access link 105A (the physical address of interface of MC client 101 for 3GPP communication corresponds to the second physical address and the link correspond to the second link) with the eNB/gNB 111A (e.g., Uu interface or the like), and capable of establishing a WiFi access link 105B (The physical address of the WiFi interface corresponds to the first physical address). fig. 1b discloses MX client is configures to communicate with MX server 140 over different links. Each physical address of the interfaces corresponds to physical address),
Zhu inherently 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
But, Zhu does not explicitly disclose: the first link and the second link being links supporting a quick user datagram protocol Internet connection (QUIC) protocol.
determining a first service data stream based on the first data stream and the second data stream.
However, in the same field of endeavor, Amend discloses 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 MPTCP [1], MP-DCCP [3] or MP-QUIC [2] 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);
determining a first service data stream based on the first data stream and the second 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 stream).
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 a multi-path communication system where data can be effectively communicated over a plurality of paths simultaneously.
Regarding claim 14. The combination discloses method according to claim 9.
Amend 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([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 third data stream to the first apparatus based on the transmitting stream of the first link; and transmitting the fourth data stream to the first apparatus based on the 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);
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) 2-5, and 10-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 10, The limitations of claim 10 are similar with the limitations of claim 2 where the method steps are seen from the other side of the two devices. Claims 10 rejected on the same analysis of claim 2.
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. Claims 11 rejected on the same analysis of claim 3.
Regarding claim 12, The limitations of claim 12 are similar with the limitations of claim 4 where the method steps seen from the other side of the two devices. Claims 12 rejected on the same analysis of claim 4.
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. Claims 13 rejected on the same analysis of claim 5.
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 Coninck, “Multipath Extension for QUICdraft-deconinck-multipath-quic-00”.
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, 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, 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 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:
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 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 Coninck, “Multipath Extension for QUICdraft-deconinck-multipath-quic-00”, 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
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