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 .
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 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.
Claims 1-14 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by Velev et al. (Provisional Application Number: 63/127,988 of U.S. Patent Application Number: 2024/0306008).
Consider claim 1; Velev discloses a primary network slice admission control function (NSACF) configured to perform operations comprising:
determining a global quota comprising a first number of user equipments (UEs) or protocol data unit (PDU) sessions that are allowed to be registered to a network slice [“The central QMF is responsible to manage/control the global status and/or quota of a controlled slice attribute, whereas “global” means all non-roaming and roaming UEs using the network slice resources.” (par. 67, lines 3-5)];
receiving [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], from a first local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], an indication of a second number of UEs or PDU sessions currently registered to the network slice by the first local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], wherein the first local NSACF is configured with a first local quota comprising a third number of UEs or PDU sessions that are allowed to be registered to the network slice by the first local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)];
comparing the second number to a local quota usage threshold for the first local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “…the QMF collects information about the status of the slice attribute.” (par. 100, line 1) “…the QMF may determine “quota reached” event when the quota is consumed by 99%, and the QMF may determine “quota available again” event when the quota is consumed below 95%” (par. 101, lines 4-6)]; and
determining [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)], based on the comparing [“…the QMF collects information about the status of the slice attribute.” (par. 100, line 1) “…the QMF may determine “quota reached” event when the quota is consumed by 99%, and the QMF may determine “quota available again” event when the quota is consumed below 95%” (par. 101, lines 4-6)], whether the first local quota for the first local NSACF is to be updated by decreasing the third number [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 2; Velev discloses receiving an update request from a second local NSACF indicating the second NSACFs has reached a second local quota comprising a fourth number of UEs or PDU sessions that are allowed to be registered to the network slice by the second local NSACF [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)]; and determining the primary NSACF does not have a global quota to allocate to the second NSACF [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 3; Velev discloses sending a request to the first local NSACF to report the second number [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], wherein the request is triggered based on the receiving the update request from the second local NSACF and determining the primary NSACF does not have a global quota to allocate to the second NSACF [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)].
Consider claim 4; Velev discloses the first local quota is updated when the second number is less than the local quota usage threshold [“The distributed QMFs are responsible to manage local quotas, i.e., collecting data from other NFs and enforcing policies for local quotas.” (par. 67, lines 8-9)].
Consider claim 5; Velev discloses sending an update message to the first local NSACF to update the first local quota by decreasing the third number [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)]; and receiving an update response from the first local NSACF indicating the first local quota has been updated [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)].
Consider claim 6; Velev discloses determining the second local quota is to be updated by increasing the fourth number [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], wherein an increase of the fourth number corresponds to a decrease of the third number [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)]; and sending an update response to the second local NSACF to update the second local quota by increasing the fourth number [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)].
Consider claim 7; Velev discloses the first local quota is not updated when the second number is greater than the local quota usage threshold [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 8; Velev discloses sending an update response to the second local NSACF to indicate the second local quota is not to be updated [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 9; Velev discloses a local network slice admission control function (NSACF) configured to perform operations comprising:
receiving [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], from an access and mobility control function (AMF) [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1… NFs (e.g. AMF…)…” (par. 117, lines 4-6)], a first update request indicating a first number of user equipments (UEs) or protocol data unit (PDU) sessions currently registered to a network slice by the local NSACF should be incremented [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)];
determining the first number of UEs or PDU sessions will exceed a local quota comprising a second number of UEs or PDU sessions that are allowed to be registered to the network slice by the local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)]; and
sending [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], to a primary NSACF [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], a second update request from a second local NSACF indicating the first number should be incremented [“…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)].
Consider claim 10; Velev discloses receiving [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], from the primary NSACF [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], a first update response to the second update request indicating the local NSACF is to update the local quota by increasing the second number [“…the central status and quota of controlled slice attribute is managed centrally in the QMF, which allows the QMF to enforce policy (e.g., configure policy) I other for NFs to enforce a particular action (e.g., start/end rejecting new UEs or new PDU sessions).” (par. 76, lines 3-6) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)]; incrementing the first number [“…the central status and quota of controlled slice attribute is managed centrally in the QMF, which allows the QMF to enforce policy (e.g., configure policy) I other for NFs to enforce a particular action (e.g., start/end rejecting new UEs or new PDU sessions).” (par. 76, lines 3-6) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)]; and sending, to the AMF [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1… NFs (e.g. AMF…)…” (par. 117, lines 4-6)], a second update response indicating the first number has been incremented [“…the central status and quota of controlled slice attribute is managed centrally in the QMF, which allows the QMF to enforce policy (e.g., configure policy) I other for NFs to enforce a particular action (e.g., start/end rejecting new UEs or new PDU sessions).” (par. 76, lines 3-6) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)].
Consider claim 11; Velev discloses receiving [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)], from the primary NSACF [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)], a first update response to the second update request indicating the first number is not incremented [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)]; and sending [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)], to the AMF [“The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1… NFs (e.g. AMF…)…” (par. 117, lines 4-6)], a second update response indicating the first number is not incremented [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 12; Velev discloses a primary network slice admission control function (NSACF) configured to perform operations comprising:
receiving [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], from each of a plurality of local NSACFs [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], a report indicating a first number of user equipments (UEs) or protocol data unit (PDU) sessions currently registered to a network slice by the local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)];
comparing the first number to a local quota usage threshold for each of the local NSACFs [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “…the QMF collects information about the status of the slice attribute.” (par. 100, line 1) “…the QMF may determine “quota reached” event when the quota is consumed by 99%, and the QMF may determine “quota available again” event when the quota is consumed below 95%” (par. 101, lines 4-6)], wherein the local quota usage threshold is based on a local quota for each of the local NSACFs comprising a second number of UEs or PDU sessions that are allowed to be registered to the network slice by a corresponding local NSACF [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “…the QMF collects information about the status of the slice attribute.” (par. 100, line 1) “…the QMF may determine “quota reached” event when the quota is consumed by 99%, and the QMF may determine “quota available again” event when the quota is consumed below 95%” (par. 101, lines 4-6)]; and
determining [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)], based on the comparing [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “…the QMF collects information about the status of the slice attribute.” (par. 100, line 1) “…the QMF may determine “quota reached” event when the quota is consumed by 99%, and the QMF may determine “quota available again” event when the quota is consumed below 95%” (par. 101, lines 4-6)], whether the local quota for one or more of the local NSACFs is to be updated [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 13; Velev discloses updating the local quota comprises decreasing the second number [“The policy created by the QMF may depend on the level of the quota. For example, if the slice quota has reached 90%, apply policy 1; whereas if the slice quota has reached 95%, apply policy 2; and if the slice quota has reached 99%, apply policy 3. Policy 1 may be to reject ‘bronze’ subscribers; policy 2 may be to reject ‘bronze’ and ‘silver’ subscribers, and policy 3 may be to reject all types of subscribers (e.g. including ‘gold’ subscribers)” (par. 110, lines 1-5)].
Consider claim 14; Velev discloses sending [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], to the one or more local NSACFs that are to be updated [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], an update request indicating the local quota is to be updated comprising an indication that the second number is to be decreased; and receiving [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)], from the one or more local NSACFs that are to be updated [“…the central status and quota of controlled slice attribute is managed centrally in the QMF, which allows the QMF to enforce policy (e.g., configure policy) I other for NFs to enforce a particular action (e.g., start/end rejecting new UEs or new PDU sessions).” (par. 76, lines 3-6) “The method for sending the notifications from the reporting NFs to the QMF is flexible and can be adapted depending on how close the current status is to the maximum number (or quota). For example, the QMF can configure the reporting NFs to report for each new UE or new PDU Session increase or decrease in the S-NSSAI-1.” (par. 117, lines 4-5)], an update response indicating the local quota is updated [“The central QMF is responsible to manage the local quotas in the distributed QMFs. The local quotas configured in the vQMFs can be either reporting quotas…” (par. 67, lines 9-11) “The parameter “AttributeID” may identify the controlled slice attribute which should be monitored, e.g., number of UE, number of PDU sessions…” (par. 88, lines 1-2) “…the vQMFs count/collect/monitor information about the status of a slice attribute. If the vQMFs determine that a configured reporting quota of the slice attribute is reached, the vQMF sends a notification to the QMF.” (par. 96, lines 1-3)].
Gupta is another reference that discloses the inventive concept.
Conclusion
Any response to this Office Action should be faxed to (571) 273-8300 or mailed to:
Commissioner for Patents
P.O. Box 1450
Alexandria, VA 22313-1450
Hand-delivered responses should be brought to
Customer Service Window
Randolph Building
401 Dulany Street
Alexandria, VA 22314
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Joel Ajayi whose telephone number is (571) 270-1091. The Examiner can normally be reached on Monday-Friday from 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Jeanette Parker can be reached on (571) 270-3647. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free) or 703-305-3028.
Any inquiry of a general nature or relating to the status of this application or proceeding should be directed to the receptionist/customer service whose telephone number is (571) 272-2600.
/JOEL AJAYI/
Primary Examiner, Art Unit 2646
