DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Action is in response to communications filed on 10/30/2025.
Claims 37-38, 42, 46-47, 51, 53, and 55-56 have been amended. There are no new claims.
Claims 44-45 and 50 have been cancelled. Claims 1-36 were previously cancelled.
Claims 37-43, 46-49, 51-56 are presented for examination.
Claims 37-43, 46-49, 51-56 remain pending in this application.
Response to Arguments Regarding Specification
In the non-final office Action mailed on 08/06/2025, the Abstract was objected to due to minor informalities. The amendment to abstract was received on 10/30/2025. These amendments are acceptable, and as a result, the respective specification objection made in the non-final Office Action is withdrawn.
Response to Arguments Regarding Claim Objections
In the non-final office Action mailed on 08/06/2025, claims 37-41, 43-44, 46-49, and 53-56 were objected to due to minor informalities. The amendment to claims 53 and 56 are acceptable, and as a result, the respective specification objection made in the non-final Office Action is withdrawn.
The Applicant's remaining amendment/ arguments, see page 13 of REMARKS, filed 10/30/2025, with respect to objections to claims 37-41, 43-44, 46-49, and 54-55 have been fully considered but they are not persuasive. In the response filed on 10/30/2025, applicant puts forth in substance that:
“In the OA (at 3-4), the Examiner objected to various "informalities" in claims 37-41, 43- 44, 46-49, and 53-56. Applicant addresses these "informalities" individually below.
For example, the Examiner objected to the use of "the following" in claims 37-41, 43-44, 46-49, and 53-54 because it has "insufficient antecedent basis." Applicant respectfully points out that "antecedent basis" means "a basis in what comes before." However, the concept of "antecedent basis" is entirely inapplicable to a phrase that explicitly refers to what comes immediately after, such as "the following" used in claims 37-41, 43-44, 46-49, and 53-54. In other words, a skilled person would immediately interpret this common English grammatical construct as referring to what comes immediately after rather than what came before, such that it would not affect the skilled person's understanding of claims that use it properly, as in this case. Accordingly, Applicant respectfully requests withdrawal of the objections to the use of this phrase.”
Examiner reminds the applicant that the claims were objected to due to lack of antecedent basis. In response to the applicant’s arguments, examiner acknowledges and agrees that "antecedent basis" means "a basis in what comes before". Since the applicant’s amendment addresses what comes after, but still does not change what came before, the recitation of “the following” in the objected claims still lack proper antecedent basis. For this reason, the applicant’s arguments are not persuasive.
Response to Arguments Regarding Claim Rejections - 35 USC § 112
In the non-final office Action mailed on 08/06/2025, claim 53 was rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite. In the response filed on 10/30/2025, applicant amends the claim to obviate the rejection. These amendments are acceptable, and as a result, the respective claim rejection made in the non-final Office Action has been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 102/ 103
The Applicant's amendment/ arguments, see pages 15-20 of REMARKS, filed 10/30/2025, with respect to rejections to claims under 35 USC § 102/ 103 have been fully considered but they are not persuasive. In the response filed on 10/30/2025, applicant puts forth in substance that:
“In the OA, the Examiner rejected claims 37-49 and 54-56 under 35 U.S.C. 103 as anticipated by 3GPP document R3-215659 ("Huawei" cited in ISR) and claims 50-52 as obvious in view of Huawei and U.S. Pat. Pub. 2023/0199543 ("Zhang").
Claimed embodiments address various problems, issues, and/or difficulties related to quality-of-experience (QoE) reporting by user equipment (UEs) operating in radio access networks (RANs). In general, QoE is intended to measure end-user experience for certain applications (e.g., streaming) in the UE that rely on communication with the RAN. As such, conventional QoE measurements are application-layer measurements that are sent by a UE to a collection entity via the RAN, but are not visible to the RAN itself. Appl. 2:30-3:9.
In addition, the Third Generation Partnership Project (3GPP) has defined some RAN- visible QoE (RVQoE) metrics that a UE may collect and provide to its serving RAN node, which may use these metrics for monitoring or adapting its own performance to suit application needs. Like conventional QoE measurements, RVQoE reporting may be triggered by various events and/or conditions, which may be associated with the UE's application layer or the UE's access stratum (AS). For RVQoE reporting in particular, the events and/or conditions may be detected at the UE or in the serving RAN node. Currently, however, there is no way for the UE's AS to inform the UE application layer that a triggering condition - or which one - for RVQoE reporting by the UE application layer has been fulfilled. Appl. 24:16-28.
Claimed embodiments address these and related problems, issues, and/or difficulties by a "method for a UE configured to perform QoE measurements in a RAN" (independent claim 37), a corresponding "UE' apparatus (independent 55), and a complementary "method for a RAN node configured to manage QoE measurements by UEs" (independent claim 46). The rejections of these claims are discussed in more detail below.” (See pages 15-16 of REMARKS, filed 10/30/2025).
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., UE's AS to inform the UE application layer that a triggering condition - or which one - for RVQoE reporting by the UE application layer has been fulfilled) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
“In claims 37 and 55, the UE "performs QoE measurements for one or more applications operating on a UE application layer" and "detects occurrence of at least one event or condition that triggers a RVQoE report." In particular, "detecting occurrence of the at least one event or condition comprises receiving from a RAN node an indication that the at least one event or condition has occurred." This feature was previously recited in dependent claim 45.
Then "based on detecting the occurrence of the at least one event or condition," the UE "sends the following to the RAN node":
"at least one RVQoE report that includes one or more RVQoE metrics or RVQoE values, wherein each RVQoE metric or RVQoE value is based on the QoE measurements performed"; and
"one or more trigger-related indications associated with the detected event or condition, included in or with each RVQoE report sent."
In the OA (at 12-13), the Examiner found that Huawei page 1 lines 9-11 and 25-26 disclose the features of dependent claim 45 that have been incorporated into independent claims 37 and 55. A closer inspection shows error in these findings.
According to Applicant's understanding, the Examiner cites the following statements in Huawei as disclosing these claim features (underline emphasis added):
Upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN. …
The RVQoE configuration sent to UE should contain: …
Metrics to be reported, as a mandatory IE
Sample percentage (FFS)
Start Time (FFS)
Duration (FFS)
Reporting Interval for periodic case (FFS)
Triggering Event (FFS)
To summarize, the "UE AS" indicates to the "UE APP" (application layer) that "RAN visible QoE measurement has been triggered" in the UE. This action is between two functions in the UE and does not involve the RAN. Although the event may be related to RVQoE metrics requested by the RAN, it is the UE AS -not the RAN - that detects and indicates the trigger to the UE APP.
In contrast, claims 37 and 55 specify that "detecting occurrence of the at least one event or condition [that triggers a RVQoE report] comprises receiving from a RAN node an indication that the at least one event or condition has occurred." In other words, the RAN node detects the trigger occurrence and indicates that to the UE.
Although Huawei's "RVQoE configuration sent to the UE" may indicate the "triggering event," this configuration does not indicate "that the ...event has occurred" as required by amended independent claims 37 and 55. Instead, the "RVQoE configuration" indicates to the UE what the triggering event is, so the UE AS can later detect the configured triggering event and indicate it to the UE APP. This understanding is consistent with the following explanation in Huawei section 2.2, immediately before "Proposal 5":
Therefore we think the UE can report the RAN visible QoE results only if the results satisfy the conditions. But as proposed in the above, the RAN visible QoE metrics are reported together with the QoE report container. Therefore when the application layer generates the legacy QoE results, the application layer reports the RAN visible QoE only if the RAN visible QoE metrics satisfy the triggering event.
Since the UE "reports the RAN visible QoE results only if the results satisfy the conditions," and the UE is the entity that collects the RVQoE results, the UE must be the entity that determines whether "the results satisfy the conditions" (or triggering event).
For at least these reasons, Huawei does not disclose all the features of amended independent claim 37, which was previously in dependent form as claim 45. For the same reasons, Huawei does not disclose all the features of amended independent UE apparatus claim 55, which is substantially identical to method claim 37. Accordingly, Applicant respectfully requests withdrawal of the anticipation rejections of independent claims 37 and 55.” (See pages 16-18 of REMARKS, filed 10/30/2025).
In response to the applicant’s arguments, it is noted that Huawei discloses that RVQoE metrics are available for the RAN to configure the UE to collect (on page 1, see lines 32-33). Huawei also discloses the RAN generates the RVQoE measurement configuration (see line 14) and/or that a target/new RAN node assembles RVQoE configuration (see last paragraph on page 1). Furthermore, lines 20-26 on page 1 of Huawei discloses that the RVQoE configuration sent to UE should contain… reporting interval for periodic case and/or triggering event. Then in line 30, Huawei discloses that the RAN decides whether RVQOE measurement collection and reporting is activated. In addition, page 1: lines 9-11 discloses that upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN.
Examiner articulates that “RAN deciding whether RVQOE measurement collection and reporting is activated” corresponds to “the at least one event or condition has occurred” as claimed. Also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports; the UE can report the RAN visible QoE results only if the results satisfy the conditions. The examiner further articulates that the RAN requesting the RVQoE metrics needed to be collected (to the UE) corresponds to the UE “receiving from the RAN node an indication that the at least one event or condition has occurred” that triggers a RAN-visible QoE (RVQoE) report.
Applicant also cited section 2.2, immediately before "Proposal 5" to argue that the “UE AS can later detect the configured event and indicate it to the UE APP”. The concerned paragraph from Huawei that is cited in the applicant’s argument is reproduced below for ease:
In some cases, the RAN only optimizes the radio resource when the RAN visible QoE results satisfy some conditions, i.e. the triggering event. Therefore we think the UE can report the RAN visible QoE results only if the results satisfy the conditions. But as proposed in the above, the RAN visible QoE metrics are reported together with the QoE report container. Therefore when the application layer generates the legacy QoE results, the application layer reports the RAN visible QoE only if the RAN visible QoE metrics satisfy the triggering event. Whether the UE reports the RAN visible QoE metric or only the indication of the satisfied event can be further discussed.
As highlighted above, examiner notes that the citation for applicant’s argument is taken out of context, and that the paragraph is instead related to how/when the UE can report the RAN visible QoE metrics/ results so that the RAN optimizes the radio resource (rather than the alleged “indication to the UE APP”).
Applicant's arguments for independent claim 55 appear to stem from the applicant's assertion that the cited reference(s) and/or their combination fails to disclose the similarly recited limitations of claim 37. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the independent claim 55persists.
Applicant's arguments for the dependent claims 38-43 appear to stem from the applicant's assertion that the cited reference(s) and/or their combination fails to disclose all the limitations of respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the dependent claims persist.
“In complementary independent claim 46, the RAN node "sends, to a UE, a RVQoE reporting request that includes one or more of the following:"
"a request to include trigger-related indications with or in RVQoE reports," and
"a reporting configuration comprising at least one event or condition that triggers an RVQoE report."
The RAN node "subsequently detects occurrence of the at least one event or condition" and "sends to the UE an indication that the at least one event or condition has occurred." These features were previously recited in dependent claim 50. Then "in response to the indication," the RAN node receives from the UE the same information that the UE sends the RAN node in independent claims 37 and 55.
In the OA (at 16-17), the Examiner found that Huawei page 1 lines 9-11 and 25-26 (discussed above) and Zhang [0006], [0008], and [0015] disclose the features of dependent claim 50 that have been incorporated into independent claim 46. A closer inspection shows error in these findings.
Applicant's above discussion about Huawei's disclosure with respect to amended independent claims 37/55 is equally applicable to amended independent claim 46, but it is omitted here for the sake of brevity. Zhang [0008] cited by the Examiner discloses the following (with underline emphasis added):
The method includes generating, by a network node, a quality of experience (QoE) measurement retrieval configuration that configures a wireless device to retrieve QoE measurements that are visible to the network node, transmitting, to the wireless device, a first radio resource control message comprising the QoE measurement retrieval configuration, and receiving, from the wireless device, a second radio resource control message comprising a QoE evaluation result, wherein the wireless device is configured to generate the QoE evaluation result based on the QoE measurements
To summarize, Zhang's network node sends a "QoE measurement retrieval configuration" to a wireless device, based on which the wireless device reports a "QoE evaluation result." According to Applicant's understanding, Zhang's "QoE measurement retrieval configuration" is similar to the claimed "RVQoE reporting request" that includes "a reporting configuration comprising at least one event or condition that triggers an RVQoE report."
However, claim 46 also requires that, after sending this "request," the RAN node" subsequently detects occurrence of the at least one event or condition" and "sends to the UE an indication that the at least one event or condition has occurred", in response to which the UE reports its results. Huang [0008] is silent about the network node detecting any conditions after sending the "QoE measurement retrieval configuration" but before receiving the "QoE evaluation result" from the UE.
Huang [0006] and [0015] are also silent about these features of amended independent claim 46, formerly found in dependent claim 50. Huang [0006] discloses a "DU of a network node ... generating ... a first QoE measurement configuration that configures the wireless device to perform QoE measurement that are visible to the network node [and] transmitting, to a CU of the network node, an Fl Application Protocol (F1AP) requirement message comprising the first QoE measurement configuration." Huang [0015] merely summarizes Figure 4, which "shows an example timing diagram for a DU of a RAN triggering the activation of RAN-visible QoE measurements." Neither of these paragraphs - nor Zhang Figure 4 - disclose the claimed operations that take place after the RAN node sends the "RVQoE reporting request" but before the RAN node receives from the UE the "at least one RVQoE report" and the "one or more trigger- related indications."
For at least these reasons, the combination of Huawei and Zhang does not disclose all the features of amended independent claim 46, which was previously in dependent form as claim 50. Accordingly, the obviousness rejection of independent claim 46 should be withdrawn.” (See pages 15-20 of REMARKS, filed 10/30/2025).
As set forth above, Huawei discloses that the RVQoE metrics are available for the RAN to configure the UE to collect (on page 1, see lines 32-33). Huawei further discloses that the RAN generates the RVQoE measurement configuration (see line 14 on page 1) and sends the RVQoE configuration to UE (see lines 20-26). As per line 30 on page 1, the RAN then decides whether RVQOE measurement collection and reporting is activated. Upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN (see lines 9-11 on page 1). Therefore, based on these teachings, it would be inherent that the RAN node subsequently detects occurrence of the at least one event or condition (i.e. after sending the RVQoE measurement configuration but before collecting the results/ reports, as currently claimed). Although, the limitation “subsequently detecting occurrence of the at least one event or condition” is inherent in the cited reference to Huawei, examiner has not invoked inherency and has instead presented secondary art, in the interest of compact prosecution and advancing prosecution.
ZHANG discloses that transmitting, to a wireless device, a first radio resource control message comprising the second QoE measurement configuration and an activation configuration (see [0008]). Furthermore, the RAN-visible QoE configuration includes… a report event trigger, which defines one or more events that trigger a measurement report, e.g., a QOE metric being above or below a predefined threshold, and/or a reporting method, which includes periodic reporting, event-triggered reporting, or one-time immediate reporting (see [0036]-[0058]). Examiner articulates that given the teachings of RAN-visible QoE measurements configuration and an activation configuration for event-triggered reporting in Huawei as well as in ZHANG, it would be obvious that the event or condition occurrence is subsequently detected- i.e. after the RAN-visible QoE configuration. For instance, a first radio resource control message in ZHANG comprises the second QoE measurement configuration and an activation configuration, thus it would be obvious to one of ordinary skill in the art to modify it so that that activation configuration is subsequent to QoE measurement configuration.
Applicant's arguments for the dependent claims 47-49, 51-54, and 56 appear to stem from the applicant's assertion that the cited reference(s) and/or their combination fails to disclose all the limitations of respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the dependent claims persist.
Claim Objections
Claim(s) 37-41, 43-44, 46-49, and 55-55 are objected to because of the following informalities:
Claim 37 recites the limitation “the following” in lines 10-11. There is insufficient antecedent basis for this limitation in the claim.
Claims 38-41 recite the limitation “the following” in line 2. There are insufficient antecedent basis for this limitation in the claims.
Claim 43 recites the limitation “the following” in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 46 recites the limitation “the following” in lines 5 and 11. There are insufficient antecedent basis for these limitations in the claim.
Claims 47-49 and 53-54 recite the limitation “the following” in line 2. There are insufficient antecedent basis for this limitation in the claims.
Claim 53 recites the limitations “an F1AP message” in line 3 as well as “an E1AP message” in line 6. Examiner suggests abbreviating “F1AP” and “E1AP” before its first use.
Claim 55 recites the limitation “the following” in lines 12-13. There is insufficient antecedent basis for this limitation in the claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 37-43, and 55 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Non-Patent Literature to Huawei (hereinafter, Huawei, “Further discussions on RAN visible QoE metrics”; R3-215659; 3GPP TSG-RAN WG3 Meeting #114-e; 1-11 Nov 2021).
NOTE: NPL reference to Huawei cited herein was provided by the applicant in/with the IDS dated 06/11/2024, and is already made or record. A copy of the cited NPL reference to Huawei is therefore NOT furnished herewith.
Regarding claim 37, Huawei discloses a method for a user equipment (UE) configured to perform quality-of-experience (QoE) measurements in a radio access network (RAN), the method comprising (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN):
performing QoE measurements for one or more applications operating on a UE application layer (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; also see Proposal 2 on page 5 and Proposal 5 on page 6 disclosing UE may need to measure the metrics/ QoE measurement per slice; also see Proposal 2-5 on pages 5-6 disclosing the UE application layer reports the RAN visible QoE);
detecting occurrence of at least one event or condition that triggers a RAN-visible QoE (RVQoE) report, wherein detecting the occurrence of the at least one event or condition comprises receiving from the RAN node an indication that the at least one event or condition has occurred (on page 1, see lines 32-33 that indicates “RVQoE metrics are available for the RAN to configure the UE to collect”; also see line 14; the RAN generates the RVQoE measurement configuration; also see last paragraph on page 1 disclosing target/new RAN node that assembles RVQoE configuration; also see lines 20-26; the RVQoE configuration sent to UE should contain… reporting interval for periodic case and/or triggering event; also see line 30; the RAN decides whether RVQOE measurement collection and reporting is activated; also see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; examiner articulates that “RAN deciding whether RVQOE measurement collection and reporting is activated” corresponds to “the at least one event or condition has occurred” as claimed; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports; the UE can report the RAN visible QoE results only if the results satisfy the conditions; the examiner also articulates that the RAN requesting the RVQoE metrics needed to be collected (to the UE) corresponds to the UE “receiving from the RAN node an indication that the at least one event or condition has occurred that triggers a RAN-visible QoE (RVQoE) report”); and
based on detecting the occurrence of the at least one event or condition, sending the following to the RAN node (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; also see Proposals 4-5 on pages 5-6; the UE can report the RAN visible QoE results only if the results satisfy the conditions):
at least one RVQoE report that includes one or more RVQoE metrics or RVQoE values, wherein each RVQoE metric or RVQoE value is based on the QoE measurements performed (see Proposals 2-3 on page 5; the RAN visible QoE metrics are reported together with the QoE report container from the application layer to the AS; also see proposal 4 on page 5-6; the application layer reports the RAN visible QoE only if the RAN visible QoE metrics satisfy the triggering event); and
one or more trigger-related indications associated with the detected event or condition, included in or with each RVQoE report sent (see Proposal 6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE; also see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration).
Regarding claim 38, Huawei discloses the method of claim 37, as set forth above. In addition, Huawei further discloses wherein the one or more trigger-related indications include any of the following:
indication that an RVQoE reporting trigger occurred;
indication or identifier of the RVQoE reporting trigger (see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration);
a time at which the RVQoE reporting trigger occurred (see Proposal 7 on page 6; UE to report the average buffer level during the measurement interval);
cause or reason for occurrence of the RVQoE reporting trigger;
indication or identifier of entity that detected the RVQoE reporting trigger;
type of the RVQoE reporting trigger; and
extended information associated with the RVQoE reporting trigger (see Proposal 6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE; also see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration; also see proposal 5 on page 6; the UE will also report the RAN visible QoE results per slice together with the QoE measurement).
Regarding claim 39, Huawei discloses the method of claim 38, as set forth above. In addition, Huawei further discloses wherein the extended information includes one or more of the following: cell identifier; network slice identifier (see proposal 5 on page 6; the UE will also report the RAN visible QoE results per slice together with the QoE measurement); network slice type; radio access technology (RAT) identifier; public land mobile network (PLMN) identifier; protocol data unit (PDU) session-related parameters (see Proposal 6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE); and respective values of one or more QoE-related parameters that caused the RVQoE reporting trigger (see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration; also see Proposal 7 on page 6; UE to report the average buffer level during the measurement interval).
Regarding claim 40, Huawei discloses the method of claim 37, as set forth above. In addition, Huawei further discloses wherein the at least one event or condition is related to one or more of the following:
an RVQoE reporting request from the RAN node (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN);
a duration since last RVQoE report (see Proposal 7 on page 6; UE to report the average buffer level during the measurement interval);
an RVQoE reporting configuration from the RAN node (see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports);
messages or control elements (CEs) sent to or received from the RAN node (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; also see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event);
messages sent between different units of the RAN node (see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event);
one or more RAN-related events (see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports);
a UE procedure related to mobility, multi-connectivity, and/or Radio Resource Control (RRC) state change (see last paragraph on page 1);
a protocol data unit (PDU) session (see Proposal 5-6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE);
a network slice (see Proposal 5 on page 6; UE will also report the RAN visible QoE results per slice together with the QoE measurement);
layer-2 and/or radio-related measurements performed by the UE ((see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration; also see Proposal 7 on page 6; UE to report the average buffer level during the measurement interval);
one or more RVQoE metrics and/or RVQoE values in relation to corresponding thresholds (see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration; also see Proposal 7 on page 6; UE to report the average buffer level during the measurement interval);
service types, service subtypes, and/or subservice types of the one or more applications being measured (see Observation 5 on page 5; QoE metrics of QoE measurements for each service type are configurable); and
session-related events for the one or more applications being measured (see Proposal 5-6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE).
Regarding claim 41, Huawei discloses the method of claim 37, as set forth above. In addition, Huawei further discloses receiving from the RAN node an RVQoE reporting request (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN) that includes one or more of the following:
a request to include trigger-related indications with or in RVQoE reports (see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports); and
an RVQoE reporting configuration comprising the at least one event or condition (see Observation 3 on page 4; triggering event in the RAN visible QoE configuration; also see page 1: lines 9-11, 14 and 19-27; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; RVQoE configuration sent to UE should contain mandatory metrics to be reported, reporting interval for periodic case and/or triggering event).
Regarding claim 42, Huawei discloses the method of claim 37, as set forth above. In addition, Huawei further discloses wherein:
the indication is received by a UE access stratum (AS) (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN); and
the method further comprises:
based on the received indication, the UE AS sending an RVQoE reporting request to the UE application layer (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN); and
receiving, by the UE AS from the UE application layer, the at least one RVQoE report that includes the one or more RVQoE metrics or RVQoE values (see Proposals 2-3 on page 5; the RAN visible QoE metrics are reported together with the QoE report container from the application layer to the AS; also see proposal 4 on page 5-6; the application layer reports the RAN visible QoE only if the RAN visible QoE metrics satisfy the triggering event).
Regarding claim 43, Huawei discloses the method of claim 42, as set forth above. In addition, Huawei further discloses wherein one of the following applies:
the RVQoE reporting request sent to the UE application layer and the at least one RVQoE report received from the UE application layer include the trigger-related indications (see Observation 3 on page 4; triggering event in the RAN visible QoE configuration; also see page 1: lines 9-11, 14 and 19-27; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; RVQoE configuration sent to UE should contain mandatory metrics to be reported, reporting interval for periodic case and/or triggering event; see Proposal 6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE; also see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration); or
the method further comprises modifying, by the UE AS, the at least one RVQoE report received from the UE application layer to include or to associate the trigger- related indications, before sending the at least one RVQoE report to the RAN node.
As for Claim 55, the claim lists all the same elements of claim 37, but in User equipment (UE) (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN) comprising: communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry (see page 1: lines 9-11; inherent components of a UE), wherein the processing circuitry and the communication interface circuitry are configured to carry out the steps of claim 37, rather than the method form. Therefore, the supporting rationale of the rejection to claim 37 applies equally as well to claim 55.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 46-49, 51-54 and 56 is/are rejected under 35 U.S.C. 103 as being unpatentable over Non-Patent Literature to Huawei (hereinafter, Huawei, “Further discussions on RAN visible QoE metrics”; R3-215659; 3GPP TSG-RAN WG3 Meeting #114-e; 1-11 Nov 2021) in view of ZHANG et al. (hereinafter, ZHANG, US 20230199543 A1).
NOTE: ZHANG (US publication # US 20230199543 A1) was filed on 02/22/2023 and published on 06/22/2023, but is a continuation of and claims benefit of priority to International Patent Application No. PCT/CN2021/087103, filed on Apr. 14, 2021. The corresponding WIPO publication WO 2022217477 A1 was previously made of record and attached. But for citation purpose, US publication has been used herein below.
Regarding claim 46, Huawei discloses a method for a radio access network (RAN) node configured to manage quality-of-experience (QoE) measurements by user equipment (UEs) in the RAN, the method comprising:
sending, to a UE, a RAN-visible QoE (RVQoE) reporting request (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN) that includes one or more of the following:
a request to include trigger-related indications with or in RVQoE reports (see lines 25-26 for RVQoE configuration sent to UE should contain reporting interval for periodic case and/or triggering event; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports), and
a reporting configuration comprising at least one event or condition that triggers an RVQoE report (see Observation 3 on page 4; triggering event in the RAN visible QoE configuration; also see page 1: lines 9-11, 14 and 19-27; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; RVQoE configuration sent to UE should contain mandatory metrics to be reported, reporting interval for periodic case and/or triggering event; also see last paragraph on page 1 disclosing target/new RAN node that assembles RVQoE configuration);
sending to the UE an indication that the at least one event or condition has occurred (on page 1, see lines 32-33 that indicates “RVQoE metrics are available for the RAN to configure the UE to collect”; also see line 14; the RAN generates the RVQoE measurement configuration; also see last paragraph on page 1 disclosing target/new RAN node that assembles RVQoE configuration; also see lines 20-26; the RVQoE configuration sent to UE should contain… reporting interval for periodic case and/or triggering event; also see line 30; the RAN decides whether RVQOE measurement collection and reporting is activated; also see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; examiner articulates that “RAN deciding whether RVQOE measurement collection and reporting is activated” corresponds to the RAN “subsequently detecting occurrence of the at least one event or condition” as claimed; also see Proposals 4-5 on pages 5-6 disclosing event/ condition triggered QoE reports; the UE can report the RAN visible QoE results only if the results satisfy the conditions; the examiner also articulates that the RAN requesting the RVQoE metrics needed to be collected (to the UE) corresponds to the RAN “sending to the UE an indication that the at least one event or condition has occurred” that triggers a RAN-visible QoE (RVQoE) report); and
in response to the indication, receiving the following from the UE (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN; also see Proposals 4-5 on pages 5-6; the UE can report the RAN visible QoE results only if the results satisfy the conditions; the examiner also articulates that the RAN requesting the RVQoE metrics needed to be collected (to the UE) corresponds to the RAN “sending to the UE an indication that the at least one event or condition has occurred” that triggers a RAN-visible QoE (RVQoE) report):
at least one RVQoE report that includes one or more RVQoE metrics or RVQoE values, wherein each RVQoE metric or RVQoE value is based on QoE measurements performed by the UE (see Proposals 2-3 on page 5; the RAN visible QoE metrics are reported together with the QoE report container from the application layer to the AS; also see proposal 4 on page 5-6; the application layer reports the RAN visible QoE only if the RAN visible QoE metrics satisfy the triggering event); and
one or more trigger-related indications associated with the at least one event or condition, included in or with each RVQoE report received (see Proposal 6 on page 6; The PDU session information and QoS flow information are reported together with the RAN visible QoE; also see Observation 3 on page 4; the UE sends one alarm indication to the RAN when the buffer level falls below an alarm level… in triggering event in the RAN visible QoE configuration).
Examiner’s Note: As set forth above, Huawei discloses that the RVQoE metrics are available for the RAN to configure the UE to collect (on page 1, see lines 32-33). Huawei further discloses that the RAN generates the RVQoE measurement configuration (see line 14 on page 1) and sends the RVQoE configuration to UE (see lines 20-26). As per line 30 on page 1, the RAN then decides whether RVQOE measurement collection and reporting is activated. Upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN (see lines 9-11 on page 1). Therefore, based on these teachings, it would be inherent that the RAN node subsequently detects occurrence of the at least one event or condition (i.e. after sending the RVQoE measurement configuration but before collecting the results/ reports, as currently claimed). Although, the limitation “subsequently detecting occurrence of the at least one event or condition” is inherent in the cited reference to Huawei, examiner has not invoked inherency and has instead presented secondary art, in the interest of compact prosecution and advancing prosecution.
Although Huawei discloses sending to the UE an indication that the at least one event or condition has occurred (on page 1, see lines 32-33; also see line 14, 20-26; also see line 30; also see page 1: lines 9-11), Huawei does not explicitly disclose subsequently detecting occurrence of the at least one event or condition.
However, in an analogous art, ZHANG discloses subsequently detecting occurrence of the at least one event or condition (see [0006]; determination, by a distributed unit (DU) of a network node, regarding activating a wireless device to perform quality of experience (QoE) measurement that are visible to the network node; also see [0015]; Distributed Unit (DU) of a RAN triggering the activation of RAN-visible QoE measurements; also see [0008]; transmitting, to a wireless device, a first radio resource control message comprising the second QoE measurement configuration and an activation configuration; also see [0036]-[0058]; the RAN-visible QoE configuration includes… a report event trigger, which defines one or more events that trigger a measurement report, e.g., a QOE metric being above or below a predefined threshold, and/or a reporting method, which includes periodic reporting, event-triggered reporting, or one-time immediate reporting (wherein RAN QoE measurements are performed immediately based on the RAN-visible QoE configuration, and reported once); examiner articulates that given the teachings of RAN-visible QoE measurements configuration and an activation configuration for event-triggered reporting in Huawei as well as in ZHANG, it would be obvious that the event or condition occurrence is subsequently detected- i.e. after the RAN-visible QoE configuration; for instance, a first radio resource control message in ZHANG comprises the second QoE measurement configuration and an activation configuration, thus it would be obvious that activation configuration is subsequent to QoE measurement configuration); and
sending to the UE an indication that the at least one event or condition has occurred (see [0008]; method includes generating, by a network node, a quality of experience (QoE) measurement retrieval configuration that configures a wireless device to retrieve QoE measurements that are visible to the network node, transmitting, to the wireless device, a first radio resource control message comprising the QoE measurement retrieval configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of ZHANG with Huawei to subsequently detect the occurrence of the at least one event or condition.
One of ordinary skill in the art would have been motivated so that the reported RAN-visible QoE metrics are visible by RAN and are useful to the RAN node for optimizing QoE (ZHANG: [0042]).
As for Claims 47-49, the claims depend on claim 46, but does not teach or further define over the limitations in claims 38-40 respectively. Therefore, claims 47-49 are rejected for the same reasons as set forth in claims 38-40 respectively.
Regarding claim 51, Huawei (modified by ZHANG) discloses the method of claim 46, as set forth above. ZHANG further discloses wherein:
the occurrence of the at least one event or condition is detected by a first unit of the RAN node (see Fig.3:step 2 in view of [0062]-[0065]; The gNB-CU receives the QoE measurement configuration and decides to activate the RAN-visible QoE);
the indication is sent to the UE by a second unit of the RAN node (see Fig.3:step 5 in view of [0090]; The gNB-CU sends an RRC message to the UE AS layer); and
detecting the occurrence of the at least one event or condition comprises receiving, by the second unit from the first unit, the indication that the at least one event or condition has occurred (see Fig.3:step 3-4 in view of [0088]-[0089]; The gNB-CU sends an F1 Application Protocol (F1AP) message (e.g., UE Context Setup Request or UE Context Modification Request) to the gNB-DU, which includes the QoE measurement configuration and the RAN-visible QoE configuration; The gNB-DU sends an F1AP message (e.g., UE Context Setup Response or UE Context Modification Response) to the gNB-CU with an indication to notify gNB-CU that the DU has received the measurement configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of ZHANG with Huawei so that the occurrence of the at least one event or condition is detected by a first unit of the RAN node; the indication is sent to the UE by a second unit of the RAN node; and detecting the occurrence of the at least one event or condition comprises receiving, by the second unit from the first unit, the indication that the at least one event or condition has occurred.
One of ordinary skill in the art would have been motivated so that the reported RAN-visible QoE metrics are visible by RAN and are useful to the RAN node for optimizing QoE (ZHANG: [0042]).
Regarding claim 52, Huawei (modified by ZHANG) discloses the method of claim 51, as set forth above. ZHANG further discloses sending, by the second unit to the first unit, an RVQoE reporting configuration comprising the at least one event or condition (see Fig.3:step 3-4 in view of [0088]-[0089]; The gNB-CU sends an F1 Application Protocol (F1AP) message (e.g., UE Context Setup Request or UE Context Modification Request) to the gNB-DU, which includes the QoE measurement configuration and the RAN-visible QoE configuration; The gNB-DU sends an F1AP message (e.g., UE Context Setup Response or UE Context Modification Response) to the gNB-CU with an indication to notify gNB-CU that the DU has received the measurement configuration).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of ZHANG with Huawei to send, by the second unit to the first unit, an RVQoE reporting configuration comprising the at least one event or condition.
One of ordinary skill in the art would have been motivated so that the reported RAN-visible QoE metrics are visible by RAN and are useful to the RAN node for optimizing QoE (ZHANG: [0042]).
Regarding claim 53, Huawei (modified by ZHANG) discloses the method of claim 51, as set forth above. ZHANG further discloses wherein the second unit is a centralized unit control plane (CU-CP) (see Fig.3: “gNB-CU”) and one of the following applies:
the first unit is a distributed unit (DU) and the indication received by the second unit from the first unit is an F1 Application Protocol (F1AP) message (see Fig.3:step 3-4 in view of [0088]-[0089]; The gNB-DU sends an F1AP message (e.g., UE Context Setup Response or UE Context Modification Response) to the gNB-CU with an indication to notify gNB-CU that the DU has received the measurement configuration); or
the first unit is a centralized unit user plane (CU-UP) and the indication received by the second unit from the first unit is an El Application Protocol (E1AP) message.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of ZHANG with Huawei so that the second unit is a centralized unit control plane (CU-CP) and one of the following applies: the first unit is a distributed unit (DU) and the indication received by the second unit from the first unit is an F1 Application Protocol (F1AP) message; or the first unit is a centralized unit user plane (CU-UP) and the indication received by the second unit from the first unit is an El Application Protocol (E1AP) message.
One of ordinary skill in the art would have been motivated so that the reported RAN-visible QoE metrics are visible by RAN and are useful to the RAN node for optimizing QoE (ZHANG: [0042]).
Regarding claim 54, Huawei (modified by ZHANG) discloses the method of claim 46, as set forth above. In addition, Huawei further discloses performing one or more of the following based on the received at least one RVQoE report:
managing carrier aggregation (CA) and/or dual connectivity (DC) for the UE;
scheduling and/or link adaptation for data associated with a UE application;
selecting a type of handover or other mobility operation to be performed by the UE;
evaluating a handover or other mobility operation previously performed by the UE (see section 2.3 on pages 6-7; optimize the handover configuration); and
training one or more artificial intelligence/machine learning (AI/ML) models.
As for Claim 56, the claim lists all the same elements of claim 46, but in a radio access network (RAN) node (see page 1: lines 9-11; upon RAN visible QoE measurement activation, UE AS indicates to UE APP that RAN visible QoE measurement has been triggered, potentially with RAN visible QoE metrics needed to be collected at UE APP as requested by RAN) comprising: communication interface circuitry configured to communicate with UEs and with one or more other RAN nodes; and processing circuitry operatively coupled to the communication interface circuitry (see page 1: lines 9-11; inherent components/feature of a RAN node), whereby the processing circuitry and the communication interface circuitry are configured to carry out the steps of claim 46, rather than the method form. Therefore, the supporting rationale of the rejection to claim 46 applies equally as well to claim 56.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Non Patent Literature to Agilent Technologies; "LTE and the Evolution to 4G Wireless: Design and Measurement Challenges, Second Edition"; Chapter 4: Upper Layer Signaling; pages 159-194 (Year: 2013).
Non Patent Literature to Ralf Kreher, 'A Look into 5G Virtual Open RAN - Part 7 Change of gNB-CU-UP without Handover'; Retrieved online on 02/17/2026 from https://blog.3g4g.co.uk/2020/07/a-look-into-5g-virtualopen-ran-part-7.html (Year: 2020).
Johansson et al. (US 20220279385 A1) discloses technique for reporting quality of experience and application layer measurements at high load.
ZHANG et al. (US 20230199543 A1) discloses QoE measurements for RAN.
Liu et al. (US 20220417780 A1) collects and reports QoE information.
HONG (US 20210127293 A1) teaches base station may indicate a status information trigger condition of the IAB node, included in a F1AP.
Hahn et al. (US 10869209 B2) discloses exchanging data with base station.
SHI et al. (US 20200413301 A1) teaches handling of application layer measurements during handover in wireless communication networks.
Conclusion
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 SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453