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 .
Claims 1-20 are pending.
Response to Arguments
Regarding 35 U.S.C. 112:
Applicant’s amendments and arguments regarding the rejection of claims 1-20 under 35 U.S.C. 112(b) have been fully considered and are found to be persuasive. The rejections of claims 1-20 under 35 U.S.C. 112(b) are withdrawn.
Regarding 35 U.S.C. 101:
Applicant’s amendments and arguments regarding the rejection of claims 1-20 under 35 U.S.C. 101 have been fully considered and are found to be persuasive. The rejections of claims 1-20 under 35 U.S.C. 101 are withdrawn.
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-6 under 35 U.S.C. 103 have been fully considered and are moot due to new grounds of rejection necessitated by amendment.
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 1-3, 5, 22, 24 are rejected under 35 U.S.C. 103 as being unpatentable over Pan et al. US 20210019160 A1 in view of Snyder et al. US 20160139950 A1.
Regarding claim 1, Pan teaches the invention substantially as claimed including:
A method for provisioning at least one hosted compute resource (HCR); the method comprising:
configuring a plurality of pre-configured compute resource modules for a first workload ([0001] A workload, such as a virtual machine (“VM”), can require certain resources at a host, which the DRS can reserve through reservation, limit, and share settings); and
selectively assigning a job requesting the first workload to at least one available compute resource module of the plurality of pre-configured compute resource modules based on a provisioning algorithm configured to receive as input a hash of a data structure ([0006] A tag identifying the profile can be attached to the workload. The profile can include scheduling primitives that are used by a DRS (dynamic resource scheduler) for managing the workload. The DRS can make various decisions regarding placing and moving workloads, including reserving resources for the workloads. These decisions now can enforce QoS based on considering the scheduling primitives of the profiles. For example, the DRS can read the tag of a workload and retrieve scheduling primitives relevant to specific workflows of the DRS, such as initial workload placement, load balancing, and host maintenance mode; [0063] the DRS 112 can place multiple workloads at a first host. To do so, the DRS 112 can retrieve profiles for the VMs to determine placement priority. In one example, each VM includes a tag that the DRS can use to retrieve the corresponding profile. The tag can be part of metadata or configuration information for the VM), the data structure comprising a first data element indicative of the first workload requested by the job and a second data element specifying performance requirements of the job ([0026] The profiles 125 can represent QoS categories and define how the DRS 112 will treat the workloads during placement, load balancing, host maintenance, and other scenarios. The profiles 125 can also be used with EDRS and DPM in determining how to scale a cluster);
wherein the at least one available compute resource module is configured to process instructions to perform the job ([0023] The workloads can perform various tasks in the network. For example, workloads can handle VoIP calls, perform virtualized routing, and interact with internet-of-things (“IoT”) devices and their respective backend systems, among other things. End users 160 can connect to the network and to the various VMs 142, 144, 146, depending on which VMs 142, 144, 146 correspond to particular end user applications. For example, a first VM 142 could be for streaming video whereas a second VM 144 could be for VoIP calls).
While Pan discloses the profiles representing quality of service requirements are linked to workloads (i.e., virtual machines), it does not explicitly teach the data structure comprising a first data element indicative of the first workload requested by the job.
However, Snyder teaches the data structure comprising a first data element indicative of the first workload requested by the job ([0012] a context including at least one quality of service parameter and allocating access to the at least one resource of the hardware processor based on the quality of service parameter of the context, a device identifier, a virtual machine identifier, and the context; [0051] A context stores information specific to a particular process or a device/process combination. Examples of information stored in a context can be a virtual machine ID and process ID).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Snyder’s quality of service context with the existing system of Pan. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of associating a desired quality of service parameter to a specific virtual machine (see Snyder [0018] providing quality of service to at least one resource of a hardware processor includes a memory of the hardware processor providing a context including at least one quality of service parameter and a quality of service module configured to partition access to the at least one resource of the hardware processor based on the quality of service parameter of the context, a device identifier, a virtual machine identifier, and the context; [0050] Prioritizing or partitioning shared resources (e.g., busses, cache memories, interfaces, etc.) within the SMMU 202 to handle the requests from the devices 204a-n can improve Quality of Service (QoS). Prioritization can be based on the combination of devices/cores and users/processes).
Regarding claim 2, Pan and Snyder teach the method of claim 1.
Pan further teaches wherein the at least one HCR provides the plurality of pre-configured compute resource modules based on real-time demand for the plurality of pre-configured compute resource modules ([0010] The DRS can also use the profiles in determining when to scale-out or scale-in a cluster, such as part of elastic dynamic resource allocation. To do this, the DRS can calculate a total demand based on the individual demands of multiple workloads in a cluster).
Regarding claim 3, Pan and Snyder teach the method of claim 1.
Pan further teaches wherein the at least one HCR comprises a plurality of racks respectively configured to execute one or more workload requests ([0023] workloads can handle VoIP calls, perform virtualized routing, and interact with internet-of-things (“IoT”) devices and their respective backend systems, among other things; [0024] Hosts 140, 150 can be physical or virtual and act as servers upon which workloads execute), the one or more workload requests respectively requesting a workload of a plurality of workloads, the plurality of workloads comprising the first workload (Fig 1 App Owners; [0023] End users 160 can connect to the network and to the various VMs 142, 144, 146, depending on which VMs 142, 144, 146 correspond to particular end user applications. For example, a first VM 142 could be for streaming video whereas a second VM 144 could be for VoIP calls).
Regarding claim 5, Pan and Snyder teach the method of claim 3.
Pan further teaches increasing a number of pre-configured compute resource modules as a number of the one or more workload requests requesting the first workload increases ([0011] the DRS can determine whether to scale the cluster based on the total demand and cluster capacity. This can include creating a ratio based on the total demand versus cluster capacity and comparing that ratio to one or more thresholds that indicate a need to scale the cluster one way or the other. Then, the DRS can recommend scaling when the thresholds are exceeded. An orchestrator process or other management process in the SDDC can receive the recommendation and scale the cluster).
Regarding claim 22, Pan and Snyder teach the method of claim 1.
Pan further teaches wherein the plurality of pre-configured compute resource modules comprises at least one of a computer processor system ([0008] A first resource reservation primitive can specify a relative amount of computer processing unit (“CPU”) resources to reserve); an accelerator processor; or a programmable circuit ([0035] The hardware portion of a host 140, 150 can include a processor and a memory. The memory can be implemented in various ways, such as in the form of one or more memory devices mounted upon a printed circuit board located in the host 140, 150).
Regarding claim 24, Pan and Snyder teach the method of claim 1.
Pan teaches wherein the performance requirements of the job comprise at least one of service level agreement (SLA) requirements, queries per second (QPS) requirements, instructions per second (IPS) requirements, qualitative operational requirements (QOR), or quality of service (QoS) requirements ([0006]Examples described herein include systems and methods for enforcing QoS scheduling on workloads by using profiles. The method can include assigning different profiles to different workloads, with the profiles defining different QoS categories and having different scheduling primitives. A primitive can be an attribute or variable used in a DRS workflow to decide how to act with respect to a workload).
Regarding claim 25, it is the computing system of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Pan et al. US 20210019160 A1 in view of Snyder et al. US 20160139950 A1 in view of Li et al. DyCuckoo: Dynamic Hash Tables on GPUs.
Regarding claim 23, Pan and Snyder teach the method of claim 1.
Pan and Snyder do not explicitly teach wherein the provisioning algorithm comprises a friendly cuckoo algorithm.
However, Li teaches wherein the provisioning algorithm comprises a friendly cuckoo algorithm ([Abstract] we propose a novel dynamic cuckoo hash table technique on GPUs, known as DyCuckoo. We devise a resizing strategy for dynamic scenarios without rehashing the entire table that ensures a guaranteed filled factor. The strategy trades search performance with resizing efficiency, and this tradeoff can be configured by users. To further improve efficiency, we propose a 2-in-d cuckoo hashing scheme that ensures a maximum of two lookups for find and delete operations, while retaining similar performance for insertions as a general cuckoo hash).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Li’s cuckoo hashing with the system of Pan and Snyder. A person of ordinary skill in the art would have been motivated to make this combination to provide the system with the advantage of improved memory efficiency and reduced lookup time in task execution (see Li We propose an efficient strategy for resizing hash tables and demonstrate the near-optimality of the resizing strategy through theoretical analysis. We devise a 2-in-d cuckoo hash scheme that ensures a maximum of two lookups for find and deletion operations, while still retaining similar performance for insertions as general cuckoo hash tables. We conduct extensive experiments on both synthetic and real datasets and compare the proposed approach against several state-of-the-art GPU hash table baselines. For dynamic workloads, the proposed approach demonstrates superior performance and enables fine-grained memory control, which is not available in existing approaches).
Allowable Subject Matter
Claims 7-8, 10-17, and 20-21 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm ET.
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, Aimee Li can be reached on (571) 272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights