Details
Claims 24-26, 32, 36-37, 39-40, 54-55, and 59-60, 62-63, and 66-70 are pending.
Claims 24-26, 32, 36-37, 39-40, 54-55, and 59-60, 62-63, and 66-70 are rejected.
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) 24-26, 32, 36-37, 39-40, 54-55, and 59-60, 62-63, 66-67, and 69 is/are rejected under 35 U.S.C. 103 as being anticipated by Muñoz De La Torre Alonso et al (WO 2022/053168 A1, NOTE US 2023/0336432 A1 is used, as an English Translation, for the mapping; Muñoz hereinafter) in view of XIN et al (WO 2022/033115 A1, NOTE US 2023/0188424 A1 is used, as an English Translation, for the mapping; XIN hereinafter).
As per claim 24, Muñoz discloses a method for communication, comprising: - receiving, by a first network element, fourth information from a network data analytics function, wherein the fourth information comprises second packet flow description (PFD) analytics information corresponding to a second application identifier and/or fourth PFD information corresponding to the second application identifier (Muñoz, paragraph 0107-0108, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, “In some embodiments, the NWDAF sends the PFD to the NEF, so the NEF stores the PFD data for the application ID in UDR as Application Data, along with the other parameters (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location)”; Thus, a first network element (which can be the NEF) receive fourth information (which can be the PFD corresponding to an application identifier));- obtaining, by the first network element, fifth information from a unified data repository function, wherein the fifth information comprises fifth PFD information corresponding to the second application identifier (Muñoz, paragraph 0115-0116, wherein “At step 314, the NEF requests the PFD information to the UDR for the at least one further parameter (including the App-ID). At step 315, the UDR looks for the PFD set matching the application ID and the at least one further parameter and sends the matching PFDs to the NEF”); and- sending, by the first network element, sixth information to the unified data repository function, wherein the sixth information is configured to request processing PFD information corresponding to the second application identifier, and the processing comprises at least one of creation, update and deletion (Muñoz, paragraph 0107-0109, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, wherein the Nudr_DataManagement_Store request message can be the processing comprises at least one of creation, update and deletion);wherein the method further comprises:- sending, by the first network element, seventh information to the network data analytics function (Muñoz, paragraph 0054, wherein “At step 210, the NWDAF receives a subscription request for traffic classification analytics from an analytics consumer 201. The NWDAF may receive a subscription request from a UDR 114, an Operations and Management system (OAM), or any consumer in charge of retrieving and storing the PFDs for traffic classification purposes within the mobile network”), wherein the seventh information is configured to subscribe PFD analysis information and/or PFD information (Muñoz, paragraph 0054, wherein “At step 210, the NWDAF receives a subscription request for traffic classification analytics from an analytics consumer 201. The NWDAF may receive a subscription request from a UDR 114, an Operations and Management system (OAM), or any consumer in charge of retrieving and storing the PFDs for traffic classification purposes within the mobile network”).
XIN does not explicitly disclose that the seventh information comprises the second application identifier. XIN discloses that the seventh information comprises the second application identifier (XIN, paragraph 0200, 0252, wherein “The NEF triggers an NWDAF data analytics result subscription service Nnwdaf_AnalyticsSubscription_Subscribe to the NWDAF 1, and may subscribe to new PFD information from the NWDAF 1. For explanations of the information in an analytics filter, refer to step S01 in Embodiment 1”; “an analytics filter Analytics Filter may include a plurality of types of filtering information. For example, the analytics filter may be an application identifier App ID”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to modify Muñoz in view of XIN so that the PFD/traffic-classification analytics subscription of Muñoz is modified such that the subscription request sent from the network element to the NWDAF includes an application identifier as an analytic filter parameter as taught by XIN because this would have helped to identify the particular application for which the PFD information and/or PFD-related analytics are requested and thereby allowing the NWDAF to provide application specific information.
As per claim 25, claim 24 is incorporated and Muñoz further discloses wherein the sixth information comprises the PFD information to be processed and/or the second application identifier (Muñoz, paragraph 0107, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”);
As per claim 26, claim 24 is incorporated and Muñoz further discloses wherein the second PFD analysis information comprises the fourth PFD information (Muñoz, paragraph 0107-0108, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, “In some embodiments, the NWDAF sends the PFD to the NEF, so the NEF stores the PFD data for the application ID in UDR as Application Data, along with the other parameters (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location)”).
As per claim 31, claim 24 is incorporated and Muñoz further discloses sending, by the first network element, seventh information to the network data analytics function, wherein the seventh information is configured to subscribe PFD analysis information and/or PFD information, and the seventh information comprises the second application identifier (Muñoz, paragraph 0054, wherein “At step 210, the NWDAF receives a subscription request for traffic classification analytics from an analytics consumer 201. The NWDAF may receive a subscription request from a UDR 114, an Operations and Management system (OAM), or any consumer in charge of retrieving and storing the PFDs for traffic classification purposes within the mobile network”);
As per claim 32, claim 31 is incorporated and Muñoz further discloses receiving, by the first network element, second subscription information from the network data analytics function, wherein the second subscription information is configured to subscribe PFD information corresponding to the second application identifier (Muñoz, paragraph 0055-0056, wherein “At step 211, the NWDAF triggers a traffic trace collection request to PCF. In some embodiments, the NWDAF does so by defining an event in the Npcf_EventExposure service to obtain the PFD rules for an application. This request can be triggered by NWDAF to multiple PCFs (or every PCF) in parallel”); and querying, by the first network element, the unified data repository function to obtain sixth PFD information corresponding to the second application identifier, and sending the sixth PFD information to the network data analytics function (Muñoz, paragraph 0107, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”);
Claims 54, 59-62 are rejected under the same rationale as claims 24-26 and 31-32.
As per claim 36, Muñoz discloses a method for communication, comprising: - sending, by a network data analytics function, fourth information to a first network element, wherein the fourth information comprises second PFD analysis information corresponding to a second application identifier and/or fourth PFD information corresponding to the second application identifier (Muñoz, paragraph 0107-0108, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, “In some embodiments, the NWDAF sends the PFD to the NEF, so the NEF stores the PFD data for the application ID in UDR as Application Data, along with the other parameters (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location)”; Thus, a first network element (which can be the NEF) receive fourth information (which can be the PFD corresponding to an application identifier));- the fourth information is used for the first network element to determine or decide to request processing PFD information corresponding to the second application identifier, and the processing comprises at least one of creation, update and deletion (Muñoz, paragraph 0107, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, wherein the Nudr_DataManagement_Store request message can be the processing comprises at least one of creation, update and deletion);
As per claim 37, claim 36 is incorporated and Muñoz further discloses wherein the second PFD analysis information comprises the fourth PFD information (Muñoz, paragraph 0107-0108, wherein “At step 220, the NWDAF transmits the PFD together with the parameters of the marking information (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location) to the analytics consumer 201. The analytics consumer 201 may be a UDR and the information can be transmitted for example as Application Data, by triggering a Nudr_DataManagement_Store request message including an indication of the DataSet (e.g. ApplicationData)”, “In some embodiments, the NWDAF sends the PFD to the NEF, so the NEF stores the PFD data for the application ID in UDR as Application Data, along with the other parameters (i.e. an application identifier, an application version, an operating system identifier, an operating system version, a User Equipment, UE, vendor, a UE model, a UE identifier, a subscriber identifier, and a location)”);
As per claim 38, claim 36 is incorporated and Muñoz further discloses receiving, by the network data analytics function, seventh information from the first network element, wherein the seventh information is configured to subscribe PFD analysis information and/or PFD information, and the seventh information comprises the second application identifier (Muñoz, paragraph 0054, wherein “At step 210, the NWDAF receives a subscription request for traffic classification analytics from an analytics consumer 201. The NWDAF may receive a subscription request from a UDR 114, an Operations and Management system (OAM), or any consumer in charge of retrieving and storing the PFDs for traffic classification purposes within the mobile network”);
As per claim 39, claim 36 is incorporated and Muñoz further discloses obtaining, by the network data analytics function, the second PFD analysis information corresponding to the second application identifier and/or the fourth PFD information corresponding to the second application identifier (Muñoz, paragraph 0055-0056, wherein “At step 211, the NWDAF triggers a traffic trace collection request to PCF. In some embodiments, the NWDAF does so by defining an event in the Npcf_EventExposure service to obtain the PFD rules for an application. This request can be triggered by NWDAF to multiple PCFs (or every PCF) in parallel”, paragraph 0115-0116, wherein “At step 314, the NEF requests the PFD information to the UDR for the at least one further parameter (including the App-ID). At step 315, the UDR looks for the PFD set matching the application ID and the at least one further parameter and sends the matching PFDs to the NEF”);
As per claim 40, claim 36 is incorporated and Muñoz further discloses obtaining, by the network data analytics function, third user plane information from a user plane function (Muñoz, paragraph 0048, wherein “A first example use case is traffic classification. In this example use case a consumer requests NWDAF to classify traffic. This allows either for UPF to classify traffic or for NWDAF itself to classify traffic. The last case allows offline classification, e.g. analytics/reporting Use Cases, where the UPF forwards the traffic to NWDAF (which has a model for traffic classification where the classification rules have been derived from the collected traces)”, paragraph 0104, wherein “At step 217, the UPF detects the marked traffic and forwards it to the NWDAF, including the same parameters as in step 216”);
Claims 55 and 63-66 are rejected under the same rationale as claims 36-40.
As per claim 67, claim 66 is incorporated and XIN further discloses wherein the processor is further configured to execute the computer program to: obtain the second PFD analytics information corresponding to the second application identifier (XIN, paragraph 0244, wherein “It can be learned from the foregoing example descriptions that the NWDAF determines, based on the historical PFD information and the traffic information on the corresponding UPF, the traffic dataset corresponding to the App ID, and may further determine the traffic characteristic of the App ID or train the application type identification model”) and/or the fourth PFD information corresponding to the second application identifier by deduction based on the third user plane information (XIN, paragraph 0229, 0240, wherein “A process in which the NWDAF 1 may obtain inference data from the SMF/UPF is the same as a method in steps S03a and S03b; in other words, is a process in which the NWDAF 1 obtains traffic data corresponding to a new IP 5-tuple from the UPF”) and a pre-trained model (XIN, paragraph 0229-0230, wherein “he application type identification model is a machine learning model, and the traffic characteristic is a matching rule corresponding to an App ID. Both of the application type identification model and the traffic characteristic can be used to determine an App ID of a service flow for traffic information of the service flow. The application type identification model converts traffic information into an eigenvector and inputs the eigenvector into the model to obtain an App ID … Specifically, a process of training the application type identification model by the NWDAF 2 is training a classifier by using a supervised machine learning algorithm, for example, logistic regression or a support vector machine”);
Claims 69 is rejected under the same rationale as claim 67.
Claim(s) 68 and 70 is/are rejected under 35 U.S.C. 103 as being anticipated by Muñoz De La Torre Alonso et al (WO 2022/053168 A1, NOTE US 2023/0336432 A1 is used, as an English Translation, for the mapping; Muñoz hereinafter) in view of XIN et al (WO 2022/033115 A1, NOTE US 2023/0188424 A1 is used, as an English Translation, for the mapping; XIN hereinafter) and Pateromichelakis et al (Pub. No.: US 2025/0024284 A1).
As per claim 68, claim 67 is incorporated and Muñoz and XIN do not further disclose wherein the processor is further configured to execute the computer program to: - obtain sixth PFD information from a unified data repository function through the first network element; and/or obtain seventh PFD information and/or fourth user plane information from an analytics data repository function, wherein the seventh PFD information and/or the fourth user plane information is information within a second historical time range; and train a model based on the seventh PFD information and/or the fourth user plane information, to obtain the pre-trained model; or train the model based on at least one of the sixth PFD information, the fourth user plane information and the seventh PFD information, to obtain the pre-trained model . However, Pateromichelakis discloses obtain sixth PFD information from a unified data repository function through the first network element (Pateromichelakis, paragraph 0049, wherein “The NWDAF 112 comprises analytics services which collect data from the user-plane sessions from the user plane function (UPP) and/or AF. The collected data includes Observed Service Experience related to network data analytics. These may include: Service experience for a UE or a group UEs or any UE in an Application or a set of Applications over a specific UP path (UPF, data network access identifier and edge cloud (EC) server). These may be received from AF, NFs and OAM. Additionally, from UPF the NWDAF 112 may receive: QoS flow bit rate, QoS flow packet delay, # of packet Tx/re-Tx. Further, from AF the NWDAF 112 may receive quality of experience (QoE) metrics, service experience, app location”); and/or obtain seventh PFD information and/or fourth user plane information from an analytics data repository function, wherein the seventh PFD information and/or the fourth user plane information is information within a second historical time range (Pateromichelakis, paragraph 0131, wherein “Operation data is collected, processed as necessary and reported to the requesting entity. Typically, the collected data is stored in a storing entity (e.g. ADRF or VAL DB), which may include a database. Depending on storage requirements, either the collected data or the processed data is stored. Such storage may be required where the requested data spans a period of time and is to be delivered once the collection period is complete”); and train a model based on the seventh PFD information and/or the fourth user plane information, to obtain the pre-trained model; or train the model based on at least one of the sixth PFD information, the fourth user plane information and the seventh PFD information, to obtain the pre-trained model (Pateromichelakis, paragraph 0049, 0055, 0150, wherein “The NWDAF 112 comprises analytics services which collect data from the user-plane sessions from the user plane function (UPP) and/or AF. The collected data includes Observed Service Experience related to network data analytics. These may include: Service experience for a UE or a group UEs or any UE in an Application or a set of Applications over a specific UP path (UPF, data network access identifier and edge cloud (EC) server). These may be received from AF, NFs and OAM. Additionally, from UPF the NWDAF 112 may receive: QoS flow bit rate, QoS flow packet delay, # of packet Tx/re-Tx. Further, from AF the NWDAF 112 may receive quality of experience (QoE) metrics, service experience, app location”, “The ADRF 118 stores historical data and/or analytics, i.e. data and/or analytics related to past time period that has been obtained by the data consumer. After the data consumer obtains data and/or analytics, the data consumer may store historical data and/or analytics in the ADRF 118”, “At 686, the G-ADCCF 654 requests and receives historical data from ADRF 618 in respect of the event identity”).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to modify Muñoz and XIN in view of Pateromichelakis to achieved the claimed limitations because this would have helped to permit historical training data collected from the UPF to be persistently stored and reused for offline or repeated model training rather than re-requesting the information again which improves the performance of the system.
Response to Arguments
Applicant’s arguments filed on 08/12/2026 have been considered but are now moot in light of the new ground of rejection.
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 HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ario Etienne can be reached at ario.etienne@uspto.gov. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2457
