DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 9/22/2025, 12/02/2025, and 01/07/2026 was filed after the mailing date of the Final Office Action on 08/25/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/07/2026 has been entered.
Response to Amendment
The amendment to the claims filed on 01/07/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered.
Response to Arguments
Applicant's Arguments/Remarks filed 01/07/2026 (hereinafter Resp.) are hereby fully considered.
Applicant argues that “Hu does not disclose or suggest that a first apparatus at the terminal device receives a QMC activation message comprising a QoE configuration from a network manager at a network device nor that the first apparatus at the terminal device generates a unique, second identity associated with the QoE configuration of the service and provides the same to a second apparatus, the second apparatus also being at the terminal device” – See Resp., 15:¶4. However, as further explained in the §112 rejection below, the present disclosure neither discloses or suggests that a first apparatus at the terminal device receives a QMC activation message comprising a QoE configuration from a network manager. Just like Fig. 3 of Hu, U.S. Patent Application Publication No. US 2023/0379743 (hereinafter Hu), the present disclosure teaches, in Fig. 2, that a QMC activation message comprising a QoE configuration from a network manager is received by a second device, e.g. a network access device. Hu, in Fig. 3, also teaches the “AS of the UE,” i.e., the RRC layer, as a first apparatus at the terminal device, and the “Upper layer of an AS of the UE,” i.e., the application layer, as a second apparatus at the terminal device, just like the ones shown in Fig. 2 of the present disclosure and explained in [¶0041] of the Specification (stating: “The first device 110-1 comprises a first apparatus 210 which is implemented at the AS layer or at the RRC layer. The first device 110-1 also comprises a second apparatus 220 which is implemented at the application layer”)(emphasis added). Furthermore, the AS layer of the terminal device in Hu, i.e., the first apparatus, distinguishes different QoE measurement configurations sent to the upper layer of the AS, i.e., the second apparatus, based on “user identities” (second identity) generated at the AS layer, i.e., the first apparatus – See, e.g., [¶0038] (“a quality of experience measurement method is provided, including: An upper layer of an access stratum AS of a terminal device receives first application layer measurement from an AS of the terminal device, where the first application layer measurement corresponds to a first user identity. An upper layer of the AS receives second application layer measurement from the AS, where the second application layer measurement corresponds to a second user identity”); see also [¶0195](“A scenario in which a terminal device supports two SIMS is also referred to as supporting two user identities by the terminal device,” i.e., the second identity is generated by the lower layers of the terminal device). Thus, Applicant’s argument regarding Hu’s support of the claimed limitations is unpersuasive.
Applicant also argues that “Hu fails to disclose or suggest that when the first apparatus at the terminal device receives the QoE measurements from the second apparatus at the terminal device, the first apparatus determines whether to provide the QoE measurements in the uplink direction to the network-side and an identity of the particular network device to which to provide the QoE report based on the second identity received with the QoE measurements from the second apparatus at the terminal device” – See Resp., 15-16. Examiner respectfully disagrees and points to Figs. 5 and 10 of Hu showing two network-side devices, RAN1 and RAN2, whereby the identity of each network-side device to which to provide the QoE report is based on the second identity, i.e., a user identity, received with the QoE measurements from the second apparatus at the terminal device; see also [¶0190] (“The AS of the UE sends the application layer measurement result and the corresponding service type to the RAN. For example, the information is carried in a sent uplink RRC message”). To be sure, the most that the present disclosure teaches about the second identity is in [¶0090] (stating: “the second identity is a radio resource control (RRC) identity, or the second identity is generated based on the first identity and other identity information”). Therefore, this argument is also unpersuasive.
Applicant further argues at length against Liu, U.S. Patent Application Publication No. 2024/0107358 (hereinafter Liu) – See Resp, 16-19, when Liu is a reference that was used only in the alternative. Applicant’s main argument is that the second identity is determined at a network access device – See Resp., 17-18. However, Applicant fails to notice that the first apparatus at the terminal device, i.e., the UE Access Stratum/RRC layer in Fig. 5 of Liu, must determine, e.g., “ascertain,” (in a reasonable interpretation1 of the required limitation “determining, by the first apparatus at the terminal device”) the second identity from the QoE measurement collection configuration information received in the RRCConnectionReconfiguration message. This operation is inherently necessary because:
(1) “The +CAPPLEVMC sent by the UE AS layer to the APP layer contains” information extracted from the RRC message i.e., “the second identity information (RRC level ID), a service type and a QMC configuration file” whereby this information must be organized in a different message, specifically an AT command2 sent to the App layer, i.e., the second apparatus – See [¶0104]; and
(2) after “[t]he APP layer sends+CAPPLEVMR including the second identity information and a QoE measurement report to the UE AS layer” also in a AT command, – See [¶0105] the AS layer, i.e., the first apparatus, uses the second identity to send the QoE measurement report to the network device – See [¶0106] (stating: “The second identity information and the QoE measurement report are sent by the AS layer to the gNB through the measurement report information”)(cited at Resp.,18:¶2)
To be noted that the requirement of the claimed invention is for the first apparatus to “determine” the second identity, not to “generate” the second identity. In addition, the second step above is a reasonable interpretation of the claimed limitation “the QoE report is to be forwarded to the NM at the network device based on the second identity.”
Therefore, the argument regarding the first apparatus in Liu not determining the second identity based on a first identity, e.g., the QoE Reference Id known in the art, and not sending the QoE report to the network device based on the second identity is also unpersuasive. Another argument against Liu as not being combinable 3GPP QoE Features infra because “Liu is expressly focused on handover, meaning that it is expressly focused on mobility aspects” and 3GPP QoE Features “expressly excludes mobility aspects” – Resp., 20:¶3 is without merit simply because Liu was not referenced in the previous Office action for the handover embodiment exemplified in Fig. 6 and [¶0112] et seq.. In addition, a person of ordinary skills in the art would appreciate that an embodiment, in the main reference, combining handover with a QMC task, teaches additional QoE features, distinguishable from those taught by a secondary reference that does not address handover.
Applicant also cites at length the content of 3GPP TSG-RAN WG1 Meeting #115, Title: "Feature summary for 8.14.2.1", Source: Ericsson, August, 2021 (hereinafter 3GPP QoE Features) – See Resp., 20-21, but fails to explain how “3GPP QoE Features fails to cure any of the deficiencies of Hu and likewise fails to cure any of the deficiencies of Liu” – See Resp.,22:¶1. Therefore, Applicant's argument regarding 3GPP QoE Features do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the reference.
Applicant comes back to the Hu reference to make an argument about “the claim element ‘receiving, by the first apparatus, from a network device, a radio resource control (RRC) configuration, the RRC configuration indicating a first identity generated by the network device in an RRC layer, the RRC configuration further indicating a quality of experience (QoE) configuration of a service, wherein the first identity comprises an RRC identifier’” – See Resp., 22:¶3. However, there is no such “claim element” among the claims in the Amendment. Hence, in response to applicant's argument that the reference Hu fails to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the presented claims. 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). Therefore, this argument fails to persuade.
Applicant also argues that “Hu fails to disclose or suggest . . . ‘determining, by the first apparatus, based at least in part on the first identity indicated in the RRC configuration, a second identity associated with the QoE configuration of the service ‘. . . because no mapping between identities is described in Hu” – See Resp., 22:¶4 (emphasis added). However, a person of ordinary skills in the art would appreciate just by glancing at Fig. 10 of Hu that a mapping between the QoE measurement configuration and the second identity, e.g., the SIM identity, must exists at the AS layer of the terminal device because one the one hand “[t]he QoE measurement configuration information includes application layer measurement configuration information” and “the RAN determines to send the QoE measurement configuration information to UE” – See [¶0156], hence the terminal device identifies the QoE measurement configuration information with a first identifier, e.g., the unique QoE measurement Reference Id known in the art or the service type; and, on the other hand “the access stratum of the terminal determines, according to application layer measurement received with the connection corresponding to the SIM1,” i.e., based on the mapping between the second identity–SIM1– and the first identity–service type–“the service type and/or the measurement type corresponding to the application layer measurement configuration that can be received by the terminal device with the connection corresponding to the SIM2,”– See [¶0276], i.e., after mapping the second identity SIM2 to a first identity of the application layer measurement configuration, e.g. the service type, the terminal AS determines that “if the SIM1 has configured application layer measurement corresponding to the first service type, the SIM2 cannot or is prohibited from configuring application layer measurement corresponding to the first service type, or the SIM2 may configure application layer measurement corresponding to a service type other than the first service type” – See [¶0278]. A person of ordinary skills in eth art would appreciate that such determination at the terminal AS layer, i.e., the first apparatus is not possible without mapping each SIM, i.e., each second identity value, to its corresponding the application layer measurement configuration identifier, i.e., the first identity, be it the “globally unique” identifier “MCC+MNC+QMC ID . . . used to identify the QoE measurement collection job in the traffic nodes and in the measurement collection centre,” disclosed in 3GPP TSG-RAN WG2 Meeting #115-e, R2-2107380, Title:” 8.14.2.1-Discussion on NR QoE configuration,” Source: CATT, August 2021, (hereinafter 3GPP R2-21073803) or just the service type.
Therefore, Applicant’s argument that “Hu fails to cure the combined and overlapping deficiencies of Liu and 3GPP QoE Features because Hu focuses on multi-SIM QoE measurement and does not address identity mapping or internal apparatus communication whatsoever” – See Resp., 25:¶1 fails flat particularly when Hu discloses that “the ASs corresponding to the SIMI and the SIM2 are a same entity or module, and there is no interaction between the two SIMs, and the SIM2 may learn the configuration status of application layer measurement of the SIM1 through internal processing” – See [¶0272](emphasis added).
The last argument, regarding 3GPP R2-2107380, is addressed in Footnote 3 and will not be repeated here.
In sum, all Applicant’s arguments have been fully addressed but they are unpersuasive and do not clearly explain how the Amendment to the claims distinguish from the references cited in the previous Office action.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claim 1, 8, 12, 18 and their dependent claims are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Regarding Claim 1, the claim language now requires “receiving, by the first apparatus at the terminal device, from a network manager (NM) at a network device, . . . a radio resource control (RRC) configuration” and “transmitting, by the first apparatus at the terminal device, to the NM at the network device, with the first identity indicated by the RRC configuration, the QoE report of the service.” These two limitations do not have proper support in the present disclosure.
First, the only support for a “network manager” or a “management system” in the Specification of Application 18/045,637 is in [¶0034] (stating “QoE reference ID may be used to identify the QoE measurement collection job in the traffic nodes and in the measurement collection center” so “it’s supposed to link QMC request/configuration from a management system (for example, a network manager (NM)) to gNB,”) corresponding to WO 2023/0652714, [¶0033], and in Fig. 2, further described in Spec. [¶¶0041-42]. It is made clear by [¶¶0041-42] that the NM230 is part of “other core network entities,” connected to a second device, e.g., a base station, and that this second device–not the first apparatus at the terminal device user terminal–receives the claimed “quality of experience (OoE) measurement collection (OMC) activation message” – See [¶0042] (“The NM 230 can transmit 2005 the QMC activation message to the second device 120”). Furthermore, the first apparatus at the terminal device user terminal receives the claimed “radio resource control (RRC) configuration” from this second device, not from the NM – See [¶0043] (“second device 120 may generate 2010 a RRC configuration based on the received QMC activation message”) and Fig. 2. To be sure, there is no intimation in the disclosure that the second device, e.g., an access network device, comprises the NM, i.e., a core network entity – See, e.g., Fig. 2 and [¶0029] (stating “the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP), which is part of the core network”).
Second, the Specification clearly acknowledges the distinction between management-based and signaling-based QoE measurement activation, collection and reporting – See, e.g., [¶0032]. In particular, as described in 3GPP TR 38.890 V17.0.0 (2021-04), “Technical Specification Group Radio Access Network; Study on NR QoE (Quality of Experience) management and optimizations for diverse services (Release 17)” (hereinafter 3GPP TR 38.890) in a management-based procedure, the NM, e.g., an OAM entity, “is currently not capable of sending the QoE measurement configuration for a specific UE towards its serving gNB when the targeted UE becomes RRC_CONNECTED. This is because OAM is not informed about when a specific Ues served by a certain gNB become RRC_CONNECTED” and “There is currently no UE identifier available in OAM which can be used to identify an UE connected to a certain gNB” – See 3GPP TR 38.890:9 (emphasis added). The present disclosure does not teach how the user terminal could receive or transmit from/to a “NM at a network device” any RRC message when the NM, i.e., a CN entity, cannot identify the user terminal and is not informed about when the user terminal is in RRC_CONNECT mode with the network device, whereby the Specification clearly defines “a network device” as a network access device, e.g., a base station. A person of ordinary skills in the art would appreciate that an NM in a network is not an entity capable of generating RRC configurations.
Regarding Amended Claim 1, it also requires “wherein the second identity is determined to be the first identity.” However, the Specification only discloses the first identity determined to the the second identity – See [¶0047](“the first apparatus 210 may determine the first identity to be the second identity”); [¶0064] (stating the same). The Specification only discloses that, in some cases, the determined second identity “is mapped to the first identity” – See, e.g. [¶0069]; [¶¶0055-56], whereby the second identity may be determined based on the first identity – See, e.g., [¶0047], and is transmitted to the second apparatus with the QoE configuration in an AT command – See, e.g. [¶0050]. The Specification further explains that “the first apparatus 210 may determine 2040 the device to which the QoE report is forwarded based on the second identity . . . based on the mapping table mentioned previously” so that “if the QoE report is with the second identity and the second identity is mapped to the first identity, the first apparatus 210 can determine that the QoE is transmitted to the second device 120 based on the first identity” – See [¶0055] (emphasis added) whereby “table mentioned previously” comes from “the first apparatus 210 may store a mapping between the second identity and the second device 120” – See [¶0049], after the “the first apparatus 210 may determine the second identity based on the first identity and other identity information. the second apparatus 220 may store the mapping between the second identity and an identity of the second apparatus 220 (such as application layer identity)” – See, e.g. [¶0047] (emphasis added). Because “and other information” is not just surplusage the claimed limitation “the second identity is determined to be the first identity” is not supported in the Specification. The only intelligible principle that a person of ordinary skills may draw from the Specification regarding an identity relationship between the second identity and the first identity, in this order, is that after the first apparatus receives the RRC configuration message with “the QoE configuration of the service and the first identity” from the second device – See, e.g., [¶0044] and the “first apparatus 210 determines 2020 an associated identity (referred to as “second identity” hereinafter) for the QoE configuration based at least in part on the first identity” – See [¶0047], if the first apparatus “creates a record to map the second identity to the second device,” e.g., “in a mapping table” – See [¶0049], it can be said that the “second identity is mapped to the first identity.” However, no person of ordinary skills in the art would understand this principle as the claimed “the second identity is determined to be the first identity.” The other amended independent claims suffer from the same deficiency.
In addition, new Claims 23-34 require that “the NM in the access stratum layer at the network device” when the Specification only discloses an NM outside the network device – See Fig. 2 and [¶0034] (“QMC request/configuration from a management system (for example, a network manager (NM)) to gNB”); [¶0041](“other core network entities which are not shown in Fig. 1, for example, the MCE 240 and the NM 230”); [¶0042](“The NM 230 can transmit 2005 the QMC activation message to the second device 120”).
Therefore, all claims contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention. For the purpose of examination, the limitations at issue would be interpreted as there were a second device, e.g., a base station, intermediating the receive/transmit, at the user terminal, from/to the claimed NM.
In sum, Claims 1, 8, 12, 18 and their dependent claims are rejected under 35 U.S.C. 112(a) for lack of written description.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 8, 12, 18 and their dependent claims are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
A claim is indefinite when it contains words or phrases whose meaning is unclear. In re Packard, 751 F.3d 1307, 1314, 110 USPQ2d 1785, 1789 (Fed. Cir. 2014). MPEP §2173.05.
During prosecution the Office construes claims by giving them their broadest reasonable interpretation consistent with the specification in an effort to establish a clear record of what the applicant intends to claim and applicant has the ability to amend the claims during prosecution to ensure that the meaning of the language is clear and definite prior to issuance or provide a persuasive explanation (with evidence as necessary) that a person of ordinary skill in the art would not consider the claim language unclear. In re Buszard, 504 F.3d 1364, 1366, 84 USPQ2d 1749, 1750 (Fed. Cir. 2007) (claims are given their broadest reasonable interpretation during prosecution "to facilitate sharpening and clarifying the claims at the application stage"). MPEP §2173.02(I).
Here, each of the independent claims 1, 8, 12, and 18 recites the limitation “a network manager (NM) at a network device” and the new Claims 23-34 require “the NM is in the access stratum layer at the network device,” whereby the Specification defines the term “network device” as generic for a network access device – See, e.g., Fig. 2 and [¶0029]. It is unclear for a person of ordinary skills in the art in light of the Specification and the knowledge in the art available before the effective date of the claimed invention, how the claimed NM, shown as a separate entity in Fig. 2, is “at the network device” and/or “sits inside” the network access device so that the NM can perform RRC operations (e.g., send QoE measurement configurations and receive QoE measurement reports) with a terminal device using RRC messages, as required – See, e.g., Claim 1 (requiring “receiving, by the first apparatus at the terminal device, from a network manager (NM) . . . radio resource control (RRC) configuration”; “the RRC configuration received from the NM at the network device”; “ transmitting, by the first apparatus at the terminal device, to the NM at the network device”); see also new Claims 23-34 (“the RRC configuration received from the NM in the access stratum layer at the network device,” i.e., specifically requiring that the NM “sits” in the RRC/access stratum layer of the network access device).
Regarding Amended Claim 8, the limitation “wherein the first identity is generated by a network device and provided by a network manager (NM) at the network device to the first apparatus at the terminal device in a radio resource control (RRC) configuration of a QoE measurement collection (QMC) activation message for the service” is unclear to a person of ordinary skills in the art because, aside the indefinite term “a network manager (NM) at the network device,” a person of ordinary skills in the art would not know how a “QMC activation message for the service,” a signaling that happens between the NM at the OAM system or CN and a network access device serving the terminal device, that signaling being carried by a different protocol than RRC, as shown also in step 2005 of Fig. 2 of the present disclosure, is directly carried, through RRC directly between the NM and the terminal device.
Regarding Claims 25 and 31, they recite the limitation “the second identity received with the QoE configuration of the service” when they depend from the independent claims 1 and 12, reciting “determining, by the first apparatus at the terminal device . . . a second identity associated with the OoE configuration of the service,” i.e., the second identity is NOT received at the terminal but determined there. Applicant even argued in the Response that no reference in the previous Office action taught the determination of the second identity at the terminal. Therefore, these claims are indefinite.
For the reasons listed above, Amended Claims 1, 8, 12, 18 and their dependent claims are rejected under 35 U.S.C. 112(b) for indefiniteness. For examination purposes the configuration presented in Fig. 2, wherein the NM transmits the QMC activation command to the network device and receives the QoE report from the network device, will be used. To distinguish this interpretation from the one intended in the present application, terms such as “network manager (NM) at a network device,” “NM at a network device,” “the NM is in the access stratum layer at the network device” and equivalents thereof will appear underlined in the present Office action.
Applicant may amend to clarify, pointing to support in the present Specification, how an NM “sits” in a network access device and how that NM performs RRC operations with the first apparatus of the terminal device.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-4, 8-9, 12, 14-15, 18-19, and 21-34, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Liu, U.S. Patent Application Publication No. 2024/0107358 (hereinafter Liu1) in view of 3GPP TSG-RAN WG1 Meeting #115, Title: "Feature summary for 8.14.2.1", Source: Ericsson, August, 2021, (hereinafter 3GPP-QoE-Features), and further in view of Liu et al, U.S. Patent Application Publication No. 2024/0224347 (hereinafter Liu2).
Regarding Amended Claim 1, Liu1 teaches in Fig. 2, a first apparatus at a terminal device, i.e., “the Access Stratum (AS) of the terminal device (UE)” – See [¶0060], the first apparatus comprising: at least one processor; and at least one memory comprising instructions stored therein, that, when executed by the at least one processor, – See [¶0179] and Fig. 9, cause the first apparatus to perform at least:
receiving, by the first apparatus at the terminal device, from a network manager (NM) at a network device, a quality of experience (OoE) measurement collection (QMC) activation message for a service and a radio resource control (RRC) configuration for the service (first, “a core network device such as a Measurement Collection Entity (MCE),” i.e., an NM, “sends QMC configuration information such as activationAreaQMCjob signaling,” i.e., a QMC activation message “to a base station such as eNB or gNB,” i.e., a network device, whereby “[t]he QMC configuration information includes a service type (Service Type), a geographical scope (AreaScope), an IP address of QoE collection entity (QoE CE), a target Public Land Mobile Network (PLMN), a target QMC, a QoE reference identity (QoE Reference Identifier, QoE Reference ID) and a QMC configuration file (QMC config.file ),” i.e., the QMC activation is for a service – See [¶0057] and Fig. 2, and then “the base station sends the service type (ServiceType) and the QMC configuration file to a terminal device through Radio Resource Control (RRC) reconfiguration signaling (RRCReconfiguration signaling)” – See [¶0058])
wherein the RRC configuration indicates (“for the setting of RRCReconfiguration, reference may be made to the following description” – See [¶0059] pointing to the table describing an RRC application layer measurement configuration Information Element measConfigAppLayer-r15 containing the QoE measurement configuration container and the service type5; but see the updated MeasConfigAppLayer-r17 IE described in 3GPP-QoE-Features, infra)
a first identity associated with the OoE configuration for the service, wherein the first identity is generated by the NM at the network device (“the first identity information may be a QoE reference identity, which may contain at least one of: MCC, MNC and QMC ID” and “[t]he first identity information may be used to determine a core network device (that is, the QoE collection entity) that sends the QMC configuration information” used to perform a specific QMC task – See [¶0082], i.e., the first identity associated with the QoE configuration for the service received in the RRC configuration message is a QoE reference identity, e.g.,“(QoE Reference Id, QoE Reference ID)” – See [¶0057] and Fig. 2, and although the “QoE reference parameter must be globally unique,” – See [¶0073] for a terminal device that remains inside a limited geographical scope, e.g., same PLMN as the NM, a QoE reference identity may be ascertained/determined only from the QMC ID6, e.g. to shorten the length QoE Reference Id by not appending the MCC+MNC prefix – See [¶0074]; in addition, “[t]he QMC ID is generated by the management system or the operator, and is used to identify a traffic node and the QoE measurement collection task” – See id., whereby the “QMC configuration information is used to perform a specific QMC task” – See [¶0085] and “the terminal device may receive the measurement configuration information, and carry out the QMC task based on the measurement configuration information,”– See [¶0086] i.e., collect measurements and report per the QMC configuration file and service associated with the QMC task under the one QoE reference identity generated by the NM)
wherein the first identity comprises one of: an RRC identifier, a measurement application layer identifier, or a container identifier (because the QoE Reference Id comprising the QMC ID uniquely identifies the QMC task, i.e, the QMC configuration file for a service at the terminal device, it must comprise an identifier of the container encapsulating the QMC configuration file sent through the RRC configuration to the first apparatus, e.g., an application layer identifier measConfigAppLayey containing the measConfigAppLayerContainer with the QMC configuration file for a service – See [¶0059] and further explained in Footnote 5 and 3GPP-QoE-Features, infra, in regards to NR Rel-17 updates for QoE measurements)
determining, by the first apparatus at the terminal device, based at least in part on the first identity indicated in the RRC configuration, a second identity associated with the OoE configuration of the service, wherein the second identity is determined to be the first identity (“the access stratum of the terminal device receives the measurement configuration information, and determines a specific application based on the service type in the measurement configuration information, and sends the QMC configuration file in the measurement configuration information to the application through a terminal instruction,” i.e., an +CAPPLEVMC AT command – See [¶0090] and Fig. 2, therefore the first apparatus, at RRC layer, must determine from the RRC configuration message, based on the first identity, the individual elements of the AT command performing the QMC task associated with the first identity, and send them above the radio interface layer 3 stack,7 specifically, the first apparatus, based on the QoE reference identity associated with the QMC task generating the RRC configuration message, must determine an identity for the container with the QMC configuration file and the service type concerning the QMC task so that the application knows with which identity to return the QoE measurements report of that QMC task; this identifier for the second identity may be measConfigAppLayerId-r17, an RRC level ID, disclosed in 3GPP-QoE-Features infra; because the first apparatus must match the QoE Reference Id of the first identity received in the RRC configuration message8 with the measConfigAppLayerId, uniquely identifying the measConfigAppLayerContainer that contains the QMC configuration file and the serviceType-r17 service type for the QMC task, the first apparatus may determine the second identity, identified by the measConfigAppLayerId as being the first identity, identified by the QoE Reference Id, whereby both Ids can be interchangeably used in the RRC configuration, as further explained in 3GPP-QoE-Features infra, citing to Annex L of 3GPP TS 26.247 V16.5.0 (2021-09), “Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)(Release 16)” (hereinafter 3GPP TS 26.247));
transmitting, by the first apparatus at the terminal device, to a second apparatus at the terminal device, the QoE configuration (“the Access Stratum (AS) of the terminal device (UE) sends the service type and QMC configuration file, to the UE application layer (Application level) through a first terminal instruction such as +CAPPLEVMC” – See [¶0060])
and the second identity associated with the QoE configuration of the service (as further explained in 3GPP-QoE-Features infra, the AT command must include the identifier of the second identity, measConfigAppLayerId-r17 or its equivalent QoE Reference Id, because this identifier is uniquely associated with the container embedding the QoE measurement report for the QMC task, MeasurementReportAppLayer-IEs-r17, disclosed in 3GPP-QoE-Features infra, similar to MeasReportAppLayer-r15-IEs - See [¶0063]);
receiving, by the first apparatus at the terminal device, from the second apparatus at the terminal device a QoE report of the service (“after the UE application layer completes the measurement quantity collection, a corresponding report (the report contains the QoE reference ID) is sent to the UE AS layer through a second terminal instruction such as +CAPPLEVMR” – See [¶0061] and Fig. 2),
with the second identity associated with the OoE configuration of the service (further in 3GPP-QoE-Features infra, and in the 3GPP R2-2109004 reference in Footnote 5, the second identity identifier, measConfigAppLayerId-r17, is uniquely associated with the QoE measurement report container, measReportAppLayerContainer-r17, similar to measReportApplaycrContainer-r15 – See [¶0063], configured through the OoE configuration of the service that is received in the RRC configuration message at the first apparatus with the first identity);
determining, by the first apparatus at the terminal device, that the QoE report is to be forwarded to the NM at the network device based on the second identity associated with the QoE configuration for the service indicated in the RRC configuration received from the NM at the network device (because the first apparatus determined the second identity, identified by measConfigAppLayerId-r17, from the first identity, identified by the QoE Reference Id retrieved from the RRC configuration message containing the OoE configuration of the service associated with the QMC task from the NM, as explained supra, when the first apparatus receives the measReportAppLayerContainer-r17, configured through the same OoE configuration of the service received in the RRC message, and identified by the measConfigAppLayerId-r17 in the AT command received from the second apparatus, would know that measConfigAppLayerId-r17 corresponds to QoE Reference Id because the second identity is the first identity; because QoE Reference Id contains or is identical with QMC ID that uniquely identifies the N, as explained supra, the first apparatus at the terminal device can determine that the QoE report is to be forwarded to the NM based on the second identity associated with the QoE configuration for the service indicated in the RRC configuration received from the NM)
transmitting, by the first apparatus at the terminal device, to the NM at the network device, with the first identity indicated by the RRC configuration, the QoE report of the service (“the QoE reference ID needs to be sent along with the measurement report every time the report is sent . . . from the UE AS to the gNB” from which the first apparatus received the RRC configuration message containing the OoE configuration of the service associated with the QMC task from the NM whereby because the QoE Reference Id comprises only the QMC ID uniquely identifies the QMC task, “the transmission overhead of the air interface is [NOT] very large” – See [¶0075]).
Liu1, teaching the determining by the first apparatus of a first identity generated by the NM requesting a QMC task for a service associated with the OoE configuration for the service received by the first apparatus in the RRC configuration message, wherein the first identity comprises a measurement application layer identifier associated with a container identifier at the RRC level, both corresponding to the OoE configuration for the service received in the RRC configuration message, does not explicitly teach, on its own, how the first apparatus determines and uses the second identity in particular because the disclosure in Liu1 is based on Rel-15 of RRC Information Elements. However, 3GPP RAN2 work on Agenda item 8.14.2.1, Rel-17 configuration architecture general aspects for NR_QoE-Core WID, published before the effective filing date of the present application, brought about significant updates to the disclosure in Liu1.
Specifically, 3GPP-QoE-Features lists a summary of proposals related to QoE configuration and reporting submitted to agenda item 8.14.2.1, including proposals to “[u]se QoE reference as the ID for RRC to identify a QoE measurement[2],” and that “QoE reference ID can be used to identify QoE measurement between UE and NW,” as taught by Liu1 – See 3GPP-QoE-Features, at page 1-2, citing [2] TSG-RAN WG2 Meeting #115-e, R2-2107380, Title:” 8.14.2.1-Discussion on NR QoE configuration,” Source: CATT, August 2021, (hereinafter 3GPP R2-2107380) (stating, at page 1, that because “there will be assurance and other automated functions,” i.e., multiple NMs, “using the QMC mechanism in 5G in Rel-17, the functionality to provide QoE Reference both inside and outside the container to enable multiple simultaneous measurements and the temporary stop/restart QMCs are needed,” whereby “multiple assurance and automation functions may need to have different QoE data from the same UE, multiple simultaneous QMCs from each UE is needed,” i.e., multiple NMs may request simultaneous QMC tasks from the same terminal device, and because the “multiple QMCs are ordered by different consumers,” i.e., NMs, “the QoE Reference and the consumer address” must be mapped (emphasis added); therefore, the QoE Reference Id that may contain just the QMC ID generated by the NM, as taught in Liu1, is a value visible to the terminal device in the received RRC configuration message containing the disclosed measConfigAppLayer-r15, now updated as measConfigAppLayer-r17, and also bundled inside the RRC container holding the OoE configuration of the service, measConfigAppLayerContainer-r15, now updated to measConfigAppLayerContainer-r17).
3GPP-QoE-Features:2 further indicates that “[i]n the running RRC CR for QoE, R2-2108108, an RRC ID MeasConfigAppLayerId is used in the configuration of QoE . . . and in the reporting of QoE,” i.e., a new parameter is added to MeasConfigAppLayerId-17 is added to the measConfigAppLayer-r17 RRC IE received by the terminal device, as shown in the MeasConfigAppLayerId information element snippet at page 2, and this specific parameter was not explicitly taught in Liu1. Because the new parameter is, by its nature, a RRC ID identifying the MeasConfigAppLayer-r17 3GPP-QoE-Features specifically teaches a second identity, determined based on the QoE Reference Id received in the RRC configuration message.
Like Liu1, 3GPP-QoE-Features:2 further teaches that this second identity is used to identify, at the terminal device, the QoE report associated with the QoE configuration for the service received in an RRC configuration message from the network device, as shown in the MeasurementReportAppLayer-IEs-r17, at page 2. However, different from Liu1, 3GPP-QoE-Features teaches the second identity determining at the terminal device because of the inherent operations between the RRC layer and the application layer to extract the respective fields from the RRC message and convert them into AT commands (and the reverse for preparing and sending the QoE report) as explained in 3GPP TS 27.007 referenced in Footnote 7.
Although 3GPP-QoE-Features points to the running “CR in R2-210818” to further detail the ne RRC parameters and fields for Rel-17, that contribution was superseded (in the same meeting) by 3GPP TSG-RAN WG2 Meeting #115-e, R2-2109004, Title: “38.331 Running CR for Introduction of QoE measurements in NR,” Source to WG: Ericsson, August 2021 (hereinafter 3GPP R2-2109004), introducing Rel-17 RRC IEs for QoE measurements support, and its companion 3GPP TSG-RAN WG2 Meeting #115-e, R2-2109004, Title: “38.300 Running CR for Introduction of QoE measurements in NR,” Source to WG: China Unicom, Huawei, HiSilicon, August 2021 (hereinafter 3GPP R2-2109005), introducing collection of application layer measurements from the UE, i.e., QoE Measurement Collection (QMC) for streaming and MTSI services.
For example, 3GPP R2-2109004, at page 71, discloses that “for each measConfigAppLayerId” the measConfigAppLayerContainer is forwarded “to upper layers considering the serviceType,” e.g., for decoding the QMC configuration for QoE reporting from the application layer, as further taught at page 1004-1007, wherein the updated MeasConfigAppLayer-r17 RRC IE now comprises a measConfigAppLayerId-17 identifier associated with the measConfigAppLayerContainer-17 field “contain[ing] configuration of application layer measurements, see Annex L (normative) in TS 26.247 [64] and clause 16.5 in TS 26.114 [65].” The same reference introduces, at page 264-65, the MeasurementReportAppLayer-r17 RRC IE “used for sending application layer measurement report,” identified by the same measConfigAppLayerId-r17 described supra, and comprising a measurementReportAppLayerContainer field that “contains application layer measurements, see Annex L (normative) in TS 26.247 [64], and clause 16.5 in TS 26.114 [65]”. Annex L of 3GPP TS 26.247 cited above, discloses, at page 137, the QmcConfiguration element received by the RCC layer at the UE containing the attribute “qoeReferenceId” which uniquely identifies a QMC configuration associated with a QMC task requested by an NM (and uniquely identifies the NM), as taught in Liu1; see also Figure L-2, at page 136, showing the QMC functionality using the MeasConfigAppLayer RRC IE containing the QoE configuration of the QMC task requested by the NM.
It is true that the Annex comprising RAN2 agreements on NR QoE included in 3GPP R2-2109005:5, states that “RAN2 assumes that gNB keeps the mapping between MeasConfigAppLayerId and QoE Reference.” However, that is only an assumption, and the mapping may be kept at the UE, as explained above, as necessary and inherent to the operations between the RRC layer and the application layer when the terminal device is requested to execute a specific QMC task. The reference further discloses that “MeasConfigAppLayerId is sufficient to identify the QoE configuration between UE and gNB,” suggesting that this second identity, MeasConfigAppLayerId, may be mapped to the network device at the UE (otherwise MeasConfigAppLayerId would not be sufficient for the UE to know where to send the QoE report; in addition MeasConfigAppLayerId is also necessary because the MeasConfigAppLayerId must be sent to the network device with the MeasurementReportAppLayer-r17 RRC IE, as taught by 3GPP-QoE-Features supra). Therefore, 3GPP-QoE-Features teaches that the second identity could be a first identity in addition to the UE mapping the second identity to the first identity.
In sum, 3GPP-QoE-Features and the references cited therein teach a second identity determined by the first apparatus based at least in part on the first identity indicated in the RRC configuration, the second identity being associated with the OoE configuration of the service wherein the second identity is determined to be the first identity, within the meaning understood by one of ordinary skills in the art from the present disclosure9.
Thus, Liu1 and 3GPP QoE-Features each teaches a first apparatus and a second apparatus at a terminal device receiving QoE configuration for a service through RRC configuration from a network device, the QoE configuration for a service being a QMC task configuration information received from an NM, whereby the QoE configuration has a first identity referenced by QoE Reference Id generated by the NM requesting the QMC task with the QoE configuration. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the determination of a second identity at the first apparatus, e.g., the MeasConfigAppLayerId RRC parameter and its use between the first apparatus and the second apparatus as well as between the terminal device and the network device, as taught by 3GPP QoE-Features and its references, could have been substituted in for the determination of a second identity in Liu1, because both references provide a MeasConfigAppLayer and a MeasurementReportAppLayer transferred through RRC messages between a terminal device and a network device in fulfilment of a QMC task requested by a NM. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution through techniques known in the art. Finally, the substitution achieves the predictable result of conforming Liu1 to the updated Rel-17 RRC specifications, as taught in 3GPP QoE-Features.
In the alternative that Liu1 in view of 3GPP QoE-Features, teaching that the RRC layer may “forward[] the MeasConfigAppLayerId together with the QoE configuration to the application layer” – See Annex, R2-2109005:5, and that MeasConfigAppLayerId uniquely identifies the MeasurementReportAppLayer containing the configured QoE measurements report measReportAppLayerContainer-r17, whereby a mapping between MeasConfigAppLayerId and the QoE Reference Id is maintained at the UE, still does not teach the determining, by the first apparatus at the terminal device that the QoE report is to be forwarded to the NM at the network device based on the second identity, which it does based on the functional role of MeasConfigAppLayerId described above, then Liu2 discloses this limitation.
Liu2 teaches “operation for QoE configuration, measurement, and reporting” – See [¶0095] including “technique to improve QoE continuity for an ongoing QoE session in the case of a UE moving out of an area associated with the QoE configuration” when “[a]t the network level only a QoE configuration identifier or service type associated with the QoE configuration is visible” – See [¶0096]. The terminal device (UE) in Liu2, like in Liu1 in view of 3GPP QoE-Features comprises a first apparatus and a second apparatus – See, e.g., Fig. 14, showing the UE RRC layer and the UE App layer, whereby “the UE (e.g., using communication manager 140 and/or QoE component 1108, depicted in FIG. 11),” i.e., the RRC layer, “may initiate a QoE session for a QoE configuration, the QoE session being initiated at an application layer of the UE” – See [¶0099] and also that the “UE can be configured with a QoE measurement configuration (herein referred to as a QoE configuration). For example, a QoE device (referred to as a QoE server or a measurement collection entity (MCE)) may provide the QoE configuration to a base station. The base station may provide the QoE configuration to an RRC layer of the UE via an RRC configuration (e.g., an RRC reconfiguration message)” – See [¶0091].
Liu2 explicitly teaches the mapping between the second identity and the first identity (“storing, at the RRC layer, information associated with a mapping between the RRC level identifier and the QoE reference based at least in part on the RRC configuration including the QoE reference” – See [¶0106], whereby the RRC identifier is the second identity, e.g., MeasConfigAppLayerId, and the QoE reference is the first identity, e.g. QoE Reference Id).
Liu2 further teaches, at the UE, a QoE session associated with the QoE configuration, wherein “the session start or stop indication being provided from the application layer to an RRC layer of the UE, . . . includes at least one of a service type associated with the QoE configuration, an RRC level identifier associated with the QoE configuration, a QoEreference associated with the QoE configuration, or a QMC associated with the QoE configuration” – See [¶0100] and Fig. 4, i.e., when executing a QMC task based on the QoE configuration for the service as received in an RRC configuration message, the first apparatus and the second apparatus exchange, through internal apparatus communication, identifiers of the first and the second identity – See, e.g., [¶0191] (“if the RRC level ID associated with the QoE configuration was provided to the application layer, then the application layer includes the RRC level ID in the session start or stop indication. In this way, the application layer of the UE 120 can indicate, to the RRC layer of the UE 120, one or more items of information associated with the QoE configuration based at least in part on initiating a corresponding QoE session at the UE 120”) and Fig. 14. Finally, Liu2 teaches the QoE report is to be forwarded to the NM at the network device based on the second identity associated with the OoE configuration for the service (“the RRC layer of the UE 120 may provide, and the first base station 110a may receive, an RRC message including one or more items of information associated with the QoE configuration,” i.e., a QoE report, the “information indicating the service type associated with the QoE configuration, the RRC level ID associated with the QoE configuration” – See [¶0192], whereby “the UE 120 may derive the RRC level ID at the RRC layer based at least in part on . . . the QoE reference” – See [¶0193]) and
transmitting, by the first apparatus at the terminal device, to the NM at the network device, with the first identity indicated by the RRC configuration, the QoE report of the service (“The RRC layer of the UE then reports the QoE measurements (per service type) to the base station, and the base station provides a corresponding QoE report to the QoE server” – See [¶0091], i.e., the QoE report is associated with the QoE reference generated by the NM, i.e., the first identity)
Thus, Liu2 and Liu1 and 3GPP QoE-Features each teaches QoE reporting between the RRC layer at a terminal device and a network device based on a QoE configuration for a service received in a RRC configuration message. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the explicit mapping at the RRC layer of the terminal device between a second identity derived by the terminal device from a first identity received in the RRC message being used to forward a QoE report received from the application layer of the terminal device to the network device based on (1) the second identity being associated with the QoE report, (2) the network device having sent to the terminal device the RRC configuration message with the first identity; and (3) the RRC layer of the UE having the mapping between the second identity and the first identity could have been combined with the QoE reporting in Liu1 and 3GPP QoE-Features because the RRC layer ID derived by the terminal device in Liu2 may be the substituted in for the MeasConfigAppLayerId taught in Liu1 and 3GPP QoE-Features and all the internal operations and the operations with the network node stay the same. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination and substitution through techniques known in the art. Finally, the combination achieves the predictable result of providing support for terminal device mobility during the QMC task as taught in Liu2 who also teaches that because “[a]t the network level only a QoE configuration identifier or service type associated with the QoE configuration is visible” – See [¶0096], therefore mapping identities and filtering conditions are better performed at the UE.
Therefore, Amended Claim 1 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 3, dependent from Amended Claim 1, Liu1 in view of 3GPP QoE-Features and further in view of Liu2 teaches the first apparatus of claim 1, wherein the instructions stored in the at least one memory, when executed by the at least one processor, further cause the first apparatus to perform the determining the second identity for the QoE configuration by performing:
determining the second identity, by the first apparatus at the terminal device, based on the first identity and other identity information (“The QMC configuration information” may include a “geographic scope (AreaScope)” – See Liu1:[¶0057] that is used by “the network to determine terminal(s) that meets(meet) the QoE collection conditions” – See Liu1:[¶0071] but also the UE “may determine whether a UE is located in an area associated with a QoE configuration configured on the UE” – See Liu2:[¶0184], and “evaluation of any filtering criteria, such as location filtering ( e.g., geographical filtering), which should be done only when the QoE session” starts whereby a person of ordinary skills in the art would appreciate that the area scope may be a tracking area code, TAC, of the primary cell configured to the UE, e.g., in an RRC AreaConfiguration information element that “indicates area for which UE is requested to perform measurement logging” and is identified by TrackingAreaIdentity-r16 pointing to plmn-Identity and trackingAreaCode values – See 3GPP TS 38.331: 762-763; furthermore, Annex L of 3GPP TS 26.247:135 cited in 3GPP QoE-Features references, teaches that the area identity may be associated with the RRC level ID MeasConfigAppLayerId hence forming a second identity associated with the QoE configuration for the service because “[t]he QoE configuration AT command +CAPPLEVMC [61] may also indicate with an Within-area Indication if the UE is inside or outside a wanted geographic area”).
Therefore, Amended Claim 3 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 4, dependent from Amended Claim1 Liu1 in view of 3GPP QoE-Features and further in view of Liu2, further teaches the first apparatus of claim 1, wherein the instructions stored in the at least one memory, when executed by the at least one processor, further cause the first apparatus to perform:
storing, by the first apparatus at the terminal device, a mapping between the second identity and the NM at the network device (“Measurement Collection Entity (MCE) sends QMC configuration information” that “includes a service type (Service Type), a geographical scope (AreaScope), an IP address of QoE collection entity (QoE CE), a target Public Land Mobile Network (PLMN), a target QMC, a QoE reference identity (QoE Reference Identifier, QoE Reference ID)” – See Liu1:[¶0057] whereby “the first identity information,” i.e., the QoE reference identity, “may contain at least one of: MMC, MNC and QMC ID. The first identity information may be used to determine a core network device (that is, the QoE collection entity) that sends the QMC configuration information”– See Liu1: [¶0082]; furthermore, the terminal device stores “at the RRC layer, information associated with a mapping between the RRC level identifier,” i.e., the second identity, “and the QoE reference based at least in part on the RRC configuration including the QoE reference,” i.e., the identifier pointing to the QMC ID of the NM – See Liu2: [¶0106]; furthermore, “[a]t the network level only a QoE configuration identifier or service type associated with the QoE configuration is visible” – See Liu2:[¶0096], therefore all these mappings are better performed at the UE).
Therefore, Amended Claim 4 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 8, Liu1 further teaches a second apparatus at a terminal device, (e.g., the UE Application level in Fig. 2), the second apparatus comprising: at least one processor; and at least one memory comprising instructions stored therein that, when executed by the at least one processor, cause the second apparatus to perform at least:
receiving, by the second apparatus at the terminal device, from a first apparatus at the terminal device, a quality of experience (QoE) configuration of a service and a second identity wherein the second identity is generated by the first apparatus at the terminal device based on a first identity, (“[t]he measurement configuration information includes the second identity information (RRC level ID), a service type and a QMC configuration file. The +CAPPLEVMC sent by the UE AS layer to the APP layer contains the same information” – See [¶0104], whereby the second identity information (RRC level ID) may be the new MeasConfigAppLayerId taught in 3GPP QoE-Features determined from the MeasConfigAppLayer RRC IE associated the with the QoE Reference Id, i.e., the first identity, of the QoE configuration for the service received by the first apparatus through RRC message, as taught in Liu1 and explained in Regarding Amended Claim 1 supra),
wherein the first identity is generated by a network device and provided by a
network manager (NM) at the network device to the first apparatus at the terminal device in a
radio resource control (RRC) configuration of a QoE measurement collection (QMC) activation
message for the service, wherein the first identity indicates the OoE configuration of the service (“a core network device such as a Measurement Collection Entity (MCE) sends QMC configuration information such as activationAreaQMCjob signaling to a base station such as eNB or gNB. The QMC configuration information includes a service type (Service Type), a
geographical scope (AreaScope), an IP address of QoE collection entity (QoE CE), a target Public Land Mobile Network (PLMN), a target QMC, a QoE reference identity (QoE Reference Identifier, QoE Reference ID) and a QMC configuration file (QMC config.file )” – See [¶0057] and “[t]he QMC configuration file contains a QoE reference identity (QoE Reference ID)” whereby “the base station sends the service type (ServiceType) and the QMC configuration file to a terminal device through Radio Resource Control (RRC) reconfiguration signaling (RRCReconfiguration signaling)” with the QoE Reference ID to the first apparatus at the terminal device, i.e., the AS/RRC layer – See [¶0058], and “first identity information may be
a QoE reference identity, which may contain at least one of: MMC, MNC and QMC ID” – See [¶0082] wherein “[t]he QMC ID is generated by the management system or the operator, and is
used to identify a traffic node and the QoE measurement collection task of a measurement collection center” – See [¶0074], thus providing that the first identity is generated by the NM; furthermore, the network can associate this first identity with the QoE measurement collection configuration for the service in the RRC message because “[a]t the network level, [] a QoE configuration identifier or service type associated with the QoE configuration is visible” – See Liu2:[¶0096])
wherein the first identity indicates the OoE configuration of the service, wherein the first identity comprises one of: an RRC identifier, a measurement application layer identifier, or a container identifier, and wherein the second identity is determined to be the first identity (as explained at length in Regarding Amended Claim 1, supra, wherein the same limitations are recited using the same language)
measuring a QoE of the service, by the second apparatus at the terminal device, based at least on the QoE configuration of the service and the second identity associated with the
QoE configuration of the service and transmitting, by the second apparatus at the terminal device, to the first apparatus at the terminal device, with the second identity of the OoE configuration of the service, the QoE report of the service (“the measurement configuration information may include second identity information, a service type and a QMC configuration file” – See [¶0084] and the measConfigAppLayer-r15 shown in [¶0059], updated for Rel-17 to contain the second identity, MeasConfigAppLayerId, as further taught in 3GPP QoE-Features supra, whereby “[t]he service type is used to enable the AS layer of the terminal device receiving the measurement information to determine a terminal device application (App) for which the QoE measurement is performed,” i.e., the second apparatus – See [¶0085] and Fig. 2, and “[t]he application, based on the QMC configuration file, performs QoE measurement, obtains a QoE measurement report, and sends the QoE measurement report to the access stratum of the terminal device through a terminal Instruction” – See [¶0090] and Fig. 2, wherein “for the setting of measurementreportApplyer, reference can be made to the” MeasReportAppLayer-r15 IE – See [¶0063], updated to MeasReportAppLayer-r17 to contain the same MeasConfigAppLayerId, as further taught in 3GPP QoE-Features supra, and whereby the MeasConfigAppLayerId is communicated between the first apparatus and the second apparatus through AT commands when the “RRC layer forwards the MeasConfigAppLayerId together with the QoE configuration to the application layer” – See Annex to R2-2109006:5; see also Liu2:[¶0103]).
Therefore, Amended Claim 8 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 9, dependent from Amended Claim 8, Liu1 in view of 3GPP QoE-Features and further in view of Liu2 further teaches the second apparatus of claim 8, wherein the instructions stored in the at least one memory when executed by the at least one processor, further cause the second apparatus to perform:
associating, by the second apparatus at the terminal device, the second identity and an identity of the second apparatus at the terminal device (“the measurement configuration information may include second identity information, a service type and a QMC configuration file” when sent to the second apparatus – See Liu1:[¶0084] whereby the second identity is the MeasurementReportAppLayer-IEs which is uniquely associated with the serviceType-r17 as taught in 3GPP QoE-Features:2; furthermore, the “QoE configuration and information [] identifies a service type associated with the the QoE configuration (e.g., multimedia broadcast/multicast service (MBMS), streaming service, multimedia telephony service for Internet protocol multimedia subsystem (MTSI), or the like)” and “[t]he application layer of the UE initiates a QoE session according to the QoE configuration and provides QoE measurements (per service type) to the RRC layer” – See Liu2:[¶0091], i.e., the second identity is associated at the second apparatus with the service type identity) and
storing, by the second apparatus at the terminal device, a mapping between the second identity and the identity of the second apparatus at the terminal device (taking the DASH/streaming service example described in Annex L of 3 GPP TS 26.247:135, the “QoE Configuration shall be forwarded to the DASH client. The interface towards the RRC signalling is handled by the AT command +CAPPLEVMC [61],” whereby “The QoE configuration AT command +CAPPLEVMC” includes the second identity because “RRC layer forwards the MeasConfigAppLayerId together with the QoE configuration to the application layer” – See Annex to R2-2109006:5; see also Liu2:[¶0103], so that the QoE report from the second apparatus can be mapped back to the first identity, as explained in Amended Claim 1 supra; furthermore, “the QoE reporting AT command +CAPPLEVMR [61] shall be used to send a Recording Session Indication” based on the QoE reporting configuration, according to an XML schema associating the type of service with the reported identity – See Annex L of 3 GPP TS 26.247:135&137, i.e., the second apparatus must store the mapping between QoE reporting configuration second identity and the service type to perform QoE session recording; see also Liu2:[¶0191] (“the application layer of the UE 120 may provide, to the RRC layer of the UE 120, a session start or stop indication based at least in part on initiating the QoE session associated with the QoE configuration” including “the service type associated with the QoE configuration, the RRC level ID associated with the QoE configuration, the QoE reference, or a QMC associated with the QoE configuration,” i.e., the mapping between the service type and the second identity must be stored at the second apparatus at least for the session duration)).
Therefore, Amended Claim 9 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 12, the claim language merely repeats the steps executed by the first apparatus of Amended Claim 1, with no other limitations. Because the Amended Claim 1 is obvious over Liu in view of 3GPP QoE-Features and further in view of Liu2 and the apparatus and devices of Amended Claim 1 execute exactly the same steps as recited by Amended Claim 12, Amended Claim 12 is obvious over Liu in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Claims 14-15, as amended, each dependent from Amended Claim 12, each claim merely recites the same steps executed by a first apparatus in Claims 3-4, respectively, as amended. Because each of those claims are obvious over Liu in view of 3GPP QoE-Features and further in view of Liu2, and the first apparatus is obvious over Liu in view of 3GPP QoE-Features and further in view of Liu2, each of the claims 14-15, as amended, is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claim 18, the claim language merely repeats the steps executed by the second apparatus of Amended Claim 8, with no other limitations. Because the Amended Claim 8 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, and the apparatus of Amended Claim 8 executes exactly the same steps as recited by Amended Claim 18, Amended Claim 18 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Amended Claims 19, 21 and 22, dependent from Amended Claims 18 and 8, respectively, they merely recite the limitations in Claims 9 and 3, only applied to the method in Amended Claim 18 and the second apparatus of Claim 8. Because each of the claims 3, 8-9, and 18, as amended, is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, Claims 19, and 21-22, as amended, are obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Claims 23, 26, 29, and 32, dependent from Amended Claims 1, 8, 12, and 18, each obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2,
Liu1 further teaches the limitation wherein the first apparatus is in an access stratum layer at the terminal device, the second apparatus is in an application layer at the terminal device, and the NM is in the access stratum layer at the network device10, as applied to each independent claim (“the Access Stratum (AS) of the terminal device (UE) sends the service type and QMC configuration file to the UE application layer (Application level)” – See [¶0060] and Fig. 2; “a core network device such as a Measurement Collection Entity (MCE) sends QMC configuration
information such as activationAreaQMCjob signaling to a base station such as eNB or gNB” – See [¶0057] and Fig. 2, and “the base station sends the service type (ServiceType) and the QMC configuration file to a terminal device through Radio Resource Control (RRC) reconfiguration
signaling (RRCReconfiguration signaling),” – See [¶0058] i.e., the QMC is activated at the access stratum of the base station by a NM when “the base station binds a service type with an IP address of a QoE collection entity” – See [¶0072]). Because each of the Amended Claims 1, 8, and 12 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, each of the claims 23, 26, 29, and 32 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Claims 24, 27, 30, and 33, dependent from Claims 23, 26, 29, 33, as amended, it is obvious for a person of ordinary skills in the art that the access stratum layer is one of: an RRC layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, or a medium access control (MAC) layer because these are the main functions of the Access Stratum provided in the 3 GPP specifications – See, e.g., 3GPP TS 38.300 V16.6.0 (2021-06), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16) (hereinafter 3GPP TS 38.300), showing, at page 21, Figure 4.4.2-1 the enumerated functions of the Access Stratum and distinguishing the from the NAS layer terminated in the core network, in case a CN entity like a QoE server might want to control the UE; see also Liu1:[¶0104] (“The gNB sends measurement configuration information to the UE AS layer through RRC reconfiguration information (RRCConnectionReconfiguration signaling)”).
Because each of the Claims 23, 26, 29, 33, as amended is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, each of the claims 24, 27, 30, and 33 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Claims 25 and 31, dependent from Claims 24 and 30, Liu1 in view of 3GPP QoE-Features and further in view of Liu2 further teaches the determining, by the first apparatus in the access stratum layer at the terminal device, the second identity associated with the QoE configuration of the service, is further based on
the second identity received with the QoE configuration of the service being a same identity as the first identity indicated in the RRC configuration received from the NM in the access stratum layer at the network device (discounting the dependency from the independent Amended Claims 1 and 12, Liu1 teaches “the gNB needs to perform mapping of first identity information (QoE reference ID) to second identity information (RRC level ID)” and “sends measurement configuration information to the UE AS layer through RRC reconfiguration information (RRCConnectionReconfiguration signaling). The measurement configuration information includes the second identity information (RRC level ID), a service type and a QMC configuration file” – See [¶¶0103-04]) or
the second identity received with the QoE configuration of the service being associated with the first identity indicated in the RRC configuration received from the NM in the access stratum layer at the network device (as explained at length in Regarding Amended Claim 1, supra, the first apparatus determines the second identity by ascertaining the MeasConfigAppLayerId from the measConfigAppLayer information element containing the QoE configuration for the service and associated with the QoE Reference Id, the first identity identifier, generated by the NM, sent to the network device and included in the RRC configuration message sent by the access stratum layer of the network device to the firs apparatus at the terminal device), as applied to the first apparatus of Claim 24 and the method of Claim 30.
Because each of the Claims 24 and 29 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, each of the claims 25 and 31 is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Regarding Claims 28 and 34, dependent from Claims 27 and 33, Liu1 further teaches the second apparatus of claim 27 and the method of claim 33, wherein, in an instance in which
the second identity is a same identity as the first identity or
the second identity is associated with the first identity,
the second identity indicates to the first apparatus in the access stratum layer at the terminal device that the QoE report of the service transmitted by the second apparatus in the application layer at the terminal device is to be forwarded to the NM in the access stratum layer at the network device associated with the first identity. Because an instance in which the second identity, i.e., MeasConfigAppLayerId from the measConfigAppLayer information element containing the QoE configuration for the service is associated with the QoE Reference Id, i.e., the first identity identifier, was explained in Regarding Amended Claims 8 and 18 as obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, and the limitation regarding forwarding QoE report of the service, recited with the same language in Amended Claim 1, is obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, and Claims 27 and 33 are obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2, Claims 28 and 34 are obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
In sum, Claims 1, 3-4, 8-9, 12, 14-15, 18-19, and 21-34, as amended, are rejected under 35 U.S.C. § 103 as obvious over Liu1 in view of 3GPP QoE-Features and further in view of Liu2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Liu et al., U.S. Patent Application Publication No. 2024/0172027 discloses the QoE report includes the access stratum identifier to indicate that the QoE report is associated with the application-level identifier or the one or more QoE configurations;
Hu, U.S. Patent Application Publication No. 2023/0379743 discloses QoE measurement and reporting;
Hu et al., U.S. Patent Application Publication No. 2024/0040440 discloses QoE application layer measurement and access stratum measurement;
Hu et al., U.S. Patent Application Publication No. 2023/0156767 discloses QoE measurement with a master node or a secondary node of the terminal device;
Hu et al., U.S. Patent Application Publication No. 2023/0080089 discloses QoE configuration and measurements;
Kumar et al., U.S. Patent Application Publication No. 2022/0217560 teaches QoE handling in NR;
Kim , U.S. Patent Application Publication No. 20220264373, method and apparatus for QoE reporting in a wireless communication system showing the RRC layer and the application layer of the wireless device, and associating the measurement results with specific QoE configuration;
Johansson et al., U.S. Patent Application Publication No. 2022/0279385, techniques for application level QoE measurements reporting;
3GPP TR 26.909 V16.0.0 (2020-07), “Technical Specification Group Services and System Aspects; Study on improved streaming Quality of Experience (QoE) reporting in 3GPP services and networks (Release 16)”;
3GPP TR 38.890 V17.0.0 (2021-04), “Technical Specification Group Radio Access Network; Study on NR QoE (Quality of Experience) management and optimizations for diverse services (Release 17)”;
3GPP TS 26.247:135 V16.5.0 (2021-09), “Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)(Release 16)”;
3GPP TS 38.331 V16.6.0 (2021-09), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16)”;
3GPP TS 27.007 V17.3.0 (2021-09), “Technical Specification Group Core Network and Terminals; AT command set for User Equipment (UE) (Release 17)”;
3GPP TS 38.300 V16.6.0 (2021-06), “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 16);
See 3GPP TS 36.331 V16.6.0 (2021-09), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (Release 16)”;
3GPP TSG-RAN2 Meeting # 115-e, R2-2109005, CR to 3GPP TS 38.300, August 2021, adding RRC identifier is mapped to the QoE Reference and the UE AS configuration for the QoE is stored in the UE Inactive AS context;
3GPP TSG-RAN2 Meeting # 115-e, R2-2108108, CR to 3GPP TS 38.331, August 2021;
3GPP TSG-RAN WG2 Meeting #115-e, R2-2109004, Title: “38.300 Running CR for Introduction of QoE measurements in NR,” Source to WG: China Unicom, Huawei, HiSilicon, August 2021;
3GPP TSG-RAN WG2 Meeting #116 electronic, R2-2110993, Title: “Discussion on NR QoE configuration,” Source: Qualcomm, August 2021;
3GPP TSG-RAN WG2 Meeting #116-e, R2-2110607, Title: “RAN visible QoE,” Source: Huawei, published October 22, 2021, disclosing updates to the QoE application layer measurement configuration IE;
3GPP TSG-RAN WG2 Meeting #115-e, R2-2107380, Title:” 8.14.2.1-Discussion on NR QoE configuration,” Source: CATT, August 2021;
3GPP TSG-RAN WG2 Meeting #115-electronic, R2-2107396, Title: “8.14.2.1-Further discussion on QoE measurement collection in NR” Source: OPPO, August 2021;
3GPP TSG-RAN2 Meeting #115-e, R2-2108197, Title: “8.14.2.1 - Discussion on QoE measurement and configuration” Source: China Unicom, China Southern Power Grid, August 2021.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
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, Joseph AVELLINO can be reached at (571)272-3905. 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.
/L.G.G./ Examiner, Art Unit 2478
/JOSEPH E AVELLINO/ Supervisory Patent Examiner, Art Unit 2478
1 Under the Broadest Reasonable Interpretation (BRI) standard used for interpreting the claim language, when the Specification does not disclose a specific intended meaning, the plain meaning interpretation as understood by one of ordinary skills in the art is used. Here, the transitive verb “determine” means “to settle or decide by choice of alternatives or possibilities” or “to fix the form, position, or character of “and has as synonyms verbs such as “discover,” “ascertain”, “learn” or “unearth” – See Merriam-Webster Dictionary available online at https://www.merriam-webster.com/dictionary/determine.
2 See, e.g., § 6.1, 3GPP TR 38.890 V17.0.0 (2021-04), “Technical Specification Group Radio Access Network; Study on NR QoE (Quality of Experience) management and optimizations for diverse services (Release 17)” (hereinafter 3GPP TR 38.890) showing, at page 7-8, in Figure 6.1.1-1 that the UE AS layer sends the QoE measurement configuration to UE application layer in a AT command; see also page 9, Figure 6.2.1-1 showing the same for the Management-based NR QoE activation procedure; accord with Spec.[¶0050].
3Applicant argues that the “3GPP R2-2107380 reference, after being originally submitted to the 3GPP standardization body by Qualcomm, was formally withdrawn as a submission to the 3GPP standardization body by Qualcomm, such that it was never actually made publicly available” whereby in the Office Action, at page 5 – Resp.,25:¶2. However, 3GPP R2-2107380, as used in the Office action, is a contribution submitted by CATT and is publicly available since July 6, 2021 at https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_115-e/Docs/R2-2107380.zip. Examiner is not aware of a 3GPP document authored by Qualcomm that is a Change Request and was cited in the previous Office action without being published by the respective 3GPP workgroup and available to the public; Office examiners do not have member access to 3GPP internal repository. In addition, the fact that 3GPP adopts or does not adopt a contribution or a Change Request is of no relevance to examination as long as the document is publicly available before the effective date of filing the claimed invention. Therefore, without a proper reference, this argument cannot be addressed.
4 Paragraph numbers in the corresponding WIPO application are just one unit behind paragraph numbers in the US Patent Application 20230128583 (application # 18/045,637).
5Section 5.3.5.9 of the running Change Request to 3GPP TS 38.331 V16.6.0 (2021-09), “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) protocol specification (Release 16)” (hereinafter 3GPP TS 38.331) describes, at page 71, that for each measConfigAppLayerId value included in the measConfigAppLayerToAddList:, the UE will extract the measConfigAppLayerContainer, whereby these parameters are configured to the UE through the RRC IE OtherConfig, described at page 1004, showing the updated MeasConfigAppLayer-r17 parameter comprising the application measurement identifier measConfigAppLayerId-r17 and the container identifier measConfigAppLayerContainer-r17 –– See 3GPP TSG-RAN WG2 Meeting #115-e, R2-2109004, Title: “Running CR for Introduction of QoE measurements in NR,” Source to WG: Ericsson, August 2021 (hereinafter 3GPP R2-2109004).
6 See, e.g., 3GPP TSG-RAN WG2 Meeting #115-e, R2-2107816, Title: “QoE configuration and Reporting,” Source: Qualcomm, August 2021, (hereinafter 3GPP R2-2107816) acknowledging, at page 2, that the “3-byte QMC ID is unique within one PLMN” and in Table 1 that QMC ID is an option for QoE reference ID.
7 See Fig. 1 at page 11, shown the first and the second apparatus of a terminal device, and § 4.0, at page 19-20, 3GPP TS 27.007 V17.3.0 (2021-09), “Technical Specification Group Core Network and Terminals; AT command set for User Equipment (UE) (Release 17)” (hereinafter 3GPP TS 27.007).
8 Liu explains the same mapping only at the transmit end of the RRC configuration message, i.e., the network access device, instead of the RRC layer of the terminal device, i.e., the first apparatus. – See [¶0082] (“the first identity information may be a QoE reference identity . . . which may contain at least: . . . QMC ID . . . to determine a core network device (that is, the QoE collection entity) that sends the QMC configuration,” i.e., lumps under one identity the NM sending the QMC task and the QMC configuration information associated with the task, so that the device knows where to send the QoE measurement report associated the QMC task, only that the mapping of the first identity with the second identity is done at the network access device sending the RRC configuration rather than at the terminal receiving the RRC configuration message, noting that “the second identity information is determined according to the first identity information, the first identity information may also be determined based on the second identity information” – See id., whereby “[t]he measurement configuration information” sent to the terminal device via the RRC configuration message “includes the second identity information . . . used to indicate the terminal device to obtain a QoE measurement report and send the QoE measurement report and the second Identity information” – See [¶0080].
9 The Specification only alleges that “the first apparatus 210 may determine the first identity to be the second identity” – See [¶0047] but not that the second identity may be the first entity. The only disclosure made is that when ”the second identity is mapped to the first identity, the first apparatus 210 can determine that the QoE is transmitted to the second device 120 based on the first identity” – See [¶0055](emphasis added).
10 This limitation will be interpreted as the “NM activates a QoE collection and reporting in the access stratum layer at the network device” because there is no support in the Specification for a “NM [that sits] in the access stratum layer at the network device.” Applicant could refer to 3GPP TR 26.909 V16.0.0 (2020-07), “Technical Specification Group Services and System Aspects; Study on improved streaming Quality of Experience (QoE) reporting in 3GPP services and networks (Release 16)” to amend these claims.