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 .
DETAILED ACTION
Claims 1-20 are pending in Instant Application.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of 63603837 filed 11/29/2023.
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-5, 7-13, 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jacob et al., “hereinafter Jacob” (U.S. Patent Application: 20160043968).
As per Claim 1, Jacob discloses a method comprising:
receiving, from a first customer of a cloud environment that is provided by a cloud services provider (CSP) (Jacob, Para.07, The resources may be provided for services requested by a user. Certain techniques are disclosed for managing and provisioning of computing resources based on user requests. Based on user requests, policies may be identified to determine provisioning and configuration of resources.), a request for a cluster placement group (CPG), the CPG identifying a first set of requested resources comprising a first type of resource and a second type of resource requested by the first customer (Jacob, Para.94, Placement characteristics may relate to placement of computing resources, such as a grouping of computing resources (e.g., one or more group definitions of a type of computing resources), one or more location characteristics (e.g., a geographic location), or one or more security characteristics (e.g., an isolated environment or an isolated computing resources)., wherein the first type of resource is different than the second type of resource (Jacob, Para.75, A resource definition may indicate one or more characteristics of computing resources. For example, a resource definition may indicate the types of resources and the amount of each type of resource to allocate. The types of resources may be indicated based on a service that is requested,);
identifying an availability domain in the cloud environment that includes a second set of available resources comprising all resources included in the first set of requested resources (Jacob, Para.69, One or more indices may be maintained for access to computing resources in resource pool 310. An index may indicate what resources are currently available at a particular data center and/or what resources can be provided by each data center. For example, data center index 314 may indicate how many hypervisors are available in each connected data center and whether those hypervisors can be shared and/or used for dedicated placement policies. Similarly, resource index 316 may indicate what pre-existing resources are available at any given data center, such as current available application servers, RAC nodes, storage nodes, etc.);
allocating, from the second set of available resources in the availability domain, a set of resources corresponding to the first set of requested resources to the first customer (Jacob, Para.79, Based on a policy definition chosen for a resource request, resource pool 310 may allocate one or more computing resources according to the policy definition. Resource allocation module 318 may allocate, using a placement policy and a resource definition of a policy definition, computing resources from resource pool 310. A resource definition may be used to determine computing resources to allocate in resource pool 310. A configuration of the computing resources may be determined based on the placement policy of a policy definition selected based on a resource request. Resource allocation module 318 may use data center index 314 and resource index 316 to identify computing resources for allocation according to the policy definition, Para.168, the placement configuration indicates a plurality of groups, wherein the placement configuration identifies a set of virtual machines allocated to a first group of the plurality of groups, and wherein a first computing resource of the plurality of computing resources is allocated to the first group based on the placement configuration. ); and
associating the set of resources allocated to the first customer with the CPG (Jacob, Para.114, a cloud environment may provide one or more services for placement policy-based resource allocation. …system environment 800 includes one or more client computing devices 804, 806, and 808 that may be used by users to interact with a cloud infrastructure system 802 that provides cloud services, including services for placement policy-based resource allocation.).
With respect to Claim 9 and Claim 17 are substantially similar to Claim 1 and are rejected in the same manner, the same art and reasoning applying.
As per Claim 2, Jacob discloses the method of claim 1, wherein the first type of resource corresponds to a compute instance (Jacob, Para.57, compute nodes, such as memory, number of CPUs, storage requirements, and other specifications as required by the user.), and the second type of resource corresponds to a block storage (Jacob, Para.67, one or more databases (e.g., a document database, a relational database, or other type of database), one or more file stores, one or more file systems, or combinations thereof.).
With respect to Claim 10 and Claim 18 are substantially similar to Claim 2 and are rejected in the same manner, the same art and reasoning applying.
As per Claim 3, Jacob discloses the method of claim 1, wherein the step of allocating further comprises: instantiating the set of resources in a compartment included in a first tenancy of the first customer in the cloud environment (Jacob, Para.44, A POD is a logical entity that can represent one of the following: a pre-provisioned anonymous single-tenant deployment (as is the case for the Java service); or a multi-tenant stack (physical or virtualized) that serves multiple tenants (as is the case for the database service)).
With respect to Claim 11 and Claim 19 are substantially similar to Claim 3 and are rejected in the same manner, the same art and reasoning applying.
As per Claim 4, Jacob discloses the method of claim 3, further comprising:
configuring, one or more access role policies for the CPG (Jacob, Para.09, Based on the information indicated by a request, the resource management system may determine a placement policy for allocation of computing resources indicated by the request. A placement policy may indicate a placement of one or more computing resources requested by a user. The placement policy may indicate where and how computing resources are to be placed once allocated.), wherein at least one access role policy grants a second customer associated with a second tenancy in the cloud environment, access to the set of resources instantiated in the compartment included in a first tenancy, wherein the second tenancy is different than the first tenancy (Jacob, Para.08, The policies may be chosen based on user preferences for requesting a service, which can include a request for specific computing resources. For example, the user can have the ability to specify a geographical location of where the resources are provisioned; if the service is a multi-tenant service (e.g., the same resource can be shared by two separate users), the user can have the ability to indicate that the user does not want to share the resource; if the service is a multi-tenant service, the user can have the ability to indicate an affinity towards a particular tenant (e.g., the user can have the ability to indicate that they want to share a resource with tenant X), or in contrast, the user can have the ability to indicate that they do not want to share with a particular tenant; the user can have the ability to control separate POD provisioning and service provisioning for services; etc.).
With respect to Claim 12 and Claim 20 are substantially similar to Claim 4 and are rejected in the same manner, the same art and reasoning applying.
As per Claim 5, Jacob discloses the method of claim 1, wherein identifying the availability domain in the cloud environment further comprises: determining one or more site groups associated with the availability domain (Jacob, Para.69, An index may indicate what resources are currently available at a particular data center and/or what resources can be provided by each data center. For example, data center index 314 may indicate how many hypervisors are available in each connected data center and whether those hypervisors can be shared and/or used for dedicated placement policies. Similarly, resource index 316 may indicate what pre-existing resources are available at any given data center, such as current available application servers, RAC nodes, storage nodes, etc.), wherein at least one site group of the one or more site groups corresponds to a label indicative of a physical placement location of a resource included in the set of resources (Jacob, Para.62, resource request 304 may include a placement configuration 334 that identifies information about placement (e.g., a physical location) for allocation of the computing resources indicated by the resource definition, Para.84, The number and/or types of fields can vary based on computing resources that are requested. The data shown with respect to a particular field may be stored in data record 400 or may indicate a memory location where the data is stored.).
With respect to Claim 13 is substantially similar to Claim 5 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 7, Jacob discloses the method of claim 5, further comprising:
processing, in a sequential manner, the one or more site groups associated with the availability domain to determine whether each of the one or more site groups can be used to provision the request (Jacob, Para.103, The individual steps illustrated in FIGS. 5 and 6 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular applications. While processing depicted in each of FIGS. 5 and 6 is with respect to placement policy-based resource allocation based on a request from a user, such processing may be performed for multiple resources requests indicating different types of characteristics for allocating computing resources, Para.69, One or more indices may be maintained for access to computing resources in resource pool 310. An index may indicate what resources are currently available at a particular data center and/or what resources can be provided by each data center. For example, data center index 314 may indicate how many hypervisors are available in each connected data center and whether those hypervisors can be shared and/or used for dedicated placement policies. Similarly, resource index 316 may indicate what pre-existing resources are available at any given data center, such as current available application servers, RAC nodes, storage nodes, etc.); and
filtering, restricted site groups from the one or more site groups, wherein a restricted site group cannot be used to provision the request (Jacob, Para.50, placement policy-based resource allocation and management according to an embodiment of the present invention. As described above, typical PaaS, SaaS, and IaaS providers may not enable users to define what, how, and where their requested computing resources are provisioned, Para.138, Order provisioning module 824 provides a level of abstraction between the cloud services provided by cloud infrastructure system 800 and the physical implementation layer that is used to provision the resources for providing the requested services. This enables order orchestration module 822 to be isolated from implementation details, such as whether or not services and resources are actually provisioned on the fly or pre-provisioned and only allocated/assigned upon request.).
With respect to Claim 15 is substantially similar to Claim 7 and is rejected in the same manner, the same art and reasoning applying.
As per Claim 8, Jacob discloses the method of claim 1, wherein the availability domain includes a plurality of data centers (Jacob, Para.13, the plurality of computing resources in a resource infrastructure system. A resource infrastructure system may include one or more data centers.), each data center in the plurality of data centers comprising one or more buildings, and wherein the first type of resource corresponds to a compute fabric including a plurality of compute instances and/or a GPU fabric including a plurality of GPUs hosted in one of the one or more buildings (Jacob, Para.64, the software may be stored in a memory (e.g., a non-transitory computer-readable medium), on a memory device, or some other physical memory and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more GPUs,).
With respect to Claim 16 is substantially similar to Claim 8 and is rejected in the same manner, the same art and reasoning applying.
Claims 6, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Jacob et al., “hereinafter Jacob” (U.S. Patent Application: 20160043968) in view of Brar et al. “hereinafter Brar” (U.S. Patent Application: 20240152409).
As per Claim 6, Jacob discloses the method of claim 5,
wherein the one or more site groups are arranged in a hierarchical manner including a first hierarchical level corresponding to a first site group associated with the availability domain (Jacob, Para.59, Resource pool 208 may include or may be implemented using one or more data centers. In some embodiments, resource pool 208 may be a hypervisor pool managed by a service provider (e.g., an IaaS provider), Fig.7),
a second hierarchical level corresponding to a building within a data center in the availability domain (Jacob, Para.69, resource index 316 may indicate what pre-existing resources are available at any given data center, such as current available application servers, RAC nodes, storage nodes, etc.), and
a third hierarchical level corresponding to a network resource that is located in the building within the data center (Jacob, Para.104, distributed system 700 includes one or more client computing devices 702, 704, 706, and 708, which are configured to execute and operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like over one or more network(s) 710. Server 712 may be communicatively coupled with remote client computing devices 702, 704, 706, and 708 via network 710.).
However Jacob did not disclose hierarchical manner including hierarchical levels.
Brar discloses hierarchical manner including hierarchical levels (Brar, Para.189, plurality of network devices (e.g., switches) arranged in a hierarchical manner is provided in a network fabric, Para.194, the subset of network devices that implement the GPU based policy routing mechanism correspond to switches included in the Tier-1 and Tier-2 levels of the hierarchical levels of switches.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Jacob with the teachings as in Brar. The motivation for doing so would have been for relates to cloud architectures, and more particularly to a supercluster architecture of graphical processing units (GPUs). More specifically, the present disclosure is related to a network architecture that provides for hybrid clusters of GPUs (e.g., different generations of GPUs, or GPUs operating at different speeds, etc.) to coexist in a same network fabric. (Brar, Para.11).
With respect to Claim 14 is substantially similar to Claim 6 and is rejected in the same manner, the same art and reasoning applying.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 pm.
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, Vivek Srivastava can be reached at 5712727304. 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.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449
Prosecution Insights