Prosecution Insights
Last updated: October 16, 2026
Application No. 19/101,380

SENDING AND RECEIVING A NETWORK SLICE SERVICE PROFILE

Non-Final OA §102§103
Filed
Feb 05, 2025
Priority
Aug 15, 2022 — nonprovisional of PCTEP2022072769
Examiner
KAZI, SAYEEM MUHAMMAD
Art Unit
2455
Tech Center
2400 — Computer Networks
Assignee
Telefonaktiebolaget LM Ericsson
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-58.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
10 currently pending
Career history
12
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§102 §103
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 . Specification The abstract of the disclosure is objected to because it should avoid using phrases which can be implied, such as “… are disclosed,” “this disclosure concerns,” “the disclosure describes.” Here, the abstract uses the term “provided …” The abstract is further objected because, it is a copy of claim 1. Pursuant to MPEP 608.01(b), an abstract must be a narrative summary of the invention. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b). Claim Rejections - 35 USC § 102 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. (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. Claims 1, 9, 13, 16, 18, 20-22, 35 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Gupta et al. (US 20210185695). With regards to claim 1, Gupta teaches a method in a first network node of monitoring network slice usage, the method comprising: receiving a service profile for a network slice, the service profile identifying a plurality of sets of one or more conditions and a plurality of traffic profiles, individual traffic profiles being associated with a respective set of one or more conditions (…NRF 100 may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances...; [0043], Gupta. … NRF 100 is a repository for NF profiles. In order to communicate with a producer NF, a consumer NF (i.e., first node) or an SCP must obtain the NF profile from NRF 100... [0044], Gupta. 3GPP TS 28.531 defines procedures for network slice service consumers to request creation, deletion, and check the feasibility of network slice instances and network slice subnet instances. The procedure defined for a network slice feasibility check by a network slice management service provider is illustrated in FIG. 5. Referring to FIG. 5, in line 1, a Network Slice Subnet Management Service Provider (NSSMS_Provider) 500 receives a provisioning NSSI request (e.g., AllocateNssi request or ModifyNssi request) from Network Slice Subnet Management Service Consumer (NSSMS_Consumer) 502 with network-slice subnet-related requirements (e.g. area information, user number, traffic demand, QoS quality, whether the requested network slice instance can be shared (i.e., service profile with plurality of conditions)). The request is evaluated and initial resources to be allocated are identified. NSSMS_Provider 500 may be NSMF 402 and NSSMS_Consumer 502 may be CSMF 400 described above with respect to FIG. 4; [0063], Gupta); receiving usage information identifying usage of the network slice by a consumer of the network slice (…NWDAF 600 includes a network slice load information subscription manager 808. Network slice load information subscription manager 808 receives subscription requests from NSMF 402 and other consumers that wish to receive load information concerning network slices… The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription… [0097], Gupta); determining whether the usage of the network slice under one or more conditions of the usage of the network slice satisfies the traffic profile associated with the set of one or more conditions that correspond to the one or more conditions of the usage of the network slice (In step 902, the process includes receiving network slice load information from the NWDAF. For example, NSMF 402 may receive an Eventsubscription_Notify message from NWDAF 600 containing load information for network slice instances and network slice subnet instances identified in the Eventsubscription_Subscribe message. The load information may identify the percentage loading (or availability) of each network slice instance or subnet instance. The Eventsubscription_Notify message may be received by or via NWDAF subscription interface 804 of NSMF 402 illustrated in FIG. 8. The reporting may be triggered in response to the NSMF-defined criterion associated with the subscription being met; [0103], Gupta). With regards to claim 9, Gupta teaches a method of sending a service profile, the method comprising: receiving, at a second network node (NSSMS_Provider), a notification of allocation of a network slice and a service profile for the network slice, the service profile identifying a plurality of sets of one or more conditions and a plurality of traffic profiles, individual traffic profiles being associated with a respective set of one or more conditions (…NRF 100 may maintain profiles of available producer NF service instances and their supported services and allow consumer NFs or SCPs to subscribe to and be notified of the registration of new/updated producer NF service instances...; [0043], Gupta. … NRF 100 is a repository for NF profiles. In order to communicate with a producer NF (i.e., second node), a consumer NF or an SCP must obtain the NF profile from NRF 100... [0044], Gupta. subscribing, by the NSMF, independently of monitoring requests from the network slice service consumers and via a network data analytics function (NWDAF) subscription interface of the NSMF, directly with the NWDAF to create a subscription to be notified of network slice load information and specifying, as part of the subscription, network slice load information report generation criteria defined by the NSMF; Claim 1, Gupta); sending, by the second network node, the service profile and usage information identifying usage of the network slice by a consumer of the network slice to a first network node (3GPP TS 28.531 defines procedures for network slice service consumers to request creation, deletion, and check the feasibility of network slice instances and network slice subnet instances. The procedure defined for a network slice feasibility check by a network slice management service provider is illustrated in FIG. 5. Referring to FIG. 5, in line 1, a Network Slice Subnet Management Service Provider (NSSMS_Provider) 500 receives a provisioning NSSI request (e.g., AllocateNssi request or ModifyNssi request) from Network Slice Subnet Management Service Consumer (NSSMS_Consumer) 502 with network-slice subnet-related requirements (e.g. area information, user number, traffic demand, QoS quality, whether the requested network slice instance can be shared). The request is evaluated and initial resources to be allocated are identified. NSSMS_Provider 500 may be NSMF 402 and NSSMS_Consumer 502 may be CSMF 400 described above with respect to FIG. 4 (i.e., second network node sending profile and usage information to the first network node); [0063], Gupta); receiving, at the first network node, the service profile for the network slice and the usage information (subscribing, by the NSMF, independently of monitoring requests from the network slice service consumers and via a network data analytics function (NWDAF) subscription interface of the NSMF, directly with the NWDAF to create a subscription to be notified of network slice load information and specifying, as part of the subscription, network slice load information report generation criteria defined by the NSMF; Claim 1, Gupta); determining, by the first network node whether the usage of the network slice under one or more conditions of the usage of the network slice satisfies the traffic profile associated with the set of one or more conditions that correspond to the one or more conditions of the usage of the network slice (In step 902, the process includes receiving network slice load information from the NWDAF. For example, NSMF 402 may receive an Eventsubscription_Notify message from NWDAF 600 containing load information for network slice instances and network slice subnet instances identified in the Eventsubscription_Subscribe message. The load information may identify the percentage loading (or availability) of each network slice instance or subnet instance. The Eventsubscription_Notify message may be received by or via NWDAF subscription interface 804 of NSMF 402 illustrated in FIG. 8. The reporting may be triggered in response to the NSMF-defined criterion associated with the subscription being met; [0103], Gupta). With regards to claim 13, Gupta teaches the method of claim 9, further comprising sending, by the second network node to a network usage node, a subscription request to subscribe to usage information identifying usage of the network slice by a consumer of the network slice (NWDAF 600 includes a network slice load information subscription manager 808. Network slice load information subscription manager 808 receives subscription requests from NSMF 402 and other consumers that wish to receive load information concerning network slices. Network slice load information subscription manager 808, after validating the subscribing entities, creates network slice load information subscriptions by storing records corresponding to the subscriptions in network slice analytics and subscriptions database 810…; [0097], Gupta). With regards to claim 16, Gupta teaches the method of claim 13, further comprising: receiving, from the network usage node, the usage information identifying usage of the network slice by a consumer of the network slice, wherein the information identifying the usage of the network slice by the consumer of the network slice is sent by the second network node to the first network node in a charging data request (NWDAF 600 includes a network slice load information subscription manager 808. Network slice load information subscription manager 808 receives subscription requests from NSMF 402 and other consumers that wish to receive load information concerning network slices. Network slice load information subscription manager 808, after validating the subscribing entities, creates network slice load information subscriptions by storing records corresponding to the subscriptions in network slice analytics and subscriptions database 810. The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription; [0097], Gupta). With regards to claim 18, Gupta teaches the method of claim 9, further comprising: receiving, at a third network node, a request for allocation of a network slice from a network slice consumer, the request identifying a service profile for a network slice, the service profile identifying a plurality of sets of one or more conditions and a plurality of traffic profiles, wherein individual traffic profiles are associated with a respective set of one or more conditions; determining, by the third network node, a network slice instance, NSI, for the request; and sending, by the third network node, a notification identifying the network slice instance to a second network node, the notification identifying the service profile. (FIG. 6 is a diagram illustrating a procedure implemented by the NSMF (i.e., claimed third network node) for obtaining network slice load information from a network data analytics function (NWDAF), after creation of a network slice instance (i.e., network slice instance determined), dynamically during operation of the network slice instance, and independently of (i.e., without receiving a monitoring request from) a network slice services consumer. Referring to FIG. 6, in line 1 of the message flow diagram, NSMF 402 sends an Eventsubscription_Subscribe/Unsubscribe message to NWDAF 600. In this example, it is assumed that the message is an Eventsubsccription_Subscribe message. The Eventsubscription_Subscribe message is used by NSMF 402 to subscribe to receive information regarding the real-time, instantaneous load level of a network slice. Exemplary parameters that can be included in the event subscription message will be described in further detail below with respect to FIG. 7. NWDAF 600 is an analytics function defined in 3GPP TS 29.520 that collects information regarding utilization of network functions and provides a subscription services for other nodes to be notified of the information it collects; [0070], Gupta. Gupta further teaches … The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription; [0097], Gupta). With regards to claim 20, Gupta teaches the method of claim 18, further comprising receiving, at the third network node from the second network node, a subscription request for notifications of allocations of network slice instances, the subscription request based on the service profile, wherein sending the notification to the second network node is performed in response to the subscription request (FIG. 6 is a diagram illustrating a procedure implemented by the NSMF (i.e., claimed third network node) for obtaining network slice load information from a network data analytics function (NWDAF), after creation of a network slice instance (i.e., network slice instance determined), dynamically during operation of the network slice instance, and independently of (i.e., without receiving a monitoring request from) a network slice services consumer. Referring to FIG. 6, in line 1 of the message flow diagram, NSMF 402 sends an Eventsubscription_Subscribe/Unsubscribe message to NWDAF 600. In this example, it is assumed that the message is an Eventsubsccription_Subscribe message. The Eventsubscription_Subscribe message is used by NSMF 402 to subscribe to receive information regarding the real-time, instantaneous load level of a network slice. Exemplary parameters that can be included in the event subscription message will be described in further detail below with respect to FIG. 7. NWDAF 600 is an analytics function defined in 3GPP TS 29.520 that collects information regarding utilization of network functions and provides a subscription services for other nodes to be notified of the information it collects; [0070], Gupta. Gupta further teaches … NWDAF 600 includes a network slice load information subscription manager 808. Network slice load information subscription manager 808 receives subscription requests from NSMF 402 and other consumers that wish to receive load information concerning network slices. Network slice load information subscription manager 808, after validating the subscribing entities, creates network slice load information subscriptions by storing records corresponding to the subscriptions in network slice analytics and subscriptions database 810. The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription; [0097], Gupta). With regards to claim 21, Gupta teaches the method of claim 18, further comprising sending, by the third network node, an allocation response to the network slice consumer, the allocation response identifying the network slice instance (…The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription; [0097], Gupta). With regards to claim 22, Gupta teaches the method of claim 18, further comprising sending, by the third network node towards the second network node, usage information identifying usage of the network slice by a consumer of the network slice, wherein sending, by the third network node towards the second network node, the usage information comprises sending the usage information to an aggregation node for aggregation of the usage information before the aggregation node sends the aggregated usage information to the second network node (A network slice load information analytics engine 809 receives load information from network functions (e.g., PCFs, SMFs, AMFs, etc.), performs analytics based on the load information (i.e., aggregate), and stores results of the analytics and the load information in network slice analytics and subscription database 810; [0098], Gupta). With regards to claim 35, the claim limitations are identical and/or equivalent in scope to claim 1, therefore, claim 35 is rejected under the same rationale as claim 1. 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. Claims 2, 10, 12, 25, 29, and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Vaishnavi et al. (US 20250150540). With regards to claim 2, Gupta teaches the limitations of claim 2 as applied to claim 1 except for wherein one or both of the service profile and the usage information is received from a second network node, wherein one or both: the second network node is a Charging Enablement Function, CEF; and the first network node is a Charging Function, CHF. However, in the same field of endeavor Vaishnavi teaches wherein one or both of the service profile and the usage information is received from a second network node, wherein one or both: the second network node is a Charging Enablement Function, CEF; and the first network node is a Charging Function, CHF (…the processor 805 derives reporting requirements for charging based on existing business level agreements, the business level agreements comprising one or more of service level agreements (“SLAs”), service level specifications (“SLSs”), generic network slice templates (“GSTs”), network slice type (“NEST”), ServiceProfile, and NetworkSlice profile; [0155], Vaishnavi. Vaishnavi Further teaches … SA5 supports CTF and CEF based solutions for charging. CTF-based is when the entity reporting information relating to charging inherently supports charging triggers, e.g., it can trigger the collection of charging reports in the CHF. A CEF based solution is when a centralized function collects data that may be relevant to one or more charging reports and may trigger a joint charging data trigger to the CHF; [0102], Vaishnavi. Vaishnavi further teaches … charging function (“CHF”) and the first event notification comprises a charging data request to the CHF (i.e., Claimed CHF receiving the service profile in order to perform charging action sent by the claimed second node); [0148], Vaishnavi). One of ordinary skill in the art would have been motivated to use Vaishnavi’s charging architecture to improve the system by providing a standardized and efficient mechanism for implementing usage-based charging. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to employ the CEF and CHF of Vaishnavi for performing the charging action based on service profile and usage information that reflects subscriber’s agreement. This would improve the system by providing a standardized and efficient mechanism for implementing usage-based charging according to applicable service agreements/profiles, with a reasonable expectation of success. With regards to claim 10, Gupta teaches the limitations of claim 10 as applied to claim 9 except for sending, by the second network node, the service profile to the first network node in a charging data request. However, in the same field of endeavor Vaishnavi teaches sending, by the second network node, the service profile to the first network node in a charging data request (…the processor 805 derives reporting requirements for charging based on existing business level agreements, the business level agreements comprising one or more of service level agreements (“SLAs”), service level specifications (“SLSs”), generic network slice templates (“GSTs”), network slice type (“NEST”), ServiceProfile, and NetworkSlice profile; [0155], Vaishnavi. Vaishnavi further teaches …the first entity comprises a charging function (“CHF”) and the first event notification comprises a charging data request to the CHF (i.e., Claimed CHF receiving the service profile in order to perform charging action sent by the claimed second node); [0148], Vaishnavi). One of ordinary skill in the art would have been motivated to use Vaishnavi’s charging architecture to improve the system by providing a standardized and efficient mechanism for implementing usage-based charging. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to employ the CEF and CHF of Vaishnavi for performing the charging action based on service profile and usage information that reflects subscriber’s agreement. This would improve the system by providing a standardized and efficient mechanism for implementing usage-based charging according to applicable service agreements/profiles, with a reasonable expectation of success. With regards to claim 12, Gupta teaches the limitations of claim 12 as applied to claim 9 except for receiving, at the second network node, with the notification of allocation of a network slice, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile. However in the same field of endeavor Vaishnavi teaches receiving, at the second network node, with the notification of allocation of a network slice, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile (…the processor 805 derives reporting requirements for charging based on existing business level agreements, the business level agreements comprising one or more of service level agreements (“SLAs”), service level specifications (“SLSs”), generic network slice templates (“GSTs”), network slice type (“NEST”), ServiceProfile, and NetworkSlice profile; [0155], Vaishnavi. Vaishnavi Further teaches … SA5 supports CTF and CEF based solutions for charging. CTF-based is when the entity reporting information relating to charging inherently supports charging triggers, e.g., it can trigger the collection of charging reports in the CHF. A CEF based solution is when a centralized function collects data (i.e., claimed second node CEF receiving the details) that may be relevant to one or more charging reports and may trigger a joint charging data trigger to the CHF; [0102], Vaishnavi. Vaishnavi further teaches … charging function (“CHF”) and the first event notification comprises a charging data request to the CHF ; [0148], Vaishnavi). One of ordinary skill in the art would have been motivated to use Vaishnavi’s charging architecture to improve the system by providing a standardized and efficient mechanism for implementing usage-based charging. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to employ the CEF and CHF of Vaishnavi for performing the charging action based on service profile and usage information that reflects subscriber’s agreement. This would improve the system by providing a standardized and efficient mechanism for implementing usage-based charging according to applicable service agreements/profiles, with a reasonable expectation of success. With regards to claim 25, Gupta teaches the limitations of claim 25 as applied to claims 18 except for receiving, at the third network node with the request, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile ; and sending, by the third network node to the second network node, with the notification, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile. However, in the same field of endeavor Vaishnavi teaches comprising one or both: receiving, at the third network node with the request, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile ; and sending, by the third network node to the second network node, with the notification, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile (…the processor 805 derives reporting requirements for charging based on existing business level agreements, the business level agreements comprising one or more of service level agreements (“SLAs”), service level specifications (“SLSs”), generic network slice templates (“GSTs”), network slice type (“NEST”), ServiceProfile, and NetworkSlice profile (i.e., claimed third node receiving the details and sending for charging action); [0155], Vaishnavi. Vaishnavi Further teaches … SA5 supports CTF and CEF based solutions for charging. CTF-based is when the entity reporting information relating to charging inherently supports charging triggers, e.g., it can trigger the collection of charging reports in the CHF. A CEF based solution is when a centralized function collects data that may be relevant to one or more charging reports and may trigger a joint charging data trigger to the CHF; [0102], Vaishnavi. Vaishnavi further teaches … charging function (“CHF”) and the first event notification comprises a charging data request to the CHF (i.e., second node receiving the details); [0148], Vaishnavi). One of ordinary skill in the art would have been motivated to use Vaishnavi’s charging architecture to improve the system by providing a standardized and efficient mechanism for implementing usage-based charging. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to employ the CEF and CHF of Vaishnavi for performing the charging action based on service profile and usage information that reflects subscriber’s agreement. This would improve the system by providing a standardized and efficient mechanism for implementing usage-based charging according to applicable service agreements/profiles, with a reasonable expectation of success. With regards to claim 29, Gupta teaches the method of claim 18, further comprising: sending, by the network slice consumer to the third network node, a request for a network slice instance, the request identifying a service profile for a network slice, the service profile identifying a plurality of sets of one or more conditions and a plurality of traffic profiles, wherein individual traffic profiles are associated with a respective set of one or more conditions (Referring to FIG. 5, in line 1, a Network Slice Subnet Management Service Provider (NSSMS_Provider) 500 receives a provisioning NSSI request (e.g., AllocateNssi request or ModifyNssi request) from Network Slice Subnet Management Service Consumer (NSSMS_Consumer) 502 with network-slice subnet-related requirements (e.g. area information, user number, traffic demand, QoS quality, whether the requested network slice instance can be shared (i.e., service profile with plurality of conditions)). The request is evaluated and initial resources to be allocated are identified. NSSMS_Provider 500 may be NSMF 402 and NSSMS_Consumer 502 may be CSMF 400 described above with respect to FIG. 4; [0063], Gupta); Gupta does not teach sending, by the network slice consumer with the request, an indication that a charging action for the consumer of the network slice maybe based on one or more of the sets of one or more conditions in the service profile. However in the same field of endeavor Vaishnavi teaches sending, by the network slice consumer with the request, an indication that a charging action for the consumer of the network slice maybe based on one or more of the sets of one or more conditions in the service profile (…the processor 805 derives reporting requirements for charging based on existing business level agreements, the business level agreements comprising one or more of service level agreements (“SLAs”), service level specifications (“SLSs”), generic network slice templates (“GSTs”), network slice type (“NEST”), ServiceProfile, and NetworkSlice profile; [0155], Vaishnavi. Vaishnavi Further teaches … SA5 supports CTF and CEF based solutions for charging. CTF-based is when the entity reporting information relating to charging inherently supports charging triggers, e.g., it can trigger the collection of charging reports in the CHF. A CEF based solution is when a centralized function collects data that may be relevant to one or more charging reports and may trigger a joint charging data trigger to the CHF; [0102], Vaishnavi. Vaishnavi further teaches … charging function (“CHF”) and the first event notification comprises a charging data request to the CHF (i.e., second node receiving the details); [0148], Vaishnavi. Vaishnavi further teaches However, there is agreement in SA5 that when the operator and the external consumer agree to the exposure of the raw network management level APIs, or in other words management service producers (“MnS producers”), the external consumer may be charged for access to the APIs (i.e., agreement and communication between provider and consumer); [0037], Vaishnavi) One of ordinary skill in the art would have been motivated to use Vaishnavi’s charging architecture to improve the system by providing a standardized and efficient mechanism for implementing usage-based charging. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to employ the CEF and CHF of Vaishnavi for performing the charging action based on service profile and usage information that reflects subscriber’s agreement. This would improve the system by providing a standardized and efficient mechanism for implementing usage-based charging according to applicable service agreements/profiles, with a reasonable expectation of success. With regards to claim 31, Gupta teaches through Vaishnavi the limitations of claim 29, including comprising receiving, at the network slice consumer from the third network node, an allocation response, the allocation response identifying the network slice instance (NWDAF 600 includes a network slice load information subscription manager 808. Network slice load information subscription manager 808 receives subscription requests from NSMF 402 and other consumers that wish to receive load information concerning network slices. Network slice load information subscription manager 808, after validating the subscribing entities, creates network slice load information subscriptions by storing records corresponding to the subscriptions in network slice analytics and subscriptions database 810. The records may identify the subscribing entities (e.g., NSMF 402), the network slice instances and network slice subnet instances to which each entity subscribes, and the trigger conditions that trigger reporting of network slice load information for each subscription; [0097], Gupta). Claims 5, 6, 7, 8, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Senarath et al. (US 20180220277). With regards to claim 5, Gupta teaches the method of claim 1, further comprising … the determination of whether the usage of the network slice under one or more conditions of the usage of the network slice satisfies the traffic profile for the set of one or more conditions corresponding to the one or more conditions of the usage of the network slice (In step 902, the process includes receiving network slice load information from the NWDAF. For example, NSMF 402 may receive an Eventsubscription_Notify message from NWDAF 600 containing load information for network slice instances and network slice subnet instances identified in the Eventsubscription_Subscribe message. The load information may identify the percentage loading (or availability) of each network slice instance or subnet instance. The Eventsubscription_Notify message may be received by or via NWDAF subscription interface 804 of NSMF 402 illustrated in FIG. 8. The reporting may be triggered in response to the NSMF-defined criterion associated with the subscription being met; [0103], Gupta). Gupta does not teach performing a charging action based on the determination of whether the usage of the network... However, in the same field of endeavor, Senarath teaches performing a charging action based on the determination of whether the usage of the network... (charging to a VN customer is usage based charging. For example, a first charge may be levied for access network usage and a second, possibly different charge may be levied for core network usage. Charging may be pay as you go charging, for example. Usage-based charging may be based for example on amount of generated traffic (e.g. number of sessions, bit volume) or based on an amount of resources used for serving the VN customer. The charging data collected would thus be usage based, but it could be reported to the VN customer on a very short reporting cycle so that the VN customer can accurately determine the data usage. The collected data could also reflect the time and location of the data connection along with network usage statistics to enable congestion based billing; [0131], Senarath) One of ordinary skill in the art would have been motivated to combine the teachings of Gupta and Senarath usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to perform a charging action based on its usage determination as taught by Senarath, to provide usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage and the applicable service profile. With regards to claim 6, Gupta and Senarath teaches the limitations of claim 6 as applied to claim 5 including the charging action comprises a surcharge action or a discount action for a consumer of the network slice (The comparison can be used to prepare charging data, bills or invoices, or account debiting or crediting information. For example, if delivered performance does not meet promised performance, an agreed-upon discount may be applied; [0113], Senarath). Motivation to combine is similar to that of claim 5. With regards to claim 7, Gupta teaches the limitations of claim 7 as applied to claim 1 except for the service profile, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile. However, in the same field of endeavor, Senarath teaches, the service profile, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile (These billing rules may include a fixed data allocation to be associated with a monthly subscription and charges for overages, a per bit/byte/megabyte (etc.) charge for all data consumed, etc. There may be times of day in which consuming network resources is discounted across the network (e.g. free phone calls or a reduced rate for data consumption during evenings and weekends (i.e., charging action based on service profile); [0003], Senarath). One of ordinary skill in the art would have been motivated to combine the teachings of Gupta and Senarath usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to perform a charging action based on its usage determination as taught by Senarath, to provide usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage and the applicable service profile. With regards to claim 8, Gupta teaches the limitations of claim 8 as applied to claim 1 except for wherein the usage information comprises a charging data request. However, in the same field of endeavor, Senarath teaches, wherein the usage information comprises a charging data request (These billing rules may include a fixed data allocation to be associated with a monthly subscription and charges for overages, a per bit/byte/megabyte (etc.) charge for all data consumed, etc. There may be times of day in which consuming network resources is discounted across the network (e.g. free phone calls or a reduced rate for data consumption during evenings and weekends (i.e., usage information includes data consumption information); [0003], Senarath). One of ordinary skill in the art would have been motivated to combine the teachings of Gupta and Senarath usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to perform a charging action based on its usage determination as taught by Senarath, to provide usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage and the applicable service profile. With regards to claim 11, Gupta teaches the method of claim 9, further comprising sending, by the second network node to the first network node with the service profile (3GPP TS 28.531 defines procedures for network slice service consumers to request creation, deletion, and check the feasibility of network slice instances and network slice subnet instances. The procedure defined for a network slice feasibility check by a network slice management service provider is illustrated in FIG. 5. Referring to FIG. 5, in line 1, a Network Slice Subnet Management Service Provider (NSSMS_Provider) 500 receives a provisioning NSSI request (e.g., AllocateNssi request or ModifyNssi request) from Network Slice Subnet Management Service Consumer (NSSMS_Consumer) 502 with network-slice subnet-related requirements (e.g. area information, user number, traffic demand, QoS quality, whether the requested network slice instance can be shared). The request is evaluated and initial resources to be allocated are identified. NSSMS_Provider 500 may be NSMF 402 and NSSMS_Consumer 502 may be CSMF 400 described above with respect to FIG. 4 (i.e., second network node sending profile to the first network node); [0063], Gupta); Gupta does not teach the service profile, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile. However, in the same field of endeavor, Senarath teaches, the service profile, an indication that a charging action for a consumer of the network slice may be based on one or more of the sets of one or more conditions in the service profile (These billing rules may include a fixed data allocation to be associated with a monthly subscription and charges for overages, a per bit/byte/megabyte (etc.) charge for all data consumed, etc. There may be times of day in which consuming network resources is discounted across the network (e.g. free phone calls or a reduced rate for data consumption during evenings and weekends (i.e., charging action based on service profile); [0003], Senarath). One of ordinary skill in the art would have been motivated to combine the teachings of Gupta and Senarath usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage. Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to modify Gupta to perform a charging action based on its usage determination as taught by Senarath, to provide usage-based charging that reflects a subscriber’s or consumer’s actual network slice usage and the applicable service profile. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAYEEM KAZI whose telephone number is (571)397-2559. The examiner can normally be reached Mon-Fri 8:00-5:00 EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise can be reached at 571-272-3865. 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. /S.K./Examiner, Art Unit 2455 /EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455
Read full office action

Prosecution Timeline

Feb 05, 2025
Application Filed
Sep 08, 2026
Non-Final Rejection mailed — §102, §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month