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 May 6, 2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Applicant should note that the large number of references in the attached IDSs have been considered by the examiner in the same manner as other documents in Office search files are considered by the examiner while conducting a search of the prior art in a proper field of search. See MPEP 609.05(b). Applicant is invited to point out any particular reference(s) in the IDS that they believe may be of particular relevance to the instant claimed invention in response to this Office Action. It is desirable to avoid the submission of long lists of documents if it can be avoided. If a long list is submitted, highlight those documents which have been specifically brought to applicant’s attention and/or are known to be of most significance. See Penn Yan Boats, Inc. v. Sea Lark Boats, Inc., 359 F. Supp. 948, 175 USPQ 260 (S.D. Fla. 1972), aff ’d, 479 F.2d 1338, 178 USPQ 577 (5th Cir. 1973), cert. denied, 414 U.S. 874 (1974). But cf. Molins PLC v. Textron Inc., 48 F.3d 1172, 33 USPQ2d 1823 (Fed. Cir. 1995).
Claim Objections
Claims 30, 38, and 46 are objected to because of the following informalities: “NAS” should be spelled out in the claims. Claims 31-37, 39-45, 47-49 depend from one of the independent claims, thus carry the same issues as described above, and therefore are objected on the same grounds discussed above.
Claim Rejections - 35 USC § 112
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 30-45, and 49 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 30 and 38 recite “receive (‘receiving’) system performance statistics; send a NAS message indicating a request for network analytics, the NAS message comprising one or more analytic identifiers, a correlation identifier, and a slice service type (SST); and receive an analytics message from a network node, wherein the analytics message indicates one or more network analytics.”
To the extent that the step “receive system performance statistics” in the claims is interpreted as receiving distinct performance statistics prior to and independent of sending the NAS message indicating a request for network analytics, the specification fails to provide any written description or enabling support for such a mechanism.
Review of paragraphs [0008] and [0118-0128] demonstrates that the WTRU is only disclosed as receiving system performance statistics after a PDU Session Establishment has successfully triggered the SMF to subscribe to the NWDAF on behalf of the WTRU.
The specification is completely silent on any procedure or structural configuration enabling a WTRU to receive “system performance statistics” before initiating the NAS analytics request. Appropriate clarifications are required.
Claims 31-37, 39-45 and 49 depend from one of the independent claims, thus carry the same issues as described above, and therefore are rejected on the same grounds discussed above.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 30-45, and 49 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 30 and 38 recite a sequential process where the processor is configured to: (1) receive system performance statistics; (2) send a NAS message indicating a request for network analytics, the NAS message comprising one or more analytic identifiers, a correlation identifier, and a slice service type (SST); and (3) receive an analytics message from a network node, wherein the analytics message indicates one or more network analytics.
However, Applicant’s specification in paragraphs [0008], [0115], and [0128] explicitly disclose that the “system performance statistics and predictions” are the substantive payload carried within the final ‘Nnwdaf_AnalyticsSubscription_Notify’ message (the claimed “analytics message”) which is relay the via a DL NAS TRANSPORT message in response to the WTRU’s request.
The physical placement of the step “receive system performance statistics” prior to the “request” step introduces a logical contradiction and rendering the claim structurally vague. It is completely ambiguous whether the “system performance statistics” received in the first step are identical to, or distinct from, the network analytics received in the final “analytics message.” Therefore the metes and bounds of the claim cannot be determined with legal certainty.
Claim 38 recites the following method steps: “receiving system performance statistics;” “sending a NAS message …;” and “receive an analytics message from a network node …” The shifting of the verb form from gerunds (“receiving”, “sending”) to a base verb (“receive”) in the final step creates a grammatical non-sequitur. It is unclear whether the phrase “receive an analytics message” is intended to be a sequential step performed by the method, or if it is a typographical error meant to be “receiving an analytics message.” Claims 39-45 and 49 depend from independent claim 38, thus carry the same issues as described above, and therefore are rejected on the same grounds discussed above.
Claims 34 and 42 utilize the transitional phrase “where the NAS message comprises…” whereas the surrounding dependent claims (e.g., Claims 33, 35, 36, 37, 41) uniformly utilize the standard phrase “wherein the NAS message comprises…”. While minor, the use of “where” instead of “wherein” introduces informalities and creates ambiguity as to whether a conditional environment or a further structural limitation is being defined.
Claims 31-37, 39-45 and 49 depend from independent claim 30 or 38, respectively, thus carry the same issues as described above, and therefore are rejected on the same grounds discussed above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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”).
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:
receive system performance statistics (Examiner’s comment: Under 35 U.S.C. 112(a) and (b), the limitation “receive system performance statistics” in Claim 30 introduces a chronological contradiction because the specification only discloses receiving such statistics after a NAS analytics request is made. Because this limitation lacks proper support and renders the claim boundary indefinite, it is treated as a functional statement of ultimate data identity rather than an independent, prior tracking step during this examination. Therefore, the Examiner evaluates the substance of Claim 30 over Chen and Lee by focusing on the remaining structural signaling limitations.);
send a NAS message indicating a request for network analytics (paragraphs [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. 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. Step S402: The first network element receives the first indication information from the UE. … The first indication information further indicates a type of the requested network information. For details, refer to step S301. Details are not described herein again.) (para [0103]: For example, the first indication information may further indicate the type of the network information…) (para [0107]: In a second manner, before the first network element sends the first information to the NWDAF network element, the first network element receives first indication information and type indication information from the UE, where the first indication information indicates to obtain the network information, and the type indication information indicates the type of the network information. The first network element determines, based on the first indication information and the type indication information, that the network information requested by the UE is the network performance prediction information …), the NAS message comprising one or more analytic identifiers, (para [0108]: In a third manner, before the first network element sends the first information to the NWDAF network element, the first network element receives the first indication information from the UE, 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.) (para [0110]: …. In a possible implementation, the first information includes an analytics identifier (Analytics ID) (interpreted as “analytic identifiers”). When the first information is used for obtaining the network performance prediction information, Analytics ID=network performance information (Network Performance). When the first information is used for obtaining the media parameter, Analytics ID=media parameter. After receiving the first indication information from the UE, the first network element may trigger sending of the first information to the NWDAF network element.) (The missing/crossed out limitation will be discussed in view of 3GPP TS 23.228); 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.
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, Chen teaches A wireless transmit receive unit (WTRU) (Fig. 4, UE) comprising:
a processor (Fig. 7, processing unit 701) configured to:
send a NAS message indicating a request for network analytics to a session management function (SMF) (paragraphs [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. 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. Step S402: The first network element receives the first indication information from the UE. … The first indication information further indicates a type of the requested network information. For details, refer to step S301. Details are not described herein again.) (para [0103]: For example, the first indication information may further indicate the type of the network information…) (para [0107]: In a second manner, before the first network element sends the first information to the NWDAF network element, the first network element receives first indication information and type indication information from the UE, where the first indication information indicates to obtain the network information, and the type indication information indicates the type of the network information. The first network element determines, based on the first indication information and the type indication information, that the network information requested by the UE is the network performance prediction information …), the NAS message comprising one or more analytic identifiers, (para [0108]: In a third manner, before the first network element sends the first information to the NWDAF network element, the first network element receives the first indication information from the UE, 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.) (para [0110]: …. In a possible implementation, the first information includes an analytics identifier (Analytics ID) (interpreted as “analytic identifiers”). When the first information is used for obtaining the network performance prediction information, Analytics ID=network performance information (Network Performance). When the first information is used for obtaining the media parameter, Analytics ID=media parameter. After receiving the first indication information from the UE, the first network element may trigger sending of the first information to the NWDAF network element.) (The missing/crossed out limitation will be discussed in view of 3GPP TS 23.228); and
receive from an access and mobility management function (AMF) 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 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”).) (para [0096]: The first network element includes an AMF network element)).
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.
With respect to dependent claims:
Regarding Claim 33, Chen and Lee 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 and Lee 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 and Lee 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, has similar limitation as of Claim(s) 33, therefore it is rejected under the same reasons as Claim(s) 33.
Regarding Claim 43, Claim 43, has similar limitation as of Claim(s) 35, therefore it is rejected under the same reasons as Claim(s) 35.
Regarding Claim 44, Claim 44, has similar limitation as of Claim(s) 36, therefore it is rejected under the same reasons as Claim(s) 36.
Claim(s) 31, 39, and 47 rejected under 35 U.S.C. 103 as being unpatentable over Chen, in view of Lee, and further in view of Samdanis et al. (U.S. Patent Application Publication No. 20220272510, hereinafter “Samdanis”).
Regarding Claim 31, Chen and Lee teach The WTRU of claim 30, Chen and Lee fail to teach:
wherein the SST corresponds to artificial intelligence (AI) operation types and the NAS message further comprises a mapping between the AI operation types and one or more analytic identifiers.
In analogous art, Samdanis teaches wherein the SST corresponds to artificial intelligence (AI) operation types and the NAS message further comprises a mapping between the AI operation types and one or more analytic identifiers (para [0136-0147]: According to one example, one or more functions included in the register at the repository function include a management data analytics function (MDAF) (such as one operating according to a 3GPP protocol) producing management data analytics services (MDAS) at the management plane. The register entry for such a MDAF may include: (i) Identity/address (provided e.g. by IP@, URI) of the function; (ii) “per use case” specific attributes, such as those defined in a 3GPP specification such as TR 28.809; (iii) an analytic type (such as e.g. those defined in a 3GPP specification such as TR 28.809); (iv) information about the data required as input by the MDAF; and (vi) information about the output (analytic report) of the data produced by the service of the MDAF. A management service provided by a MDAF may be associated with one or more of the following specific attributes:
Reporting Capabilities: Time Scheduling (e.g. periodic, historical),
Reporting Type: (e.g. file, streaming, notification),
Condition based/Trigger (e.g. threshold, area of interest),
Type of Data Collected (e.g. percentage of UEs, average/distribution);
Geographical Area;
Scope (Target): e.g. single UE, group of UEs, S-NSSAI, Area of interest;
Pre-processing options including aggregation, filtering etc.;
Analytics types, statistics or prediction: e.g. analytic-type=mobility-prediction;
Algorithm options: In case of artificial intelligence (AI)/machine learning (ML)/Linear Regression/Reinforcement Learning, etc.),
other attributes may include, for example: time ahead, prediction-frequency, confidence degree, vendor information.
The attributes mapped to a management service of a management plane function may comprise an indication of one or more other functions with which the management service is associated. A consuming function can discover a function producing relevant management services by directing to the repository function a request specifying one or more function types and attributes that the consuming function associates with the management service. For example, the consuming function may be a network data analytics function (NWDAF) and may require a management service (such as a user equipment (UE) trace) with certain attributes, e.g. real-time, which is associated with an access and mobility function (AMF) at the control plane in the example of FIG. 3. The NWDAF may direct a request to the repository function for information about management services that are associated with the AMF, and receive the requested information from the repository function.).
As reproduced above, Samdanis explicitly discloses a network management and data analytics framework (incorporating NWDAF and MDAF) operating under 3GPP protocols that dynamically configures and maps artificial intelligence (AI) parameters with network slicing attributes. Furthermore, paragraph [0147] of Samdanis explicitly teaches that “The attributes mapped to a management service of a management plane function may comprise an indication of one or more other functions with which the management service is associated,” enabling a consuming function (such as an NWDAF) to discover, request, and retrieve specific analytics services based on this explicit metadata mapping (see paragraphs [0147] and [0155] of Samdanis). Thus Samdanis teaches the core concept of associating and mapping network slice resources (S-NSSAI/SST) to specific AI/ML algorithm options and their corresponding analytics types.
It would have been obvious to one of ordinary skill in the art at the time of instant application to modify the WTRU-initiated analytics request protocol taught by Chen and Lee by incorporating the AI-to-Analytics mapping attributes disclosed in Samdanis. Chen establishes a control-plane signaling pipeline where a WTRU directly request network analytics via an uplink NAS message based on a specific network slice/SST (paragraphs [0108] and [0141] of Chen). Samdanis teaches that in advanced 3GPP networks, network slices (S-NSSAI) run specialized data analytics driven by various algorithm options, including artificial intelligence (AI) and machine learning (ML) (para [0145] of Samdanis). Therefore, configuring a network slice (SST) to specifically correspond to an AI operation type is a predictable implementation choice based on network virtualization trends. The combination of Chen, Lee, and Samdanis yields nothing more than a predictable application of known 3GPP metadata attributes within a standard client-initiated control-plane transport message to achieve predictable correlation tracking.
Regarding Claims 39 and 47, Claims 39 and 47, have similar limitation as of Claim(s) 31, therefore it is rejected under the same reasons as Claim(s) 31.
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 31, 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 disclose 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, 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 and Lee teach The WTRU of claim 30, Chen and Lee does not explicitly teach where 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 and Lee 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 and Lee teach 37. The WTRU of claim 30, Chen and Lee does 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 explicitly 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 and Lee 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 and Lee.
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
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
Prosecution Insights