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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 07/23/2026 has been placed in record and considered by the examiner.
Status of the Claims
This office action considers claims 1-20 filed on 07/23/2026 are pending for prosecution.
Response to Arguments
Applicant’s arguments, with respect to claims 1-20, filed on 07/23/2026 have been fully considered but they are not persuasive.
Regarding claims 1 and 12, the Applicant presented argument regarding that -
1.a) page 3 of Vivo cannot provide all features of claim 1 without hindsight.
1.b) the figure mentions "Step 2. Aggregation request during PDU Session Modification", so without the part "for an QoS flow". The one or more quality-of-service requirements are not mentioned at all in Vivo. The Office further refers to "Step 4: Provisioning UE IDs, an aggregation policy, together with QoS profile to the RAN node". However, this is the step that was mentioned as an objective for the study, so this simply cannot disclose the above mentioned feature.
1.c) Then, for the next two features:
"obtain a first signal received by the first wireless receiver over a data radio bearer associate with the data flow,
obtain a second signal received by the second wireless receiver over the data radio bearer or over a further data radio bearer associated with a further data flow, the data flow and the further data flow belonging to the same group of data flows, the group of data flows being associated with one or more joint quality-of-service requirements, "
the Office refers to "Step 5. DRB Resource configuration". However, Applicant submits that these three words cannot disclose the two features of claim 1. Not even a skilled person is able to derive this from these three words. The Office further refers to the CN-based solution in the figure on page 4, which is, as mentioned earlier, a different solution than the RAN based solution.
1.d) The last feature "extract data from the first and second signals by aggregating the first and second signals" is allegedly disclosed in the figure on page 3. However, this figure shows what the study is aiming at, and provides no details regarding a solution.
Regarding claims 10 and 14, the Applicant presented argument regarding that –
10.a) Applicant submits that at least "allocate resources, based on one or more joint quality-of service requirements" is not disclosed in Vivo. The Office stated "claim 10 is interpreted mutatis mutandis of claim 1, and rejected for the same reason as set forth for claim l ." However, since neither allocating resources nor joint quality-of-service requirements is part of claim 1, the rejection is deficient and the Office has not provided details on where this feature is disclosed in Vivo.
Regarding claims 6 and 13, the Applicant presented argument regarding that –
6.a) Applicant submits that Vivo does not disclose "receive, from a further system, a request to admit at least one data flow with one or more quality-of-service requirements, the at least one data flow being intended to be used for transmissions from a base station to a plurality of devices, the request specifying the one or more quality-of-service requirements".
Because no mentioning of quality-of-service requirements specified in the request in Vivo, in fact QoS requirements are nowhere mentioned. Moreover, Step 2 does not mention ''for an QoS flow". Also, a QoS requirement profile (emphasis added) is not mentioned, only a QoS profile which is provided to the NG RAN by the 5G CN, but nowhere is mentioned that this QoS profile comprises QoS requirements.
6.b) Furthermore, Vivo does not disclose the partial feature "transmit, to the further system, a response that the request has been accepted if it is determined that the one or more quality-of-service requirements can be accepted' in Step 4 and Step 5. As mentioned above, there are no QoS requirements in any of the messages on page 3. Moreover, Step 4 is sent by 5G CN to NGRAN so this cannot the response sent by the NG RAN to the further system.
(REMARKS, Pages 10-11 and 12)
The Examiner respectfully disagrees. The Examiner presents-
1.a) regarding hindsight reasoning, MPEP teaches a reconstruction based upon hindsight reasoning is proper so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure. See MPEP 7.37.03.
In this case Vivo, provides explicit or implicit or at least obvious teaching as required by all elements of claim 1, presented below with additional clarifying evidence.
1.b) Vivo Step 2. Aggregation request during PDU Session Modification (for an QoS flow),
The above Step 2 aggregation request does not show the part "for an QoS flow". However the part “for an QoS flow” is implicit or inherent or at least obvious since VIVO also discloses the aggregation request causes-
Step 3: Authorization and policy check by 5G CN
Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN, and
Page 3 top right figure disclosing concept for RAN based UE aggregation for an QoS flow for which the protocol Steps 1-5 and subsequent UL/DL data flows are illustrated.
Therefore, Vivo Page 3 discloses “transmit the information to cause a data flow to be requested with one or more quality-of-service requirements and the admittance of the data flow with the one or more quality-of-service requirements to be decided upon based on the information”.
1.c) The Examiner notes that the Applicant only recognized cited Step 5, overlooking the second part.
The citation in Office action was-
Page 3, after Step 5. DRB resource configuration, 5G CN transmitted DL data for an QoS flow reception at UE1 via NG-RAN, and
Page 3, after Step 5. DRB resource configuration, 5G CN transmitted DL data for same QoS flow reception at UE2 via NG-RAN
In the above the DRB resource configuration and DL data reception for a single/same QoS flow is evident from Page 3 figures in upper right, lower middle and lower right, disclosing High-level concept pf RAN based UE aggregation for an QoS flow, DL data originated at 5G CN gets splitted at the NG-RAN over two links to UE1 & UE2, and then aggregation at PDCP+ (higher than PDCP) layer of respective received DL data flows at the aggregated UE1-UE2, after Step 5 DRB (Data Radio Bearer commonly known in the art) resource configuration to be used for the respective UL/DL aggregated data flows, which indicates a joint QoS flow.
Therefore, Vivo Page 3 RAN based solution teaches the two features of claim 1–
"obtain a first signal received by the first wireless receiver over a data radio bearer associate with the data flow,
obtain a second signal received by the second wireless receiver over the data radio bearer or over a further data radio bearer associated with a further data flow, the data flow and the further data flow belonging to the same group of data flows, the group of data flows being associated with one or more joint quality-of-service requirements, "
1.d) The limitation "extract data from the first and second signals by aggregating the first and second signals" is taught as previously cited by Vivo -
Page 3, Figure illustrating UE1 and UE2 integrated in a device to communicate with 5G CN via same NG-RAN, Bearer aggregation at PDCP layer at a device received via UE1 and UE2 for a DL QoS flow Data, Step 5. DRB resource configuration.
See also Page 3 figures showing UL/DL data flows between the aggregated UE1-UE2 and 5G CN via NG-RAN, after Step 5 DRB resource configuration to be used for the respective UL/DL data flows as implied by the Figures on Page 3.
Additionally, Vivo also discloses in Page 3, the benefit of minimal packet retransmission via another connection when one connection fails with RAN based solution for
Page 1, Requirement and Scenarios:
Improve UL/DL capability/reliability for consumer scenarios (e.g. AR/VR) and industry scenarios
indicating received packets, of bidirectional data flows for a single QoS flow over split DRBs as illustrated Page 3 figures, are extracted and decoded correctly for minimizing packet retransmission improving UL/DL capability/reliability for AR/VR application as the reason for the study proposal.
Therefore Vivo teaches the last feature "extract data from the first and second signals by aggregating the first and second signals” as required by claim 1.
Accordingly claim 1 and claim 12 with similar features as in claim 1 are rejected.
10.a) The Examiner presents that claim 1 lines 15-16 recites the feature “the group of data flows being associated with one or more joint quality-of-service requirements”, which can be mapped to the said claim 10 lines 7-8 feature “the group of data flows having been assigned the one or more joint quality-of-service requirements”.
See Examiner’s answer presented above for claim 1, that this feature is disclosed in Vivo as evident from Page 3 figures in upper right, lower middle and lower right, disclosing High-level concept pf RAN based UE aggregation for an QoS flow, splitted over two links to UE1 & UE2, and then aggregation at PDCP+ (higher than PDCP) layer of respective DL data flows between the two aggregated UE1-UE2 and 5G CN via NG-RAN, after Step 5 DRB resource configuration to be used for the respective bidirectional data flows, which indicates a joint QoS flow.
Accordingly claim 10 and claim 14 with similar features as in claim 10 are rejected.
6.a) The Examiner presents that, Vivo Page 3 figures discloses QoS profile provisioning, corresponding DRB resource configuration for a QoS flow indicating quality of service requirement indication in Step 2, as explained in response to argument 1.b for claim 1 presented above.
Therefore Vivo discloses "receive, from a further system, a request to admit at least one data flow with one or more quality-of-service requirements, the at least one data flow being intended to be used for transmissions from a base station to a plurality of devices, the request specifying the one or more quality-of-service requirements".
6.b) The Examiner presents that Vivo discloses –
Page 3, Step 3. Authorization, policy check (UL/DL load balance… etc.)
Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN
Step 5. DRB resource configuration (communicating with respective UE1 and UE2), and
Subsequent DL/UL data reception and transmission between UE1-UE2 and 5G CN via NG-RAN.
From the above it is construed that NG-RAN communicating with 5G CN checking authorization and policy for UL/DL load balance creates QoS profile in response to request initiated by Step 2, transmits a response for 5G CN and to UE1-UE2 via DRB resource configuration that the request has been accepted, since NG-RAN configures DRB resources for subsequent DL/UL data communication communicating with respective UE1 and UE2.
Therefore, Vivo discloses the feature “transmit, to the further system, a response that the request has been accepted if it is determined that the one or more quality-of-service requirements can be accepted” as required by claim 6 and similarly claim 13.
Accordingly claims 6 and 13 are rejected.
Dependents claims 2-5, 7-9, 11 and 15-20, being dependent on claims 1, 6, 10 and 12-14, are also rejected for the same reason as above.
NOTICE for all US Patent Applications filed on or after March 16, 2013
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 10-12, 14 and 15-17 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Vivo (“Study on UE Aggregation for Industry with Multi-Connectivity”, of IDS, hereinafter ‘VIVO’).
Regarding claim 1, VIVO teaches a system for receiving wireless signals over one or more data radio bearers associated with one or more data flows (
Page 3, RAN based solution Figures illustrating UE1 and UE2 integrated in a device to communicate with 5G CN via same NG-RAN, Bearer aggregation at PDCP layer at a device for DL QoS Data, Step 5. DRB resource configuration,
Page 4 Right side, CN based solution Figures illustrating UE1 and UE2 integrated in a device with MPTCP function communication for QoS flow with a Data Network in Network Core via split user plane over two 3GPP Access path), the system including:
a plurality of devices, the plurality of devices including a first device which includes a first wireless receiver and a second device which includes a second wireless receiver (
See Page 3 and Page 4 UE1 and UE2 receiving an QoS flow); and
at least one processor (See Page 3 and Page 4 UE1 and UE2) configured to:
- determine information relating to each of the plurality of devices (
Page 3, Step 1. UE1 and UE2 Aggregation capability indication),
- transmit the information to cause a data flow to be requested with one or more quality-of-service requirements and the admittance of the data flow with the one or more quality-of-service requirements to be decided upon based on the information (
Page 3, Step 1. UE1 and UE2 Aggregation capability indication to 5G CN during registration, and
Step 2. Aggregation request during PDU Session Modification (for an QoS flow),
The above Step 2 aggregation request does not show the part "for an QoS flow". However the part “for an QoS flow” is implicit or inherent or at least obvious since VIVO also discloses the aggregation request causes-
Step 3: Authorization and policy check by 5G CN
Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN, and
Page 3 top right figure disclosing concept for RAN based UE aggregation for QoS flow for which the protocol Steps 1-5 and subsequent UL/DL data flows are illustrated),
- obtain a first signal received by the first wireless receiver over a data radio bearer associated with the data flow (
Page 3, after Step 5. DRB resource configuration, 5G CN transmitted DL data for an QoS flow reception at UE1 via NG-RAN,
See also Page 4 Right side a DL QoS flow of PDU session1 reception at UE 1 via Uu/3GPP Access from UPF),
- obtain a second signal received by the second wireless receiver over the data radio bearer or over a further data radio bearer associated with a further data flow, the data flow and the further data flow belonging to the same group of data flows, the group of data flows being associated with one or more joint quality-of-service requirements (
Page 3, after Step 5. DRB resource configuration, 5G CN transmitted DL data for same QoS flow reception at UE2 via NG-RAN.
In the above the DRB resource configuration and DL data reception for a single/same QoS flow is evident from Page 3 figures in upper right, lower middle and lower right, disclosing High-level concept pf RAN based UE aggregation for an QoS flow, DL data originated at 5G CN gets splitted at the NG-RAN over two links to UE1 & UE2, and then aggregation at PDCP+ (higher than PDCP) layer of respective received DL data flows at the aggregated UE1-UE2, after Step 5 DRB (Data Radio Bearer commonly known in the art) resource configuration to be used for the respective UL/DL aggregated data flows, which indicates a joint QoS flow.
See also Page 4 Right side same DL QoS flow of PDU session2 reception at UE2 via Uu/3GPP Access from UPF for CN based solution), and
- extract data from the first and second signals by aggregating the first and second signals (
Page 1, Requirement and Scenarios:
Improve UL/DL capability/reliability for consumer scenarios (e.g. AR/VR) and industry scenarios
Page 3, Figure illustrating UE1 and UE2 integrated in a device to communicate with 5G CN via same NG-RAN, Bearer aggregation at PDCP layer at a device received via UE1 and UE2 for a DL QoS flow Data, Step 5. DRB resource configuration.
See also Page 3 figures showing UL/DL data flows between the aggregated UE1-UE2 and 5G CN via NG-RAN, after Step 5 DRB resource configuration to be used for the respective UL/DL data flows as implied by the Figures on Page 3.
Additionally, Vivo also discloses in Page 3, the benefit of minimal packet retransmission via another connection when one connection fails with RAN based solution for
Page 1, Requirement and Scenarios:
Improve UL/DL capability/reliability for consumer scenarios (e.g. AR/VR) and industry scenarios
indicating received packets, of bidirectional data flows for a single QoS flow over split DRBs as illustrated Page 3 figures, are extracted and decoded correctly for minimizing packet retransmission improving UL/DL capability/reliability for AR/VR application as the reason for the study proposal.).
Regarding claim 10, VIVO teaches a base station (Page 3 Figure NG-RAN) for transmitting wireless signals to a plurality of devices, the base station including at least one processor configured (
Page 3, RAN based solution Figures illustrating UE1 and UE2 integrated in a device to communicate with 5G CN via same NG-RAN, Bearer aggregation at PDCP layer at a device for a single/same DL QoS Data, Step 5. DRB resource configuration by NG- RAN for UE1-UE2 communicating with UE1-UE2, and after Step 5 DRB resource configuration for UE1 and UE2 data received from 5G CN is transmitted by NG-RAN to UE1 at first instance/moment and to UE2 at second instance or moment which are indicated by the sequences of Step 1 to Step 5 and UL/DL data flows in time;
See also Page 4 Right side, CN based solution Figures illustrating UE1 and UE2 integrated in a device with MPTCP function communication for QoS flow with a Data Network in Network Core via split user plane over two 3GPP Access path).
Further claim 10 is interpreted mutatis mutandis of claim 1, and rejected for the same reason as set forth for claim 1.
Regarding claim 12, the claim is interpreted mutatis mutandis of claim 1, and rejected for the same reason as set forth for claim 1.
Regarding claim 14, the claim is interpreted mutatis mutandis of claim 10, and rejected for the same reason as set forth for claim 10.
Regarding claim 15, the claim is interpreted and rejected for the same reason as set forth for claim 12.
Regarding claim 2, VIVO teaches a system as claimed in claim 1, wherein the information includes channel state information and/or device information (
Page 3, Figure illustrating UE1 and UE2 registering with 5G CN via NG-RAN indicating aggregation capability and UE ID, which together with QoS profile are then used by 5G CN to provision NG-RAN ).
Regarding claim 3, VIVO teaches a system as claimed in claim 2, wherein the information includes device information and the device information specifies a quantity of the plurality of devices and/or capabilities of the plurality of devices and/or device identifiers of the plurality of devices (
See citation from Page 3 for claim 2).
Regarding claim 11, VIVO teaches a base station as claimed in claim 10, wherein the at least one processor is configured to:
- decide whether to terminate the data flow or the further data flow, and
- terminate the data flow or the further data flow and transmit a message to a further system to inform the further system that the data flow or the further data flow of the group of data flows has been or will be terminated if the decision is made to terminate the data flow or the further data flow (
Page 5, Figure Switch media for Hot Backup, RAN based or CN based
PNG
media_image1.png
200
400
media_image1.png
Greyscale
Construed that when RAN based or CN based, RAN or Base Station detecting link failure with UE1 indicate the failure to CN for terminating QoS data flow via UE1 and continuing with QoS flow via UE2 only in view of Figure in Page 3).
Regarding claim 16, VIVO teaches The base station as claimed in claim 10, wherein the at least one processor is further configured to determine whether to allocate certain resources to transmitting the first wireless signal to the first device or to transmitting the second wireless signal to the second device based on a first channel quality associated with the first device and a second channel quality associated with the second device (
It is implied from citation for claim 10).
Regarding claim 17, VIVO teaches the base station as claimed in claim 11, wherein the further system is a system for receiving wireless signals or a system for establishing data flows (
Page 5, CN in Figure Switch media for Hot Backup cited for claim 10.).
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 4-5 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (“Study on UE Aggregation for Industry with Multi-Connectivity”, of IDS, hereinafter ‘VIVO’) in view of Yum et al. (US 20210409174 A1, of record, hereinafter ‘YUM’).
Regarding claim 4, VIVO teaches a system as claimed in claim 1.
VIVO does not explicitly disclose wherein the at least one processor is configured to determine beamforming feedback based on the reception of one or more reference signals by the first wireless receiver and the reception of the one or more reference signals and/or one or more further reference signals by the second wireless receiver, determine channel state information which includes the beamforming feedback,
and transmit the information including the channel state information.
In an analogous art, YUM teaches wherein the at least one processor is configured to determine beamforming feedback based on the reception of one or more reference signals by the first wireless receiver and the reception of the one or more reference signals and/or one or more further reference signals by the second wireless receiver, determine channel state information which includes the beamforming feedback (
[0118] If a carrier aggregation (CA) environment is considered, a 2-bit CSI request field is used in DCI format 0 or 4, for an aperiodic CSI feedback in the current LTE standards. If a plurality of serving cells are configured for a UE in the CA environment, the UE interprets the CSI request field in 2 bits. If one of TM 1 to TM 9 is configured for every component carrier (CC), an aperiodic CSI feedback is triggered according to values listed in Table 8 below. If TM 10 is configured for at least one of all CCs, an aperiodic CSI feedback is triggered according to values listed in Table 9 below.
See also Table 8 and Table 9 disclosing required CSI reporting indication for multiple serving cells or CCs, indicating multi-connectivity.
[0132] One feedback type may apply to a plurality of stage configurations. For example, although different RSs (e.g., a plurality of CSI-RSs of precoding different from BRS) are defined from an analog beam selection stage and a digital beam selection stage, respectively, feedback on each stage may include feedback of all beam indexes.
[0133] The following purposes may be considered for each CSI stage.
[0134] 1. Analog beam selection: Selecting an analog beam that is used by a BS.
[0135] 2. Digital Beam selection: This is the step of designating ports amounting to the number of ports (e.g., the number of TXU) to be actually used for data transmission to a UE when a BS has antenna ports more than TXU of the BS.
[0136] 3. CSI acquisition: CSI calculation/reporting to be actually used for data transmission by a UE),
and transmit the information including the channel state information (
[0162] In each CSI stage, a UE may calculate CSI on a designated feedback type using a designated RS and report it to a BS using a designated feedback resource (e.g., time-frequency resource).).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of reporting channel state including beam selection information in a wireless communication system with carrier aggregation of YUM to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO in order to take the advantage of method for reducing overhead (YUM: [0001, 0124, 0132]).
Regarding claim 5, VIVO, in view of YUM, teaches a system as claimed in claim 1.
VIVO does not explicitly disclose wherein the beamforming feedback includes first beamforming feedback determined based on the reception of the one or more reference signals by the first wireless receiver and second beamforming feedback determined based on the reception of the one or more reference signals and/or the one or more further reference signals by the second wireless receiver or includes combined beamforming feedback determined based on the reception of the one or more reference signals by the first wireless receiver and the reception of the one or more reference signals by the second wireless receiver.
YUM teaches wherein the beamforming feedback includes first beamforming feedback determined based on the reception of the one or more reference signals by the first wireless receiver and second beamforming feedback determined based on the reception of the one or more reference signals and/or the one or more further reference signals by the second wireless receiver or includes combined beamforming feedback determined based on the reception of the one or more reference signals by the first wireless receiver and the reception of the one or more reference signals by the second wireless receiver (
See [0118, 0132-0136] and Table 8 and Table 9 disclosing required CSI reporting indication for multiple serving cells or CCs, indicating multi-connectivity, cited for claim 4.).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of reporting channel state including beam selection information in a wireless communication system with carrier aggregation of YUM to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO in order to take the advantage of method for reducing overhead (YUM: [0001, 0124, 0132]).
Claim 18 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (“Study on UE Aggregation for Industry with Multi-Connectivity”, of IDS, hereinafter ‘VIVO’) in view of McCormick et al. (US 20140376383 A1, of record, hereinafter ‘MCCORMICK’).
Regarding claim 18, VIVO, in view of YUM, teaches the base station as claimed in claim 10.
VIVO does not explicitly disclose wherein the at least one processor is further configured to allocate excess resources fairly between the group of data flows and ungrouped data flows and other groups of data flows.
In an analogous art, MCCORMICK teaches wherein the at least one processor is further configured to allocate excess resources fairly between the group of data flows and ungrouped data flows and other groups of data flows (
Fig. 4, [0025] Aspects of this disclosure provide methods for performing alpha-fairness TE optimization. FIG. 4 illustrates an embodiment method 400 for performing alpha-fairness TE optimization for a traffic flow by an SDN controller. As shown, the method 400 begins at step 410, where the SDN controller identifies paths for the traffic flow. ….. the method 400 proceeds to step 460, where the SDN processor distributes the flow assignments to data plane entities in the communications network.
(It is obvious in MCCORMICK, all path resources or links are assigned using a fairness Traffic Engineering optimization for all identified data flows irrespective of flows are grouped, ungrouped or of any other group)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of fairness TE optimization of YUM to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO in order to take the advantage of method for providing an optimization algorithm to dynamically adjust to provide different performance characteristics, e.g., higher throughput versus higher quality of service (QoS) to achieve different levels of fairness/throughput (MCCORMICK: [Abstract, 0003]).
Claims 6-7, 13 and 19-20 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (“Study on UE Aggregation for Industry with Multi-Connectivity”, of IDS, hereinafter ‘VIVO’) in view of Zhang et al. (US 20210409996 A1, of record, hereinafter ‘ZHANG’).
Regarding claim 6, VIVO teaches a system for establishing data flows located in a mobile communication network, the system including at least one processor configured (
Page 3, RAN based solution Figures illustrating UE1 and UE2 integrated in a device to communicate with 5G CN via same NG-RAN, Bearer aggregation at PDCP layer at a device for DL QoS Data, Step 5. DRB resource configuration,
Page 4 Right side, CN solution Figures illustrating UE1 and UE2 integrated in a device with MPTCP function communication for QoS flow with a Data Network in Network Core via split user plane over two 3GPP Access path) to:
- receive, from a further system, a request to admit at least one data flow with one or more quality-of-service requirements, the at least one data flow being intended to be used for transmissions from a base station to a plurality of devices, the request specifying the one or more quality-of-service requirements (
Page 3, Step 1. UE1 and UE2 Aggregation capability indication to 5G CN during registration,
Step 2. Aggregation request during PDU Session Modification (for an QoS flow),
The above Step 2 aggregation request does not show the part "for an QoS flow". However the part “for an QoS flow” is implicit or inherent or at least obvious since VIVO also discloses the aggregation request causes-
Step 3: Authorization and policy check by 5G CN
Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN, and
Page 3 top right figure disclosing concept for RAN based UE aggregation for an QoS flow for which the protocol Steps 1-5 and subsequent UL/DL data flows are illustrated
(In the above Step 2 is construed as a request from UE1-UE2 or a remote further system received by NG-RAN and 5G CN for one or more QoS data flows with QoS requirement causing NG-RAN and 5G CN to provision corresponding QoS profile and subsequent data flows for a single/same QoS flow)),
- obtain, from and/or based on the request, information relating to each of the plurality of devices (
Page 3, Step 2. Aggregation request during PDU Session Modification for an QoS flow, Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN),
- transmit, to the further system, a response that the request has been accepted if it is determined that the one or more quality-of-service requirements can be accepted or a response that the request has been rejected otherwise (
Page 3, Step 3. Authorization, policy check (UL/DL load balance… etc.)
Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN
Step 5. DRB resource configuration (communicating with respective UE1 and UE2), and
Subsequent DL/UL data reception and transmission between UE1-UE2 and 5G CN via NG-RAN.
(From the above it is construed that NG-RAN communicating with 5G CN checking authorization and policy for UL/DL load balance creates QoS profile in response to request initiated by Step 2, transmits a response for 5G CN and to UE1-UE2 via DRB resource configuration that the request has been accepted, since NG-RAN configures DRB resources for subsequent DL/UL data communication communicating with respective UE1 and UE2)).
VIVO does not explicitly disclose
determine, based on the information, whether the one or more quality-of- service requirements can be accepted.
In an analogous art, ZHANG teaches determine, based on the information, whether the one or more quality-of- service requirements can be accepted (
Fig. 2, [0007] Once a UE is connected to the core network, CN, a session may be established between the UE and the CN with a default QoS flow and a default data radio bearer (DRB). Reference [2] specifies a number of ways to establish/release a new QoS flow. Brief reference is made to FIG. 2, which is a schematic data flow diagram illustrating an example of QoS flow establishment in NR Uu. As provided, a new QoS flow can be initiated by CN, the request is sent to gNB. It may be up to gNB to decide whether to accept or reject the QoS flow according to admission control rules. If accepted, gNB may map the QoS flow to a new DRB or an existing DRB.).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of whether to establish or accept or reject by a gNB for a new QoS flow request from CN or UE of ZHANG to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO in order to take the advantage of method for providing a decision by gNB for new QoS flow establishment based updated radio congestion, prioritization of the QoS flow in terms of pre-emption with respect to a new QoS flow establishment request and bearer mapping to enhance the system level performance under high device density (ZHANG: [0003, 0008]).
Regarding claim 7, VIVO, in view of ZHANG, teaches a system as claimed in claim 6.
VIVO does not explicitly disclose wherein the request is a request to admit a group of at least two data flows and the one or more quality-of-service requirements are one or more joint quality-of-service requirements.
ZHANG teaches wherein the request is a request to admit a group of at least two data flows and the one or more quality-of-service requirements are one or more joint quality-of-service requirements (
[0008] The ARP of a QoS flow is used for the sake of flow-based admission control procedures in which gNB decides whether or not the requested flow should be established in case of radio congestion. It also governs the prioritization of the QoS flow in terms of pre-emption with respect to a new QoS flow establishment request [3]. Further, in NR, it may be allowed to have multiple QoS flows mapped to the same bearer. In other word, it may be up to gNB to map the QoS flow to an existing DRB or a new DRB.
(“pre-emption with respect to a new QoS flow” and “multiple QoS flows” are obviously indicating request to admit a group of at least two data flows)).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of whether to establish or accept or reject by a gNB for a new QoS flow request from CN or UE of ZHANG to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO in order to take the advantage of method for providing a decision by gNB for new QoS flow establishment based updated radio congestion, prioritization of the QoS flow in terms of pre-emption with respect to a new QoS flow establishment request and bearer mapping to enhance the system level performance under high device density (ZHANG: [0003, 0008]).
Regarding claim 13, the claim is interpreted mutatis mutandis of claim 6 and rejected for the same reason as set forth for claim 6.
Regarding claim 19, VIVO, in view of ZHANG, teaches the system as claimed in claim 6, wherein the further system is a system for receiving wireless signals or a system in the core network (
Page 3, Step 1. UE1 and UE2 Aggregation capability indication to 5G CN during registration, and Step 2. Aggregation request during PDU Session Modification for an QoS flow, Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN
(In the above Step 1 is construed as a request from UEs or a remote further system received via 5G CN or another further system for one or more QoS data flows with QoS requirement profile)).
Regarding claim 20, VIVO, in view of ZHANG, teaches the system as claimed in claim 19, wherein the system in the core network is an Application Function in a 5G network (
Page 3, Step 1. UE1 and UE2 Aggregation capability indication to 5G CN during registration, and Step 2. Aggregation request during PDU Session Modification for an QoS flow, Step 4. Provision UE IDs, aggregation policy together with QoS profile to the RAN node by 5G CN …
Step 5. DRB resource configuration followed by QoS flows between UE1/UE2 and 5G CN via NG-RAN
See also Page 4, similar QoS flows between Data Network and UPF in Network core and UE1/UE2
(From Page 3 and Page 4 Figures, it is obvious that 5G CN with Data Network is a system in the core network is an Application Function in a 5G network with Data Network for the QoS flow data)).
Claims 8-9 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vivo (“Study on UE Aggregation for Industry with Multi-Connectivity”, of IDS, hereinafter ‘VIVO’) in view of Zhang et al. (US 20210409996 A1, of record, hereinafter ‘ZHANG’) and with further in view of Timo et al. (US 20240283509 A1 with priority of us-provisional-application US 63215743, of record, hereinafter ‘TIMO’).
Regarding claim 8, VIVO, in view of ZHANG, teaches a system as claimed in claim 7.
VIVO and ZHANG do not explicitly disclose wherein the information includes channel state information relating to each of the plurality of devices and the at least one processor is configured to determine, based on the channel state information, a correlation between a channel of a first device and a channel of a second device of the plurality of devices, estimate based on the correlation to what degree the first and second devices can be co-scheduled on the same time-frequency resources, and determine whether the one or more joint quality-of-service requirements can be accepted in dependence on the degree to which the first and second devices can be co-scheduled on same time-frequency resources.
In an analogous art, TIMO teaches wherein the information includes channel state information relating to each of the plurality of devices and the at least one processor is configured to determine, based on the channel state information (
[0013] In such cases, active UEs need to feedback channel information to the RAN node. In LTE and NR, a RAN node periodically transmits DL CSI-RS from which the UE estimates the DL channel. The UE reports CSI feedback to the RAN node over an UL channel ……. ),
a correlation between a channel of a first device and a channel of a second device of the plurality of devices, estimate based on the correlation to what degree the first and second devices can be co-scheduled on the same time-frequency resources, and determine whether the one or more joint quality-of-service requirements can be accepted in dependence on the degree to which the first and second devices can be co-scheduled on same time-frequency resources (
[0010] transmitting multiple layers on the same time-frequency resource to multiple users (referred to as “MU-MIMO”) can increase the system capacity in terms of number of users.
[0011] a multi-antenna radio access network (RAN) node (e.g., base station) with N.sub.TX antenna ports simultaneously transmits information to several UEs using the same OFDM time-frequency resources. Before modulation and transmission, a precoding matrix W.sub.V.sup.(j) is applied to sequence Ŝ.sup.(i) transmitted to user (or UE) i for spatial separation from other transmissions and mitigation of multiplexing interference. Each UE(i) demodulates its received signal and combines receiver antenna signals in order to obtain an estimate Ŝ.sup.(i) of sequence S) transmitted to it. In general, the precoder W.sub.V.sup.(i) should correlate well with channel HG observed by UE(i) and it should correlate poorly with the channels observed by other UEs.
[0012] To construct precoders that enable efficient MU-MIMO transmissions, the RAN node needs to acquire detailed knowledge of the DL channels H(i)…..
[0013] In such cases, active UEs need to feedback channel information to the RAN node. In LTE and NR, a RAN node periodically transmits DL CSI-RS from which the UE estimates the DL channel. The UE reports CSI feedback to the RAN node over an UL channel ……. The RAN node uses the UE's feedback to select suitable precoders for DL MU-MIMO transmissions. The CSI feedback mechanism from the UE to the RAN node or network targeting MU-MIMO operations in NR is referred to as CSI Type II reporting.
[0078] The Type II CSI report can be used by the RAN node to spatially co-schedule multiple UEs on the same OFDM time-frequency resources. For example, the RAN node can select UEs that have reported different sets of beams or beams that have weak correlations. The CSI Type II report enables the UE to report a precoder hypothesis that trades CSI resolution for reduced UL transmission overhead.
See also Fig. 7 Steps 760 [Wingdings font/0xE8] …. [Wingdings font/0xE8] 790).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of RAN co-scheduling multiple UEs on the same time-frequency resources based on reported CSI by the UEs of TIMO to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO and ZHANG in order to take the advantage of method for increasing the system capacity in terms of number of users (TIMO: [0010, 0078]).
Regarding claim 9, VIVO, in view of ZHANG, teaches a system as claimed in claim 6.
VIVO and ZHANG do not explicitly disclose wherein the information further includes further channel state information relating to a further device, the further device not being included in the plurality of devices, and the at least one processor is configured to determine, based on the further channel state information, a further correlation between a channel of a device of the plurality of devices and a channel of the further device,
estimate based on the further correlation to what degree the device and the further device can be co-scheduled on the same time-frequency resources, and determine whether the one or more quality-of-service requirements can be accepted in dependence on the degree to which the device and the further device can be co-scheduled on same time-frequency resources
TIMO teaches wherein the information further includes further channel state information relating to a further device, the further device not being included in the plurality of devices, and the at least one processor is configured to determine, based on the further channel state information, a further correlation between a channel of a device of the plurality of devices and a channel of the further device (
[0013] In such cases, active UEs need to feedback channel information to the RAN node. In LTE and NR, a RAN node periodically transmits DL CSI-RS from which the UE estimates the DL channel. The UE reports CSI feedback to the RAN node over an UL channel ……. ),
estimate based on the further correlation to what degree the device and the further device can be co-scheduled on the same time-frequency resources, and determine whether the one or more quality-of-service requirements can be accepted in dependence on the degree to which the device and the further device can be co-scheduled on same time-frequency resources (
[0010] transmitting multiple layers on the same time-frequency resource to multiple users (referred to as “MU-MIMO”) can increase the system capacity in terms of number of users.
[0011] a multi-antenna radio access network (RAN) node (e.g., base station) with N.sub.TX antenna ports simultaneously transmits information to several UEs using the same OFDM time-frequency resources. Before modulation and transmission, a precoding matrix W.sub.V.sup.(j) is applied to sequence Ŝ.sup.(i) transmitted to user (or UE) i for spatial separation from other transmissions and mitigation of multiplexing interference. Each UE(i) demodulates its received signal and combines receiver antenna signals in order to obtain an estimate Ŝ.sup.(i) of sequence S) transmitted to it. In general, the precoder W.sub.V.sup.(i) should correlate well with channel HG observed by UE(i) and it should correlate poorly with the channels observed by other UEs.
[0012] To construct precoders that enable efficient MU-MIMO transmissions, the RAN node needs to acquire detailed knowledge of the DL channels H(i)…..
[0013] In such cases, active UEs need to feedback channel information to the RAN node. In LTE and NR, a RAN node periodically transmits DL CSI-RS from which the UE estimates the DL channel. The UE reports CSI feedback to the RAN node over an UL channel ……. The RAN node uses the UE's feedback to select suitable precoders for DL MU-MIMO transmissions. The CSI feedback mechanism from the UE to the RAN node or network targeting MU-MIMO operations in NR is referred to as CSI Type II reporting.
[0078] The Type II CSI report can be used by the RAN node to spatially co-schedule multiple UEs on the same OFDM time-frequency resources. For example, the RAN node can select UEs that have reported different sets of beams or beams that have weak correlations. The CSI Type II report enables the UE to report a precoder hypothesis that trades CSI resolution for reduced UL transmission overhead.
See also Fig. 7 Steps 760 [Wingdings font/0xE8] …. [Wingdings font/0xE8] 790).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention to take the technique of RAN co-scheduling multiple UEs on the same time-frequency resources based on reported CSI by the UEs of TIMO to the system of UE Aggregation with Multi-Connectivity for a QoS flow of VIVO and ZHANG in order to take the advantage of method for increasing the system capacity in terms of number of users (TIMO: [0010, 0078]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Pelletier et al. (US 20210058951 A1), describing FLOW-BASED PROCESSING IN WIRELESS SYSTEMS
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 SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM PST.
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, UN C CHO can be reached at 571-272-7919. 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.
/SHAH M RAHMAN/Primary Examiner, Art Unit 2413
Prosecution Insights