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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 5/7/2026 has been entered.
Claims 1-20 are presented for examination. Claims 1, 3-7, 10-12 and 14 have been amended.
Applicant’s amendments to the claims have overcome claim objection previously set forth in the Final Office Action mailed 2/12/2026.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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 of this title, 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, 7 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang).
Regarding to claim 1, Butler discloses: A method comprising:
receiving, by one or more processors, supply signaling and demand signaling, each of the supplying signaling and the demand signaling indicating one or more changes in available hardware computing resource inventory in a cloud computing environment including multiple virtual machines (VMs) of different VM types, wherein each VM type is associated with a different set of computing hardware resources; updating, by the one or more processors, a centralized record of available computing hardware resource inventory in response to the supply signaling and the demand signaling (see [0164]-[0165], [0168], [0174]; “an inventory catalog subsystem 740 persists a catalog of available resources and configurations that can be added to the existing computing infrastructure, along with the times at which any of those resources are requested to be deployed/placed in the infrastructure”, “Collating inputs from the resource modeler and the inventory catalog to continuously provide an updated capacity assessment for all infrastructural resources”, “Estimating business/purchasing decisions by conducting ‘what-if’ scenarios based available inventory configurations and resource configuration updates that can inform an update to the future inventory”. A centralized record/catalog is continuously updated based on available resources. For claimed supply signaling and demand signaling, see [0139], [0177], [0194], [0404], [0497]; “allowing for customers and service providers to automatically plan for optimal capacity”, “long-term purchases of new computing hardware to bring additional capacities into the system, or short-term purchases such as renting capacities from cloud providers”, “a first portion of the requisite resource capacities should be allocated in certain resources that are already deployed in the computing infrastructure, while a second portion of the requisite resource capacities should be allocated in new resources that can be added to the computing infrastructure from the resource inventory catalog (e.g., physical resources available for purchase or logical resources available to rent)”, “ A service provider (e.g., an owner/operator of server 3050, CN 3042, and/or cloud 3044) may deploy the IoT devices in the IoT group to a particular area (e.g., a geolocation, building, etc.) in order to provide the one or more services”. The information related to new computing hardware resources added or offered by the resource/service/cloud providers can be considered as claimed supply signaling, the information related to requesting or using already deployed resources from the users/customers/tenants can be considered as claimed demand signaling. Also see [0242]-[0247] for claimed cloud computing environment; “This solution proposes a novel methodology and algorithm to solve the technical problem … incrementing the flexibility of cloud orchestrators to choose the right placement option … place workloads distributed over edge, core network, and cloud resources”. For claimed “wherein each VM type is associated with a different set of computing hardware resources”, see [0148]; “details on how a set of virtual machines (VMs) are being deployed on a physical server (e.g., VM sizes/configurations pinned to particular physical cores)”, i.e., at least different VM sizes having different set of hardware resources are considered as different VM types);
receiving, by the one or more processors, a first capacity planning signal from a first capacity management subsystem, and a second capacity planning signal from a second capacity management subsystem, the first capacity management subsystem configured to receive a first signaling subset of the supply signaling and the demand signaling and perform a first capacity management action type for managing the computing hardware resource inventory across the computing environment according to the first signaling subset, and the second capacity management subsystem assigned to receive a second signaling subset of the supply signaling and the demand signaling and perform a second capacity management action type for managing the computing hardware resource inventory across the cloud computing environment according to the second signaling subset, wherein the second signaling subset is different from the first signal subset, and wherein the second capacity management action type is different from the first capacity management action type (see [0091], [0343]-[0346], “all edge compute nodes involved in this collaborative video analytics pipeline must share their system load status to allow overloaded edge nodes to choose optimal peer edge nodes for offloading compute tasks and rebalancing the overall load”, “a set of actions, which are then issued to the controller. These actions can include: … inserting advanced reservations to keep enough headroom for future function invocations … the deployment option can change from a cold to warm to hot container”. The resources from Butler include cloud hardware resources, and thus the feature of “inserting advanced reservations to keep enough headroom for future function invocations” from [0344] would require managing/reserving the computing hardware resource inventory (note: even if it is about certain virtual machine/function invocation, such virtual machine/function invocation still requires managing/reserving hardware resource inventory) according to the future function invocations, i.e., claimed first signaling subset of the supply signaling and demand signaling (to be more specific, a received demand signaling for future function invocations, see “incoming service requests for new services” from [0187]). The feature of offloading tasks to other edge nodes discussed at [0091] can be considered as the claimed second capacity management subsystem performs second capacity management action type according to the available edge nodes, i.e., claimed second signal subset of the supply signaling and demanding signaling (to be more specific, a received supplying signaling indicates available edge nodes type of resources). Also see Fig. 7, [0166], [0187], “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning”, “The infrastructure capacity model may be generated based on the current capacity and telemetry data for the resources in the computing infrastructure”. The current capacity and telemetry data from each of subsystem described by [0091] and [0344] to form current infrastructure capacity 725 can be considered claimed corresponding second and first capacity planning signals. Note: system or subsystem is a broad term that any combination of objects/components performs corresponding function(s) can be considered as corresponding system or subsystem, and thus the combination of objects/components performing feature “inserting advanced reservations to keep enough headroom for future function invocations” from [0344] and objects/components receiving “incoming service requests for new services” from [0187] can be considered as claimed first capacity management subsystem; the combination of objects/components performing feature of offloading tasks from overloaded edge nodes to other edge nodes from [0091] and the objects/components receiving edge nodes provided by services provider can be considered as claimed second capacity management subsystem);
evaluating, by the one or more processors, the first capacity planning signal against the centralized record according to one or more rules included in a common supply-demand matching (SDM) logic, evaluating, by the one or more processors, the second capacity planning signal against the centralized record according to the one or more rules included in the SDM logic (see [0133]-[0136]; “a solution that provides automated capacity planning for dynamic environments”, “a ‘resource reasoning and planning module’ (RRPM) that complements existing resource managers/orchestrators by enabling continuous capacity planning, near-term scheduling decisions”, “a model-based mechanism/subsystem for expression and reasoning between different stakeholders (in space and time) based on different objectives capturing used and available capacity, dynamicity of the system, dynamicity of the workload, and dependability of a distributed edge platform” and “a method/subsystem that allows for ‘what-if’ and forward-looking planning capabilities while comprehending future and dynamic changes in resources availability and resource requirements”. Also see [0141]; “Such automated planning involves balancing multiple objectives (e.g., focusing on maximizing total cost of ownership (TCO) and quality of service (QoS)) across multiple stakeholders (e.g., infrastructure provider, service provider, end-user)”. In addition, see [0164] and [0166] for centralized record to be used during resource management performed by RRPM discussed at [0134]; “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning”);
transmitting, by the one or more processors, a first capacity management signal to the first capacity management subsystem, the first capacity management signal indicating for the first capacity management subsystem to perform a first action of the first capacity management action type based on the evaluation of the first capacity planning signal (see [0142] for applying common SDM logic to generation capability management signal in generality; “using a resource reasoning and planning module (RRPM) 604. This architectural diagram outlines the interaction of RRPM 604 with the other components available for managing compute platforms. For example, based on various insights 602 associated with the infrastructure and workloads, the RRPM 604 outputs a capacity plan 605. The capacity plan 605 can help inform a scheduling component of an orchestrator/resource manager 606 to make spatial and temporal workload placement decisions (in the near and longer term), as well as inform business decisions (e.g., via business intelligence dashboard 608) on adding additional capacity to the infrastructure 610 to maintain an overall optimal infrastructure capacity”. Also see [0238]-[0241] for a specific example of applying common SDM logic to balance multiple objectives to generate a corresponding action to be performed, i.e. claimed first capacity management signal indicating to perform an action of the first capacity management action type, like “inserting advanced reservations to keep enough headroom for future function invocations” discussed at [0344]); and
transmitting, by the one or more processors, a second capacity management signal to the second capacity management subsystem, the second capacity management signal indicating to perform a second action of the second capacity management action type based on the common SDM logic (see [0142] for applying common SDM logic to generation capability management signal in generality; “using a resource reasoning and planning module (RRPM) 604. This architectural diagram outlines the interaction of RRPM 604 with the other components available for managing compute platforms. For example, based on various insights 602 associated with the infrastructure and workloads, the RRPM 604 outputs a capacity plan 605. The capacity plan 605 can help inform a scheduling component of an orchestrator/resource manager 606 to make spatial and temporal workload placement decisions (in the near and longer term), as well as inform business decisions (e.g., via business intelligence dashboard 608) on adding additional capacity to the infrastructure 610 to maintain an overall optimal infrastructure capacity”. Also see [0093]-[0101] for a specific example of applying common SDM logic to balance multiple objectives to generate a corresponding action to be performed, i.e. claimed second capacity management signal indicating to perform an action of the second capacity management action type, like “allow overloaded edge nodes to choose optimal peer edge nodes for offloading compute tasks and rebalancing the overall load” discussed at [0091]).
Butler does not disclose:
wherein the one or more rules are configured to direct matching of supplying to demand based at least in part on the different VM types and the associated computing hardware resources
However, Huang discloses: A method comprising:
receiving, by one or more processor, supply signaling and demand signaling, each of the supply signaling and the demand signaling indicating one or more changes in available computing hardware resource inventory in a cloud computing environment including multiple virtual machines (VMs) of different VM types, wherein each VM type is associated with a different set of computing hardware resources (see [0002]; “In cloud computing IaaS mode, cloud computing service provider is with virtual machine (Virtual machine, VM) as clothes Business provides unit, provides a user the infrastructure resources such as calculating, network, storage.Specifically, cloud computing service provider mentions For various type of virtual machine so that user carries out unrestricted choice, type of virtual machine contains the money such as different calculating, network, storage The matched combined in source；The type of virtual machine that cloud computing platform is selected according to user creates on the physical host of its data center Meet the virtual machine of user resources demand”. The cloud computing service provider is required to provide certain information or signal to indicate what kind of hardware resources that the provider can offer/added and the user is required to provide certain information or signal to indicate what kind of hardware resources that the user requires/needed. Also see claim 1 for similar description, “Obtain the available resource information of host group, wherein the available resource information of the host group includes number of host and each The available resources size of the host” and “Obtain the priority of user and the host resource size of request”),
one or more rules included in a common supply-demand matching (SDM) logic, wherein the one or more rules are configured to direct matching of supply to demand based at least in part on different VM types and the associated computing hardware resources (see [0002]; “The matched combined in source；The type of virtual machine that cloud computing platform is selected according to user creates on the physical host of its data center Meet the virtual machine of user resources demand, and provides it to user's use”. Also see claim 2; “The remaining available resource size for traversing each host in the host group, when i-th host in the host group It is tired according to first priority when remaining available resource size is greater than or equal to the resource size of j-th of user request”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the usage of common supply-demand logic from Butler by including matching cloud service provider’s resource with user’s requirements to create virtual machine for user from Huang, and thus the combination of Butler and Huang would disclose the missing limitations from Butler, since it is well-known and understood to provide sufficient resource sizes based on user’s requirements (see [0002] from Huang).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further the combination of Butler and Huang discloses: wherein each of the first capacity management action type and the second capacity management action type is selected from the group consisting of: reserving hardware computing resource inventory for a forecasted demand; determining pool sizes for domains of the cloud computing environment; moving computing hardware resource inventory between domains of the cloud computing environment; moving projects between domains of the cloud computing environment; and moving demand for computing hardware resource inventory between domains of the cloud computing environment (see “inserting advanced reservations to keep enough headroom for future function invocations” from [0344] of Butler as claimed limitation of “reserving hardware computing resource inventory for a forecasted demand”. See “the deployment option can change from a cold to warm to hot container” from [0345] of Butler as claimed limitation of “moving projects between domains of the cloud computing environment”. See “If one of the edge nodes 210 a-c becomes overloaded, however, a portion of its video processing workload can be dynamically offloaded to other edge nodes 210 a-c to prevent video frames from being dropped” from [0053] of Butler as claimed limitation of “moving demand for computing hardware resource inventory between domains of the cloud computing environment”).
Regarding to Claim 3, the rejection of Claim 1 is incorporated and further the combination of Butler and Huang discloses: wherein one or more changes in available computing hardware resource inventory indicated by the supply signaling and the demand signaling includes at least one of central processing unit (CPU) capacity, random access memory (RAM) size, or solid state drive (SSD) size (see [0217] and [0260] from Butler; “tasks and services requests need to express their requirements and operations margins (e.g., latency boundaries in which it can operate and hence defining where it can be placed at the edge)”, “the workload model for the experimental setup is a compute-intensive OpenFoam computational fluid dynamics (CFD) simulation workload, requesting for 24 cores”. Also see [0433] from Butler; “in response to a request by a user … fulfils the requirements of the application 3105 … Requirements of the application can include latency, location, compute resources, storage resources, network capability, security conditions, and the like”. Also see [0002] from Huang), and wherein the common SDM logic directs matching of demand to supply based at least in part on the one or more changes in available computing hardware resource inventory indicated by the supply signaling and the demand signaling (see [0217]-[0222] from Butler; “matching task(s) and/or sub-task(s) to resources based on various properties. In particular, the illustrated process flow shows how a system can, given a service request, decompose it into a set of task(s) and/or sub-task(s) and match those to resources capabilities known to it”. Also see [0433] from Butler; “an instance of a specific MEC App 3136 fulfilling the requirements of the MEC App 3136 regarding the UE 3120. If no instance of the MEC App 3136 fulfilling these requirements is currently running, the multi-access edge system management may create a new instance of the application 3105 on a MEC host 3036 that fulfils the requirements of the application 3105”).
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further the combination of Butler and Huang discloses:
wherein the one or more rules of the common SDM logic is configured to direct matching imminent demand with currently available computing hardware resources, and to direct matching forecasted demand with future available computing hardware resources (see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”).
Regarding to Claim 10, the rejection of Claim 1 is incorporated and further the combination of Butler and Huang discloses: wherein the supply signaling indicates the VM type (see [0148] from Butler and [0002] from Huang; “hold details on how a set of virtual machines (VMs) are being deployed on a physical server (e.g., VM sizes/configurations pinned to particular physical cores)” and “cloud computing service provider is with virtual machine (Virtual machine, VM) as clothes Business provides unit, provides a user the infrastructure resources such as calculating, network, storage.Specifically, cloud computing service provider mentions For various type of virtual machine so that user carries out unrestricted choice, type of virtual machine contains the money such as different calculating, network, storage”) and wherein the one or more rules of the common SDM logic is configured to direct matching supply signaling to demand signaling based at least in part on mappings between VM types and compatible machine types (see [0002] and claim 2 from Huang; “The matched combined in source；The type of virtual machine that cloud computing platform is selected according to user creates on the physical host of its data center Meet the virtual machine of user resources demand, and provides it to user's use” and “The remaining available resource size for traversing each host in the host group, when i-th host in the host group It is tired according to first priority when remaining available resource size is greater than or equal to the resource size of j-th of user request”. The match of the resource requirements of jth user requests with ith host is based on the remaining available resource size of the ith host, the remaining available resources size of the ith host is generated or resulted from mapping or matching of the resource requirement of the previous user requests, i.e. other VM types, and resource availability of all hosts, i.e., machine types).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang) and further in view of Kasiolas et al. (US 20070088703 A1, hereafter Kasiolas).
Regarding to Claim 4, the rejection of Claim 1 is incorporated and further the combination of Butler and Huang discloses: wherein the one or more rules included in the common SDM logic include at least one of: packing a location to reduce fragmentation of stored data; requiring supply signaling to be matched with demand [on a first-come-first-served basis]; avoiding inventory that is held back from being counted towards currently available capacity; applying a multiplier to a location in which available resources are overcommitted to reduce a likelihood of further resources being committed; applying a cost efficiency weighting to available capacity based on machine type; or avoiding a single virtual machine (VM) from being split across multiple machines (see [0217]-[0222] from Bulter; “matching task(s) and/or sub-task(s) to resources based on various properties. In particular, the illustrated process flow shows how a system can, given a service request, decompose it into a set of task(s) and/or sub-task(s) and match those to resources capabilities known to it”).
The combination of Butler and Huang does not disclose: wherein the one or more rules in the common SDM logic include at least: requiring supply signaling to be matched with demand on a first-come-first-served basis.
However, Kasiolas discloses: wherein the common SDM rules include: requiring supply signaling to be matched with demand on a first-come-first-served basis (see [0061]; “One or more bids are received from participating cluster managers at step 915. The bids may identify one or more destination nodes which can receive data. One or more of the bids are selected at step 920. Bids can be accepted based on ranking, on a first-come, first served basis”. Also see [0045]; “perhaps one or more bids are received but the bids are deemed to be unsatisfactory, the auctioning node can notify the cluster manager”, i.e., requiring matching of resource node with demand of the bid).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the specific rules or policies for handling resource requests from the combination of Butler and Huang by including a policy of handing requests on a manner of first come first server from Kasiolas, and thus the combination of Butler, Huang and Kasiolas would disclose the missing limitations from the combination of Butler and Huang, since first-come first server is a well-known and understood scheduling mechanism to provide certain level of fairness to the jobs or tasks received earlier.
Claims 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang) and Kasiolas et al. (US 20070088703 A1, hereafter Kasiolas) and further in view of Orellana et al. (US 20220035669 A1, hereafter Orellana).
Regarding to Claim 5, the rejection of Claim 4 is incorporated and further the combination of Butler, Huang and Kasiolas discloses: wherein the supply signaling further indicates a supply lead time for new computing hardware resource inventory to become available in the cloud computing environment, and wherein a record of available computing hardware resource inventory includes recording the supply lead time (see [0164]-[0165] from Butler; “an inventory catalog subsystem 740 persists a catalog of available resources and configurations that can be added to the existing computing infrastructure, along with the times at which any of those resources are requested to be deployed/placed in the infrastructure”. Also see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”).
The combination of Butler, Huang and Kasiolas does not disclose: wherein the demand signaling further indicates a demand lead time indicative of when new demand will be received.
However, Orellana discloses: wherein the demand signaling further indicates a demand lead time indicative of when new demand will be received (see claim 2, “obtaining the number and use time periods of computing resources requested by the computing resource requester from the resource use request”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the demanding request/signaling from the combination of Butler, Huang and Kasiolas by including the resource use request include resource use time periods from Orellana, and thus the combination of Butler, Huang, Kasiolas and Orellana would disclose the missing limitations from the combination of Bulter, Huang and Kasiolas, since it would provide a specified resource demand or request for better planning resource usage via knowing the actual time period of the request should be achieved (see claim 2 from Orellana).
Regarding to Claim 6, the rejection of Claim 5 is incorporated and further the combination of Butler, Huang, Kasiolas and Orellana discloses: wherein the one or more rules of the common SDM logic is configured to direct matching supply signaling to demand signaling based at least in part on the supply lead time and the demand lead time (see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang), Kasiolas et al. (US20070088703A1, hereafter Kasiolas) and Orellana et al. (US 20220035669 A1, hereafter Orellana) and further in view of Greenwood et al. (US 20190158422 A1-IDS recorded, hereafter Greenwood).
Regarding to Claim 8, the rejection of Claim 5 is incorporated and further the combination of Butler, Huang, Kasiolas and Orellana discloses:
wherein each of the supply lead time and the demand lead time is selected from a plurality of lead time categories, wherein the lead time categories include at least: an imminent lead time indicating immediately available computing hardware resources and immediate computing hardware resource demand, respectively; a reserved lead time indicating incoming computing hardware resources that will be available on the order of period longer than the imminent lead time and forecasted computing hardware resource demand that will be received on the order of duration longer than the imminent lead time, respectively; and an in-transit lead time indicating incoming computing hardware resources that will be available on the order of duration longer than the reserved lead time and forecasted computing hardware resource demand that will be received on the order of duration longer than the reserved lead time, respectively (see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”. At least three different categories of time period can be classified for “a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)”, i.e., at least the “1s” time windows can be considered as claimed an imminent lead time, the “1m” time windows can be considered as generic/plain meaning of reserved lead time and the “1h” time windows can be considered as generic/plain meaning of in-transit lead time).
The combination of Butler, Huang, Kasiolas and Orellana does not disclose:
a reserved lead time indicating a time duration on the order of days; and
an in-transit lead time indicating a time duration on the order of weeks.
However, Greenwood discloses: a reserved lead time indicating duration in the order of days an in-transit lead time indicating duration in the order of weeks (see [0043] and [0072]; “the request 450 may include an amount of time into the future to predict (e.g., 1 week). The available capacity forecast returned 460 may provide a forecast of available capacity based on fragmentation for the 1 week period into the future from a time at which the forecast was generated” and “enough lead time remains to add new capacity as soon as possible before the remaining available capacity is exhausted (e.g., 2 weeks before the remaining 25% may be exhausted) … If, available capacity, decreases by 2 units per day, and 60 units of capacity remain, then the timing of adding new capacity may be set to within 30 days”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the variety of tunable time windows from the combination of Butler, Huang, Kasiolas and Orellana by including time windows period in the order of days and weeks from Greenwood, and thus the combination of Butler, Huang, Kasiolas, Orellana and Greenwood would discloses the missing limitations from the combination of Butler, Huang, Kasiolas and Orellana, since it would provide longer lead time for supply or demand action to provide “enough lead time remains to add new capacity as soon as possible before the remaining available capacity is exhausted” (see [0072] from Greenwood).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang), Kasiolas et al. (US20070088703A1, hereafter Kasiolas), Orellana et al. (US 20220035669 A1, hereafter Orellana), and Greenwood et al. (US 20190158422 A1-IDS recorded, hereafter Greenwood) and further in view of Mauer et al. (US 11467872 B1, hereafter Mauuer).
Regarding to Claim 9, the rejection of Claim 8 is incorporated and further the combination of Butler, Huang, Kasiolas, Orellana and Greenwood discloses: for supply signaling indicating the in-transit lead time, the supply signaling further indicates a vendor of the incoming computing hardware resource (see [0139], [0177], [0404] from Butler and [0002] from Huang; “allowing for customers and service providers to automatically plan for optimal capacity”, “long-term purchases of new computing hardware to bring additional capacities into the system, or short-term purchases such as renting capacities from cloud providers”, “A service provider (e.g., an owner/operator of server 3050, CN 3042, and/or cloud 3044) may deploy the IoT devices in the IoT group to a particular area (e.g., a geolocation, building, etc.) in order to provide the one or more services”. There are multiple service providers, and thus the supply signaling is required to include certain identification information indicates which service provider is provide the corresponding resources, i.e., claimed vendor. Also see [0043] and [0072] for in-transit lead time. Note: the current claimed language does not exclude the interpretation of only the supply signaling indicating the in-transit lead time would further indicate vendor information, and thus the embodiment of the vendor information included at all different supply signaling (no matter it is related to imminent lead time, reserved lead time or in-transit lead time) is still reasonable to be used to teach current claim 9), and wherein an amount of the incoming computing hardware resource that will be available on the order of weeks is approximated (see [0156] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available”. Note: once again, there is no requirement on the current claim 9 to perform the resource prediction only on the supply having in-transit lead time).
The combination of Butler, Huang, Kasiolas, Orellana and Greenwood does not disclose: wherein an amount of the incoming computing hardware resources that will be available on the order of weeks is approximated based at least in part on historical fulfillment data of the vendor.
However, Mauer discloses: wherein an amount of the incoming computing hardware resources that will be available on the order of weeks is approximated based at least in part on historical fulfillment data of the vendor (see lines 23-40 of col. 2 and lines 25-45 of col. 10 “machine learning can be used to estimate available capacity for various categories of capacity based on the parameters input by the customer and on historical information about capacity in the provider network … a quick determination as to the availability of a specific number and category or resources, or resource instances, at a future period of time”, “current and historical data is obtained 302 regarding total resource capacity for a resource provider. This can include the total capacity of any type that is available for allocation, regardless of whether or not that capacity was allocated. This amount can vary over time based upon factors such as additional physical resources being provisioned, physical resources being removed from service, maintenance, machine failures, and the like … indicating which portions of the overall capacity were either allocated for a specific customer, application, or task, for example, or unallocated and available for other usage”. Also see lines 64-13 of cols. 4-5; “If additional capacity is needed, it can take weeks to generate additional supply but obtaining, installing, and configuring new server racks or other additional resources”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the resource prediction function from the combination of Butler, Huang, Kasiolas, Orellana and Greenwood by including predicting resource capacities based on historical information of the service provider from Mauer, and thus the combination of Butler, Huang, Kasiolas, Orellana, Greenwood and Mauer would disclose the missing limitations from the combination of Butler, Huang, Kasiolas, Orellana and Greenwood, since it would provide a method to allow “a customer or other entity can obtain a quick determination as to the availability of a specific number and category or resources, or resource instances, at a future period of time” (see lines 23-40 of col. 2 from Mauer).
Claims 11-13, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Orellana et al. (US 20220035669 A1, hereafter Orellana).
Regarding to Claim 11, Butler discloses: a system comprising:
memory storing a supply-demand matching (SDM) logic framework for processing inputs from a plurality of capacity management subsystems, wherein each of the plurality of capacity management subsystems is configured to manage resources of a cloud computing environment and requests for the resources of the cloud computing environment according to a different respective capacity planning objective (see [0133]-[0136], [0166], [0187]; “a model-based mechanism/subsystem for expression and reasoning between different stakeholders (in space and time) based on different objectives capturing used and available capacity, dynamicity of the system, dynamicity of the workload, and dependability of a distributed edge platform”, “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning”, “The infrastructure capacity model may be generated based on the current capacity and telemetry data for the resources in the computing infrastructure”. The RRPM as claimed supply-demand matching logic framework processes at least current infrastructure capacity 725 as inputs that is formed by current capacity and telemetry data from each different computing infrastructures, i.e., claimed plurality of capacity management subsystems. Also see [0141]; “Such automated planning involves balancing multiple objectives (e.g., focusing on maximizing total cost of ownership (TCO) and quality of service (QoS)) across multiple stakeholders (e.g., infrastructure provider, service provider, end-user)”. Also see [0242]-[0247] for claimed cloud computing environment; “This solution proposes a novel methodology and algorithm to solve the technical problem … incrementing the flexibility of cloud orchestrators to choose the right placement option … place workloads distributed over edge, core network, and cloud resources. Also see [0091], [0343]-[0346] for particular capacity management action examples, and thus there are different capacity management subsystems to perform such different capacity management actions), wherein the resources of the cloud computing environment include multiple virtual machines (VMs) of different VM types, wherein each VM type is associated with a different set of computing hardware resources (see [0148]; “details on how a set of virtual machines (VMs) are being deployed on a physical server (e.g., VM sizes/configurations pinned to particular physical cores)”, i.e., at least different VM sizes having different set of hardware resources are considered as different VM types), and wherein each of the resources includes an indication of lead time (see [0164]-[0165]; “an inventory catalog subsystem 740 persists a catalog of available resources and configurations that can be added to the existing computing infrastructure, along with the times at which any of those resources are requested to be deployed/placed in the infrastructure); and
one or more processors of a global cloud inventory availability system configured to:
access a centralized record of available computing hardware resource inventory and the SDM logic framework (see [0156] and [0257]-[0259]; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”. Also see [0164] and [0168] for the claimed centralized record; “an inventory catalog subsystem 740 persists a catalog of available resources and configurations that can be added to the existing computing infrastructure, along with the times at which any of those resources are requested to be deployed/placed in the infrastructure”);
receive, from a first capacity management subsystem among the plurality of capacity management subsystems, a first capacity planning signal requesting access to the centralized record, the first capacity management subsystem being configured to perform capacity management actions in accordance with a first capacity planning objective; receive, from a second capacity management system among the plurality of capacity management subsystem, a second capacity planning signal requesting access to the centralized record, the second capacity management subsystem being configured to perform capacity management actions in accordance with a second capacity planning objective (see [0091], [0343]-[0346], “all edge compute nodes involved in this collaborative video analytics pipeline must share their system load status to allow overloaded edge nodes to choose optimal peer edge nodes for offloading compute tasks and rebalancing the overall load”, “a set of actions, which are then issued to the controller. These actions can include: … inserting advanced reservations to keep enough headroom for future function invocations … the deployment option can change from a cold to warm to hot container”. Also see [0166]; “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning”. The current infrastructure capacity 725 formed by current capacity and telemetry data from each different capacity management subsystems would cause RRPM 750 uses inventory catalog to perform the automated capacity planning discussed at [0091], [0343]-[0346], and thus such current infrastructure capacity from each different capacity management subsystems would request access to the inventory catalog, i.e., claimed centralized record); and
transmit, to the first capacity management subsystem, a first capacity management signal including an indication of matched resources and requests relevant to the first capacity planning signal; and transmit, to the second capacity management subsystem, a second capacity management signal including an indication of matched resources and requests relevant to the second capacity planning signal (see [0142] for applying common SDM logic to generate a resource allocation plan indicating the matched resources and requests in generality; “using a resource reasoning and planning module (RRPM) 604. This architectural diagram outlines the interaction of RRPM 604 with the other components available for managing compute platforms. For example, based on various insights 602 associated with the infrastructure and workloads, the RRPM 604 outputs a capacity plan 605. The capacity plan 605 can help inform a scheduling component of an orchestrator/resource manager 606 to make spatial and temporal workload placement decisions (in the near and longer term), as well as inform business decisions (e.g., via business intelligence dashboard 608) on adding additional capacity to the infrastructure 610 to maintain an overall optimal infrastructure capacity”. Also see [0093]-[0101] for a specific example of applying common SDM logic to balance multiple objectives to generate a corresponding action to be performed).
Bulter does not disclose: requests include an indication of lead time.
However, Orellana discloses: each requests includes an indication of lead time (see claim 2, “obtaining the number and use time periods of computing resources requested by the computing resource requester from the resource use request”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the demanding request/signaling from Butler by including the resource use request include resource use time periods from Orellana, and thus the combination of Butler and Orellana would disclose the missing limitations from Bulter , since it would provide a specified resource demand or request for better planning resource usage via knowing the actual time period of the request should be achieved (see claim 2 from Orellana).
Regarding to Claim 12, the rejection of Claim 11 is incorporated and further the combination of Bulter and Orellana discloses: wherein the different capacity management action types are selected from the group consisting of: reserving hardware computing resource inventory for a forecasted demand; determining pool sizes for domains of the cloud computing environment; moving computing hardware resource inventory between domains of the cloud computing environment; moving projects between domains of the cloud computing environment; and moving demand for computing hardware resource inventory between domains of the cloud computing environment (see “inserting advanced reservations to keep enough headroom for future function invocations” from [0344] of Butler as claimed limitation of “reserving hardware computing resource inventory for a forecasted demand”. See “the deployment option can change from a cold to warm to hot container” from [0345] of Butler as claimed limitation of “moving projects between domains of the cloud computing environment”. See “If one of the edge nodes 210 a-c becomes overloaded, however, a portion of its video processing workload can be dynamically offloaded to other edge nodes 210 a-c to prevent video frames from being dropped” from [0053] of Butler as claimed limitation of “moving demand for computing hardware resource inventory between domains of the cloud computing environment”).
Regarding to Claim 13, the rejection of Claim 11 is incorporated and further the combination of Bulter and Orellana discloses: wherein the one or more processors are configured to match the resources with the requests based further on at least one of computation capacity, storage capacity or virtual machine (VM) type (see [0217] and [0260] from Butler; “tasks and services requests need to express their requirements and operations margins (e.g., latency boundaries in which it can operate and hence defining where it can be placed at the edge)”, “the workload model for the experimental setup is a compute-intensive OpenFoam computational fluid dynamics (CFD) simulation workload, requesting for 24 cores”. Also see [0433] from Butler; “in response to a request by a user … fulfils the requirements of the application 3105 … Requirements of the application can include latency, location, compute resources, storage resources, network capability, security conditions, and the like”. Furthermore see [0217]-[0222] from Butler; “matching task(s) and/or sub-task(s) to resources based on various properties. In particular, the illustrated process flow shows how a system can, given a service request, decompose it into a set of task(s) and/or sub-task(s) and match those to resources capabilities known to it”).
Regarding to Claim 16, the rejection of Claim 11 is incorporated and further the combination of Bulter and Orellana discloses: wherein lead time for the resources indicates a time that the resources become available in the cloud computing environment, and wherein lead time for the requests indicates when projects included in the requests will be executed (see [0164]-[0165] from Butler; “an inventory catalog subsystem 740 persists a catalog of available resources and configurations that can be added to the existing computing infrastructure, along with the times at which any of those resources are requested to be deployed/placed in the infrastructure”. Also see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”. For limitation related to lead time for the requests, see claim 2 from Orellana; “obtaining the number and use time periods of computing resources requested by the computing resource requester from the resource use request”).
Regarding to Claim 17, the rejection of Claim 16 is incorporated and further the combination of Butler and Orellana discloses:
match resources having an imminent lead time with requests having the imminent lead time; match resources having a ready-for-reservation lead time with requests having the ready-for-reservation lead time; and transmit an indication of the matched resources and requests having the imminent and ready-for-reservation lead times to one or more capacity management subsystems configured to perform one of short-term supply shaping or short-term demand steering (see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”. Also see [0142], [0476] from Butler; “The capacity plan 605 can help inform a scheduling component of an orchestrator/resource manager 606 to make spatial and temporal workload placement decisions (in the near and longer term), as well as inform business decisions (e.g., via business intelligence dashboard 608) on adding additional capacity to the infrastructure 610 to maintain an overall optimal infrastructure capacity”, “Choosing the right platform architecture, rack design, or other hardware features or configurations, for short-term and long term usage (in addition to conducting an appropriate mapping of the services and workloads)”).
Regarding to Claim 18, the rejection of Claim 16 is incorporated and further the combination of Butler and Orellana discloses:
match resources having an in-transit lead time with requests having the in-transit lead time; transmit an indication of said matched resources and requests having the in-transit lead time to one or more capacity management subsystems configured to perform one of long-term supply shaping or long-term demand forecasting (see [0156] and [0257]-[0259] from Butler; “determines current and future (based on predictions) available capacities 725 for the resources and the service instances available. This will be carried out over a variety of tunable time windows (e.g., 1 s, 1 m, 1 h, and so forth)” and “Algorithm 1: derives optimal workload placement options in (near) real time based on current resource availability (e.g., by performing placement modeling using current resource and workload data)” and “Algorithm 2: derives optimal workload placement options at future time points based on future resource availability (e.g., by performing forward-looking placement modeling using predicted resource and workload data, such as the possibility of resources being freed/reserved or added/removed from inventory in the future)”. Also see [0142], [0476] from Butler; “The capacity plan 605 can help inform a scheduling component of an orchestrator/resource manager 606 to make spatial and temporal workload placement decisions (in the near and longer term), as well as inform business decisions (e.g., via business intelligence dashboard 608) on adding additional capacity to the infrastructure 610 to maintain an overall optimal infrastructure capacity”, “Choosing the right platform architecture, rack design, or other hardware features or configurations, for short-term and long term usage (in addition to conducting an appropriate mapping of the services and workloads)”).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Orellana et al. (US 20220035669 A1, hereafter Orellana) and further in view of Kasiolas et al. (US20070088703A1, hereafter Kasiolas).
Regarding to Claim 14, the rejection of Claim 11 is incorporated and further the combination of Bulter and Orellana discloses: wherein the SDM logic framework includes one or more rules including at least one of: a bin packing rule for reducing fragmentation of stored data; a VM integrity rule for ensuring that VMs are not scheduled across multiple machines of the resources of the cloud computing environment; a place in line rule for addressing requests [on a first-come first-served basis]; a holdback rule for ensuring that held-back resources are not counted towards available capacity of the cloud computing environment; or a clustering rule for moving requests between cells of a common cluster of the cloud computing environment (see [0217]-[0222] from Bulter; “matching task(s) and/or sub-task(s) to resources based on various properties. In particular, the illustrated process flow shows how a system can, given a service request, decompose it into a set of task(s) and/or sub-task(s) and match those to resources capabilities known to it”).
The combination of Butler and Orellana does not disclose: a place in line rule for addressing requests on a first-come first-served basis.
However, Kasiolas discloses: a place in line rule for addressing requests on a first-come first-served basis (see [0061]; “One or more bids are received from participating cluster managers at step 915. The bids may identify one or more destination nodes which can receive data. One or more of the bids are selected at step 920. Bids can be accepted based on ranking, on a first-come, first served basis”. Also see [0045]; “perhaps one or more bids are received but the bids are deemed to be unsatisfactory, the auctioning node can notify the cluster manager”, i.e., requiring matching of resource node with demand of the bid).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the specific rules or policies for handling resource requests from the combination of Butler and Orellana by including a policy of handing requests on a manner of first come first server from Kasiolas, and thus the combination of Butler, Orellana and Kasiolas would disclose the missing limitations from the combination of Butler and Orellana, since first-come first server is a well-known and understood scheduling mechanism to provide certain level of fairness to the jobs or tasks received earlier.
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Orellana et al. (US 20220035669 A1, hereafter Orellana) and Kasiolas et al. (US20070088703 A1, hereafter Kasiolas) and further in view of Natesan et al. (US 20200380746 A1, hereafter Natesan).
Regarding to Claim 15, the rejection of Claim 14 is incorporated and further the combination of Butler, Orellana and Kasiolas discloses: wherein the SDM logic framework includes at least two of the bin packing rule, the VM integrity rule, the place in rule, the holdback rule, and the clustering rule (see “One or more bids are received from participating cluster managers at step 915. The bids may identify one or more destination nodes which can receive data. One or more of the bids are selected at step 920. Bids can be accepted based on ranking, on a first-come, first served basis” from [0061] of Kasiolas for the claimed place in rule and see “works to negotiate and facilitate data relocations between data storage nodes within a cluster” from [0072] of Kasiolas for claimed clustering rule).
The combination of Butler, Orellana and Kasiolas does not disclose: the SDM logic framework includes at least three of the bin packing rule, the VM integrity rule, the place in rule, the holdback rule, and the clustering rule.
However, Natesan discloses: a bin packing rule for reducing fragmentation of stored data (see [0049]; “attempting to pack objects together into a finite space. In a bin-packing problem, a set of ‘objects’ some or all of which must be packed into a container”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the common supply-demand logic from the combination of Butler, Orellana and Kasiolas by including additional bin packing rule that attempting to placing some or all of asset of object into a container from Natesan, and thus the combination of Butler, Orellana, Kasiolas and Natesan would disclose the missing limitations from the combination of Butler, Orellana and Kasiolas, since it would provide a well-known and understood packing optimization rule/policy to placing a set of object (see “packing problems are a class of optimization problems that involve attempting to pack objects together into a finite space” from [0049] of Natesan).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Butler et al. (US 20220197773 A1, hereafter Butler) in view of Orellana et al. (US 20220035669 A1, hereafter Orellana) and further in view of Huang et al. (CN 109062683 A-publication date: 12/21/2018-English translation provided by Google Patents, hereafter Huang).
Regarding to Claim 20, the rejection of Claim 11 is incorporated and further the combination of Butler and Orellana discloses: wherein the memory includes a mapping between the plurality of requests and a plurality of resources (see [0188] from Butler; “the placement options may identify possible mappings of the underlying tasks and dependencies of the services to the resources of the computing infrastructure, which may be determined based on the service requirements and the available capacities of the infrastructure resources”)
The combination of Butler and Orellana does not disclose: the mapping is between the plurality of VM types and a plurality of machine platforms, wherein the one or more processors are configured to match the resources with the requests in accordance with the SDM logic framework based further the mapping.
However, Huang discloses: wherein the memory includes a mapping between the plurality of VM types and a plurality of machine platforms, wherein the one or more processors are configured to match the resources with the requests in accordance with the SDM logic framework based further on the mapping (see [0002] and claim 2; “The type of virtual machine that cloud computing platform is selected according to user creates on the physical host of its data center Meet the virtual machine of user resources demand, and provides it to user's use” and “The remaining available resource size for traversing each host in the host group, when i-th host in the host group It is tired according to first priority when remaining available resource size is greater than or equal to the resource size of j-th of user request”. The match of the resource requirements of jth user requests with ith host is based on the remaining available resource size of the ith host, the remaining available resources size of the ith host is generated or resulted from mapping or matching of the resource requirement of the previous user requests, i.e. other VM types, and resource availability of all hosts, i.e., machine types).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the usage of common supply-demand logic from the combination of Butler and Orellana by including matching cloud service provider’s resource with user’s requirements to create virtual machine for user from Huang, and thus the combination of Butler, Orellana and Huang would disclose the missing limitations from the combination of Butler and Orellana, since it is well-known and understood to provide sufficient resource sizes based on user’s requirements (see [0002] from Huang).
Allowable Subject Matter
Claim 19 is objected to due to corresponding limitations. Claim 19 contains allowable subject matter of “determine a level of confidence of delivery of the resources having the in-transit lead time based on a vendor delivering the resources having the in-transit lead time, and historical fulfillment data of the vendor”.
Response to Arguments
Applicant’s arguments, filed 5/7/2026, with respect to rejection of claims 1-20 under 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 10-13 are summarized as the following:
Applicant used [0166] from Butler (particularly, “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning”) to argue that “the RRPM functions as a central brain to which all supply signaling and all demand signaling is input. Thus, the automated capacity planning of Butler is a centralized function conducted by a single system … the centralized decisions made by the RRPM are then output as directions to other modules such as a resource manager or BI dash dashboard” (see last paragraph of page 10 and 1st paragraph of page 11 from the Remarks). However, “amended claim 1 recites a system in which resource management, such as supply and demand steering and shaping, is performed in a decentralized manner. This is evidence from the recitation of that each of the first and second capacity management subsystems … In other words, claim 1 is directed to a system which includes various subsystems that receive their own inputs and then perform actions that are determined by those inputs” (see 2nd paragraph of page 11 from the Remarks).
“the Final Office Action relies on paragraphs [0091], [0343]-[0346] and [0472] of Butler as disclosure of receiving first and second capacity planning signals from first and second subsystems, and then replies on paragraph [0142], [0238]-[0241] and [0344] of Butler as disclosure of transmitting first and second capacity management signals to the first and second subsystems” (see last paragraph of page 11 and 1st paragraph of page 12 from the Remarks). However, none of the paragraph [0091], [0343]-[0346] and [0472] from Butler discusses feature of communicating “to the RRPM, let alone, that they communicate capacity planning signals, or that any of the edge nodes, SLA handler, or FaaS platform receive different subsets of supply signaling and demand signaling” (see 2nd paragraph of page 12 from the Remarks). However, “Paragraphs [0142], [0238]-[0241] and [0344] from Butler, at best, describe the RRPM outputting its capacity plan to an orchestrator/resource manager and business intelligence dashboard, and the aforementioned actions performed by the SLA handler. To the best of Applicant’s understand, the Final Office Action does not contend that RRPM communicates to the SLA handler. Furthermore, the Final Office Action does not contend that either of the orchestrator/resource manager or the business intelligence dashboard would amount to a capacity management subsystem that communicates capacity planning signals to the RRPM. Therefore, the Final Office Actions reliance on the disparate citations to various unconnected components of Bulter does not amount to the specific intercommunication between capacity planning subsystems and one or more processors that access common supply-demand matching (SDM) logic, as recited in claim 1” (see 3rd and 4th paragraphs of page 12 from the Remarks).
The examiner respectively disagrees.
First of all, Applicant’s overall logics at the Remarks are confuse. Such as, according to what Applicant admitted, particularly, “The Final office Action further relies on the resource reasoning and planning module (RRPM) of Butler as discourse of ‘a common SDM logic’ recited in claim 1. (Final Office Action 6.)” (see last paragraph of page 10 from the Remarks), Applicant understood that Examiner mapped RRPM from Butler as claimed common SDM logic. According to either independent claim, claimed common SDM logic is different from each of the claimed capacity management subsystems and such claimed common SDM logic would performs operations in response to signals or inputs or requests from at least two claimed capacity management subsystems, i.e., such claimed common SDM logic makes centralized decisions as same as RRPM as Applicant argued. However, Applicant compared such RRPM with claimed capacity management subsystems to make arguments on such RRPM is centralized component but the claimed invention requires de-centralized components. None of one with ordinary skill in the art would understand such logic.
In addition, even if Examiner’s rejection is based on mapping RRPM from Butler to claimed capacity management subsystems, Applicant’s conclusion on Butler is about centralized system that “the automated capacity planning of Butler is a centralized function conducted by a single system” but the claimed invention is about “a system in which resource management, such as supply and demand steering and shaping, is performed in a decentralized manner” is still illogical. To one with ordinary skill in the art, “a single system” (like RRPM from Butler) is reasonable to include different sub-systems and the different sub-systems (like claimed “each of the first and second capacity management subsystems) are reasonable to form a single system (such as, Applicant already admitted that “amended claim 1 recites a system in which …. This is evident from the recitation of that each of the first and second capacity management subsystems”, emphasis added, see 2nd paragraph of page 11 from the Remarks). As explained at the Final Office Action, system or sub-system is broad term that any component or logic that enables to perform corresponding function is reasonable to be considered corresponding system or sub-system performs such functions. Examiner also made such examples like “the printing service and the typing/inputting service of same Microsoft Word application executing at one single CPU core can be considered as two different systems or sub-systems” at the Final Office Action. Thereby, the fact of RRPM from Butler is “one single system” and the claimed invention requires at least two “capacity management subsystems” is illogical to conclude that Butler handles supply and demand in a centralized manner but the claimed invention handles supply and demand in a decentralized manner.
For the issue/argument related to receiving capacity planning signals from each of the capacity management subsystems, Examiner already updated the rejection to explain such issue. Such as, “the information from the steps above (e.g., current infrastructure capacity 725, load to physical capacity mapping 735, inventory catalog 740) serve as input to the RRPM 750, which is responsible for performing automated capacity planning” from [0166] requires RRPM to receive current infrastructure capacity from the infrastructure capacity model, “The infrastructure capacity model may be generated based on the current capacity and telemetry data for the resources in the computing infrastructure” from [0187] requires the current infrastructure capacity described by [0166] is actually formed by the current capacity and telemetry data for the resource in the computing infrastructure. Thereby, the capacity management plan related to offloading task to other edge node discussed at [0091] does includes a sub-system to provide current capacity and telemetry data to form current infrastructure capacity to be inputted to RRPM. Similarity, the capacity management plan related to inserting advanced reservations discussed at [0344] does include a sub-system to provide current capacity and telemetry data to form current infrastructure capacity to be inputted to RRPM.
For the issue/argument related to “receive different subsets of supply signaling and demand signaling”, Applicant’s argument is illogic since Applicant did not make any argument on the claimed “receiving, by one or more processors, supply signaling and demand signaling” at line 2 of claim 1. If the reference does teach the claimed limitation of “receiving, by one or more processors, supply signaling and demand signaling”, then the reference by inherence does teach the limitations “the first capacity management subsystem configured to receive a first signaling subset of the supply signaling and the demand signaling” and “the second capacity management subsystem assigned to receive a second signaling subset of the supply signaling and the demand signaling”. Because it is reasonable to be consider the different portions or sub-systems of the “one or more processors” receive different subset of supply singling and demand signaling at line 2 as claimed first capacity management subsystem and claimed second capacity management subsystem. Applicant is reminded again, without further specifying the distinguish architecture of a particular system or subsystem, system or subsystem is very broad term that combination of any components/objects/logics perform corresponding function/step can be considered as corresponding system or subsystem to perform the corresponding function/step.
For the issue/argument related to transmitting capacity management subsystem, according to [0343]-[0346], the SLA handler is reasonable to be considered as resource manager since such SLA handler is used to perform resource management functions like “inserting advanced reservations to keep enough headroom for future function invocations”. In addition, according to [0091], the feature related to “choose optimal peer edge nodes for offloading compute tasks and rebalancing the overall load” is also required a resource manager in order to achieve the described choose and rebalance feature. Furthermore, the capacity plan 605 that mapped to corresponding capacity management signal according to [0142] is plan that “to make spatial and temporal workload placement decisions (in the near and longer term)”. Either one of offloading overloaded task discussed at [0091] or advanced reservation discussed at [0344] is reasonable to be considered as “spatial and temporal workload placement decisions”. For this point of view, either one feature discussed at [0091] and [0344] would require include a corresponding resource manager as part of the claimed corresponding capacity management subsystem to receive corresponding capacity plan as claimed corresponding capacity management signal in order to achieve the feature discussed at [0091] and [0344]. Applicant is reminded again, without further specifying the distinguish architecture of a particular system or subsystem, system or subsystem is very broad term that combination of any components/objects/logics perform corresponding function/step can be considered as corresponding system or subsystem to perform the corresponding function/step.
Therefore, Claims 1-20 are rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights