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 .
Information Disclosure Statement
As required by M.P.E.P. ' 609 (C), the applicant's submission of the Information Disclosure Statement dated March 13th, 2025, is acknowledged by the examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P. ' 609 C(2), a copy of the PTOL-1449 initialed and dated by the examiner is attached to the instant office action.
Claim Interpretation
The examiner has determined that the applicant has defined “page size” as meaning “record fetch size”. Where the typical meaning of page size relates to the size of a fixed-length, contiguous block of virtual memory that serves as the smallest unit of data for memory management in an operating system. The applicant is going with an alternative definition that relates to the number of records that are retrieved from a database using the HTTP protocol.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 8-9, 11, 18-19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dey et al. [US11,360,821]. Dey teaches systems and methods for resource utilization control.
Regarding claims 1, 11, and 20, Dey teaches a system, comprising:
at least one processor [Dey figure 6, feature 602 “Processor”]; and
at least one memory including program instructions which when executed by the at least one processor causes operations [Dey figure 6, feature 604 and 624 “Main Memory” and “Instructions”] comprising:
generating [Dey column 7, line 57-column 8, line1 “…The request optimization module 108 can be configured to provide notifications, suggestions, or recommendations about a request to a user. Based on resource usage associated with a request exceeds an associated resource usage threshold, the request optimization module 108 may provide a notification to a user who submitted the request. The notification can include various information about the request, such as reasons the request was terminated, an amount of cloud computing resources (e.g., CPU, GPU, memory) used by the request, a time duration that the request ran, syntax of the request, etc. The notification also can include a recommendation on how to improve the request…”], by a multi-tenant application [Dey column 7, lines 16-23 “…The resource usage threshold may be specific to the user or may be shared by a group in which the user is a member. For example, a user can be a member of a group “Elite User” and the members of the “Elite User” group may share the same resource usage threshold associated with the group. Further, a first group may be associated with a resource usage threshold that is different from a resource usage threshold associated with a second group…”(Where the user group reads on tenant.)], one or more page size recommendations [Dey column 3, lines 29-55 “…The resource usage thresholds can be defined based on a certain amount of resource usage (e.g., memory space, processing power, etc.) or a certain duration of resource usage (e.g., over 10 minutes, 3 hours, 1.5 days, etc.). Groups of users can be associated with usage resource thresholds that correspond to selected, acceptable levels of resource usage. For example, a group of users can be associated with a certain resource usage threshold that corresponds to an acceptable level of resource usage (e.g., 10 minutes time and/or 20 megabytes of memory), and each user in the group will enjoy the acceptable level of resource usage. A group of users can correspond to users that have a common role, responsibility, authority, duty, or the like. Examples of groups can include, for example, data readers, power users, elite users, data scientists, administrators, junior employees, senior employees, or the like. For example, a data reader may be associated with a threshold usage duration of 15 minutes while, as another example, a power user may be associated with a threshold usage duration of an hour. The resource usage thresholds can define an acceptable level of duration or amount of cloud computing resource usage before the usage is terminated. In some embodiments, a user may be individually associated with a resource usage threshold without regard to possible association with or membership in a group. The resource usage thresholds associated with users or groups of users can be reflected in one or more lookup tables…” and column 7, lines 59-column 8, line 8 “…Based on resource usage associated with a request exceeds an associated resource usage threshold, the request optimization module 108 may provide a notification to a user who submitted the request. The notification can include various information about the request, such as reasons the request was terminated, an amount of cloud computing resources (e.g., CPU, GPU, memory) used by the request, a time duration that the request ran, syntax of the request, etc. The notification also can include a recommendation on how to improve the request. For example, the request optimization module 108 may provide recommendations on how to modify the request so that execution time of the request does not exceed an associated resource usage threshold in future executions. In some embodiments, the request optimization module 108 may actively modify the request and re-submit the request as modified without intervention by a person, such as a user or a system administrator…” and column 8, lines 65-column 9, line 1 “…the request optimization module 108 can analyze how data is structured or organized (e.g., partitioned) in a database and proactively offer request rewrite recommendations that would improve efficiency…”(The examiner has determined that it would have been obvious to adjust the record size when preventing termination by staying under resource usage thresholds by providing request optimizations as is taught by Dey.)] and one or more sequential request count recommendations for one or more calls [Dey column 8, lines 9-26 “…the request optimization module 108 can be configured to detect and determine various scenarios of request termination, including request termination based on excessive resource usage. In some instances, a termination scenario may be a special, one-off instance. For example, a data reader may have written a request and submitted it as part of a proof-of-concept effort. In this scenario, the request optimization module 108 may record termination of the request, but may not take or recommend additional actions. In contrast, if multiple requests submitted by a particular user are consistently terminated, the terminated requests may be recorded, identified, and analyzed to detect a pattern or common characteristic(s) among the requests causing excessive resource usage. Causes of excessive resource usage, or issues, can be various. For example, an issue (e.g., anomaly) may relate to a request that is identical, or substantially similar, to a previously identified request that exceeded a common resource usage threshold…” and lines 38-42 “…For example, a user who has submitted a threshold number of successive requests that have exceeded an associated resource usage threshold within a certain time period can be identified as an issue…”(The examiner has determined that if a number of successive request by a user is surpassing a set threshold then this will lead to the termination of those requests. Therefore, the optimization module will inform the tenant group that a number of successive requests below said threshold will not lead to excessive resource usage and thus not lead to termination, therefore it reads on “one or more sequential request count recommendations for one or more calls”.)”] to an external database [Dey column 2, lines 57-58 “…As used herein, a request can be a query (e.g., a database query)…”(The examiner would like to point to MPEP 2144.04(V)(C) which states making something separable such as an external database vs an internal database is rendered obvious under KSR.)];
performing, by the multi-tenant application [Dey column 7, lines 16-23 “…the user or may be shared by a group in which the user is a member…”], a first call to the external database using a page size which is based on a first page size recommendation [Dey column 8, lines 65-column 9, line 1 “…the request optimization module 108 can analyze how data is structured or organized (e.g., partitioned) in a database and proactively offer request rewrite recommendations that would improve efficiency…”(The examiner has determined that it would have been obvious to adjust the record size when preventing termination by staying under resource usage thresholds by providing request optimizations as is taught by Dey.),
wherein the page size specifies a number of records to retrieve from the external database [Dey column 8, lines 65-column 9, line 1 “…the request optimization module 108 can analyze how data is structured or organized (e.g., partitioned) in a database and proactively offer request rewrite recommendations that would improve efficiency…”(See additional citations above for page size)(The examiner has determined that it would have been obvious to adjust the record size when preventing termination by staying under resource usage thresholds by providing request optimizations as is taught by Dey.) ; and
performing, in a sequential manner by the multi-tenant application [Dey column 7, lines 16-23 “…the user or may be shared by a group in which the user is a member…”], the first call and a number of subsequent calls to the external database [Dey column 8, lines 38-42 “…a user who has submitted a threshold number of successive requests that have exceeded an associated resource usage threshold within a certain time period can be identified as an issue…”],
wherein the number of subsequent calls is based on a first sequential request count recommendation [Dey column 8, lines 35-48 “…issues can be detected based on whether a specified number of successive requests have exceeded an associated resource usage threshold within a specified period of time. For example, a user who has submitted a threshold number of successive requests that have exceeded an associated resource usage threshold within a certain time period can be identified as an issue. In an embodiment, if an issue is detected, the request optimization module 108 may give a user guidance as to how to improve future requests. For example, a request may include multiple request clauses with each request clause intended to reduce (e.g., filter) the number of results during execution of the request…”(Where successive reads on subsequent)].
Regarding claims 2 and 12, as per claim 1, Dey teaches the program instructions are further executable by the at least one processor [Dey figure 6, feature 602 “Processor”] to cause operations comprising:
generating the first page size recommendation based on a plurality of inputs [Dey column 8, lines 65-column 9, line 1 “…the request optimization module 108 can analyze how data is structured or organized (e.g., partitioned) in a database and proactively offer request rewrite recommendations that would improve efficiency…”(The examiner has determined that it would have been obvious to adjust the record size when preventing termination by staying under resource usage thresholds by providing request optimizations as is taught by Dey.), the plurality of inputs comprising at least a real-time status of a cloud platform and a subscription plan of a corresponding client [Dey column 8, lines 9-26 “…the request optimization module 108 can be configured to detect and determine various scenarios of request termination, including request termination based on excessive resource usage. In some instances, a termination scenario may be a special, one-off instance. For example, a data reader may have written a request and submitted it as part of a proof-of-concept effort. In this scenario, the request optimization module 108 may record termination of the request, but may not take or recommend additional actions. In contrast, if multiple requests submitted by a particular user are consistently terminated, the terminated requests may be recorded, identified, and analyzed to detect a pattern or common characteristic(s) among the requests causing excessive resource usage. Causes of excessive resource usage, or issues, can be various. For example, an issue (e.g., anomaly) may relate to a request that is identical, or substantially similar, to a previously identified request that exceeded a common resource usage threshold….”]; and
training a machine learning engine with performance data of the cloud platform [Dey column 8, lines 27-33 “…one or more machine learning models can be trained with training data that associates some or all of various request parameters, syntaxes, resource usages, and/or identified issues. The one or more machine learning models, once trained, can be used to infer whether a given request is likely to exceed the common resource usage threshold…”].
Regarding claim 8 and 18, as per claim 1, Dey teaches the multi-tenant application executes on a cloud platform [Dey column 2, lines 59-60 “…provided to a computing system (e.g., a cloud computing service) for execution…”].
Regarding claim 9 and 19, as per claim 1, Dey teaches the program instructions are further executable by the at least one processor [Dey figure 6, feature 602 “Processor”] to cause operations comprising
dynamically generating the first page size recommendation and the first sequential request count recommendation for the first call to the external database in response to a scheduled job or a detected event [Dey column 10, lines 58-65 “…Azure Analysis Service® 302 is a fully managed platform as a service (PaaS) that provides enterprise-grade data models in a cloud. Azure Event Hub® 304 is a fully managed, real-time data ingestion service that can stream millions of events per second from any source to build dynamic data pipelines. Azure Event Hub® 304, using its ingestion service, collects execution logs from Azure Analysis Service® 302 in real-time…”(Dey teaches building dynamic data pipelines in response to detected event in the event hub.)],
wherein the first page size recommendation and the first sequential request count recommendation are generated based on a subscription plan of a corresponding client, a real-time status of the cloud platform, and a real-time status of the external database [Dey column 10, lines 63-column 11, lines 7 “…Azure Event Hub® 304, using its ingestion service, collects execution logs from Azure Analysis Service® 302 in real-time. In some embodiments, Azure Event Hub® 304 can perform cloud computing resource utilization and streaming log extraction. Some example parameters provided to Azure Event Hub® for the streaming log extraction can be identifying information of a resource being monitored (e.g., a name of a monitored semantic model), identifying information of a log that Azure Event Hub® should access, request information including user identifying information or request identifying information, or the like. Azure Event Hub® can monitor or publish log data of cloud computing resource usage...”(Where the examiner has determined the teachings of Azure would require a subscription to the Azure service.)].
Allowable Subject Matter
Claims 3-7, 10, and 13-17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dodson et al. [US9,892,066] Dodson teaches dynamically adjusting read request sizes.
Parra [US20170131936] Parra teaches regulations of runaway messaging requests in a conventional distributed computing network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC CARDWELL whose telephone number is (571)270-1379. The examiner can normally be reached on Monday - Friday 10-6pm EST.
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, Reginald Bragdon can be reached on (571) 272-4204. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ERIC CARDWELL/Primary Examiner, Art Unit 2139