DETAILED ACTION
This office action is in response to claims filed 7 May 2026.
Claims 1-20 are pending.
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 .
Response to Arguments
Applicant’s arguments filed on 7 May 2026 have been considered but are moot because the remarks do not specifically address the new reference (GHOSH, cited below) used to rejected the limitations at issue.
Examiner’s Note
Applicant is reminded of the requirement in MPEP 714 (c)(2) that “The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters”. At least claims 1, 12, and 17 fail to comply with this requirement, because there at least appears to be multiple instances of text that are deleted and not shown by strike through.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 12-14, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over RANJAN et al. Pub. No.: US 2021/0232440 A1 (hereafter RANJAN), in view of GHOSH et al. Patent No.: US 12,461,971 B1 (hereafter GHOSH).
RANJAN was cited previously.
Regarding claim 1, RANJAN teaches the invention substantially as claimed, comprising:
A method for providing dynamic resource allocation in a computing environment, comprising:
determining a database access pattern by monitoring traffic pattern using a Client Traffic Monitor that collects database traffic information, wherein the traffic pattern is monitored between a pool of resources and a plurality of clients ([0010] An example of a cluster (i.e., “pool of resources”) is a cluster that operates a serverless computing environment, in which custom application code is run in managed and ephemeral containers on a Functions-as-a-Service (FaaS) platform (i.e., FaaS provide cluster resources to plural customers, or clients)) during a performance of at least one task ([0011] A function (i.e., “task”) may be executed upon invocation, for example, in response to a service request. The execution of the function may involve consumption of computing resources of the cluster. [0001] An example function is a search function that is to search for an item in a database (i.e., execution of a function, representing a database access task, results in database access “traffic”)), wherein said traffic pattern includes accessing at least one database; analyzing any resource relationships and any database access patterns by using a Database Resource Analyzer ([0047] To determine the resource availability information, a cluster, such as the first cluster 102 (i.e., resources within a same cluster are “related” while those not within the same cluster are not “related”), may forecast its resource consumption for a predetermined future time duration, such as one hour. The forecast may be performed, for example, by the computing agent of the cluster, such as the first computing agent 307 (i.e., computing agent acts as both a “Client Traffic Monitor” and a “Database Resource Analyzer” because it both monitors and analyzes historical workloads (traffic) to determine database access patterns of a cluster). Such a forecast may be performed based on an analysis of a historical workload pattern of the cluster (i.e., workloads due to database access function execution are “monitored” to produce a historical workload “pattern” utilizing related resources within a same cluster));…
generating a consumption model based on all identified relationships to predict resource needs based on said resource relationships, a traffic pattern, and an availability of said plurality of resources ([0047] A cluster, such as the first cluster 102, may forecast its resource consumption for a predetermined future time duration (i.e., a “consumption model), such as one hour. The forecast may be performed, for example, by the computing agent of the cluster, such as the first computing agent 307. Such a forecast may be performed based on an analysis of a historical workload pattern of the cluster (i.e., computing agent predicts resource consumption needs based on available resources in a cluster and workload patterns)); and
allocating resources once a subsequent request for task performance has been received to be performed by using relationship identification and availability of resources in said pool using said consumption model to predict any resource needs so as to dynamically allocate, reallocate, and release said plurality of resources in a cascading manner until completion of said subsequent request ([0065] At block 402, an identification request may be received from a requesting cluster, such as the first cluster 102. The identification request may be for identification of a cluster that can spare ‘X’ number of computing units. Here, ‘X’ may be the first number if the identification request corresponds to the first service request 216 alone. [0066] In response to the request, at block 404, clusters of the community that can spare the ‘X’ number of computing units may be identified. Such an identification may be performed based on the resource availability information published by each cluster, as explained earlier. If it is identified that a single cluster alone can spare the ‘X’ number of computing units, at block 408, such a cluster may be selected as the lender cluster. Further, an indication of the lender cluster may be provided to the requesting cluster. If, at block 406, it is identified that multiple clusters can spare the ‘X’ number of computing units, at block 410, one cluster is selected from among the multiple clusters (i.e., clusters predicted to have resources that are capable of supporting the received service request are dynamically selected, or allocated to the service request). [0032] A container hosting the function may be instantiated in a node of a cluster when the function is to be executed and may be terminated when the output of the execution is completed (i.e., resources of a container are terminated, or “released” for “reallocation” to other functions to be executed. Further, this technique of allocating, terminating, and reallocating, may be considered a “cascading manner”)).
While RANJAN discusses allocation of resources to tasks to access resources of clusters based on consumption models that include identified relationships between resources, RANJAN does not explicitly teach:
identifying using said Database Resource Analyzer these following relationships:
relationship of a same resource in using components within a first database,
relationship of same resource in using components across at least two different databases,
relationship of a plurality of different resources in using components within said first database,
relationship of different resources using components across at least two different databases;
However, in analogous art that similarly discusses client devices accessing resources of clusters, GHOSH teaches:
identifying using said Database Resource Analyzer these following relationships:
relationship of a same resource in using components within a first database, relationship of same resource in using components across at least two different databases, relationship of a plurality of different resources in using components within said first database, relationship of different resources using components across at least two different databases ([Column 11, Line 63-Column 12, Line 5] in some embodiments, the repository processing system 102 includes one or more computing devices (e.g., application servers and/or corresponding database servers, and/or the like) that access the data system 104 to identify file data objects stored on one or more data repositories thereof, process data and/or metadata associated with one or more data repositories thereof, perform scanning of file data objects stored to one or more data repositories thereof, and/or the like (i.e., one or more computing devices, representing “resources” access one or more data objects representing database “components” within a first data repository or across multiple data repositories));
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined GHOSH’s teaching of resources having relationships with database components across one or multiple databases, with RANJAN’s teaching of allocating resources based on consumption models that use relationships to determine predicted resource consumption, to realize, with a reasonable expectation of success, a system that allocates resources based on consumption models that use relationships to determine predicted resource consumption, as in RANJAN, where those relationships include relationships with database components across one or multiple databases, as in GHOSH. A person having ordinary skill would have been motivated to make this combination to enable resource allocation to optimized across multiple different databases.
Regarding claim 2, RANJAN further teaches:
upon determining that said plurality of resources are not sufficient ([0068] If, at block 404, it is determined that there is no single cluster that can spare the ‘X’ number of computing units, at block 411, it is determined if computing units can be obtained from a group of clusters (i.e., there is no cluster having “sufficient” resources to fulfil the request)), at least one additional resource is added and enabled from said resource pool ([0069] If it is possible to obtain the computing units from a group of clusters, at block 413, it is determined if more than one cluster can collectively spare the ‘X’ number of computing units. For instance, it may be checked if the first number of computing units can be spared by the second cluster 202 and the second number of computing units can be spared by the third cluster 204 or vice versa. If yes, at block 414, the clusters from which the computing units are to be obtained may be selected and computing units may be obtained (i.e., at least one resource from a different cluster is added to a “pool” comprising the first cluster of the group of clusters)).
Regarding claim 3, RANJAN further teaches:
other resources are enabled and added that have not been part of said resource pool and when no resource availability is found, an alert is generated so that a processing request cannot be performed due to resource availability ([0068] If it is not possible to obtain the computing units from the group of clusters, at block 412, the selection process ends, and the first cluster 102 is notified (i.e., generating an “alert”) that workload sharing is not possible (i.e. other clusters represent other “resources” that are enabled and are able to be added to a group of clusters representing said “resource pool”, but which together are unable to satisfy the computing request, and which results in a notification being generated)).
Regarding claims 12-14, and 17-18, they comprise limitations similar to those of claims 1-3, and are therefore rejected for similar rationale.
Claims 4-6, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over RANJAN, in view of GHOSH, as applied to claims 1, 12, and 17 above, and in further view of KULACK et al. Pub. No.: US 2012/0310996 A1 (hereafter KULACK).
KULACK was cited previously
Regarding claim 4, while RANJAN and GHOSH discuss accessing a database in response to a request, they do not explicitly teach:
a plurality of databases is used by said computing environment.
However, in analogous art that similarly teaches accessing a database in response to a request, KULACK teaches:
a plurality of databases is used by said computing environment ([0004] The method, computer program product and system include analyzing the first database to determine a first set of structural characteristics of the first database. The method, computer program product and system also include analyzing a second database to determine a second set of structural characteristics of the second database, wherein the second database is associated with a second data abstraction model (i.e., system uses a plurality of databases to create data abstraction models)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KULACK’s teaching of executing queries to access multiple databases, with the combination of RANJAN and GHOSH’s teaching of executing database access operations, to realize, with a reasonable expectation of success, a system that executes database access operations, as in RANJAN and GHOSH, to multiple different databases, as in KULACK. A person of ordinary skill would have been motivated to make this combination to enable access to multiple databases to improve data locality or resilience.
Regarding claim 5, KULACK further teaches:
analyzing the relationships between said resources, and further relationships between resources and any internal and external clients includes at least one of identifying the relationships of same resources among components within a database or identifying the relationships of same resources among components across one or more databases ([0030] Generally, the database analysis component 135 may analyze the database 130.sub.1 to determine a first set of structural characteristics for the database 130.sub.1. These characteristics may include information related to the structure of the database, such as the tables contained in the database and the structure of those tables (i.e., each table represents a same type of “resource” that are also “components” of a database). The characteristics may further include information on the data contained in the tables. For instance, the database analysis component 135 may analyze the database 130.sub.1 and determine that one column of data conforms to a particular industry standard. The database analysis component 135 may also examine relationships between the tables in the database (i.e., relationships between tables represents “relationships between resources”). One example of such a relationship would be if a first table of the database 130.sub.1 contains references to a second table of the database 130.sub.1 (e.g., a foreign key). [0036] The embodiments of the present invention may also be practiced in distributed computing environments in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In this regard, the computer system 175 and/or one or more of the networked devices 176 may be thin clients which perform little or no processing (i.e., multiple thin clients represent at least one internal or external client having a relationship with the databases and components of those databases)).
Regarding claim 6, KULACK further teaches:
analyzing the relationships between said resources, and further relationships between resources and any internal and external clients includes at least one of identifying the relationships of different resources among components within one or more databases, and identifying the relationships of different resources among components across at least one of said one or more databases ([0030] Generally, the database analysis component 135 may analyze the database 130.sub.1 to determine a first set of structural characteristics for the database 130.sub.1. These characteristics may include information related to the structure of the database, such as the tables contained in the database and the structure of those tables (i.e., each individual table represents a different “resource” that are also “components” of a database). The characteristics may further include information on the data contained in the tables. For instance, the database analysis component 135 may analyze the database 130.sub.1 and determine that one column of data conforms to a particular industry standard. The database analysis component 135 may also examine relationships between the tables in the database (i.e., relationships between tables represents “relationships between resources”). One example of such a relationship would be if a first table of the database 130.sub.1 contains references to a second table of the database 130.sub.1 (e.g., a foreign key). [0036] The embodiments of the present invention may also be practiced in distributed computing environments in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In this regard, the computer system 175 and/or one or more of the networked devices 176 may be thin clients which perform little or no processing (i.e., multiple thin clients represent at least one internal or external client having a relationship with the databases and components of those databases)).
Regarding claims 15, and 20, they comprise limitations similar to claim 4, and are therefore rejected for similar rationale.
Claims 7, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over RANJAN, in view of GHOSH, as applied to claims 1, 12, and 17 above, and in further view of KRISHNAN et al. Pub. No.: US 2019/0324820 A1 (hereafter KRISHNAN).
KRISHNAN was cited previously.
Regarding claim 7, while RANJAN and GHOSH discusses assigning resources from pools to handle requests, they do not explicitly teach:
said consumption model is used by a Multi-Resource Pool Predictor to allocate and reallocate resources, wherein said Multi-Resource Pool Predictor is enabled to scan a usage of said Multi-Resource Pool Predictor and remove any resources when a resource idle time is larger than a defined threshold.
However, in analogous art that similarly assigns resources from pools to handle requests, KRISHNAN teaches:
said consumption model is used by a Multi-Resource Pool Predictor to allocate and reallocate resources, wherein said Multi-Resource Pool Predictor is enabled to scan a usage of said Multi-Resource Pool Predictor and remove any resources when a resource idle time is larger than a defined threshold ([0098] In some examples, the resource pool handler 460 compares a quantity of time ones of the free pool servers 310 are inactive or not utilized to an inactive time threshold specified by a policy rule based on the policy 304. For example, the resource pool handler 460 may instruct the resource deallocator 440 to decompose one or more of the free pool servers 310 when the one or more free pool servers 310 have been inactive for a period of time greater than the inactive time threshold (i.e., deallocating a server resource “removes” the resource from the pool)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined KRISHNAN’s teaching of removing idle resources from a pool, with the combination of RANJAN and GHOSH’s teaching of maintaining a pool of resources for handling database access requests, to realize, with a reasonable expectation of success, a system that maintains a pool of resources, as in RANJAN and GHOSH, where idle resources are dynamically removed, as in KRISHNAN. A person having ordinary skill would have been motivated to make this combination so that unused resources may be reallocated thereby optimizing the use of resources for improved performance (KRISHNAN [0027]).
Regarding claims 16, and 19, they comprise limitations similar to claim 7, and are therefore rejected for similar rationale.
Claims 8-11 are rejected under 35 U.S.C. 103 as being unpatentable over RANJAN, in view of GHOSH, in view of KRISHNAN, as applied to claims 7, above, and in further view of NAGPAL et al. Patent No.: US 10,089,144 B1 (hereafter NAGPAL).
NAGPAL was cited previously.
Regarding claim 8, while RANJAN, GHOSH, and KRISHNAN discuss use of a consumption model to predict resource needs, they do not explicitly teach:
said Multi-Resource Pool Predictor uses said consumption model to provide an estimated time request for completing processing and a plurality of related metrics for said request processing.
However, in analogous art that similarly teaches use of a consumption model to predict resource needs, NAGPAL teaches:
said Multi-Resource Pool Predictor uses said consumption model to provide an estimated time request for completing processing and a plurality of related metrics for said request processing ([Abstract Lines 1-10] Measurements comprising time-series stimuli and time-series responses of a computing platform that has executed a first set of jobs are collected over a first time period. The measurements are used to form a query-able predictive model pertaining to resource usage demand predictions (i.e., “consumption model”) for the first set of jobs. A second set of job records describe a second set of jobs to be invoked in a second time period. The predictive model is queried to determine a likelihood to complete by the predicted finish time (i.e., estimated “time” for completing processing) based on resource usage demand predictions for the first set of jobs (i.e., other related metrics include “likelihood to complete by the predicted finish time”, as well as “resource usage demand predictions”)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined NAGPAL’s teaching of a predictive model that predicts a finish time for a job, as well as other related metrics, with the combination of RANJAN, GHOSH, and KRISHNAN’s teaching of a predictive model used to allocate resources, to realize, with a reasonable expectation of success, a system that uses a predictive model to allocate resources, as in RANJAN, GHOSH, and KRISHNAN, which also provides an estimated time for completion and other related metrics, as in NAGPAL. A person having ordinary skill would have been motivated to make this combination to provide accurate information for better workload planning.
Regarding claim 9, NAGPAL further teaches:
said metrics include at least one of: an expected arrival rate of at least one [job] and a running time of each [job] ([Column 9, Lines 55-57] This schedule is formed over a set of predicted foreground demands, which predicted foreground demands may or may not be accurate in fact during the timeframe T.sub.0 to T.sub.3 (i.e., a predicted set of demands over a timeframe represents a predicted demand arrival rate)).
RANJAN further teaches:
at least one query ([0011] A function (i.e., “task”) may be executed upon invocation, for example, in response to a service request. The execution of the function may involve consumption of computing resources of the cluster. [0001] An example function is a search (i.e., “query”) function that is to search for an item in a database)
Regarding claim 10, NAGPAL further teaches:
said metrics also include a next transaction of a new [job] (Column 9, Lines 35-54 Multiple backup jobs can be scheduled on top of one another, and further on top of a set of predictions of foreground demands. FIG. 2C depicts a front-to-back greedy scheduling regime 210. As shown, all 10 units of Job1 are allocated into the T.sub.0 to T.sub.1 time slot, leaving a predicted 50 units available in that time slot, which is consumed when 50 units are allocated to Job2 in that time slot, leaving 30 more units to be allocated to Job2. Even after allocating greedily to the remaining demands of the remaining jobs, Job3 cannot be completed by its end time of T.sub.3. As shown, there are five units of resource utilization that Job3 needs to complete. Depending on the SLA it might be late (overage indication 218). For example, if the SLA specifies “100% completion of backup jobs by the scheduled time” (e.g., referring to a Gold SLA), then job J3 would be deemed to be late. However, if the SLA specifies a more relaxed specification such as “80% of the time the backup jobs are to complete by the scheduled time” (e.g., a Silver SLA), then even though job J3 runs over its scheduled completion time, it still might fall into the acceptable relaxed range) and a memory usage associated with each of said queries ([Column 1, Lines 27-31] In many cases such resources (e.g., CPU cycles, network I/O (input/output or IO), storage (i.e., “memory”) space, etc) can be consumed by backup jobs).
Regarding claim 11, RANJAN further teaches:
said metrics can include a structural and a periodic shift in a workload or a prediction of the workload shift associated with a processing of said request ([0047] To determine the resource availability information, a cluster, such as the first cluster 102, may forecast its resource consumption for a predetermined future time duration, such as one hour. The forecast may be performed, for example, by the computing agent of the cluster, such as the first computing agent 307. Such a forecast may be performed based on an analysis of a historical workload pattern of the cluster. In an example, the forecast may utilize machine learning. Here, historical workload pattern may include a pattern in which service requests are received by the cluster and a pattern in which resources of the cluster are consumed to handle the service requests).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 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, Aimee Li can be reached at (571) 272-4169. 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.
/MICHAEL W AYERS/ Primary Examiner, Art Unit 2195
Prosecution Insights