DETAILED ACTION
Claim(s) 1,3-11 and 13-20 have been examined and are pending.
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 Remarks/Comments
Status of Claims as of the Non-Final Rejection mailed April 23, 2026, the status of the claims was as follows: Claim(s) 1, 2, 3, 4, 9, 11, 12, 13, 14, 19, were rejected under 35 U.S.C. 102(a)(2) as being anticipated by ZHANG (US 20230199543 A1). Claim(s) 5, 6, 7, 8, 10, 15, 16, 17, 18, 20, were rejected under 35 U.S.C. 103 as being unpatentable over ZHANG (US 20230199543 A1) in view of NUGGEHALLI (US 20240414072 A1).
Response to the Non-Final Rejection
In response to the Non-Final Rejection, Applicants have amended each of independent claim(s) 1, 9, and 11, by incorporating features found in either of dependent claim(s) 2 or 12. Claim(s) 2 and 12 have been cancelled. Furthermore, Applicants have presented arguments in light of amendments to the claims. The arguments are addressed below. Claim(s) 1, 3-11, and 13-20 are pending.
Arguments made in response to the rejections of claim(s) 1, 9, and 11 under 35 U.S.C. 102(a)(2) as being anticipated by ZHANG (US 20230199543 A1).
Applicants argue that the prior art of record, ZHANG (US 20230199543 A1) fails to teach or anticipate the features of the independent claim(s) 1, 9, and 11. As previously stated, claims 1, 9, 11, have been amended to incorporate limitations found in the now cancelled claim(s) 2 and 11. Applicants argue that amended claim(s) 1, 9, and 11, overcome the current rejection of said claims under 35 U.S.C. 102(a)(2) as being anticipated by ZHANG (US 20230199543 A1). Regarding claim 1, Applicants argue that ZHANG fails to anticipate claim 1, because ZHANG fails to teach or suggest at least the following limitation (See Remarks, Page(s) 9 - 12),
“1. A method for releasing quality of experience (QoE) configuration, comprising:
receiving QoE configuration release information transmitted by a network side device, wherein the QoE configuration release information comprises a release type parameter…
wherein the determining the target QoE configuration that needs to be released according to the release type parameter, further comprises:
in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determining candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and selecting QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration;
or in a case that the release type parameter comprises a configuration type parameter and a service type parameter, selecting QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter…”
In the Non-Final Rejection, ZHANG [Par. 0187 – Par. 0190] was relied upon to teach the limitation in question. Applicants disagree with this characterization of ZHANG in view of claim 1. Applicants appear to argue that ZHANG does not teach and/or suggest QoE configuration release information further comprising QoE identifier information, a release type parameter comprising a configuration type parameter and/or service type parameter and selecting a QoE configuration corresponding to the release type parameter(s) and/or QoE identifier information. See Remarks [Page(s) 10-11]
“Zhang only mentions the configuration for deactivation can include at least one of a
deactivation indication, a RAN-visible QoE reference identifier, or a service type, but does not
mention how to perform operation when the configuration for deactivation can include two or
more of the deactivation indication, the RAN-visible QoE reference identifier, or the service type.”
In response to the arguments, it is first noted that the Examiner disagrees that ZHANG fails to teach or anticipate amended claim 1, with respect to the limitation(s) in question. ZHANG is at least believed to teach and/or suggest, “… in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determining candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and selecting QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration…”
See where ZHANG recites a release type parameter comprising a configuration type parameter, “RAN-Visible QoE reference identifier”, QoE configuration release information further comprising QoE identifier information, “RAN-Visible QoE reference identifier”, and determining candidate QoE configuration, “RAN-visible QoE reference identifier, indicating the related QoE reference of QoE measurement for RAN-visible QoE”, corresponding to the configuration type parameter from the candidate QoE configuration QoE configuration as the target QoE configuration. The relevant portion of ZHANG is cited below
“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”
Additionally with respect to the interpretation of RAN Visible QoE reference identifier qualifying as a configuration type parameter and as QoE identifier information, note that the Instant Application qualifies the attribute of being “RAN Visible” as a configuration type parameter. See where the Instant Application recites the following:
“[0040] Where, the configuration type parameter can be the first configuration type parameter, for example, the first configuration type can be a QoE configuration type (Traditional QoE) invisible to the network side device, or the first configuration type can be the Traditional QoE and the QoE configuration type (RAN-visible QoE) visible to the network side device.”
Thus, the ZHANG’s “RAN Visible QoE reference identifier” is regarded as conveying both configuration type parameter information and QoE reference identifier information. Thus at least for this reason ZHANG is believed to anticipate with respect to claim 1, a feature
“…wherein the determining the target QoE configuration that needs to be released according to the release type parameter, further comprises:
in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determining candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and selecting QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration…”
Furthermore, ZHANG is further believed to teach with respect to claim 1, a feature for
“…in a case that the release type parameter comprises a configuration type parameter and a service type parameter, selecting QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter…”
See where ZHANG recites a release type parameter comprising a configuration type parameter and a service type parameter, service type, and selecting QoE configuration, deactivating RAN-visible QoE of the specified service, corresponding to the configuration type parameter as the target QoE configuration corresponding to the service type parameter
“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”
Note that a quality of being RAN-visible qualifies as a configuration type parameter, according to the instant application (See, [Par. 40] of the Instant Application cited above), and that ZHANG’s service type, specifies a RAN visible QoE of the specified service, thus ZHANG’s service type is regarded as conveying both service type information and configuration type information. Therefore, ZHANG is regarded as also teaching with respect to claim 1, a feature for “…in a case that the release type parameter comprises a configuration type parameter and a service type parameter, selecting QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter…”.
Finally, regarding the method of claim 1, in the Non-Final Rejection, Applicants were alerted to with respect to contingent claim limitations such as the limitations where the selection of a QoE configuration as the target QoE configuration is contingent upon the release type parameter and/or the QoE configuration release information, (See amended claim 1, where it recites at least, “…in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information…in case that the release type parameter comprises a configuration type parameter and a service type parameter…”) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. …receiving QoE configuration release information transmitted by a network side device, wherein the QoE configuration release information comprises a release type parameter, and the release type parameter is configured to indicate a type of QoE configuration to be released by a terminal determining target QoE configuration that needs to be released according to the release type parameter; and releasing the target QoE configuration…) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016). The amendment does not appear to address the contingent limitations of claim 1. Thus, even if Applicants believe that ZHANG fails to teach the contingent limitations, ZHANG is believed to anticipate claim 1, due to teaching the remaining (non-contingent) limitations of claim 1. Thus, for all the reasons explained ZHANG is believed to anticipate the features of claim 1. Furthermore, with respect to independent claim 9, a method claim reciting substantially the same features as claim 1, claim 9 is believed to be anticipated by ZHANG for substantially the same reasons provided with respect to claim 1. Regarding claim 11, an apparatus/system claim, reciting substantially the same features as claim 1, claim 11 is believed to be anticipated by ZHANG for the reasons explained with respect to claim 1, excluding the issues raised with respect to contingent limitations.
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)(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) 1, 3, 4, 9, 11, 13, 14, 19, is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by ZHANG (US 20230199543 A1)
In regards to claim 1, ZHANG (US 20230199543 A1) teaches a method for releasing quality of experience (QoE) configuration, comprising:
receiving QoE configuration release information transmitted by a network side device, wherein the QoE configuration release information comprises a release type parameter, and the release type parameter is configured to indicate a type of QoE configuration to be released by a terminal determining target QoE configuration that needs to be released according to the release type parameter; and releasing the target QoE configuration (ZHANG teaches a UE receiving QoE configuration release information, QoE measurement deactivation indication, transmitted by a network side device, OAM/CN/NG-RAN node/gNB, wherein the QoE configuration release information comprises a release type parameter (i.e. deactivation indication that indicates QoE and RAN-visible QoE, RAN-visible QoE only, a RAN-visible QoE reference identifier, service type) and the release type parameter is configured to indicate a type of QoE Configuration to be released by a terminal determining target QoE configuration that needs to be released according to the release type parameter, and releasing the target QoE configuration, “[0031] For signaling-based QoE measurement deactivation, the deactivation is configured by OAM and triggered by CN. The CN initiates the deactivation of QoE measurement, as configured by OAM, and sends the deactivation indication to the NG-RAN node. The NG-RAN node sends the deactivation indication to the UE AS layer, which then sends the deactivation indication to the UE application layer. [0032] For management-based QoE measurement, the deactivation is triggered by OAM. OAM sends the deactivation indication to NG-RAN node to indicate which QoE measurement should be deactivated. The NG-RAN node then sends the deactivation indication to the UE AS layer, which sends it to the application layer in UE…[0184] FIG. 6 shows an example timing diagram for the CU deactivating RAN-visible QoE measurements. In some embodiments, as shown in FIG. 6, the following steps are performed: [0185] Step 1: The gNB-CU decides to deactivate the RAN-visible QoE. [0186] Step 1a: Before or after the gNB-CU node decides to deactivate RAN visible QoE, the OAM/CN might send QoE deactivation configuration to gNB-CU, with an indication to deactivate the QoE measurement. [0187] Step 2: The gNB-CU makes the decision to deactivate and assembles the configuration for deactivation, which can include at least one of the following: [0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service. [0191] Step 3: The gNB-CU sends an F1AP message (e.g., UE Context Modification Request) to the gNB-DU with the deactivation configuration generated in Step 2. [0192] Step 4: The gNB-DU releases the related QoE configuration based on the received deactivation configuration. [0193] Step 5: The gNB-DU sends an F1AP message (e.g., UE Context Modification Response) to the gNB-CU with an indication to notify the gNB-CU that the DU has released the related configuration based on the deactivation configuration.
[0194] Step 6: gNB-CU sends RRC message to the UE with the deactivation configuration. [0195] Step 7: The UE AS layer sends the deactivation configuration to the UE application layer. The UE deletes the specified RAN-visible QoE measurement and/or QoE measurement configuration, and permanently stops the specified RAN-visible QoE and/or QoE.”) wherein the determining the target QoE configuration that needs to be released according to the release type parameter, further comprises:
in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determining candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and selecting QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
or in a case that the release type parameter comprises a configuration type parameter and a service type parameter, selecting QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”. Note that with respect to contingent limitation(s) recited in the method of claim 2 (i.e. selecting of the QoE configuration being contingent upon particular conditions, such release type parameter being of a particular type such as service type and/or configuration type) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 1) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016). );
In regards to claim 11, ZHANG (US 20230199543 A1) teaches a terminal, comprising: a memory, a processor, and a transceiver; wherein: the memory is configured to store computer programs; the transceiver is configured to transmit and receive data under a control of the processor; the processor is configured to read the computer programs in the memory and perform the following operations (ZHANG teaches a terminal, UE, , comprising: a memory, a processor, and a transceiver; wherein: the memory is configured to store computer programs; the transceiver is configured to transmit and receive data under a control of the processor; the processor is configured to read the computer programs in the memory and perform the following operations “[0343] 32. A wireless communications apparatus comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement a method recited in any of solutions 1 to 31...[0345] FIG. 18 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 1805, such as a base station or a wireless device (or UE), can include processor electronics 1810 such as a microprocessor that implements one or more of the techniques presented in this document. The apparatus 1805 can include transceiver electronics 1815 to send and/or receive wireless signals over one or more communication interfaces such as antenna(s) 1820. The apparatus 1805 can include other communication interfaces for transmitting and receiving data. Apparatus 1805 can include one or more memories (not explicitly shown) configured to store information such as data and/or instructions. In some implementations, the processor electronics 1810 can include at least a portion of the transceiver electronics 1815. In some embodiments, at least some of the disclosed techniques, modules or functions are implemented using the apparatus 1805.”):
receiving quality of experience (QoE)configuration release information transmitted by a network side device, wherein the QoE configuration release information comprises a release type parameter, and the release type parameter is configured to indicate a type of QoE configuration to be released by a terminal;
determining target QoE configuration that needs to be released according to the release type parameter; and releasing the target QoE configuration (ZHANG teaches a UE receiving QoE configuration release information, QoE measurement deactivation indication, transmitted by a network side device, OAM/CN/NG-RAN node/gNB, wherein the QoE configuration release information comprises a release type parameter (i.e. deactivation indication that indicates QoE and RAN-visible QoE, RAN-visible QoE only, a RAN-visible QoE reference identifier, service type) and the release type parameter is configured to indicate a type of QoE Configuration to be released by a terminal determining target QoE configuration that needs to be released according to the release type parameter, and releasing the target QoE configuration, “[0031] For signaling-based QoE measurement deactivation, the deactivation is configured by OAM and triggered by CN. The CN initiates the deactivation of QoE measurement, as configured by OAM, and sends the deactivation indication to the NG-RAN node. The NG-RAN node sends the deactivation indication to the UE AS layer, which then sends the deactivation indication to the UE application layer. [0032] For management-based QoE measurement, the deactivation is triggered by OAM. OAM sends the deactivation indication to NG-RAN node to indicate which QoE measurement should be deactivated. The NG-RAN node then sends the deactivation indication to the UE AS layer, which sends it to the application layer in UE…[0184] FIG. 6 shows an example timing diagram for the CU deactivating RAN-visible QoE measurements. In some embodiments, as shown in FIG. 6, the following steps are performed: [0185] Step 1: The gNB-CU decides to deactivate the RAN-visible QoE. [0186] Step 1a: Before or after the gNB-CU node decides to deactivate RAN visible QoE, the OAM/CN might send QoE deactivation configuration to gNB-CU, with an indication to deactivate the QoE measurement. [0187] Step 2: The gNB-CU makes the decision to deactivate and assembles the configuration for deactivation, which can include at least one of the following: [0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service. [0191] Step 3: The gNB-CU sends an F1AP message (e.g., UE Context Modification Request) to the gNB-DU with the deactivation configuration generated in Step 2. [0192] Step 4: The gNB-DU releases the related QoE configuration based on the received deactivation configuration. [0193] Step 5: The gNB-DU sends an F1AP message (e.g., UE Context Modification Response) to the gNB-CU with an indication to notify the gNB-CU that the DU has released the related configuration based on the deactivation configuration.
[0194] Step 6: gNB-CU sends RRC message to the UE with the deactivation configuration. [0195] Step 7: The UE AS layer sends the deactivation configuration to the UE application layer. The UE deletes the specified RAN-visible QoE measurement and/or QoE measurement configuration, and permanently stops the specified RAN-visible QoE and/or QoE.”) wherein the processor is further configured to:
in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determine candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and select QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
or in a case that the release type parameter comprises a configuration type parameter and a service type parameter, select QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”.);
In regards to claim 9, ZHANG (US 20230199543 A1) teaches a method for releasing quality of experience (QoE) configuration, comprising: generating QoE configuration release information comprising a release type parameter after determining that a terminal needs to release the QoE configuration; wherein the release type parameter is configured to indicate a type of QoE configuration to be released by the terminal; transmitting the QoE configuration release information to the terminal (ZHANG teaches a network device (i.e. OAM/CN/NG-RAN node/gNB) , generating, QoE configuration release information, QoE measurement deactivation indication, after determining that the terminal needs to release the QoE configuration; wherein the QoE configuration release information comprises a release type parameter (i.e. deactivation indication that indicates QoE and RAN-visible QoE, RAN-visible QoE only, a RAN-visible QoE reference identifier, service type) and the release type parameter is configured to indicate a type of QoE Configuration to be released by a terminal, UE; Zhang further teaches transmitting the QoE Configuration release information to the UE, “[0031] For signaling-based QoE measurement deactivation, the deactivation is configured by OAM and triggered by CN. The CN initiates the deactivation of QoE measurement, as configured by OAM, and sends the deactivation indication to the NG-RAN node. The NG-RAN node sends the deactivation indication to the UE AS layer, which then sends the deactivation indication to the UE application layer. [0032] For management-based QoE measurement, the deactivation is triggered by OAM. OAM sends the deactivation indication to NG-RAN node to indicate which QoE measurement should be deactivated. The NG-RAN node then sends the deactivation indication to the UE AS layer, which sends it to the application layer in UE…[0184] FIG. 6 shows an example timing diagram for the CU deactivating RAN-visible QoE measurements. In some embodiments, as shown in FIG. 6, the following steps are performed: [0185] Step 1: The gNB-CU decides to deactivate the RAN-visible QoE. [0186] Step 1a: Before or after the gNB-CU node decides to deactivate RAN visible QoE, the OAM/CN might send QoE deactivation configuration to gNB-CU, with an indication to deactivate the QoE measurement. [0187] Step 2: The gNB-CU makes the decision to deactivate and assembles the configuration for deactivation, which can include at least one of the following: [0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service. [0191] Step 3: The gNB-CU sends an F1AP message (e.g., UE Context Modification Request) to the gNB-DU with the deactivation configuration generated in Step 2. [0192] Step 4: The gNB-DU releases the related QoE configuration based on the received deactivation configuration. [0193] Step 5: The gNB-DU sends an F1AP message (e.g., UE Context Modification Response) to the gNB-CU with an indication to notify the gNB-CU that the DU has released the related configuration based on the deactivation configuration.
[0194] Step 6: gNB-CU sends RRC message to the UE with the deactivation configuration. [0195] Step 7: The UE AS layer sends the deactivation configuration to the UE application layer. The UE deletes the specified RAN-visible QoE measurement and/or QoE measurement configuration, and permanently stops the specified RAN-visible QoE and/or QoE.”) and in a case that the release type parameter comprises a configuration type parameter, and the QoE configuration release information further comprises QoE identifier information, determining candidate QoE configuration corresponding to the QoE identifier information according to the QoE identifier information, and selecting QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
or in a case that the release type parameter comprises a configuration type parameter and a service type parameter, selecting QoE configuration corresponding to the configuration type parameter as the target QoE configuration from QoE configuration corresponding to the service type parameter (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”. Note that with respect to contingent limitation(s) recited in the method of claim 2 (i.e. selecting of the QoE configuration being contingent upon particular conditions, such release type parameter being of a particular type such as service type and/or configuration type) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 1) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016). );
In regards to claim 19, ZHANG (US 20230199543 A1) teaches a network side device, comprising: a memory, a processor, and a transceiver; wherein: the memory is configured to store computer programs; the transceiver is configured to transmit and receive data under the control of the processor (ZHANG teaches a network side device, base station/gNB/NG-RAN node, comprising: a memory, a processor, and a transceiver; wherein: the memory is configured to store computer programs; the transceiver is configured to transmit and receive data under a control of the processor; the processor is configured to read the computer programs in the memory and perform the method according to claim 9. “[0343] 32. A wireless communications apparatus comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement a method recited in any of solutions 1 to 31...[0345] FIG. 18 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 1805, such as a base station or a wireless device (or UE), can include processor electronics 1810 such as a microprocessor that implements one or more of the techniques presented in this document. The apparatus 1805 can include transceiver electronics 1815 to send and/or receive wireless signals over one or more communication interfaces such as antenna(s) 1820. The apparatus 1805 can include other communication interfaces for transmitting and receiving data. Apparatus 1805 can include one or more memories (not explicitly shown) configured to store information such as data and/or instructions. In some implementations, the processor electronics 1810 can include at least a portion of the transceiver electronics 1815. In some embodiments, at least some of the disclosed techniques, modules or functions are implemented using the apparatus 1805.”); the processor is configured to read the computer programs in the memory and perform the method according to claim 9 (ZHANG teaches a network device (i.e. OAM/CN/NG-RAN node/gNB/base station) , generating, QoE configuration release information, QoE measurement deactivation indication, after determining that the terminal needs to release the QoE configuration; wherein the QoE configuration release information comprises a release type parameter (i.e. deactivation indication that indicates QoE and RAN-visible QoE, RAN-visible QoE only, a RAN-visible QoE reference identifier, service type) and the release type parameter is configured to indicate a type of QoE Configuration to be released by a terminal, UE; Zhang further teaches transmitting the QoE Configuration release information to the UE, “[0031] For signaling-based QoE measurement deactivation, the deactivation is configured by OAM and triggered by CN. The CN initiates the deactivation of QoE measurement, as configured by OAM, and sends the deactivation indication to the NG-RAN node. The NG-RAN node sends the deactivation indication to the UE AS layer, which then sends the deactivation indication to the UE application layer. [0032] For management-based QoE measurement, the deactivation is triggered by OAM. OAM sends the deactivation indication to NG-RAN node to indicate which QoE measurement should be deactivated. The NG-RAN node then sends the deactivation indication to the UE AS layer, which sends it to the application layer in UE…[0184] FIG. 6 shows an example timing diagram for the CU deactivating RAN-visible QoE measurements. In some embodiments, as shown in FIG. 6, the following steps are performed: [0185] Step 1: The gNB-CU decides to deactivate the RAN-visible QoE. [0186] Step 1a: Before or after the gNB-CU node decides to deactivate RAN visible QoE, the OAM/CN might send QoE deactivation configuration to gNB-CU, with an indication to deactivate the QoE measurement. [0187] Step 2: The gNB-CU makes the decision to deactivate and assembles the configuration for deactivation, which can include at least one of the following: [0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service. [0191] Step 3: The gNB-CU sends an F1AP message (e.g., UE Context Modification Request) to the gNB-DU with the deactivation configuration generated in Step 2. [0192] Step 4: The gNB-DU releases the related QoE configuration based on the received deactivation configuration. [0193] Step 5: The gNB-DU sends an F1AP message (e.g., UE Context Modification Response) to the gNB-CU with an indication to notify the gNB-CU that the DU has released the related configuration based on the deactivation configuration.
[0194] Step 6: gNB-CU sends RRC message to the UE with the deactivation configuration. [0195] Step 7: The UE AS layer sends the deactivation configuration to the UE application layer. The UE deletes the specified RAN-visible QoE measurement and/or QoE measurement configuration, and permanently stops the specified RAN-visible QoE and/or QoE.”)
In regards to claim 3, ZHANG (US 20230199543 A1) teaches the method according to claim 1, wherein the selecting the QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration, comprises:
in a case that the configuration type parameter is a first configuration type parameter, using all QoE configuration in the candidate QoE configuration as the target QoE configuration;
in a case that the configuration type parameter is a second configuration type parameter, selecting QoE configuration visible to the network side device from the candidate QoE configuration as the target QoE configuration (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
In regards to claim 13, ZHANG (US 20230199543 A1) teaches the terminal according to claim 11,
wherein, in a case that selecting the QoE configuration corresponding to the configuration type parameter from the candidate QoE configuration as the target QoE configuration, the processor is further configured to: in a case that the configuration type parameter is a first configuration type parameter, use all QoE configuration in the candidate QoE configuration as the target QoE configuration;
in a case that the configuration type parameter is a second configuration type parameter, select QoE configuration visible to the network side device from the candidate QoE configuration as the target QoE configuration (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
In regards to claim 4, ZHANG (US 20230199543 A1) teaches the method according to claim 1, wherein the selecting the QoE configuration corresponding to the configuration type parameter as the target QoE configuration from the QoE configuration corresponding to the service type parameter, comprises:
in a case that the configuration type parameter is a first configuration type parameter, using all QoE configuration corresponding to the service type parameter as the target QoE configuration;
in a case that the configuration type parameter is a second configuration type parameter, selecting QoE configuration visible to the network side device as the target QoE configuration from QoE configuration corresponding to the service type parameter (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service” Note that with respect to contingent limitation(s) recited in the method of claim 4 (i.e. use of a particular QoE configuration being contingent upon particular conditions, such as type of configuration type parameter) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 1) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016). );
In regards to claim 14, ZHANG (US 20230199543 A1) teaches the terminal according to claim 11, wherein, in a case that selecting the QoE configuration corresponding to the configuration type parameter as the target QoE configuration from the QoE configuration corresponding to the service type parameter, the processor is further configured to:
in a case that the configuration type parameter is a first configuration type parameter, use all QoE configuration corresponding to the service type parameter as the target QoE configuration;
in a case that the configuration type parameter is a second configuration type parameter, select QoE configuration visible to the network side device as the target QoE configuration from QoE configuration corresponding to the service type parameter (“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 5, 6, 7, 8, 10, 15, 16, 17, 18, 20, is/are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG (US 20230199543 A1) in view of NUGGEHALLI (US 20240414072 A1).
In regards to claim 5, ZHANG is silent on the method according to claim 1, wherein the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the method according to claim 1, wherein the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 15, ZHANG is silent on the terminal according to claim 11, wherein the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; the processor is further configured to: determine a release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; release the target QoE configuration after the release timing is reached. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the terminal according to claim 11, wherein the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; the processor is further configured to: determine a release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; release the target QoE configuration after the release timing is reached, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 6, ZHANG is silent on the method according to claim 5, wherein the determining the release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information, further comprises: in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, using a current moment as the release timing for releasing the target QoE configuration;
in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal (Note that with respect to contingent limitation(s) recited in the method of claim 6 (i.e. determining of a particular release timing being contingent upon particular conditions, such as the release reason) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 5) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016).). Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the method according to claim 5, wherein the determining the release timing for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information, further comprises: in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, using a current moment as the release timing for releasing the target QoE configuration; in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 16, ZHANG is silent on the terminal according to claim 15, wherein the processor is further configured to: in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, use a current moment as the release timing for releasing the target QoE configuration;
in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, determine the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the terminal according to claim 15, wherein the processor is further configured to: in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, use a current moment as the release timing for releasing the target QoE configuration; in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, determine the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 7, ZHANG is silent on the method according to claim 6, wherein the determining the release timing for releasing the target QoE configuration according to the current QoE measurement state of the terminal further comprises:
in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration;
in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration (Note that with respect to contingent limitation(s) recited in the method of claim 7 (i.e. determining of a particular release timing being contingent upon particular conditions, such as the current QoE measurement state of the terminal) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 5) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016)). Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. NUGGEHALLI further teaches in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration; and in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the method according to claim 6, wherein the determining the release timing for releasing the target QoE configuration according to the current QoE measurement state of the terminal further comprises: in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration; in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 17, ZHANG is silent on the terminal according to claim 16, wherein the processor is further configured to: in a case that the current QoE measurement state of the terminal that no QoE measurement is being performed, use a current moment as the release timing for releasing the target QoE configuration; in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determine a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. NUGGEHALLI further teaches in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration; and in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the terminal according to claim 16, wherein the processor is further configured to: in a case that the current QoE measurement state of the terminal that no QoE measurement is being performed, use a current moment as the release timing for releasing the target QoE configuration; in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determine a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 8, ZHANG is silent on the method according to claim 7, wherein, in a case that the moment at which the QoE measurement ends is as the release timing for releasing the target QoE configuration, the method further comprises:
in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, reporting a QoE measurement report to the target network side device;
in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration does not support reporting of measurement reports, storing a QoE measurement report; after the terminal accesses a network side device that supports reporting of measurement reports, reporting the QoE measurement report to the network side device that supports reporting of measurement reports;
or, in a case that the terminal accesses a network side node, that supports reporting of measurement reports, within a preset period of time, reporting the QoE measurement report to a network side device that supports reporting of measurement reports, otherwise, deleting the QoE measurement report (Note that with respect to contingent limitation(s) recited in the method of claim 8 (i.e. reporting of the measurement report being contingent upon particular conditions, such as a network device either supporting a measurement reprot) that the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed (i.e. the steps of parent claim 5) and does not include steps that are not required to be performed because the condition(s) precedent are not met. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016)). Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. NUGGEHALLI further teaches in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration; and in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”). NUGGEHALLI further suggests in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, reporting a QoE measurement report to the target network side device (“[0036] During a UE handover from a source gNB to a target gNB that supports QoE, the target gNB may decide which QoE configurations to keep and which to release, e.g., based on QoE configuration information received from the source gNB in an RRC container via Xn/Ng signaling. It is noted that the QMC configuration release can be used by the gNB to stop QoE measurement collection and reporting, even in the middle of an application session.”);
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the method according to claim 7, wherein, in a case that the moment at which the QoE measurement ends is as the release timing for releasing the target QoE configuration, the method further comprises: in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, reporting a QoE measurement report to the target network side device; in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration does not support reporting of measurement reports, storing a QoE measurement report; after the terminal accesses a network side device that supports reporting of measurement reports, reporting the QoE measurement report to the network side device that supports reporting of measurement reports; or, in a case that the terminal accesses a network side node, that supports reporting of measurement reports, within a preset period of time, reporting the QoE measurement report to a network side device that supports reporting of measurement reports, otherwise, deleting the QoE measurement report, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 18, ZHANG is silent on the terminal according to claim 17, wherein, in a case that the moment at which the QoE measurement ends is as the release timing for releasing the target QoE configuration, the processor is further configured to: in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, report a QoE measurement report to the target network side device; in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration does not support reporting of measurement reports, store a QoE measurement report; after the terminal accesses a network side device that supports reporting of measurement reports, report the QoE measurement report to the network side device that supports reporting of measurement reports; or, in a case that the terminal accesses a network side node that supports reporting of measurement reports within a preset period of time, report the QoE measurement report to a network side device that supports reporting of measurement reports, otherwise, delete the QoE measurement report. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached. NUGGEHALLI further teaches in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is normal release, core network deactivation, using a current moment as the release timing for releasing the target QoE configuration and in a case that the release reason parameter indicates that a reason for releasing the QoE configuration is that the terminal moves out of an effective range of the QoE configuration, out-area condition, determining the release timing for releasing the target QoE configuration according to a current QoE measurement state of the terminal. NUGGEHALLI further teaches in a case that the current QoE measurement state of the terminal is that no QoE measurement is being performed, using a current moment as the release timing for releasing the target QoE configuration; and in a case that the current QoE measurement state of the terminal is that QoE measurement is being performed, determining a moment at which a QoE measurement ends as the release timing for releasing the target QoE configuration. (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”). NUGGEHALLI further suggests in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, reporting a QoE measurement report to the target network side device (“[0036] During a UE handover from a source gNB to a target gNB that supports QoE, the target gNB may decide which QoE configurations to keep and which to release, e.g., based on QoE configuration information received from the source gNB in an RRC container via Xn/Ng signaling. It is noted that the QMC configuration release can be used by the gNB to stop QoE measurement collection and reporting, even in the middle of an application session.”);
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the terminal according to claim 17, wherein, in a case that the moment at which the QoE measurement ends is as the release timing for releasing the target QoE configuration, the processor is further configured to: in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration supports reporting of measurement reports, report a QoE measurement report to the target network side device; in a case that a target network side device accessed by the terminal after the terminal moves out of the effective range of the QoE configuration does not support reporting of measurement reports, store a QoE measurement report; after the terminal accesses a network side device that supports reporting of measurement reports, report the QoE measurement report to the network side device that supports reporting of measurement reports; or, in a case that the terminal accesses a network side node that supports reporting of measurement reports within a preset period of time, report the QoE measurement report to a network side device that supports reporting of measurement reports, otherwise, delete the QoE measurement report, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 10, ZHANG teaches the method according to claim 9, wherein the release type parameter comprises a configuration type parameter and/or a service type parameter, a(“[0188] a deactivation indication, which indicates the deactivation of both QoE and RAN-visible QoE, or to deactivate the RAN-visible QoE only; [0189] a RAN-visible QoE reference identifier, indicating the related QoE reference of a QoE measurement for RAN-visible QoE; or [0190] a service type, to deactivate the RAN-visible QoE of the specified service”);
ZHANG differs from claim 10, in that ZHANG is silent on where the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; ZHANG additionally differs from claim 10, in that ZHANG is silent on transmitting the QoE configuration release information comprising the release reason parameter to the terminal, wherein the release reason parameter is configured to indicate the terminal to determine a release timing of the target QoE configuration according to the release reason parameter. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the method according to claim 9, wherein the release type parameter comprises a configuration type parameter and/or a service type parameter, and the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; wherein the transmitting the QoE configuration release information to the terminal, further comprises: transmitting the QoE configuration release information comprising the release type parameter and the release reason parameter to the terminal; wherein the release reason parameter is configured to indicate the terminal to determine a release timing of the target QoE configuration according to the release reason parameter, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
In regards to claim 20, ZHANG teaches the network side device according to claim 19, wherein the release type parameter comprises a configuration type parameter and/or a service type parameter, and ZHANG differs from claim 20, in that ZHANG is silent on where the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; ZHANG additionally differs from claim 20, in that ZHANG is silent on transmitting the QoE configuration release information comprising the release reason parameter to the terminal, wherein the release reason parameter is configured to indicate the terminal to determine a release timing of the target QoE configuration according to the release reason parameter. Despite these differences similar features have been seen in other prior art involving the management of a Quality of Experience (QoE) configuration.
NUGGEHALLI (US 20240414072 A1) teaches wherein a QoE configuration release information further comprises a release reason parameter, out of area or core network deactivation, for indicating a reason for releasing the QoE configuration; wherein the releasing the target QoE configuration further comprises: determining a release timing, promptly or after an ongoing session, for releasing the target QoE configuration according to the release reason parameter comprised in the QoE configuration release information; releasing the target QoE configuration after the release timing is reached (“[0044] The UE, upon receiving the deactivation command, checks the indication to determine whether the deactivation is due to the out-of-area condition or not. If the UE has a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE does not deactivate the QoE measurements until the session ends. If the UE does not have a currently active QoE measurement session, and the indication indicates the out-of-area condition, then the UE promptly deactivates the QoE measurements. If the indication does not indicate the out-of-area condition (e.g., the indication indicates that core network deactivation), then the UE promptly deactivates the QoE measurements, regardless of whether the UE has a currently active QoE measurement session or not.”).
Thus based upon the teachings of NUGGEHALLI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the QoE configuration release feature of WANG, to arrive at the network side device according to claim 19, wherein the release type parameter comprises a configuration type parameter and/or a service type parameter, and the QoE configuration release information further comprises a release reason parameter for indicating a reason for releasing the QoE configuration; the processor is further configured to: transmit the QoE configuration release information comprising the release type parameter and the release reason parameter to the terminal; wherein the release reason parameter is configured to indicate the terminal to determine a release timing of the target QoE configuration according to the release reason parameter, in order to provide a benefit of session continuity for a QoE measurement configuration during an out-of-area scenario.
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 TARELL A HAMPTON whose telephone number is (571)270-7162. The examiner can normally be reached 9:00 AM - 5:00 PM.
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, Ayaz Sheikh can be reached at 5712723795. 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.
/TARELL A HAMPTON/Examiner, Art Unit 2476 /AYAZ R SHEIKH/Supervisory Patent Examiner, Art Unit 2476
Prosecution Insights