DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This communication is considered fully responsive to the amendment filed on 09/04/2026.
Objection to claims is withdrawn since it has been amended accordingly.
Rejection to claims under 35 USC § 112 is withdrawn.
Claims 30, 32-38, 40-46, and 48-49 are pending in the present application.
Response to Arguments
Applicant’s arguments filed 09/04/2026, pages 7-10, regarding the rejection to the claims 30, 32-38, 40-46, and 48-49 under 35 U.S.C. 103 have been fully considered but are moot because the arguments were drawn to features amended from dependent claim 31, 39, or 47 to independent claims, which have been addressed in the instant office action with previously identified prior arts by mapping the relevant teachings for more clarification thereof that read on said added features, thus rendering Applicant’s arguments moot.
In particular, Applicant argues that references Lee and Samdanis fail to disclose a NAS message, and that Samdanis fails to disclose an SST corresponding to AI operation types and a ‘mapping’ between the AI operation types and analytic identifiers.
This argument is moot and not persuasive. A rejection under 35 U.S.C § 103 is based on combination of references, not a single reference’s disclosure. The framework of a WTRU (UE) sending a NAS message to request network analytics is clearly taught by the primary reference, Chen.
Furthermore, Applicant’s assertion regarding the lack of “mapping” structure is factually incorrect. Figures 1 and 2 of Samdanis explicitly illustrate of mapping table between produced management services (e.g., Analytics types) and their corresponding attributes. Samdanis explicitly teaches in paragraph [0156] that “each service of each registered function… is mapped to one or more attributes.”. These attributes expressly include both artificial intelligence (AI)/machine learning (ML) algorithm options and the target scope S-NSSAI (SST) (see paragraphs [0136], [142-0145] of Samdanis). Additionally, Lee specifically teaches using an ‘Analytics ID’ information element to identify the requested analytics in this exact 3GPP environment (see paragraph [0113] of Lee).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate the identifier scheme of Lee and the explicitly mapped AI attribute structure of Samdanis into the NAS message framework of Chen. The rejection is maintained.
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.
Claim(s) 30, 33, 35-36, 38, 41, 43-44, 46, and 49 rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (U.S. Patent Application Publication No. 20230388360, hereinafter “Chen”) in view of Lee et al. (U.S. Patent Application Publication No 20200358689, hereinafter “Lee”), and further in view of Samdanis et al. (U.S. Patent Application Publication No. 20220272510, hereinafter “Samdanis”).
Examiner’s note: in what follows, references are drawn to Chen unless otherwise mentioned.
With respect to independent claims:
Regarding Claim 30, Chen teaches A wireless transmit receive unit (WTRU) (Fig. 4, UE) comprising:
a processor (Fig. 7, processing unit 701) configured to:
send a non-access stratum (NAS) message indicating a request for network analytics(paras [0141-0143]: Step S401: UE sends first indication information to a first network element… The first indication information is used for requesting network information. A type of the network information includes network performance prediction information …. For example, the first indication information may be carried in a non-access stratum (non-access stratum, NAS) message.), the NAS message comprising one or more analytic identifiers (para [0110]: …. In a possible implementation, the first information includes an analytics identifier (Analytics ID) (interpreted as “analytic identifiers”)), (para [0108]:… where the first indication information indicates to obtain the network information. …In another example, the first network element locally configures and determines that network information requested by UE that accesses a specific slice (interpreted as “a slice service type (SST)”) and a specific network is the media parameter.) (The missing/crossed out limitation will be discussed in view of Lee (The missing/crossed out limitation will be discussed in view of Samdanis); and
receive an analytics message from a network node, wherein the analytics message indicates one or more network analytics (para [0148]: Step S404: The NWDAF network element receives the first information from the first network element.) (paragraphs [0150-152]: Step S405: The NWDAF network element obtains data information. For example, the data information is used for determining network performance prediction information, and the data information may be session bandwidth, user plane delay, mobility information of the UE, or positioning information of the UE, or the like. …Step S406: The NWDAF network element determines network performance prediction information based on the data information.) (paragraphs [0156-0159]: Step S408: The NWDAF network element sends network information to the first network element. For example, the network information includes network performance prediction information and/or a media parameter, and the network information may be carried in an Nnwdaf_AnalyticsSubscription_Notify(Nnwdaf_AnalyticsSubscription_Notify) message... Step S409: The first network element receives the network information from the NWDAF network element.) (para [0160]: Step S410: The first network element sends the network information to the UE (interpreted as “receive an analytics message from a network node”).)
Chen does not explicitly disclose that the aforementioned NAS message further comprises “a correlation identifier” inside the specific WRTU-initiated signaling container illustrated in Fig. 4 of Chen.
In analogous art, Lee explicitly discloses input parameters for invoking network data analytics service (NWDAF).
As disclosed in paragraphs [0091-0094], [0102], [0109-116], and [0219-0220] of Lee, Lee teaches when a consumer request or subscribes to network data analytics (‘Nnwdaf_AnalyticsSubscription_Subscribe’), the input signaling payload must conjunctively comprise a set of parameters including: (i) Analytics ID(s) (corresponding to “one or more analytic identifiers”); (ii) S-NSSAI (corresponding to “a slice service type (SST)”); and (iii) A Notification Correlation ID (corresponding to “a correlation identifier”). Paragraphs [0091-0094], [0102], [0109-116], and [0219-0220] of Lee are reproduced herein below.
[0091-0094] The following factors may be considered by the NF consumer for NWDAF selection: S-NSSAI. Analytics ID(s). NWDAF Serving Area information, i.e. list of TAIs for which the NWDAF can provide analytics.
[0102] If the service invocation is for a subscription modification, the NF service consumer includes an identifier (Subscription Correlation ID) to be modified in the invocation of Nnwdaf_AnalyticsSubscription_Subscribe.
[0109] 2. The NWDAF responds with analytics information to the NWDAF service consumer.
[0110] The input parameters are described in FIG. 2 and FIG. 3 including the service operation in following:
[0111] <Contents of Analytics Exposure>
[0112] The consumers of the Nnwdaf_AnalyticsSubscription or Nnwdaf_AnalyticsInfo service operations provide the following input parameters listed below.
[0113] A list of Analytics ID(s): identifies the requested analytics.
[0114] Analytics Filter Information: indicates the conditions to be fulfilled for reporting Analytics Information. This set of optional parameter types and values enables to select which type of analytics information is requested. Analytics Filter Information are defined.
[0115] Target of Analytics Reporting: indicates the object(s) for which Analytics information is requested, entities such as specific UEs, a group of UE(s) or any UE (i.e. all UEs).
[0116] (for Nnwdaf_AnalyticsSubscription) A Notification Target Address (+Notification Correlation ID), allowing to correlate notifications received from NWDAF with this subscription.
[0219] When the subscription is accepted by the Event provider NF, the consumer NF receives from the event provider NF an identifier (Subscription Correlation ID) allowing to further manage (modify, delete) this subscription.
[0220] The Notification Correlation ID is allocated by the consumer NF that subscribes to event reporting and the Subscription Correlation ID is allocated by the NF that notifies when the event is met. Both correlation identifiers can be assigned the same value, although in principle they are supposed to be different, as they are optimized for finding the subscription related context within each NF.
As reproduced above, Lee explicitly defines the purpose of the Notification Correlation ID, stating it is used “allowing to correlate notifications received from NWDAF with this subscription.” Furthermore, paragraph [0220] of Lee clarifies that correlation identifiers are assigned to ensure proper finding of the subscription-related transaction context within each network function in an asynchronous signaling environment.
It would have been obvious to one of ordinary skill in the art at the time of instant application to combine the teachings of Chen and Lee, and specifically to include a correlation identifier along with the Analytics ID and SST(‘specific slice’) within the explicit NAS request message sent by the WTRU. Chen explicitly relies on the standardized 3GPP NWDAF subscription and notification operation (such as ‘Nnwdaf_AnalyticsSubscription_Subscribe’) to generate and relay analytics back to the UE (see paragraphs [0113], [0157] of Chen). Lee mandates that a Correlation ID must be bundled together with the Analytics ID and S-NSSAI (SST) within these exact same NWDAF service operations to successfully bind the asynchronous request to its subsequent response. Merging the complete data parameter set (Analytics ID, SST, and Correlation ID) taught by Lee into the explicit NAS signaling channel established by Chen represents nothing more than a routine implementation of standard 3GPP protocol elements.
Chen and Lee fails to explicitly teaches the “a slice service type (SST) corresponding to artificial intelligence (Al) operation types, and a mapping between the Al operation types and one or more analytic identifiers” as recited in amended claim 30.
Samdanis teaches the “a slice service type (SST) corresponding to artificial intelligence (Al) operation types(paras [0142]-[0145] of Samdanis), and a mapping between the Al operation types and one or more analytic identifiers” (para [0156] of Samdanis).
Samdanis explicitly discloses a network registry architecture where produced management service (i.e., Analytics types) are explicitly “mapped to” a plurality of attributes in a table format (Figs 1 & 2; para [0156] of Samdanis:… FIGS. 1 and 2 show simple abstract examples of registers, in which each service of each registered function (MF1-3, NF1-3) is mapped to one or more attributes (A1-A10).).
These mapped attributes expressly include target scopes such as ‘S-NSSAI’ (slice service type) and algorithm options such as ‘artificial intelligence (AI)/machine learning (ML)’ (paras [0136], [0142]-[0145] of Samdanis: A management service provided by a MDAF(‘management data analytics function’) may be associated with one or more of the following specific attributes: … Scope (Target): e.g. single UE, group of UEs, S-NSSAI, Area of interest; … Algorithm options: In case of artificial intelligence (AI)/machine learning (ML)/Linear Regression/Reinforcement Learning, etc.),).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the teachings of Chen, Lee, and Samdanis by incorporating the mapped AI/ML algorithm attributes and corresponding S-NSSAI parameters taught by Samdanis into the WTRU-initiated NAS analytics request signaling framework established by Chen and Lee. Utilizing the predefined mapping between AI operation attributes and standard Analytic IDs ensures that the core network can efficiently route and execute complex, slice-specific artificial intelligence analytics requested by the client device. This integration represents nothing more than a predictable application of standard 3GPP registry mapping structures applied to known client-network control-plane messaging to achieve highly reliable, correlated AI data exposure.
Regarding Claim 38, it is a method corresponding to the apparatus (WTRU) claim 30 and is therefore rejected for the similar reasons set forth in the rejection of claim 30.
Regarding Claim 46, it is a wireless transmit receive unit (WTRU) claim corresponding to claim 30, except limitations “send a non-access stratum (NAS) message… to a session management function (SMF)” (See paragraphs [0141-0143] of Chen: UE sends first indication information to a first network element… When the first network element is an SMF network element,) and “receive from an access and mobility management function (AMF) …” (See para [0160] of Chen: ‘Step S410: The first network element sends the network information to the UE’ and para [0096] of Chen: ‘The first network element includes an AMF network element’) and is therefore rejected for the similar reasons set forth in the rejection of claim 30.
With respect to dependent claims:
Regarding Claim 33, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen further teaches:
wherein the NAS message comprises a session establishment message (para [0143]: For example, the first indication information may be carried in a non-access stratum (non-access stratum, NAS) message. When the first network element is an AMF network element, the NAS message may be a NAS mobility management (mobility management, MM) message. When the first network element is an SMF network element, the NAS message may be a NAS session management (session management, SM) message.).
Regarding Claim 35, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen teaches:
wherein the processor configured to receive the analytics message from the network node is further configured to receive performance statistics and predictions (para [0084]: FIG. 2 shows an architecture of interaction between an NWDAF network element and another network element. (a) in FIG. 2 is an architecture used for data collection, in which the NWDAF network element invokes a service of the another network element to collect input information required for network analytics. (b) in FIG. 2 is an architecture used for data openness, in which the NWDAF network element sends, by providing an NWDAF service, analytics data to a network element that subscribes to or requests the analytics data. The analytics data includes gNB status information, gNB resource usage, and statistics or predictions of communication performance and mobility performance, or provides statistics or predictions of a quantity of UEs located in an area of interest.) (paragraphs [0152-0160]: Step S406: The NWDAF network element determines network performance prediction information based on the data information. … Step S409: The first network element receives the network information from the NWDAF network element. …Step S410: The first network element sends the network information to the UE.).
Regarding Claim 36, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen teaches:
wherein the processor configured to receive the analytics message from the network node is further configured to receive a network address associated with accessing performance statistics and predictions (para [0111]: Optionally, the first information further includes one or more of the following: a terminal identifier, second indication information, or third indication information. The second indication information indicates the NWDAF network element to send the network information to the terminal device corresponding to the terminal identifier. The third indication information indicates the NWDAF network element to send the network information to the first network element. For example, the second indication information and the third indication information may be represented by different values of a same information element.) (para [0112]: For example, the second indication information and the third indication information are represented by different values of a notification target address (Notification Target Address), and the notification target address is a parameter that indicates a destination address to which the network information is sent. If the first information includes the second indication information, the value of the notification target address is the terminal identifier; if the first information includes the third indication information, the value of the notification target address is an identifier of the first network element; or if the first information includes the second indication information and the third indication information, the values of the notification target address are the terminal identifier and an identifier of the first network element.).
Regarding Claims 41 and 49, Claims 41 and 49, have similar limitation as of Claim 33, therefore it is rejected under the same reasons as Claim 33.
Regarding Claim 43, Claim 43, have similar limitation as of Claim 35, therefore it is rejected under the same reasons as Claim(s) 35.
Regarding Claim 44, Claim 44, have similar limitation as of Claim 36, therefore it is rejected under the same reasons as Claim(s) 36.
Claim(s) 32, 40, and 48 rejected under 35 U.S.C. 103 as being unpatentable over Chen, in view of Lee, in view of Samdanis, and further in view of Balakrishnan et al. (U.S. Patent Application Publication No. 20230177349, hereinafter “Balakrishnan”).
Regarding Claim 32, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen, Lee, and Samdanis fail to teach: wherein the AI operation types comprise one or more of model distribution, operation split, or federated learning.
Balakrishnan explicitly discloses the implementation of distributed machine learning paradigms, specifically focusing on coordinating artificial intelligence (AI) tasks across client devices and central controllers within wireless network.
Specifically, Balakrishnan, in para [0115], explicitly introduces “Distributed computing” used to reduce AI/ML training time by offloading intensive gradient descent (GD) computations to multiple secondary computing nodes or edge devices. It further explicitly states that “federated learning has been proposed for distributed GD computation, where learning takes place by a federation of client computing nodes … coordinated by a central server.” Balakrishnan, in para [0116], explicitly defines the technical framework of “Federated learning”, explaining that the protocol iteratively allows client to “download a centrally trained artificial intelligence/machine-learning model… from a server, …, update it with their own data and upload the model updates … back to the server.”
Through these disclosures, Balakrishnan fully establishes the structural execution of both federated learning and model distribution within a multi-node wireless network environment.
It would have been obvious to one of ordinary skill in the art at the time of instant application to specify the AI operation types configured in the WTRU framework of Chen, Lee, and Samdanis to include model distribution and federated Learning by incorporating the distributed AI/ML principles explicitly taught by Balakrishnan. The combination of Chen, Lee, and Samdanis establishes a core network architecture (such as an NWDAF) that interacts with a WTRU to handle, request, and deliver network analytics and intelligent parameters. Balakrishnan explains that conventional centralized AI training encounters computation time bottlenecks and lag time over wireless links, and teaches that distributing the AI workload via federated learning and model distribution optimally utilizes the compute capabilities of heterogeneous client devices while maintaining data privacy.
Therefore, specifying the AI operation types to comprise model distribution or federated learning represents nothing more than a predicable application of the distributed AI methodologies of Balakrishnan to the client-network analytics pipeline established by the combination of Chen, Lee and Samdanis.
Regarding Claims 40 and 48, Claims 40 and 48, have similar limitation as of Claim(s) 32, therefore it is rejected under the same reasons as Claim(s) 32.
` Claim(s) 34, 37, 42, and 45 rejected under 35 U.S.C. 103 as being unpatentable over Chen, in view of Lee, in view of Samdanis, and further in view of 3GPP TS 23.501 V17.3.0 (2021-12) “System architecture for the 5G System (5GS); Stage 2 (Release 17) (which was included in the IDS submitted by the applicant on May 6, 2025)(hereinafter 3GPP TS 23,501).
Regarding Claim 34, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen, Lee, and Samdanis do not explicitly teach wherein the NAS message comprises a NAS transport message.
3GPP TS 23.501 explicitly discloses the functional and structural signaling mechanics conveying Session Management (SM) payloads within the 5G System control plane. Specifically, in the context of DNN-based congestion control, Clause 5.19.7.3 (in pages 278-280) explicitly teaches that:
“5.19.7.3 DNN based congestion control
…
When DNN based congestion control is activated at AMF e.g. configured by OAM, the AMF provides a NAS Transport Error message for the NAS Transport message carrying an SM message, and in the NAS Transport Error message it includes a DNN back-off timer.
The UE associates the received back-off time with the DNN …which the UE included in the uplink NAS MM message carrying the corresponding NAS SM request message.
…
If UE initiates one of the Session Management procedures that are exempted from NAS congestion control, the UE indicates that the carried NAS SM message is exempted from NAS congestion control in the UL NAS Transport message …”
Through these explicit discloses, 3GPP TS 23.501 establishes that any standard uplink session management signaling (NAS SM message) initiated by a WTRU (UE) toward the core network function is structurally carried within and encapsulated by an uplink NAS Transport message (specifically, the UL NAS Transport message)
It would have been obvious to one of ordinary skill in the art at the time of instant application the invention was made to specify the uplink NAS message container of Chen, Lee and Samdanis as a NAS transport message by implementing the standard 5G signaling transport architecture explicitly taught by 3GPP TS 23.501. Chen establishes that the WTRU initiates an analytics request containing an Analytics ID and an SST, and notes that when routing toward an SMF node, it is carried in a NAS session management (SM) message (paragraphs [0110], [0143]). Lee establishes the requirement to bundle the Correlation ID within the same analytics subscription message framework (paragraphs [0112-0119] of Lee). Utilizing the pre-existing, transparent transport container of an uplink NAS transport message to encapsulate the bundle of analytics request parameters (Analytics ID, Correlation ID, SST) represents a routine design choice among a finite number of standard 3GPP message formats. This standard implementation ensures full compatibility with 5G control-plane function (such as AMF handling congestion control as taught in Clause 5.19.7.3), allowing the WTRU to securely and predictably deliver its analytics context without requiring the definition of new, non-standard message classes.
Regarding Claim 37, Chen, Lee, and Samdanis teach The WTRU of claim 30, Chen, Lee, and Samdanis do not explicitly teach wherein the processor configured to receive the analytics message from the network node is further configured to receive a NAS transport message.
3GPP TS 23.501 explicitly discloses the structural control-plane mechanism wherein downlink signaling targeting a WTRU (UE) utilizes NAS Transport message wrappers to convey session management and core network analytics feedback. Specifically, Clause 5.19.7.3 of 3GPP TS 23.501 teaches, in pages 278-280, that:
“5.19.7.3 DNN based congestion control
…
the SMF may make use of Session Management Congestion Control Experience analytics provided by NWDAF, as defined in clause 6.12 of TS 23.288 [86], to determine back-off timer provided to UEs.
When DNN based congestion control is activated at AMF e.g. configured by OAM, the AMF provides a NAS Transport Error message for the NAS Transport message carrying an SM message, and in the NAS Transport Error message it includes a DNN back-off timer.”
Through these explicit discloses, 3GPP TS 23.501 establishes that when the network node provides data or response tied to analytics context back to the terminal device, the final downlink signaling block received by the WTRU’s processor constitutes a NAS transport message category (e.g., a NAS Transport Error message or generic downlink NAS Transport framework).
It would have been obvious to one of ordinary skill in the art at the time of instant application the invention was made to configure the WTRU of Chen, Lee, and Samdanis to receive the analytics message in the form of a NAS Transport message by implementing the standard 5GS control plane signaling transport architecture explicitly taught by 3GPP TS.501. Therefore, configuring the processor to receive a NAS transport message represents a completely predictable implementation of 3GPP TS 23.501’s standard downlink transport encapsulation mechanics applied to the analytics delivery framework of Chen, Lee, and Samdanis.
Regarding Claim 42, Claim 42, has similar limitation as of Claim(s) 34, therefore it is rejected under the same reasons as Claim(s) 34.
Regarding Claim 45, Claim 45, has similar limitation as of Claim(s) 37, therefore it is rejected under the same reasons as Claim(s) 37.
Conclusion
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 WON JUN CHOI whose telephone number is (703)756-1695. The examiner can normally be reached MON-FRI 08:00 - 17:00.
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, Derrick W Ferris can be reached at 571-272-3123. 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.
/WON JUN CHOI/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
