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 .
This communication is in response to Remarks and Amendments filed on 30 March, 2026.
Claims 1-4, 7-21 and 23 are currently pending.
Claims 1, 7, 21 and 23 are currently amended.
Claims 5 and 6 have been canceled.
Response to Arguments
Regarding amended claim 1, Applicant states that “The applicant has amended claim 1 to insert therein the matter of former claims 5 and 6”. The amended scope of claim 1 has necessitated a new ground of rejection, presented herewith.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7-21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over ETSI REL (18)000104 R2, dated 2018, hereinafter, NPL, in view of Pai et al (US 10,021,008 B1).
Regarding claim 1, NPL teaches a method for workload management, executed by a service provider (SP) Network Function Virtualization Management and Orchestration (NFV-MANO) functional entity (FE) (SP FE), comprising:
- receiving a request for an NFV-MANO service from an NFV-MANO service user (SU) (NPL RE5.4-9 provides for request handing during overload);
- upon detecting that a threshold indicative of a state of a workload of the SP FE is crossed, determining a priority of the request for the NFV-MANO service and determining, based on the priority and the workload of the SP FE, whether to accept or reject the request (NPL RE 5.4-9 provides for priority-based request handing during overload); and
- sending a response to the SU indicative of whether the request is accepted or rejected (NPL RE 5.4-9 provides for priority-based request handing during overload and informing other network elements of its overload condition).
NPL teaches the above including detecting that a threshold indicative of a state of a workload of the SP FE is crossed (NPL RE 5.4-9 provides for priority-based request handing during overload), but NPL does not explicitly teach that the threshold is a threshold, of a plurality of scale out thresholds associated with different scaling levels used for determining a warranted scale out level. However, in a similar field of endeavor, Pai teaches a threshold, of a plurality of scale out thresholds associated with different scaling levels used for determining a warranted scale out level (Pai col.2 line 60-col.3 line 35 provides “The one or more alarm triggers may be part of one or more configured magnitude scaling policies in at least some embodiments. A magnitude scaling policy may specify one or more target levels or values for a resource utilization metric (e.g., 50% CPU utilization if the metric is CPU utilization, a range of 45%-55% CPU utilization, etc.), as well as have multiple defined thresholds relative to the target level that each has an associated proposed change to the group of computing resource. The magnitude scaling policy may be configured by the client for a specific group of computing resources that is or will be provided for use by the client, for any and all groups of computing resources that are or will be provided for use by the client, etc. In addition, the configured scaling policies for a client may be of multiple types in some embodiments. For example, a client may specify one or more magnitude scaling policies that are each associated with a single resource utilization metric (e.g., one policy to scale up, and one policy to scale down), and specify how to manage scaling the group of computing resources based at least in part on values or other measurements of the metric having magnitudes that reach or exceed (“breach”) one or more of the defined thresholds. For example, a magnitude scaling policy may provide scaling the number of computing resources based on the magnitude of the breach, such that, for instance, if the breach is 20% above a threshold level (or baseline level), then the number of computing resources is scaled by 20% (or some amount based on that 20% magnitude breach). In addition, a client may specify one or more prioritization policies that are each associated with two or more magnitude scaling policies based on two or more resource utilization metrics, such as to specify how to manage multiple alarms that are received for those two or more resource utilization metrics by providing prioritization information related to the two or more scaling policies and their metrics. For example, if there is one magnitude scaling policy associated with CPU utilization and another magnitude scaling policy associated with memory utilization, each of those magnitude scaling policies may scale a different amount of computing resources based on the breach. If both magnitude scaling policies receive a breach at or near the same time, prioritization information can be used to determine which magnitude scaling policy to select and implement”).
It would have been obvious to one of ordinary skill in the art at the time of filing to have scale out levels/magnitude scaling policy corresponding to different thresholds as taught by Pai to allow user defined thresholds for clients of remote computing services so that they may manage the resources to reflect corresponding demand (e.g., from internal users of the organizations and/or external users that are using services or functionality provided by the organizations) (Pai col.1 lines 19-22; col.2 lines 26-28).
Regarding claim 2, the method of claim 1, wherein the threshold is set in advance (NPL 5.5 provides for enforcing upper capacity limitations).
Regarding claim 3, the method of claim 1, wherein the threshold is used for determining if the SP FE is in a state of overload (NPL 5.5 provides for enforcing upper capacity limitations).
Regarding claim 4, the method of claim 1, wherein the threshold is used for determining if a scale out is warranted (NPL 5.5 provides for elastic resource management and capacity scaling for overload management).
Regarding claim 7, the method of claim 1, wherein the set of thresholds comprises the threshold used for determining if the SP FE is in a state of overload (Pai col.2 line 60-col.3 line 35). Motivation provided with reference to claim 1.
Regarding claim 8, the method of claim 1, wherein a logic is used to determine whether to accept or reject the request (NPL 5.4-8 to 5.4-9 provides for management functions under overload).
Regarding claim 9, the method of claim 1, wherein determining the priority of the request comprises determining that the request has a high priority or a low priority (NPL 5.4-9 provides for determining priority).
Regarding claim 10, the method of claim 9, wherein determining that the request has a high priority or a low priority is done using a priority scale (NPL 5.4-9 provides for determining priority based on a scale predicated on type of work).
Regarding claim 11, the method of claim 1, wherein determining the priority of the request and determining whether to accept or reject the request depends on a priority of the SU, a type of the requested service or operation, or a combination thereof (NPL 5.4-9 provides for determining priority based on type of work).
Regarding claim 12, the method of claim 1, wherein determining whether to accept or reject the request depends on an escalation mechanism evaluating how close the workload is to a maximum load and having increasingly higher priority cut off values for increasingly higher workloads (NPL 5.4-8 for a gradual overload control scheme).
Regarding claim 13, the method of claim 12, wherein the escalation mechanism increases a number of rejected requests with increasing workload (NPL 5.4-8 for a gradual overload control scheme)”.
Regarding claim 14, the method of claim 12, wherein the escalation mechanism increasingly rejects requests needing a high capacity with increasing workload (NPL 5.4-8 for a gradual overload control scheme).
Regarding claim 15, the method of claim 1, wherein an output of determining the priority and determining whether to accept or reject the request takes the form of: a single binary or non- binary value, a vector of values, or a data structure (NPL 5.4-9 provides for admitting or rejecting requests).
Regarding claim 16, the method of claim 1, wherein determining whether to accept or reject the request comprises producing a predicted time to run for the service request and a predicted capacity that needs to be protected, to be used for determining whether to accept or reject the request (NPL 5.4-8 provides for a cap on processing delay indicating that capacity is monitored)
Regarding claim 17, the method of claim 1, wherein the priority is determined using a logic (NPL 5.4-8 to 5.4-9 provides for prioritizing under overload).
Regarding claim 18, the method of claim 17, wherein the logic takes the form of a policy, a script, a decision tree, or a machine learning algorithm (NPL 5.4-8 to 5.4-9 provides for prioritizing under overload).
Regarding claim 19, the method of claim 17, wherein logic for determining the priority of the request produces a value for a timer, that is sent to the SU along with a response indicative that the request is rejected (NPL 5.4-8 to 5.4-9 provides for admitting and queuing only as many requests as it can process within the requestor timeout interval and rejecting additional requests).
Regarding claim 20, the method of claim 19, wherein the SP FE receives the request for the NFV- MANO service from the SU again, after a delay of at least the timer (NPL 5.4-8 to 5.4-9 provides for a requestor timeout interval).
Regarding claim 21, this claim contains limitations found within those of claim 1, and the same rationale of rejection applies, where applicable.
Regarding claim 23, this claim contains limitations found within those of claim 1, and the same rationale of rejection applies, where applicable.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Marr et al US 2014/0058871.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ISHRAT RASHID whose telephone number is (571)272-5372. The examiner can normally be reached 10AM-6PM EST M-F.
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, Tonia L Dollinger can be reached at 571-272-4170. 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.
/I.R/ Examiner, Art Unit 2459
/TONIA L DOLLINGER/ Supervisory Patent Examiner, Art Unit 2459
Prosecution Insights