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 04/22/2026, 06/03/2026 and 07/16/2026 were filed after the mailing date of the 07/16/2026 on 03/03/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Response to Amendment
The Amendment to the claims filed on 07/06/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 3-4, 8, 12, 14-15, 18, 21-23, 26, 28-29, 32 and 34 are amended. Claims 2, 5-7, 10-11, 13, 16-17, 20, 25, and 31 are cancelled. Claims 35-38 are new. The rejections under 35 U.S.C. 112(b) are withdrawn. The rejection under 35 U.S.C. 112(a) is maintained on different grounds.
Response to Arguments
Applicant's Arguments/Remarks filed 07/06/2026 (hereinafter Resp.) have been fully considered as follows.
First, Applicant argues that the examiner erred in construing "determining" (a second identity, as recited in Amended Claim 1) as “ascertaining” – See Resp., p.16:¶2 (citing to page 5 of the NFOAM dated 03/03/2026). Applicant must be familiar with the standard claim interpretation at the Office: when the Specification does not specifically define or redefine a term, examination is made under a broadest reasonable interpretation, whereby words of the claim must be given their plain meaning, i.e., as defined in dictionaries or treatises, as understood by one of ordinary skills in the art, “unless such meaning is inconsistent with the Specification” – See MPEP §2173.01(I) (emphasis added). Here, the claim language, before the Amendment, required the determination to be a plain idempotent identification because the claim drafter stated: “the second identity is determined to be the first identity,” which reasonable persons would agree is an “ascertainment” of identity rather than a “generation” of an identity. Furthermore, the Specification does not impart in this particular case any other special meaning to the plain term “determining.” Also, on the one hand, anticipation of a limitation does not require a prior art reference to disclose each and every possible embodiment disclosed in the Specification, and, on the other hand, Applicant may rebut the presumption of plain meaning by clearly disavowing the full scope of the claim term in the Specification but disavowal, or disclaimer of claim scope, is only considered when it is clear and unmistakable – See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1341, 58 USPQ2d 1059, 1063 (Fed. Cir. 2001); see also In re Am. Acad. Of Sci. Tech Ctr., 367 F.3d 1359, 1365-67, 70 USPQ2d 1827, 1831-33 (Fed. Cir. 2004) (refusing to limit claim term "user computer" to only "single-user computers" even though "some of the language of the specification, when viewed in isolation, might lead a reader to conclude that the term . . . is meant to refer to a computer that serves only a single user, the specification as a whole suggests a construction that is not so narrow"); MPEP §2111.01 (IV)(B) (explaining when an Applicant may be his/her own lexicographer and disavow claim scope). However, here, even accounting for the Amendment applied to independent claims to now recite “generating . . . a second identity,” the Specification comes short in supporting this step happening at the first apparatus of the terminal device, as now claimed – See, e.g., Spec.[¶0047] (stating that “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” and, in an alternative embodiment. “the second identity can be generated based on the first identity and cell identity of the second device 120. In this way, the QoE configuration can be uniquely identified at the first device 110-1. Moreover, it may also reduce the length of the identity,” but failing to specify where the generation happens, e.g., at the first apparatus or at the network device, when each of these two could be reasonably assumed)(emphasis added); see also Spec:[¶0064]. Therefore, the Specification does not unequivocally place the “generating” step at “the first apparatus at the terminal device” in any pertinent paragraph of the Specification. However, the Specification is clear about “generating” QoE identities at the network device – See, e.g., Spec.:[¶0043] (stating “The second device 120 may generate an ID in RRC layer (referred to as ‘first identity’ hereinafter”) and also “generating” QoE Reports at the terminal’s second device, as stated in numerous paragraphs, signaling that the drafter knows the difference between “determining” and “generating” and judiciously uses these terms, proving that the drafter knew to specifically use “generating” and not “determining” by the terminal when it was necessary. For example, the Specification unequivocally describes the terminal “generating” an identity, but that identity is not the claimed second identity and is not based on the first identity– See, e.g., Spec:[¶0048] (“the first apparatus 210 may receive a further QoE configuration for the service from a further network device. In this case, the first apparatus 210 may generate a further associated identity for the further QoE configuration,” i.e., when a new QoE configuration arrives possibly for the same service, the terminal autonomously generates an identity for the configuration).
The limited support in the Specification for the terminal device “generating” the second identity may lead reasonable persons of ordinary skills in the art to disagree that the generating happens at the terminal device at all. Objective reasons rooted in the present disclosure and the knowledge of a person of ordinary skills in the art to NOT find support for the amended/new “generating . . . a second identity” at the terminal limitation in the Specification are as follows:
(1) the length of the first and/or second identity is of no consequence for messages exchanged between the Access Stratum and the Application Layer of the terminal because this communication is internal to the terminal; however, the length of the identity makes a big difference for the RRC messages between the terminal and the network device and the Specification is clear about reducing the length of the identity between the network device and the terminal, hence this reason points to support of generating the second identity at the network device and using this shorter ID between the network device and the terminal;
(2) terminals have limited (battery) power hence it would make no technical sense to waste that power on generating identities based on long strings such as a QoE reference identity, which may contain MCC +MNC+QMC ID, and the cell identity of the second device 120 , whereby the second device being a network access device may support many cell identities; hence this reason points to support of generating the second identity where the information is precise and readily available, i.e., at the network device;
(3) experts discussed the issue of a shorter QoE reference ID between the RAN and the terminal in over 20 contributions referenced in Report of 3GPP TSG RAN WG2 meeting #115-e, published before the effective filing date of the present application indicating both a local ID at the terminal – See, e.g., 3GPP TSG-RAN WG2 Meeting #115-e, R2-2108206, Title: “Discussion on QoE measurement configuration and reporting,” Source: Huawei, HiSilicon, (hereinafter 3GPP R2-2108206) and short ID between the base station and the terminal – See, e.g., 3GPP TSG-RAN WG2 Meeting #115-e, R2-2107816, Title: “QoE configuration and Reporting,” Source: Qualcomm, published August 2021, (hereinafter 3GPP R2-2107816); hence this reason is a tie;
(4) a person of ordinary skills in the art appraised of the determination of a shorter ID at the network access device, e.g., from the disclosure in Liu, U.S. Patent Application Publication No. 2024/0107358 (hereinafter Liu1) would find it obvious to generate the same at a terminal once the principles/logic/information underling the generation algorithm is in prior art, as explained in Footnote 8 of the NFOAM dated 03/03/2026, hence this reason tends to point towards no harm in generating the second identity at the terminal.
Therefore, Applicant argument that the present disclosure supports a terminal generating the second, shorter identity, based, among others, on the cell identity of the network device is unpersuasive and expert opinion may be required to decide upon inventor’s intent.
Second, Applicant argues that Liu1 “fails to disclose or suggest the internal apparatus-to-apparatus communication within the terminal device as recited in the claims,” specifically “is entirely silent regarding any such internal communication between distinct apparatuses within the terminal device” and “merely discloses communication between the terminal device and the network device, not internal coordination between a first apparatus and a second apparatus both residing at the terminal device” – See Resp., p.18, ¶2. First, Applicant seems unfamiliar with the technical aspects of how the Access Stratum communicates with the Application layer, the two artificially-distinct apparatuses identified at a terminal device in, e.g., Fig. 2 of the present application, identical with in Figs. 2 and 5 of Liu1. Liu1 uses 3GPP specifications related to QoE measurements, e.g., 3GPP TS 28.405 V16.1.0 (2021-09), “Technical Specification Group Services and System Aspects; Telecommunication management; Quality of Experience (QoE) measurement collection; Control and configuration (Release 16)” (hereinafter 3GPP TS 28.405), showing in §4, Figure 4.2.1-1, the QMC activation and reporting in LTE, reproduced hereinafter:
PNG
media_image1.png
236
542
media_image1.png
Greyscale
Figure 4.2.1-1: QMC activation and reporting in LTE
Although Applicant argues about an allegedly distinguishable “internal coordination communication between distinct apparatuses within the terminal device,” the argument fails to consider the teaching in Liu1 and 3GPP specifications that the “distinct apparatuses within the terminal device” are embodied in terminal’s Access Stratum and Application layers, even when the present Specification teaches the same – See [¶0033] (“For NR/LTE QoE measurement collection (QMC) mechanism, there is an air interface support required (coordination between the UE and the gNB), as well as internal coordination in the UE (between UE’s Access Stratum and Application layers”) (emphasis added); see also [¶0036](“According to embodiments of the present disclosure, a terminal device is able to coordinate between an Access Stratum layer and an Application layer to associate the QoE configuration with the corresponding reports, and in this way, it enables unique identification of a single QoE configuration, as well as the corresponding QoE report at the terminal device”). Applicant’s argument completely eschews the protocol used for “internal coordination between a first apparatus and a second apparatus both residing at the terminal device” based on AT commands as disclosed in Liu1 supra and known to one of ordinary skills in the art – See, e.g., 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), at page 19, stating: “AT commands are used as an internal interface within the physical handset, e.g. between the application and the radio interface layer 3 stack implemented on different processors” whereby the AT commands may “transfer identities” between the application layer and the RRC layer, i.e., the second and the first device at the terminal; furthermore, as specified in §§ 8.78 & 8.79, at pages 218-219, the first device (RRC or AS level), transmits an “[a]pplication level measurement configuration +CAPPLEVMC” command to “control of the application level measurement configuration according to 3GPP TS 25.331 [74] and 3GPP TS 36.331 [86]” comprising “the application level measurement configuration file for the application indicated by the <app-meas_service_type>” and receives an “[a]pplication level measurement report +CAPPLEVMR” that “allows the MT to provide the application level measurement report according to 3GPP TS 25.331 [74] and 3GPP TS 36.331 [86].” This information is perfectly aligned with the present Specification – See, e.g., [¶0050] (“the QoE configuration and the second identity may be transmitted in an AT command+CAPPLEVMC. The AT command+CAPPLEVMC may indicate the service type. The AT command+CAPPLEVMC may also comprise the container of the QoE configuration”); accord Liu1:[¶¶0104-05](“The +CAPPLEVMC sent by the UE AS layer to the APP layer contains the same information” and “[t]he APP layer sends+CAPPLEVMR including the second identity information and a QoE measurement report to the UE AS layer”). Therefore, the present Specification clearly belies Applicant’s arguments against Liu1 as failing to disclose or suggest the “internal apparatus-to-apparatus communication within the terminal device as recited in the claims” and their purported “internal coordination” and/or defies an argument that disclosure of two apparatuses at the terminal device communicating/coordinating internally regarding an application layer QoE job and report would not have been readily available to one of ordinary skills before the effective filing date of the present Application. To conclude regarding Applicant’s main arguments against Liu1, it is rather unsettling that the same arguments were addressed by the examiner in the previous NFOAM dated 03/03/2026 wherein examiner responded by explaining the very concepts Applicant argues about here, with no consideration for the technical details outlined therein.
Applicant further argues that “Liu1 does not disclose multiple QoE configurations for the same service received from multiple network devices” – See Resp., p.21:¶2. Examiner respectfully disagrees and points to Liu1:[¶0038] (stating: “the communication systems in embodiments of the present disclosure . . . may be applied to a Dual Connectivity (DC) scenario”) and Liu1: [¶0108] (“It can be seen that when 5G NR supports multiple simultaneous QoE collections and reports and the applications corresponding to these QoE collection activities belong to different network slices”) whereby DC implies the terminal receives services from multiple network devices and different network slices means service may be received from different Network Function implementations, i.e., “network devices”. Furthermore, because in Liu1 “the gNB needs to perform mapping of first identity information (QoE reference ID) to second identity information (RRC level ID)” – See [¶0103], each gNB, whether it is a Master Node (MN) or Secondary Node (SN) in DC configuration or a multi-RAT Distributed Unit (DU) would conduct its own QMC jobs. Therefore, this argument is also unpersuasive.
Applicant further argues that “[b]ecause the mapping is maintained at the network device
rather than the terminal device, the terminal device in Liu1 cannot make a determination as to
which network device to send a QoE report based on identity mappings” – See Resp., p.21:¶2. However, Applicant failed to notice that Liu1 explicitly teaches that “[t]he gNB sends measurement configuration information to the UE AS layer through RRC reconfiguration information (RRCConnectionReconfiguration signaling),” i.e., the UE being in RRC_CONNECTED mode knows precisely which network device requested a QoE report based on the QMC file contents because “The measurement configuration information includes the second identity information (RRC level ID), a service type and a QMC configuration file” – See [¶0104]. To the contrary, there is no teaching in the present disclosure that the second identity, allegedly “generated” at the terminal based on, inter alia, “the cell identity of the second device 120” – See Spec:[¶0064] is anywhere shared with the base station/network device, hence begging the question: if the second identity is only used between the layers of the terminal why would the cell identity of the network device be used to generate the second identity? The Specification does not offer an answer to this question.
Therefore, while Liu1 can be easily modified to generate the second identity at the terminal because in Liu1 “[t]he access network device determines the second identity information . . . carries the second identity information in the measurement configuration information, so that the terminal device returns the QoE measurement report and the second identity information,” i.e., the network device and the terminal share common knowledge about the second identity, the present Application does not teach whether and how the network device gains knowledge of the second identity allegedly “generated” by the terminal. Therefore, the second identity being generated at the terminal and used only between the first apparatus and the second apparatus at the terminal is rather a narrow feature that could be implemented by a person of ordinary skills in the art using a generic “id generating” function hashing into the received QoE Reference ID1 with any other variable, e.g., a cell identity, because, as the case is here, the functional language of the “generating” limitation in the independent claims does not have logic/detail support in the Specification on how to implement the “generating” function. Specifically, the use of a cell identity of the network device in addition to QoE Reference ID, as indicated in some parts of the Specification, raises the question of which cell identity to use because the terminal may be in dual connectivity (DC) and/or use carrier aggregation, whereby the QoE measurement configuration (QMC) is received from one base station and/or cell for another base station and/or cell, e.g., the MN/PCell for the SN/PSCell in DC2, as known in the art, hence the UE is using multiple cells at once for fulfilling the same QMC job. Thus, it would have been obvious for a person of ordinary skills in the art before the effective filing date of the present Application to implement an identity generation function at the terminal in Liu1 motivated by the need to coordinate the QMC job between the AS layer and the Application layer as clearly shown in Fig. 5 of Liu1, and further name that identity a “second identity” different from the second identity generated in Liu1 by the network device.
The argument regarding Liu1’s QoE reporting during or after a handover procedure was answered in the NFOAM dated 03/03/2026 and in any case is inapposite because this scenario is not used or referenced in the NFOAM.
The arguments against Liu2 are very similar to those against Liu1 and similarly lack the foundational understanding of terminal’s layered architecture and the AT commands for communication between layers. Therefore, they are unpersuasive for the same reasons as the arguments against Liu1 addressed supra.
The argument against Hu, U.S. Patent Application Publication No. US 2023/0379743 (hereinafter Hu) – See Resp., p.19:¶3 is inapposite because Hu was not used as prior art reference in the NFOAM dated 03/03/2026. Hu was the primary reference in Application # 18/703,007 (same Assignee), now abandoned.
In sum, many of Applicant’s arguments are not on point and most arguments lack persuasiveness. While the Applicant has a duty to zealously argue of client’s behalf, the arguments must be rooted in the technical foundations of the art to which the claimed invention belongs and be guided by the laws and guidelines governing the Office, including the patent lawyer not being “inventive” in the layman’s sense of the word, or directly importing "‘extraneous’ limitations from the specification" into claim interpretation – See Corning Glass Works, 868 F.2d 1251,1257. To be fair to the Applicant, the Amended Application will be examined under the assumption that the second identity is generated at the terminal and used between the first and the second apparatus at the terminal, as zealously argued by the Applicant, although the Specification lacks clear and unequivocal support for the limitation “generating” a second identity at the terminal, as explained supra.
If Applicant thinks that the examiner is wrong and/or made many errors during the examination pf the present Application, Applicant may direct such concerns to examiner’s SPE whose name and contact are listed at the end of this 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.
Claims 1, 12, and their dependent claims are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains 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 Amended Claim 1, the claim was amended to specifically require “generating, 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 QoE configuration of the service,” instead of “determining” as originally claimed.
MPEP § 2161.01 (I) states that “claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” and this may be the case “when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed”; see also MPEP §§ 2163.02 (stating that “[a]n objective standard for determining compliance with the written description requirement is, ‘does the description clearly allow persons of ordinary skill in the art to recognize that he or she invented what is claimed,’” citing In re Gosteli, 872 F.2d 1008, 1012; and “[i]f a claim is amended to include subject matter, limitations, or terminology not present in the application as filed, involving a departure from, addition to, or deletion from the disclosure of the application as filed, the examiner should conclude that the claimed subject matter is not described in that application,” i.e., new matter was added)
Here, the Specification states that in some cases, “the first apparatus 210 may determine the first identity to be the second identity” – See [¶0047]; [¶0064] and “if the QoE report is with the second identity and the second identity is mapped to the first identity, the first apparatus 210 can transmit the QoE report to the second device 120” – See [¶0056];[¶0070]. Therefore, in these cases there is no new second identity “generated” by any special algorithm allegedly disclosed in the Specification and “the QoE report can comprise the first identity received from the second device 120,” i.e., the network device – See [¶0056]; [¶0070].
The Specification also states that in other cases, “the first apparatus 210 may determine the second identity based on the first identity and other identity information,” e.g., “the first identity and cell identity of the second device 120” and further states that “the second identity can be generated” so that “QoE configuration can be uniquely identified at the first device 110-1” – See [¶0047]; [¶0064] without being specific about the logic and/or means required when the second identity is obtained from the first identity and other information, e.g., a cell identity, hence failing to provide sufficient written description for the “generating” function as required by 35 U.S.C. §112 (a).
The limitation “generating, by the first apparatus at the terminal device, based at least in part on the further first identity, a further associated identity associated with the further OoE configuration of the service” suffers from the same deficiency because the Specification merely repeats the same language as amended to the independent claims – See, e.g., [¶0048] (stating only that “the first apparatus 210 may generate a further associated identity for the further QoE configuration”) and remains completely silent as to the logic or means of obtaining or determining this further identity.
In sum, Amended Claims 1, 12, and their dependent claims are rejected under 35 U.S.C §112(a) for lack of sufficient 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.
Amended Claims 3, 14, 21, 22, and their dependent claims recite the limitation "the cell identity of the network device". There is insufficient antecedent basis for this limitation in the claim.
MPEP § 2173.05(a) provides that “[t]he meaning of every term used in a claim should be apparent from the prior art or from the specification and drawings at the time the application is filed. Claim language may not be ‘ambiguous, vague, incoherent, opaque, or otherwise unclear in describing and defining the claimed invention’” citing to In re Packard, 751 F.3d 1307, 1311, 110 USPQ2d 1785, 1787 (Fed. Cir. 2014), and further provides that Applicants “are required to make clear and precise the terms that are used to define the invention whereby the metes and bounds of the claimed invention can be ascertained” because “[d]uring patent examination, the pending claims must be given the broadest reasonable interpretation consistent with the specification” – See In re Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997); In re Prater, 415 F.2d 1393, 162 USPQ 541 (CCPA 1969); see also MPEP § 2111 - § 2111.01.
Here, the term “the cell identity of the network device” is unclear because a network device, e.g., a base station, serves multiple cells and the terminal may receive information, e.g. QoE configuration for one or more of those multiple cells either because the terminal is configured with carrier aggregation3 or configured in dual-connectivity (DC), whereby the UE may receive a QMC job from an MN/PSCell but the job refers to QoE of a service provided by the SN on one or more Scells and configures sending the QoE report to the SN on the SN PSCell, or because the UE is configured in carrier aggregation with a Pcell and several Scells with the same base station. Applicant could amend the claims to point precisely to a specific cell identity, e.g., the identity of a cell used for the service type for QoE measurement or the cell on which the terminal received the QMC job configuration from a network device or the cell in which the terminal sends the QoE report to a network device. An example is provided in Regarding Amended Claim 3 infra.
In addition, Amended Claims 3, 14, 21, 22, and their dependent claims, use the language “other identity information, in particular the cell identity of the further network device." This language renders the claim indefinite because the “[d]escription of examples and preferences is properly set forth in the specification rather than in a single claim. A narrower range or preferred embodiment may also be set forth in another independent claim or in a dependent claim. If stated in a single claim, examples and preferences lead to confusion over the intended scope of the claim” – See MPEP § 2173.05(c). Here, neither the claim language nor the Specification provide an intelligible principle to associate the preference for the cell identity as “other information,” leaving the scope of the claim wide open to any other interpretation of the “other information” term.
For these reasons, Amended Claims 3, 14, 21, 22, and their dependent claims are rejected under 35 U.S.C. § 112(b) for insufficient antecedent basis and indefiniteness.
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.
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, 4, 8-9,12, 15, 18-19, 23-24, 26-30 and 32-38, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Liu1 in view of 3GPP QoE-Features-Summary and Tdoc referenced therein as applied to Amended Claim 1 above, 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 (“The communication device 600 includes a processor 610, and the processor 610 may call and run a computer program from a memory to implement the methods in the embodiments of the present disclosure”– See [¶0155] and Fig. 9 and “the communication device 600 may further include a memory 620. The processor 610 may call and run a computer program from the memory 620, so as to implement the methods in the embodiments of the present disclosure,” – See [¶0156] i.e., the functions of the first apparatus because “the communication device 600 may be . . . the terminal device” – See [¶0160]), cause the first apparatus to perform at least:
receiving, by the first apparatus at the terminal device, from a network device, a quality of experience (QoE) measurement collection (QMC) activation message for a service and a radio resource control (RRC) configuration for a service (a “network device . . . sends QMC configuration information such as activationAreaQMCjob signaling to a base station such as eNB or gNB” – See [¶0057] 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] and Figs. 2 and 5 showing the UE comprising the first apparatus that receives the RRC Reconfiguration message from a network device)
wherein the RRC configuration comprises a OoE configuration for the service (“The QMC configuration file contains a QoE reference identity (QoE Reference ID)” – See id., whereby the RRCReconfiguration may comprise the measConfigAppLayer Information Element specifying the measConfigAppLayerContainer comprising the QMC configuration for the service type as described in the snippet of [¶0059] and in Fig. 5; see also §5.3.10.9, 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)” (hereinafter 3GPP TS 36.331) describing, at page 181, the UE receiving the measConfigAppLayer in RRCReconfiguration, specifying, at page 293, that “[a] UE capable of application layer measurement reporting in RRC_CONNECTED may initiate the procedure when configured with application layer measurement, i.e. when measConfigAppLayer has been configured by E-UTRAN” network device, and specifying, at page 739-740, the measConfigAppLayer IE described in Liu1; cf. 3GPP TSG-RAN WG2 Meeting #116-e, R2-2109865; Title: “Running CR for Introduction of QoE measurements in NR”; Source: Ericsson; published October 22, 2021 (hereinafter 3GPP R2-2109865), updating 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) with similar provisions for QMC configuration and QoE reporting configured at the UE in RRC_CONNECTED mode);
wherein the RRC configuration indicates a first identity associated with the QoE configuration for the service (“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 job – 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; furthermore, when the “QoE reference parameter must be globally unique” – See [¶0073] it may be constituted as all three parameters, i.e., “MCC+MNC+QMC ID” – See [¶0074]),
wherein the first identity is generated by the network device (when a “network device such as a Measurement Collection Entity (MCE) sends QMC configuration information” it contains “a QoE reference identity (QoE Reference Identifier, QoE Reference ID) and a QMC configuration file (QMC config.file )” – See [¶0057] wherein the first identity is generated by the network device because while MCC and MNC are unique within the scope of a base station/network access device, the “QMC ID is a 3-byte bit stream . . . used to identify a traffic node and the QoE measurement collection task” can then be used as QoE Reference ID inside the PLMN4 whereby “[t]he QMC ID is generated by the management system,” e.g., the network device – See [¶0074]), and
wherein the first identity comprises one of:
an RRC identifier (the “QoE reference parameter (QoE reference ID) is used to specify a network request session” – See [¶0073] e.g., the “Radio Resource Control (RRC) reconfiguration signaling (RRCReconfiguration signaling)” through which “the base station sends the service type (ServiceType) and the QMC configuration file to a terminal device” – See [¶0058] whereby the RRCReconfiguration message comprises the rrc-TransactionIdentifier – See 3GPP TS 36.331 specifying at page 394 the RRCReconfiguration Information Element (IE) comprising the rrc-TransactionIdentifier IE, and at page 743, the IE RRC-TransactionIdentifier “used, together with the message type, for the identification of an RRC procedure (transaction),” e.g., the transaction through which the terminal device receives the service type and the QMC configuration file from the network device wherein the rrc-TransactionIdentifier is generated by the network device),
a measurement application layer identifier, or
a container identifier (the RRCReconfiguration message supra contains the measConfigAppLayer IE for measurements that E-UTRAN may configure to the UE whereby “for the setting of RRCReconfiguration, reference may be made to the following description:”
PNG
media_image2.png
157
565
media_image2.png
Greyscale
– See [¶0059] indicating a measConfigAppLayerContainer associated with the QoE reference ID, i.e., a first identity, as shown in Figs. 2 and 5, whereby the measConfigAppLayerContainer is further described in 3GPP TS 36.331, at page 741, as “configuration of application layer measurements, see Annex L (normative) in TS 26.247” whereby 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.2475) in Annex L.1 at page 136 specifies that “[t]he QoE configuration will be delivered via RRC to the UE as a container according to . . . ‘measConfigApplicationLayer’ (see [59]) for LTE” as “an octet string with a maximum length of 1000 bytes, . . . expected to conform to XML-formatted QoE configuration data according to clause L.2 in the current specification”; see also Annex L.2 at page 137 providing that “qoeReferenceId is a reference set by the network side (see [63]), which is not directly used by the client” that “shall be copied into each QoE report, to facilitate network-side correlation” whereby “the client” is defined in § 10.1, at page 38, as “[a] progressive download or 3GP-DASH client supporting Quality of Experience (QoE) [that] shall report QoE metrics according to the QoE configuration” mainly an Application level apparatus, further providing that “QoE configuration shall only be checked by the client when each session starts, and thus all logging and reporting criterias for an ongoing session shall be unaffected by any QoE configuration changes received during that session”; in sum, because the QMC ID, the QoE reference ID, and the rrc-TransactionIdentifier of the RRCReconfiguration message containing the measConfigApplicationLayerContainer are idempotent in that they remain the same during the execution of a QMC job/task at the UE (because the QoE configuration is only checked by the client when each session starts hence these identifiers remain the same until the end of the QoE measurement collection session), hence the first identity may comprise any of these elements);
receiving, by the first apparatus at the terminal device, from a further network device, a further OoE configuration for the service and a further first identity associated with the further OoE configuration for the service (because “the communication systems in embodiments of the present disclosure . . . may be applied to a Dual Connectivity (DC) scenario” – See [¶0038] whereby, as known in the art, “multiple Rx/Tx UE in RRC_CONNECTED is configured to utilise radio resources provided by two distinct schedulers, located in two eNBs” – See 3GPP TS 36.300 V16.2.0 (2020-07), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 16)” (hereinafter 3GPP TS 36.300), reference [9] in 3GPP TS 36.331, further specifying, at page 54, that “Dual connectivity between E-UTRAN and NR is specified in TS 37.340”, whereby 3GPP TS 37.340 V16.7.0 (2021-09), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-connectivity; Overall description; Stage-2 (Release 16)” (hereinafter 3GPP TS 37.340) and reference [81] in 3GPP TS 36.331, specifies, at page 18, that “Measurements can be configured independently by the MN and by the SN (intra-RAT measurements on serving and non-serving frequencies),” i.e., when the MN already sent the service type (ServiceType) and the QMC configuration file to a terminal device for QoE measurement reporting, a further network device, the SN, may follow the same procedure described in Liu1 supra to send a further OoE configuration for the same service as the MN requested and a further first identity associated with the further OoE configuration for the same service, as requested by the SN through its own RRCReconfiguration message with the terminal device because the UE is “supporting simultaneous executions of different QoE collection sessions for the same service type” – See [¶0132]; it would then be obvious to a person of ordinary skills in the art that the QMC ID/QoE ReferenceID and the rrc-TransactionIdentifier of the RRCReconfiguration message containing the measConfigApplicationLayerContainer from the further network device would be different from those sent by the first network device supra because in DC the terminal device has two separate RRC connections to each of the MN and SN base stations and even the QoE reference IDs constituted using the rule in Liu1:[¶¶0073-74] would be different because the MN and the SN may be connected to two different CNs),
generating, by the the first identity information may be a QoE reference identity . . . the second identity information is determined according to the first identity information” – See [¶0082] and because the UE is “supporting simultaneous executions of different QoE collection sessions for the same service type” – See [¶0132] (emphasis added) e.g., supporting simultaneous QMC jobs from both the MN and the SN when the UE is configured in DC as explained supra, whereby the first identity, i.e., the “QoE reference parameter (QoE reference ID) is used to specify a network request session,” – See [¶0073] e.g., a “Recording Session Id” for each of the MN and SN QoE measurement sessions, as shown in Figs. 2 and 5, the second identity may comprise a session id locally generated by the UE for QoE measurement collection and reporting, e.g., as specified in §10.6.2 of 3GPP TS 26.247 stating, at page 52, that “If the attribute qoeReferenceId was defined in the QMC configuration (see clause L.2), the value shall be copied into each QoE report, to facilitate network-side correlation (see [63]). If this attribute was defined the attribute recordingSessionId shall also be returned for each QoE report. The recordingSessionId is a two-byte octet defined by the client.” (emphasis added), whereby the client is a streaming service client at the terminal device, hence the recordingSessionId is an example of a second identity generated by the terminal device based in part on the presence of qoeReferenceId, i.e., the first identity, and further specifying, at page 48, that a QoE report formatted as an XML document that complies with the XML schema “’application/3gpdash-qoe-report+xml’ as defined in Annex J” may comprise:
PNG
media_image3.png
24
505
media_image3.png
Greyscale
in accord with Figs. 2 and 5 of Liu1 showing that a second identity information, there generated by the network device6, is uniquely associated (at least in the measurement report information) with a “Recording session ID” specifically generated by the terminal for QoE measurements collection purposes; accord 3GPP TS 28.405 V16.1.0 (2021-09), “Technical Specification Group Services and System Aspects; Telecommunication management; Quality of Experience (QoE) measurement collection; Control and configuration (Release 16)” (hereinafter 3GPP TS 28.405) showing in §4, Figure 4.2.1-1, the QMC activation and reporting in LTE reproduced supra),
generating, by the communication systems in embodiments of the present disclosure . . . may be applied to a Dual Connectivity (DC) scenario” – See [¶0038] the same procedure applies as described in Liu1 for the terminal device to generate a second identity for the QMC job sent by the SN, i.e., the further network device, with the further first identity and it would be obvious to a person of ordinary skills in the art that this further second identity is uniquely associated with a further recordingSessionId because the streaming session to be measured may be provided through the SN and §10.6.2 of 3GPP TS 26.247 provides, at page 52, that recordingSessionId “should be different for QoE reports belonging to different streaming sessions,” e.g., when streaming sessions are different depending on whether the UE streams through the MN or the SN network device; in addition Liu1 teaches “supporting simultaneous executions of different QoE collection sessions for the same service type” – See [¶0132] hence different QoE collection sessions must have different recordingSessionId values in Figs. 2 and 5);
transmitting, by the first apparatus at the terminal device, to a second apparatus at the terminal device, the QoE configuration of the service and the second identity associated with the QoE configuration of the service and/or transmitting, by the first apparatus at the terminal device, to the second apparatus at the terminal device, the further QoE configuration of the service and the further associated identity associated with the further QoE configuration of the service (as shown in Figs. 2 and 5, the terminal device comprises two apparatuses: the UE Access Statum responsible, inter alia, for the RRC layer messaging, and the UE Application level responsible for Application layer functions, e.g., initiating and maintaining streaming sessions; furthermore, “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] i.e., using AT commands known to a person of ordinary skills in the art before the effective filing date of the present Application, e.g., from 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) as provided in § 8.78 at page 218, whereby the +CAPPLEVMC command contains <app-meas_service_type> and <app-meas_config-file> parameters, i.e., service type and QMC configuration file, whereby, as taught in Liu1, “[t]he measurement configuration information . . . 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 Liu1:[¶0080] i.e., the second identity in Liu1 is included in the measurement configuration information sent to the second apparatus albeit the second identity is generated by the AS of the network device not by the AS/first apparatus of the terminal device);
receiving, by the first apparatus at the terminal device, from the second apparatus at the terminal device, a QoE report of the service with the second identity associated with the OoE configuration of the service and/or a OoE report of the service with the further associated identity associated with the further OoE configuration 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 Figs. 2 and 5; see also 3GPP TS 27.007 specifying in § 8.79 at page 219 the +CAPPLEVMR command containing the <app-meas_report> parameter whereby the measurement report information contains the “Recording session ID” as shown in Fig. 5 of Liu1 as an example of generated second identity at the terminal device that is uniquely associated with the first identity, the QoE reference ID, as shown in the snippet reproduced from §10.6.2 of 3GPP TS 26.247 and as explained supra);
in response to the OoE report being with the second identity and the second identity being mapped to the first identity (“the second identity information is determined according to the first identity information” – See [¶0082]), or
in response to the OoE report being with the further associated identity and the further associated identity being mapped to the further first identity (as shown in Fig. 5, the “Recording session ID”/“log ID” of the recorded measurement collection is mapped with the QoE Reference ID in the measurement report information sent by the Application layer apparatus, whereby “[t]he APP layer sends+CAPPLEVMR including the second identity information and a QoE measurement report to the UE AS layer” – See [¶0105] wherein the second identity information may be the Recording session ID generated as explained supra or a local ID at the first terminal as further explained infra)
determining, by the first apparatus at the terminal device, that the QoE report is to be transmitted to the network device or the further network device (because, as shown in Fig. 5, the measurement report information comprises a QoE Reference ID and the “QoE reference parameter (QoE reference ID) is used to specify a network request session” – See [¶0073] the first apparatus at the terminal device determines the network device based on the QoE Reference ID); and
in response to the determining that the QoE report is to be transmitted to the network device or the further network device,
transmitting, by the first apparatus at the terminal device, to the network device, the QoE report of the service with the first identity or to the further network device, the QoE report of the service with the further first identity (“the QoE reference ID needs to be sent along with the measurement report every time the report is sent over the air interface (for example, when the report is sent from the UE AS to the gNB)” – See [¶0075]; the same applies when the terminal device is in DC and receives QMC configurations for independent QoE measurement reporting from and to both the MN and the SN).
While Liu1 teaches the terminal device generating a second identity for the QMC measurement collection session, e.g., the “Recording session ID” as shown in Figs. 2 and 5, and further specified in 3GPP TS 26.247, at page 52, for QoE measurement of streaming service type (stating “Note: If the attribute qoeReferenceId was defined in the QMC configuration (see clause L.2), the value shall be copied into each QoE report, to facilitate network-side correlation (see [63]). If this attribute was defined the attribute recordingSessionId shall also be returned for each QoE report.”), Liu1 does not teach that this second identity is a RRC layer/Access Stratum identifier, i.e., a first apparatus generated identity, and that the second identity is further sent by the first apparatus at the terminal device to the second apparatus at the terminal device.
3GPP-QoE-Features-Summary “summarizes proposals related to QoE configuration and reporting from contributions submitted to agenda item 8.14.2.1, except for Mobility” referencing the said contributions – See 3GPP-QoE-Features-Summary at page 1.
For example, 3GPP-QoE-Features-Summary reference [8], Tdoc R2-2108206, Title: “Discussion on QoE measurement configuration and reporting,” Source: Huawei, HiSilicon, (hereinafter 3GPP R2-2108206), discloses in § 2.2, at page 5, Proposal 2 (use a “local ID to identify a QoE configuration within RRC signaling”) when “an ID with a length of 4 bits would be sufficient to identify the QoE configuration of a UE.” The motivation for the local ID in 3GPP R2-2108206, expressed at page 4, is different from and in addition to reducing RRC signaling, as stated in most prior art. Specifically, because “RAN3 and RAN2 agreed to support the multiple QoE configurations in one message” this leads to “the QoE reference ID for the multiple QoE configurations may be the same if these QoE measurements have the same consumer address” hence “[t]he QoE reference ID cannot be used to identify a specific single QoE measurement/configuration” at the terminal device.
3GPP R2-2108206 further describes at page 4 a method to generate, at the terminal device, this local ID at the RRC layer based on using RRC “toAddMod and toRelease lists for configuration of multiple QoE configurations, as already implemented in the current running RRC CR for QoE”7; “the elements of the list must contain an identity (INTEGER) that identifies the elements unambiguously upon addition, modification and removal,” i.e., each of the QoE configurations received at the UE must be locally associated with a RRC local ID, and further proposes “to define an IE for that identifier (here ElementId) so that it can be used both for a field inside the element as well as in the elementsToReleaseList” using as example the snippet from “section ‘A.3.9 Guidelines on use of ToAddModList and ToReleaseList’ of TS 38.331”; see also 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 specifying in Annex A.3.9, at page 917, that “a list [is] maintained in the receiver (typically the UE)” wherein the ElementId is a “local ID type” as specified in Annex A.3.4, at page 913, stating: “Local IE type definitions . . .may be included in the ASN.1 section and be referenced in the other IE types defined in the same ASN.1 section,” i.e., the ElementId identifying an Element, e.g., one QoE measurement configuration, in the ToAddModList, is generated locally by the RRC layer at the terminal device, i.e., by the first apparatus of the device (otherwise the ElementId must be shared with the network through another RRC message, hence referenced outside the ASN.1 section where it is defined8).
Thus, Liu1 and 3GPP QoE-Features-Summary each teaches a first apparatus and a second apparatus at a terminal device receiving multiple QoE configurations for a service through RRCReconfiguration signaling from the network device interested in receiving the configured QoE measurements report, whereby the QoE configuration for a service type is a QMC task configuration information received from the network device with a first identity referenced by QoE Reference ID generated by the network device requesting the QMC task, the QoE configuration being based on a unique QMC ID and PLMN code (MCC+MCN). 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., an ElementId RRC parameter of type INTEGER used to identify each QoE measurement configuration information received by the terminal device from the network device for the same service type, as taught by 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary, could have been substituted in for the determination of a second identity at the terminal device as being the “Recording session ID” disclosed in Liu1, because both the ElementId RRC parameter in 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary and the “Recording session ID” disclosed in Liu1 are uniquely associated at the first apparatus of the terminal device with the QoE Reference ID, i.e., the first identity, the service type to report on and a started network request session9, hence they qualify as a second identity based in part on the first identity. 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 aligning Liu1 with the ASN.1 rules for RRC specification elements, as taught in 3GPP QoE-Features-Summary and also of generating a local RRC defined ID unique within the scope of the terminal device10, to uniquely identify a QoE configuration within one RRC message comprising multiple QoE configurations for Application layer measurements, as taught in 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary.
Although Liu1 in view of 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary teaches the reason and the mechanism of generating a local RRC ID at the first apparatus of the terminal device as the second identity, Liu1 in view of 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary does not teach that this local RRC ID is sent from the first apparatus to the second apparatus of the terminal device. However, 3GPP-QoE-Features-Summary reference [5] Tdoc R2-2107816, Title: “QoE configuration and Reporting,” Source: Qualcomm, published August 2021, (hereinafter 3GPP R2-2107816) teaches this limitation.
3GPP R2-2107816 acknowledges, at page 2-3, 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, i.e., the first identity disclosed in Liu1. Section 2.2 of 3GPP R2-2107816 further discloses at page 2 that another identifier, “an RRC level ID should be introduced” mainly for the purpose “[t]o identify one QoE configuration, and gNB can release or pause or resume the QoE configuration using RRC level ID,” i.e., perform signaling based QoE management procedures on the ongoing QoE measurements collection, implying an association between this RRC level ID and the “Recording Session ID” disclosed in Liu1. Specifically, “it is enough that RRC level ID is unique . . . within UE scope,” i.e., the RRC level ID as a second identity may be confined to the UE scope (such as between the first apparatus and the second apparatus), therefore generated at the UE rather than at the network device as taught in Liu1. For example, indicating that “we can introduce RRC defined ID, which is unique within the gNB scope or within UE scope to save RRC signaling” (emphasis added) the “Table 1 summarizes the advantages and disadvantages for three types of RRC level ID” at page 3-4 wherein in the case of an RRC defined ID Proposal 5 applies (“If there can be multiple QoE configurations provided to one application layer at the same time, then the RRC layer provides RRC defined ID together with QoE configuration to application layer,” i.e., the same purpose as for the local ID disclosed in (3GPP R2-2108206) followed by Proposal 6 (“Application layer forwards the RRC defined ID together with QoE measurement report to RRC layer”).
Therefore, 3GPP R2-2107816 teaches transmitting, by the first apparatus at the terminal device, to a second apparatus at the terminal device, the QoE configuration of the service and the second identity associated with the QoE configuration of the service in a case where the RRC defined ID is unique within the scope of the UE, i.e., between the first apparatus and the second apparatus of the terminal device. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the locally unique second identity generated by the first apparatus, as taught in 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary could have been transmitted by the first apparatus to the second apparatus at the terminal device as taught in 3GPP R2-2107816 referenced by 3GPP QoE-Features-Summary because both serve the same purpose: to uniquely identify locally multiple QoE measurement configurations of the same service type at the Application layer. Furthermore, a person of ordinary skill in the art would have been able to carry out the transmission addition through techniques known in the art. Finally, the addition achieves the predictable result of allowing multiple QoE configurations to be provided to one application at the same time so that the Application layer forwards the RRC defined ID together with QoE measurement report to RRC layer at the end of recording QoE measurements session as taught 3GPP R2-2107816 referenced by 3GPP QoE-Features-Summary.
Although Liu1 in view of 3GPP QoE-Features-Summary teaches the motivation for a RRC layer local ID and that RRC layer provides this RRC defined ID together with QoE configuration to application layer, Liu1 in view of 3GPP QoE-Features-Summary does not teach the relationship between the generation at RRC layer/Access Statum and the QoE measurement collection session at Application layer.
Liu2 teaches “operation for QoE configuration, measurement, and reporting” – See [¶0095] 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-Summary 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 first apparatus of the terminal receives, “RRC configuration including the QoE configuration and at least one of the service type associated with the QoE configuration . . . or the QoE reference associated with the QoE configuration, and forwarding at least the QoE configuration and the service type from the RRC layer to the application layer” – See [¶0105] and “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].
Like Liu1 in view of 3GPP QoE-Features-Summary, Liu2 further teaches generating a local RRC ID for the Recording session associated with the QoE measurement configuration when the measured application starts the service type (“process 400 includes deriving the RRC level identifier at the RRC layer based at least in part on the session start . . . indication from the application layer including the QoE reference and not including the RRC level identifier” – See [¶0104] (emphasis added) and “storing at the RRC layer, information associate 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]) and further teaches the base station may also receive that local RRC ID from the UE (“receiving, from a UE, information indicating at least one of a service type associated with a QoE configuration, an RRC level identifier associated with the QoE configuration, a QoE reference associated with the QoE configuration, or a QMC associated with the QoE configuration, wherein the information indicating the at least one of the service type, the RRC level identifier, the QoE reference, or the QMC indicates there is an ongoing QoE session for the QoE configuration at the UE (block 510)” – See [¶0109] and Fig. 5).
Liu2 further teaches transmitting, by the first apparatus at the terminal device, to a second apparatus at the terminal device, the QoE configuration of the service and the second identity associated with the QoE configuration of the service (“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 . . . 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” – See [¶0191] i.e., the RRC level ID is generated by the first apparatus e.g., when receiving the session start indication from the second apparatus, possibly from the Recording Session Id corresponding to the QoE Reference Id, and transmitted to the application layer so it can be used with the session stop indication because “[i]n a first aspect, the session start or stop indication includes the RRC level identifier, based at least in part on the RRC level identifier being received at the application layer” – See [¶0103] and the generation of the RRC level ID can be combined with this first aspect – See [¶0104] and a third aspect described in [¶0105]).
Furthermore, because Liu2 teaches in Fig. 1 an UE connected to multiple base stations11, e.g., UEs 120b and 102c, Liu2 also teaches and/or transmitting, by the first apparatus at the terminal device, to the second apparatus at the terminal device, the further OoE configuration of the service and the further associated identity associated with the further OoE configuration of the service by using the same procedure of generating and transmitting to the application layer the further local RRC level ID corresponding to the QoE measurement configuration (QoE reference ID and service type) received from a further base station/network device.
Thus, Liu2 and Liu1 in view of 3GPP QoE-Features-Summary each teaches generating a local identifier at the RRC level to identify a QoE measurement collection session at application layer started when the service type associated with the QoE measurement configuration information comprising the service type and a QoE reference ID received from a network device. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the RRC level ID generated by the first apparatus of the terminal device when the session start indication received from the second apparatus does not comprise the RRC level ID and provided to the second apparatus, i.e., the application layer, so that the application layer can use it as a second identity including this RRC level ID in the measurement recording session start/stop indication to the first apparatus, as taught in Liu2, could have been combined with the generation, at the RRC level, of the local ElementId associated with a QoE measurement configuration information taught in Liu1 in view of 3GPP QoE-Features-Summary (which includes the QoE Reference Id and the service type as taught in Liu1) because both the RRC level ID in Liu2 and the ElementId in Liu1 in view of 3GPP QoE-Features-Summary are generated at the first apparatus based in part on the QoE reference ID, i.e., the first identity, and both are used as a second identity associated with a QoE measurement recording session, including the case where the measurement report is sent by the UE to the base station with this second identity, as taught by Liu2. Furthermore, a person of ordinary skill in the art would have been able to carry out the combination through techniques known in the art. Finally, the combination achieves the predictable result of sharing an RRC level identifier associated with the QoE configuration between the RRC/AS layer, i.e., the first apparatus, and the Application layer, i.e., the second apparatus, as taught in Liu2 for faster communication between the two layers because the RRC level ID is shorter, e.g., only 4 bits, as taught by Liu1 in view of 3GPP QoE-Features-Summary (specifically in 3GPP R2-2108206 at page 5, stating “Proposal 2: Use the local ID to identify a QoE configuration within RRC signaling. The size of local ID can be FFS, but 4 bits seems sufficient”).
Therefore, Amended Claim 1 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Amended Claim 4, dependent from Amended Claim1, 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 network device (“The one or more processors may be configured to provide, to a base station and based at least in part on the session start or stop indication, information indicating at least one of the service type associated with the QoE configuration, the RRC level identifier associated with the QoE configuration” – See [¶0013], i.e., the first apparatus inherently stores the mapping between the network device from which it received the QoE configuration for the service type with the locally generated RRC level ID associated with that QoE configuration and service),
in particular via mapping the second identity to the first identity (“process 400 includes 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 Liu2:[¶0106] and Fig. 4, wherein process 400 is executed by the terminal device and the QoE reference ID identifies the QoE configuration being part of that configuration as taught in Liu1).
Therefore, Amended Claim 4 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Amended Claim 8, Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2 further teaches a second apparatus at a terminal device, (e.g., the UE Application level in Figs. 2 and 5 of Liu1 and Fig. 14 of Liu2; see also 3GPP TS 28.405 showing in §4.2.1, Figure 4.2.1-1, the QMC activation and reporting in LTE reproduced supra), 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 (“The processor 610 may call and run a computer program from the memory 620, so as to implement the methods in the embodiments of the present disclosure” – See [¶0156]), 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 associated with the OoE configuration of the service, 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 Liu1:[¶0104] whereby “the UE 120 may derive the RRC level ID at the RRC layer based at least in part on the session start . . .indication including the QoE reference and not including the RRC level ID” whereby “the UE 120 may derive the RRC level ID at the RRC layer ( e.g., based at least in part on the stored information associated with the mapping between the RRC level ID and the QoE reference, as described above). In this way, the RRC layer of the UE 120 can derive the RRC level ID according to the QoE reference received from the application layer of the UE 120” – See Liu2:[¶0193] and then QoE measurement recording “session . . . stop indication includes the RRC level identifier, based at least in part on the RRC level identifier being received at the application layer” – See Liu2: [¶0103] whereby the two aspects of generating and transmitting the RRC level ID, i.e., the second identity, to the application layer are combinable – See Liu2:[¶0104]).
Liu1 further teaches wherein the first identity is generated by the network device and provided 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 and wherein the first identity indicates the QoE configuration of the service (a network device “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 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),” i.e., a first identity – See [¶0058], whereby the “first identity information may be a QoE reference identity, which may contain at least one of: MMC, MNC and QMC ID” – See [¶0082] where “[t]he QMC ID is generated by the management system,” e.g. by the management system of the network device – See [¶0074] and 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),” i.e., provided to the AS/RRC layer apparatus at the terminal device – See [¶0058]),
wherein the first identity comprises one of: an RRC identifier, a measurement application layer identifier, or a container identifier, as explained in Regarding Amended Claim 1 supra, wherein the same limitation is recited with the same language.
Because Liu1 teaches “the communication systems in embodiments of the present disclosure . . . may be applied to a Dual Connectivity (DC) scenario” – See [¶0038], i.e., a UE connected to multiple network devices, hence receiving QoE measurement configuration commands from independently from an MN and an SN, as taught in 3GPP TS 37.340 supra, and Liu1 in view of 3GPP QoE-Features-Summary and Liu2 are combinable for reasons and through techniques explained in Regarding Amended Claim 1, the same reasoning explained supra applies to provide and/or receiving, by the second apparatus at the terminal device, from the first apparatus at the terminal device, a further OoE configuration of the service and a further associated identity associated with the further OoE configuration of the service, wherein the further associated identity associated with further OoE configuration of the service is generated by the first apparatus at the terminal device based at least in part on a further first identity.
Liu2 further teaches 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, the QoE report of the service with the second identity associated with the QoE configuration of the service (“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 [¶0091] whereby the application layer provides “a session start . . . indication based at least in part on initiating the QoE session, the . . . indication being provided from the application layer to an RRC layer of the UE, wherein the . . . indication includes at least one of a service type associated with the QoE configuration, an RRC level identifier associated with the QoE configuration, a QoE reference associated with the QoE configuration, or a QMC associated with the QoE configuration” – See [¶0100] and based on the indication “not including the RRC level identifier . . . deriving the RRC level identifier at the RRC layer based at least in part on the session start . . . indication from the application layer including the QoE reference” – See [¶0104] followed by “the RRC level identifier being received at the application layer” – See [¶0103]; hence the application layer, i.e., the second apparatus, measures a QoE of the service in a recording session id or ElementId as taught in Liu1 in view of 3GPP QoE-Features-Summary based at least on the QoE configuration of the service and the RRC level identifier, i.e., the second identity associated with the QoE configuration of the service and sent by the first apparatus to the second apparatus, as taught by Liu2 and explained in Regarding Amended Claim 1 supra wherein the same limitation is recited using the same language only from the perspective of the first apparatus receiving the QoE report from the second apparatus; furthermore, “[t]he application layer of the UE [that] initiate[d] a QoE session according to the QoE configuration . . . provides QoE measurements (per service type) to the RRC layer” – See [¶0091] whereby the QoE measuring “session . . . stop indication includes the RRC level identifier, based at least in part on the RRC level identifier being received at the application layer” – See [¶0103] hence indicating that the QoE report of the service with the RRC level ID, i.e., the second identity associated with the QoE configuration of the service, is ready to be transmitted to the RRC level, e.g., using the procedure taught in Liu1:[¶0105] (“The APP layer sends+CAPPLEVMR including the second identity information and a QoE measurement report to the UE AS layer”) modified in view of 3GPP QoE-Features-Summary and further in view of Liu2 to use the RRC level ID in Liu2 as second identity, the modification-combination being explained in detail in Regarding Amended Claim 1 supra).
Liu1 further provides that when the terminal device is configured in dual-connectivity (DC) – See ¶0038], i.e., a UE is connected to multiple network devices that may independently sent QMC jobs including QoE measurement configurations to the terminal device, a QoE report of the service is generated with the a further identity, as a first identity, associated with the further OoE configuration of the service as indicated by the QMC configuration file and transmitting, by the second apparatus at the terminal device, to the first apparatus at the terminal device, the QoE report of the service with the second identity associated with the QoE configuration of the service (each “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). The QMC configuration file contains a QoE reference identity (QoE Reference ID). Here, the base station binds the ServiceType to the IP address of the QoE collection entity,” – See [¶0058]; then “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” comprising the QoE Reference ID – See [¶0060] and “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] whereby “for the setting of measuremenntreportApplyer, reference can be made to the following description:”
PNG
media_image4.png
155
580
media_image4.png
Greyscale
– See [¶0063] i.e., the report is generated at the second apparatus and sent with the further identity and includes the service type measured for QoE, whereby the further associated identity associated with the further OoE configuration of the service, i.e., “the QoE reference ID needs to be sent along with the measurement report . . . when the report is sent from the UE AS to the gNB” – See [¶0075]).
Thus, the combination of Liu1 teachings (in the case of a further QoE configuration of the service and a further associated identity associated with the further QoE configuration of the service received by the second apparatus at the terminal device, from the first apparatus at the terminal device), with 3GPP-QoE-Features-Summary and further with Liu2 (in the case of receiving, by the second apparatus at the terminal device, from a first apparatus at the terminal device, a QoE configuration of a service and a second identity associated with the QoE configuration of the service), discloses all the limitations in the Amended Claim 8 whereby the three references are combinable through techniques readily available to a person of ordinary skill in the art and motivated by the reasons already explained in Regarding Amended Claim 1 supra. Therefore, Amended Claim 8 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Claim 9, dependent from Amended Claim 8, 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 (“providing a session start or stop indication based at least in part on initiating the QoE session, the session start or stop indication being provided from the application layer to an RRC layer of the UE, wherein the session start or stop indication includes at least one of a service type associated with the QoE configuration, an RRC level identifier associated with the QoE configuration” – See [¶0100] inherently associates the second identity, the RRC level identifier, with an identity of the second apparatus, i.e., the service type)
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 (“process 700 may include providing a session start or stop indication (i.e., an indication of an ongoing QoE session) at the UE, the session start or stop indication being provided from the application layer to a QoE server . . . includes at least one of a service type associated with the ongoing QoE session” – See [¶0127] whereby the RRC level identifier association with the service type must be persisted at the application layer because the session start or stop indication includes also the RRC level ID, as provided supra, and the indication of an ongoing QoE session at the UE must be available at any time to be sent to a QoE server together with the service type running at the application layer; 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 at page 135 and 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).
Therefore, Claim 9 is obvious over Liu1 in view of 3GPP QoE-Features-Summary 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 Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2 and the apparatus and devices of Amended Claim 1 execute the same steps as recited by Amended Claim 12, Amended Claim 12 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Amended Claim 15, dependent from Amended Claim 12, the claim merely recites the same steps executed by a first apparatus in Claim 4, as amended. Because each of those claims are obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, and the first apparatus is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, Amended Claim 15 is obvious over Liu1 in view of 3GPP QoE-Features-Summary 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 the same steps as recited by Amended Claim 18, Amended Claim 8 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Claim 19, dependent from Amended Claim 18, the claim merely recites the limitations as in Claim 9, only applied to the method in Amended Claim 18. Because each of the claims 9 and 18, as amended, is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, Claim 19 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Claims 23-24, 26-27, 29-30 and 32-33, as amended, dependent from Amended Claims 1, 8, 12, and 18, each obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, the combination 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 access stratum layer is an RRC layer, as applied to each of the independent claims (“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 Liu1:[¶0060] and Figs. 2 and 5; see also Fig. 14 of Liu2 and Fig. 4 of Liu3 showing that the first apparatus is an RRC layer apparatus; Figure 4.2.1-1: QMC activation and reporting in LTE, 3GPP 28.405, at page 11, showing the base station communicating through RRCReconfiguration messages with the the Access Stratum (AS) of the terminal device (UE) ). Because each of the Amended Claims 1, 8, and 12 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, each of the claims 23-24, 26-27, 29-30, and 32-33, as amended, is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Regarding Amended Claims 28 and 34, dependent from Claims 27 and 33, Liu1 view of 3GPP QoE-Features-Summary and further in view of Liu2 further teaches the second apparatus of claim 27 and the method of claim 33, wherein, in an instance in which
the second identity is associated with the first identity (as explained, e.g., in Amended Claims 1 and 4 supra),
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 network device associated with the first identity (“process 400 may include providing, to a base station and based at least in part on the session start or stop indication . . . the RRC level identifier associated with the QoE configuration” – See Liu2:[¶0101] after “deriving the RRC level identifier at the RRC layer based at least in part on the session start or stop indication from the application layer including the QoE reference” – See Liu2:[¶0104]; and the RRC level identifier, as a “second identity information and the QoE measurement report are sent by the AS layer to the gNB through the measurement report information (measReportAPPlayer message)” – See Liu1:[¶0106])
Because an instance in which the second identity (e.g., a local ID such as the TRRC level ID in Liu2) for a QoE measurement configuration for a service type is associated with the QoE Reference Id, i.e., the first identity identifier, was explained in Regarding Amended Claims 8 and 18 supra 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.
Regarding Claims 35 and 37, and 36 and 38, dependent from Amended Claims 1 and 12 and 8 and 18, respectively, they merely recite the same limitations as in Claims 4 and 9, respectively, only that the respective two apparatuses at the terminal device now communicated with a further network device and a further first identity, no different from the network device and eth first identity disclosed in Claim 4, and a further associated identity, no different from the second identity disclosed in Claims 4 and 9. Because both Liu1 and Liu2 teach the terminal device connected to multiple base stations and cells and Claims 1, 4, 8-9, 12 and 18 are each obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, each of the claims 35-38 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
In sum, Claims 1, 4, 8-9,12, 15, 18-19, 23-24, 26-30 and 32-38, as amended, are rejected under 35 U.S.C. §103 as obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2.
Claims 3, 14, and 21-22, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Liu1 in view of 3GPP QoE-Features-Summary and Liu2 as applied to Amended Claim 1 above, and further in view of Liu et al, U.S. Patent Application Publication No. 2024/0172027 (hereinafter Liu3), also provided in the IDS.
Regarding Amended Claim 3, dependent from Amended Claim 1, Liu1 in view of 3GPP QoE-Features-Summary and 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 generating the second identity by performing:
generating the second identity, by the first apparatus at the terminal device,
based on the first identity and other identity information (other information may be e.g., Recording Session Id associated with the QoE Reference Id as taught in Figs. 2 and 5 of Liu1, the ElementId integer indexing the ToAddModList of QoE configurations as taught in 3GPP R2-2108206 referenced by 3GPP QoE-Features-Summary or the RRC level ID associated with a QoE measurement configuration as taught in Liu2 and explained supra as part of session start stop indication). Because none of these “other information” identifiers depends on the network device, Liu1 in view of 3GPP QoE-Features-Summary and Liu2 teaches generating the further associated identity, by the first apparatus at the terminal device, based on the further first identity and other identity information when a further network device sends a QoE measurement configuration and/or a QMC job to the terminal device. To be sure, Liu1 in view of 3GPP QoE-Features-Summary and Liu2 also teaches the terminal device connected to two base stations – See Liu1:[¶0038] and that each “base station may support one or multiple (e.g., three) cells”– See Liu2:[¶0049] that may allow the terminal device configuration for carrier aggregation, i.e., use more than one cell of a base station for transmission on a larger bandwidth. However, Liu1 in view of 3GPP QoE-Features-Summary and Liu2 does not further disclose derivation rules for the second identity particularly based on the cell identity of the network device to which the terminal device is connected to receive QoE measurement configuration(s).
Liu3, like Liu1 in view of 3GPP QoE-Features-Summary and Liu2, teaches a first identity, “the application-level identifier,” that “may be a globally unique identifier, such as a 6-byte octet string that includes a combination of an MCC and an MNC to identify a PLMN that contains the OAM server and a QMC identifier that is generated by the OAM server identify a QoE measurement collection job to be carried out at the UE 120 (e.g., at the application layer)” – See [¶0065] and “access stratum identifier allocated to the QoE measurement configuration may be derived from the application-level identifier associated with the QoE measurement configuration” – See [¶0066].
Liu3 further teaches derivation rules for the generation of the access stratum identifier (“the access stratum identifier may be derived from the application-level identifier on one or more derivation rules, whereby the access stratum identifier may be a shortened (e.g., truncated) version of the application-level identifier” – See id. and Fig. 4) whereby the derivation may be performed at the base station or at the OAM server – See id..
Like Liu1 in view of 3GPP QoE-Features-Summary and Liu2, Liu3 teaches that the access stratum identifier (or RRC level ID) is unique within a bounded scope (“the access stratum identifier that is derived from the application-level identifier may be defined to be unique within the scope of a RAN that includes the base station 110 (e.g., to enable management-based QoE measurement), unique within the scope of a cell provided by the base station 110, or unique within the scope of the UE 120 (e.g., to enable signaling-based QoE measurement)” – See [¶0067]). The scope of “uniqueness” for this shorter RRC level ID may be represented as shown below, one scope being the terminal device scope as taught in Liu1 in view of 3GPP QoE-Features-Summary and Liu212:
[AltContent: textbox (Service on Cell2)]
PNG
media_image5.png
148
164
media_image5.png
Greyscale
[AltContent: textbox (UE Scope)][AltContent: ][AltContent: roundedrect][AltContent: textbox (Services on Cell1)][AltContent: textbox (UE1 App Layer)][AltContent: ][Relation: cs:rId17, dm:rId14, lo:rId15, qs:rId16][Relation: cs:rId22, dm:rId19, lo:rId20, qs:rId21]
Because Liu3 teaches derivation rules for “N-to-one (N:1) mapping between multiple application-level identifiers and the same access stratum identifier” and uniqueness of the access stratum identifier “within the scope of a cell provided by the base station” – See [¶0067] it would have been obvious for a person of ordinary skills in the art before the effective filing date of the present application to program the first apparatus to perform the generating the second identity for the QoE configuration to be uniquely identifiable within the scope of the UE based on the first identity (e.g., the QoERefX/Y/Z in the figure above) using a derivation rule based in particular on a cell id associated with the network device as shown in the figure above motivated by the need to identify the QoE measurements for a specific cell and using the common knowledge that the cell id is unique within the scope of a base station and the ids are standardized for LTE and NR independent of the base station. Similar reasoning applies to generating the further associated identity based on the further first identity and a cell identity of the further network device.
Thus, Liu1 in view of 3GPP QoE-Features-Summary and Liu2 and Liu3 each teaches generating an RRC level identity (second identity) based on a first identity that may be a globally unique identifier such as a QoE reference ID received from a network device. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the derivation rules using a cell identity, as taught in Liu3, could have been applied to the procedure of generating a second identity from the first identity in Liu1 in view of 3GPP QoE-Features-Summary and Liu2 because cell identity is RRC level/access stratum type of information readily available to the first apparatus in Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and Liu3 teaches that the derivation may happen in other devices than the base station – See e.g. [¶0066] (“an OAM server may derive the access stratum identifier based on the appropriate derivation rule(s) and provide the access stratum identifier to the base station 110 together with . . . the application-level identifier”), for example in the RRC layer of the terminal device – See, e.g., Liu2[¶0104] (“process 400 includes deriving the RRC level identifier at the RRC layer”) (emphasis added). Furthermore, a person of ordinary skill in the art would have been able to carry out the addition through techniques known in the art. Finally, the addition achieves the predictable result allowing N-to-one (N:1) mapping between multiple application-level identifiers and the same access stratum identifier now based on the identity of the cell delivering the service type as taught in Liu3, justified by the UE need to “provid[e], to a base station and based at least in part on the session start or stop indication, information indicating at least one of the service type associated with the QoE configuration”– See Liu2:[¶0006].
Therefore, Amended Claim 3 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and further in view of Liu3.
Regarding Amended Claim 14, as amended, dependent from Amended Claim 12, the claim merely recites the same steps executed by a first apparatus in Claim 3, as amended. Because Amended Claim 12 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and further in view of Liu2, and the first apparatus of Amended Claim 3 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2 and further in view of Liu3, Amended Claim 14 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2 and further in view of Liu3.
Regarding Amended Claims 21 and 22, dependent from Amended Claims 18 and 8, respectively, they merely recite the limitations in Amended Claim 3, only applied to the method in Amended Claim 18 and the second apparatus of Claim 8. Because each of the claims 8, and 18, as amended, is obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and the first apparatus of Amended Claim 3 is obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and further in view of Liu3, Claims 21-22, as amended, are obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and further in view of Liu3.
In sum, Claims 3, 14, and 21-22, as amended, are rejected under 35 U.S.C. §103 as obvious over Liu1 in view of 3GPP QoE-Features-Summary and Liu2, and further in view of Liu3.
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, discloses techniques for application level QoE measurements reporting;
Li et al., U.S. Patent Application Publication No. 2024/0031831 discloses activation and reporting of QoS/QoE when the UE is in MR-DC configuration;
Xu et al, China Patent Application Publication No. CN 113453247 discloses QoE reporting for a plurality of networks;
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 TS 37.340 V16.7.0 (2021-09), “Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-connectivity; Overall description; Stage-2 (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;
3GPP TSG-RAN2 Meeting # 115-e R2-2107816, Title: “QoE configuration and Reporting,” Source: Qualcomm, published August 2021;
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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 The use of a cell identity of the network device in addition to QoE Reference ID raises the question of which cell identity because the terminal may be in dual connectivity and/or use carrier aggregation, hence use multiple cells at once, making this limitation indefinite. Applicant could have amended by indicating a PCell/PScell/SpCell each of them being specifically configured to the terminal.
2 In addition, the QMC configuration file may indicate that the QoE measurement report be sent directly to the SN/PSCell.
3 See, e.g., Liu et al, U.S. Patent Application Publication No. 2024/0224347 (hereinafter Liu2) teaching that “[a] base station may support one or multiple (e.g., three) cells”– See [¶0049] hence a UE configured in carrier aggregation may use all three cells, each one identified by a cell identity.
4 See, e.g., [¶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”); see also 3GPP TSG-RAN WG2 Meeting #115-e, R2-2107816, Title: “QoE configuration and Reporting,” Source: Qualcomm, published August 2021, (hereinafter 3GPP R2-2107816), reference [5] of 3GPP-QoE-Features-Summary, 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.
5 This 3GPP technical specification is pertinent because Liu1 teaches that “the methods in the embodiments of the present disclosure may be used to transmit various types of services, for example, enhanced Mobile Broad Band (eMBB) . . . providing users with multimedia content, services and data” – See [¶0050].
6 But see 3GPP R2-2107816), reference [5] of 3GPP-QoE-Features-Summary, disclosing in § 2.2, at page 2, that “it is enough that RRC level ID is unique within gNB scope or within UE scope” hence intimating that the second identity, the RRC level ID, may be also generated at the UE not only at the network device, as taught in Liu1:[¶0079] (“a first access network device determines second identity information according to first identity
information in received QoE measurement collection configuration information”).
7 3GPP QoE-Features-Summary further provides at page 2 “the running RRC CR for QoE, R2-2108108” whereing “an RRC ID MeasConfigAppLayerId is used in the configuration of QoE (measConfigAppLayerAddModList) and in the reporting of QoE” – See Tdoc R2-2108108, Title: Running CR for Introduction of QoE measurements in NR,” Source: Ericsson, published August 2021 (hereinafter 3GPP R2-2108108) at page 742, introducing toAddMod and toRelease lists for configuration of multiple QoE configurations in the OtherConfig IE, at page 426, specifying the MeasConfigAppLayerId IE (visible globally) and at page 244 the MeasurementReportAppLayer IE. These updates to the 3GPP specification yield from a solution where the RRC defined ID is unique within the scope of the base station. This is a different approach than the one disclosed in 3GPP R2-2108206 which is tailored to a RRC level ID local to the UE and defined in the same place as the received QoE configurations, i.e., the RRC layer/Access Stratum of the UE.
8 This does not mean that the ElementId of a QoE measurement configuration received by the terminal device could not be shared with the network device – See, e.g., §4.2.1 of 3GPP TS 28.405, wherein Figure 4.2.1-1: QMC activation and reporting in LTE reproduced above is shown, specifying that only “[w]hen the application in the serviceType starts, the QMC is initiated” and then “[t]he application layer sends the AT command +CAPPLEVMR including a recording session indication that indicates that a session is started to the access stratum” wherein the “qoEReference and recordingSessionId” are associated “[w]hen the QMC is completed” and “[t]he qoEReference, Client Id [6] and [7] in the reporting container (that represent the UE request session), and recordingSessionId are needed in the QMC collection entity for post processing purposes,” i.e., the recordingSessionId is shared between the UE and the client network device while the recordingSessionId is generated by the UE, possibly the RRC layer, based on “the recording session indication that indicates that a session is started to the access stratum” – See id. Based on the provisions in Annex A.3.4, 3GPP Ts 38.331, at page 913, when the recordingSessionId is the ElementId identifying the QoE measurement configuration, such ElementId will have its own RRC Information Element of which the RRC ID MeasConfigAppLayerId Information Element disclosed in 3GPP-QoE-Features-Summary, at page 2 is an example.
9 The only difference between the “Recording session ID” in Liu1 or in 3GPP TS 26.247 and the local ID/ElementId disclosed in 3GPP R2-2108206 is that the former is likely generated (but not necessarily in a case where multiple QoE configurations are received for the same service type) at the second apparatus of the terminal device, i.e., the application layer, while the latter is certainly generated at the RRC layer.
10 The only usecase for sharing the mapping between the locally generated RRC defined ID with the network device disclosed in 3GPP R2-2108206 at page 5 is “the case of UE mobility” whereby “the target RAN also needs to send the QoE report of a measurement to the correct consumer address. Therefore, the target RAN node needs to know the relationship between QoE reference ID and the RRC ID received during handover preparation.”
11 Liu2 also teaches that “[a] base station may support one or multiple (e.g., three) cells”– See [¶0049] .
12 A person of ordinary silks in the art would appreciate now that using the local integer corresponding to/indexing each of the QoE measurement configurations in the RRC IE AddModList of QoE configurations disclosed in 3GPP R2-2108206 referenced by3GPP QoE-Features-Summary assures uniqueness within the UE scope but not within the cell or base station scope. Further uniqueness within the UE scope could be derived from using the Recording Session ID for each QoE measurement collection session together with the RRC level integer hence allowing signaling based pause/resume management procedure form the base station as taught in [¶0067].
Prosecution Insights