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
The Preliminary Amendment filed on 02/12/2025 has been entered. Claims 1-19 have been canceled. New claims 20-39 have been added. Claims 20-39 are pending in the application.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 20-39 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Samsung (Update on Solution #9: NWDAF-assisted application detection), provided by IDS.
Regarding claim 20, Samsung teaches a method, implemented by a network node in a wireless communication network, the method comprising:
receiving, from a consumer Network Function (NF), a request for an analytics service provided by a Network Data Analytics Function (NWDAF) executing on the network node, the request comprising: (Page 3: Figure 6.9.4-1. Page 2: A consumer (e.g. NEF) requests to the NWDAF to provide PFDs for newly detected applications.)
an analytics filter describing filter criteria for identifying one or more of a User Equipment Identifier (UE-ID), a Single Network Slice Selection Assistance Information (S-NSSAI) identifier, or a Domain Network Name (DNN); and (Page 3: Figure 6.9.4-1 The Analytics Filter Information may optionally include the UE ID, S-NSSAI and/or DNN. Page 2: 6.9.2 – Input Data: SUPI (UE ID), S-NSSAI, DNN, etc.)
an analytics input parameter that describes criteria for identifying a cluster from traffic data that matches the filter criteria and is stored at the NWDAF; (Pages 3-4: Figure 6.9.4-1, The NWDAF fetches currently stored PFD information from NEF(PFD) and historical data from ADRF (not shown in the figure). The NWDAF collects session related information from the UPF about URL, Domain name part, and IP 3-tuples of packets from the SDF not matching installed PDRs.)
collecting the traffic data from one or more NFs within the wireless communication network; (Pages 3-4: Figure 6.9.4-1, The NWDAF collects session related information from the UPF about URL, Domain name part, and IP 3-tuples of packets from the SDF not matching installed PDRs.)
identifying the cluster based on the collected traffic data, the filter criteria, and the analytics input parameter; (Pages 3-4: Figure 6.9.4-1, The NWDAF derives PFD analytics.)
generating Packet Flow Description (PFD) information for the cluster from the collected traffic data based on the filter criteria and the analytics input parameter; and (Page 1: The baseline usage of the generated analytics is to store the captured application characteristics as a PFD, and the PFD is used by SMF and UPF to detect an application. Page 2: The NWDAF analyses the collected data to generate unique traffic patterns, and provides it to the consumer (i.e. NEF).)
sending the PFD information to the consumer NF. (Pages 3-4: Figure 6.9.4-1, The NWDAF notifies the analytics consumer NF with outputs.)
Regarding claim 21, Samsung teaches the method of claim 20.
Samsung teaches wherein the consumer network function is a Network Exposure Function (NEF) and/or Packet Flow Description Function (PFDF). (Page 2: The NWDAF could collect the current and historical PFD information (including Application ID, historical IP 3-tuple, historical URL, historical Domain name information) from the NRF via NEF (PFDF) and ADRF respectively. A consumer (e.g. NEF) requests to the NWDAF to provide PFDs for newly detected applications.)
Regarding claim 22, Samsung teaches the method of claim 21.
Samsung teaches fetching PFDs from the NEF or the PFDF, wherein generating the PFD is responsive to the collected traffic data comprising session data that does not match any of the fetched PFDs. (Pages 3-4: Figure 6.9.4-1, The NWDAF fetches currently stored PFD information from NEF(PFD) and historical data from ADRF (not shown in the figure). The NWDAF collects session related information from the UPF about URL, Domain name part, and IP 3-tuples of packets from the SDF not matching installed PDRs.)
Regarding claim 23, Samsung teaches the method of claim 20.
Samsung teaches wherein collecting the traffic data from the one or more NFs comprises collecting historical data from an Analytical Data Repository Function (ADRF). (Page 2: The NWDAF could collect the current and historical PFD information (including Application ID, historical IP 3-tuple, historical URL, historical Domain name information) from the NRF via NEF (PFDF) and ADRF respectively.)
Regarding claim 24, Samsung teaches the method of claim 20.
Samsung teaches wherein collecting the traffic data from the one or more NFs comprises collecting Quality of Service (QoS) data from a Session Management Function (SMF). (Page 2 6.9.2 Input Data: NWDAF collects QoS flow related data from SMF for a specific S-NSSAI, DNN, and UE.)
Regarding claim 25, Samsung teaches the method of claim 20.
Samsung teaches identifying a traffic pattern from the collected traffic data that matches the filter criteria, wherein generating the PFD information comprises generating the PFD information for an application responsible for producing the traffic pattern. (Page 2: The NWDAF analyses the collected data to generate unique traffic patterns, and provides it to the consumer (i.e. NEF). Pages 3-4: Figure 6.9.4-1.)
Regarding claim 26, Samsung teaches the method of claim 20.
Samsung teaches wherein the filter criteria comprises an indicator of one or more user equipment identities. (Page 3: Figure 6.9.4-1 The Analytics Filter Information may optionally include the UE ID, S-NSSAI and/or DNN. Page 2: 6.9.2 – Input Data: SUPI (UE ID), S-NSSAI, DNN, etc.)
Regarding claim 27, Samsung teaches the method of claim 20.
Samsung teaches wherein the filter criteria comprises a predominant traffic flow direction. (Page 2 6.9.2 – Input Data: IP 3-tuple (to identify a service flow of the UE).
Regarding claim 28, Samsung teaches the method of claim 20.
Samsung teaches wherein the filter criteria comprises a metric describing packet size characteristics. (Page 2 6.9.2 – Input Data: Size of packets.)
Regarding claim 29, Samsung teaches the method of claim 20.
Samsung teaches wherein the filter criteria comprises a metric describing traffic reception. (Page 2 6.9.2 – Input Data: Data volume, Data duration.)
Regarding claim 30, Samsung teaches the method of claim 20.
Samsung teaches wherein the filter criteria comprises a metric describing traffic transmission characteristics. (Page 2 6.9.2 – Input Data: Packet transmission.)
Regarding claim 31, Samsung teaches a method, implemented by a network node in a wireless communication network, the method comprising:
sending, to a Network Data Analytics Function (NWDAF), a request for an analytics service, the request comprising: (Page 3: Figure 6.9.4-1. Page 2: A consumer (e.g. NEF) requests to the NWDAF to provide PFDs for newly detected applications.)
an analytics filter describing filter criteria for identifying one or more of a User Equipment Identifier (UE-ID), a Single Network Slice Selection Assistance Information (S-NSSAI) identifier, or a Domain Network Name (DNN); and (Page 3: Figure 6.9.4-1 The Analytics Filter Information may optionally include the UE ID, S-NSSAI and/or DNN. Page 2: 6.9.2 – Input Data: SUPI (UE ID), S-NSSAI, DNN, etc.)
an analytics input parameter that describes criteria for identifying a cluster from traffic data that matches the filter criteria and is stored at the NWDAF; (Pages 3-4: Figure 6.9.4-1, The NWDAF fetches currently stored PFD information from NEF(PFD) and historical data from ADRF (not shown in the figure). The NWDAF collects session related information from the UPF about URL, Domain name part, and IP 3-tuples of packets from the SDF not matching installed PDRs.)
receiving, from the NWDAF, Packet Flow Description (PFD) information that matches the filter criteria and the criteria for identifying the cluster; (Pages 3-4: Figure 6.9.4-1, The NWDAF derives PFD analytics. Page 1: The baseline usage of the generated analytics is to store the captured application characteristics as a PFD, and the PFD is used by SMF and UPF to detect an application.)
assigning an application identifier to the PFD information; and (Page 2: The consumer i.e. NEF stores PFD associated with an application ID to enable the detection of application traffic in the future.)
sending a PFD comprising the application identifier and PFD information to a Session Management Function (SMF). (Page 1: When an AF delivers PFD to NEF (PFDF), it will be distributed to SMFs and UPFs to enable flow detection according to clause 5.8.2 of TS 23.501. Page 2: new PFD information (including Application ID, new IP 3-tuple, new URL, new Domain name information) for the existing Application ID could be derived by the NWDAF. The new PFD information provided by the NWDAF can be used by the NEF for provisioning SMF/UPF.)
Regarding claim 32, Samsung teaches the method of claim 31.
Samsung teaches receiving a PFD fetch request from the NWDAF; and sending a plurality of PFDs to the NWDAF in response to the PFD fetch request; (Page 3: Figure 6.9.4-1 Nnef_PFDManagement_Fetch and Nnef_PFDManagement_Fetch response. Page 2: The NWDAF could collect the current and historical PFD information (including Application ID, historical IP 3-tuple, historical URL, historical Domain name information) from the NRF via NEF (PFDF) and ADRFrespectively.)
wherein the PFD sent to the SMF is distinct from each of the PFDs sent to the NWDAF. (Page 2: Based on PFD information from ADRF and NRF and traffic information from UPF, new PFD information (including Application ID, new IP 3-tuple, new URL, new Domain name information) for the existing Application ID could be derived by the NWDAF. The new PFD information provided by the NWDAF can be used by the NEF for provisioning SMF/UPF.)
Regarding claim 33, Samsung teaches the method of claim 31.
Samsung teaches wherein sending the PFD to the SMF comprises sending the PFD to a User Plane Function (UPF) via the SMF for inclusion of the PFD in enforcing user plane policies. (Page 1: When an AF delivers PFD to NEF (PFDF), it will be distributed to SMFs and UPFs to enable flow detection according to clause 5.8.2 of TS 23.501. Page 2: Based on PFD information from ADRF and NRF and traffic information from UPF, new PFD information (including Application ID, new IP 3-tuple, new URL, new Domain name information) for the existing Application ID could be derived by the NWDAF. The new PFD information provided by the NWDAF can be used by the NEF for provisioning SMF/UPF.)
Regarding claim 34, Samsung teaches the method of claim 31.
Samsung teaches wherein the filter criteria comprises an indicator of one or more user equipment identities. (Page 3: Figure 6.9.4-1 The Analytics Filter Information may optionally include the UE ID, S-NSSAI and/or DNN. Page 2: 6.9.2 – Input Data: SUPI (UE ID), S-NSSAI, DNN, etc.)
Regarding claim 35, Samsung teaches the method of claim 31.
Samsung teaches wherein the filter criteria comprises a predominant traffic flow direction. (Page 2 6.9.2 – Input Data: IP 3-tuple (to identify a service flow of the UE).
Regarding claim 36, Samsung teaches the method of claim 31.
Samsung teaches wherein the filter criteria comprises a metric describing packet size characteristics. (Page 2 6.9.2 – Input Data: Size of packets.)
Regarding claim 37, Samsung teaches the method of claim 31.
Samsung teaches wherein the filter criteria comprises a metric describing traffic reception and/or transmission characteristics (Page 2 6.9.2 – Input Data: Data volume, Data duration, and Packet transmission.)
Same rationales apply to claim 38 (network node) because it is substantially similar to claim 20 (method).
Same rationales apply to claim 39 (network node) because it is substantially similar to claim 31 (method).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455
Prosecution Insights