DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 08/01/2025.
Claims 1, 2, 4, 5, 7, 8, 11, 12, 14-17, 19, and 20 have been amended.
Claims 3, 6, 13, and 18 have been cancelled.
Claims 21 and 22 have been added.
Claims 1, 2, 4, 5, 7-12, 14-17, and 19-22 are currently pending and have been examined.
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 08/01/2025 with respect to the rejections under 35 USC § 103 have been fully considered but they moot in view of the new grounds of rejection.
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, 2, 7-12, 16, 17, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Krebs et al. (US 2014/0358620 A1) in view of Yang et al. (US 2012/0151063 A1) in further view of “Moab Workload Manager Administrator's Guide ver. 6.0.4”, 2011 (hereafter “Moab”).
Claims 1, 11, and 16:
Krebs discloses the limitations as shown in the following rejections:
Krebs discloses a multi-tenant queuing architecture (an intelligent task message queue management service) wherein a plurality of subclasses (tenants) exist within the architecture (FIG. 1, ¶0025-0028, 0038) Krebs further discloses (¶0031-0038; FIG. 2) requests (task messages) sent by the tenants are placed into tenant queues (worklist queues) corresponding respectively to the tenants (assigning the task message to a subclass worklist queue based on the assigned subclass, wherein each of the plurality of subclasses has a corresponding subclass worklist queue). Krebs further discloses wherein the task message is a request from a producer (requesting tenant) to execute a computer-based operation or computer-based process (e.g. execute shared application; database access) by a consumer (application server/thread thereof); and executing the computer based operation or computer based process associated with the task message in at least ¶0027, 0030, 0039 disclosing tenants send requests to the application server that executes a shared application to service them by accessing a database.
Krebs further discloses (FIG. 5; ¶0061-0064, 0039-0044) calculating a subclass score (“priority” and/or “request weight” and/or “weight range”) for the task message based, at least in part, on [the tenant priority] and the weight (weight) associated with the subclass worklist queue; and dispatching the task message to a consumer (application server/thread thereof) based, at least in part, on the generated subclass score for the task message. Exemplary quotation:
“Weights are initialized (402). In some examples, and at the outset of a first iteration of a period, weights for each tenant, or for tenants having a non-empty queue, are determined (¶0061)…each tenant can be assigned a priority P based on a respective weight. In some examples, tenants are selected based on the priorities. More particularly, at the beginning of each period, weights W, associated with the respective tenants can be initialized, e.g., set to initial values for the period as discussed above, and a request weight RWi for each tenant can be initialized, e.g., set to zero. In some examples, for each iteration m within the period, tenants having non-empty queues can be included in the request selection process. A priority is determined for each of the tenants (¶0063)…Consequently, a set of priorities can be provided for the current iteration. In some examples, the tenant with the lowest priority is identified, a request is selected from the request queue associated with that tenant” (¶0064)
Krebs further discloses (¶0039, 0046, 0061-0063, 0066-0067; FIG. 5) revising (initializing) the weight associated with the subclass worklist queue to a preconfigured (initial) value based on a predetermined temporal refresh rate (defined time period length), “at the beginning of each period, weights W, associated with the respective tenants can be initialized, e.g., set to initial values for the period as discussed above, and a request weight RWi for each tenant can be initialized, e.g., set to zero (¶0063)…It is determined whether the period has ended (510). If it is determined that the period has not ended, the request weight associated with the select tenant is revised (512) and the process 500 continues with the next iteration in the period…If it is determined that the period has ended, a new period is started” (¶0067).
Regarding assigning a subclass to a task message based on a predetermined set of rules, Krebs inherently employs some mechanism to discern which requests are from which tenants so that they can be appropriately queued, but Krebs does not specifically describe the step and thus does not clearly anticipate the limitation.
Yang, however, discloses (FIG. 2; ¶0012, 0019-0022, 0039-0040, 0015-0016) an analogous class-based queuing system employing “peeker” threads configured to assign a subclass (e.g. organization, priority) to a task message based on a predetermined set of rules, assign the task message to a subclass worklist queue based on the assigned subclass, wherein each of the plurality of subclasses has a corresponding subclass worklist queue. Yang also discloses (Yang ¶0039-0041, 0028, 0018) wherein the task message is a request from a producer (request source) to execute a computer-based operation or computer-based process (e.g. database queries); and executing the computer based operation. Exemplary quotation:
“peeker threads analyze metadata contained in the request to perform an analysis used to select the appropriate queue. Metadata that may be used by the peeker threads may include, for example, organization information related to the request (e.g., organization identifier, organization category, organization type), request information (e.g., request type, request size, associated requests), priority information, and/or resource information, etc. (¶0021)…A packet including a request is received…the request, which may be for database accesses (e.g., database queries) or for other resource requests” (¶0039).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to combine Krebs unspecified mechanism for classifying requests with Yang’s metadata analysis method to enhance queuing flexibility by increasing the variety of attributes by which incoming requests can be categorized beyond tenant/organization (Yang ¶0012, 0021, 0023, 0040-0041).
Regarding the limitation calculating a subclass score for the task message based, at least in part, on the priority specified by the producer and the weight associated with the subclass worklist queue, as noted above Krebs discloses using a combination of tenant/producer priority/quota and queue associated weight to calculate a request priority/request weight (subclass score); and Yang further discloses (¶0012, 0015-0016, 0021, 0033, 0040) determining request priorities based on factors including organization type (producer), request type (priority specified by the producer), and quota (weight) but does not explicitly describe combining the factors. Accordingly, the combination of Krebs/Yang does not specifically disclose the limitation.
Moab, however, discloses (pg. 8; pg. 400, figure) an analogous priority-queue based request scheduling system with detailed job priority calculations based on combinations of numerous factors and subfactors including calculating a subclass score (priority) for the task message (job) based, at least in part, on the priority specified by the producer (e.g. job attribute subfactor, user selected QoS subfactor) and the weight (class/queue weight subfactor and/or (fairshare (FS) factor) associated with the subclass worklist queue (see at least pg. 78-81, 86, and 88-89).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Krebs/Yang with the request/job priority calculations of Moab to capture a multi-faceted set of scheduling objectives in a manner that best fulfills overall goals of the scheduling system (Moab pg. 77).
Claims 2, 12, and 17:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Furthermore, Krebs discloses receiving, the task message from the producer (requesting tenant) (see at least Krebs FIG. 1; ¶0027-0028, 0054).
Claims 7 and 8:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Krebs further discloses wherein generating the subclass score for the task message further comprises: determining a priority (quota and/or response time specified in tenet SLA) of the producer of the task message; and calculating the subclass score for the task message based, at least in part, on the priority of the producer of the task message and the weight of the subclass worklist queue
wherein the intelligent task message queue management service is a multi-tenant service comprised of a plurality of producers (requesting tenants), each producer has a corresponding priority level (quota and/or response time specified in tenet SLA), and the subclass score being further based on the priority level of the requesting producer…wherein the corresponding priority levels of the plurality of producers are based on corresponding subscription plans (SLAs) (see at least Krebs ¶0028, 0055-0057, 0061-0066). See also Yang ¶0015-0016. See also Moab pg. 79, GROUP, ACCOUNT, QOS subfactors; pg. 187-192).
Claims 9 and 10:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Krebs further discloses wherein the intelligent task message queue management service is composed of a plurality of consumers (server threads), wherein the plurality of consumers can execute each task message…wherein the task message is a task encapsulated as a message (e.g. network transmission) that can be sent to the consumer, wherein the consumer executes the task encapsulated as the message (see at least Krebs FIG. 1; ¶0026-0027, 0030, 0039). See also Yang ¶0012, 0039-0041, 0025-0028, FIG. 1.
Claim 21:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Moab further discloses wherein the specified priority is a task-related priority selected from the group consisting of: a) system critical (e.g. high-priority preemptor jobs); b) business critical (e.g. admin max priority); c) data conversion; and d) data backup (low priority backfill or preemptee jobs) (pg. 205-206, sect. 8.4.1.2; pg. 85; pg. 88-91. See also Yang request type in at least ¶0012, 0015-0016, 0021, 0033, 0040.
Claim 22:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Moab further discloses the specified priority is a timing-related priority…perform as soon as possible (Moab pg. 89, 91).
Claims 4, 5, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Krebs in view of Yang in view of Moab in further view of Howes et al. (US 2014/0146677 A1)
Claims 4, 14, and 19:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Krebs further discloses (¶0039, 0054-0055, 0064, 0028) receiving feedback from the application server as it processes the received requests, the feedback including throughput, quota, and response time (subclass score) measurements for the tenant’s requests that are used for updating the weight of the subclass worklist queue based on the feedback. But Krebs/Yang does not specifically disclose the feedback is related to an acknowledgement that the dispatched task message has been received by the consumer.
Howes, however, discloses (FIG. 4; ¶0019-0021) an analogous class/priority based multi-queue dispatching system similarly configured to update dispatch priorities based on feedback (¶0057-0059, 0066-0069, 0090-0093, 0155) including embodiments where the feedback is received with acknowledgements from client devices (consumers) being dispatched the packets/tasks and accordingly teaches receiving an acknowledgement that the dispatched task message has been received by the consumer and updating the weight of the subclass worklist queue based, at least in part, on the received acknowledgement.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Krebs/Yang/Moab to employ the feedback propagation technique of Howes to facilitate real-time adjustments to the task dispatch priorities that account for the most current conditions and measurements (Howes ¶0065-0067, 0057).
Claims 5, 15, and 20:
The combination of Krebs/Yang/Moab discloses the limitations as shown in the rejections above. Krebs further discloses (¶0039, 0054-0055, 0064, 0028) receiving feedback from the application server as it processes the received requests, the feedback including throughput, quota/request weight, and response time (subclass score) measurements for the tenant’s requests that are tracked using running averages and tallies (accumulating each subclass score associated with the subclass worklist queue) for the tenants; and the used for updating the weight of the subclass worklist queue based on the feedback. But Krebs/Yang does not specifically disclose the feedback is related to an acknowledgement that the dispatched task message has been received by the consumer.
Howes, however, discloses (FIG. 4; ¶0019-0021) an analogous class/priority based multi-queue dispatching system similarly configured to update dispatch priorities based on feedback (¶0057-0059, 0066-0069, 0090-0093, 0155) including embodiments where the feedback is received with acknowledgements from client devices (consumers) being dispatched the packets/tasks and accordingly teaches receiving an acknowledgement that the dispatched task message has been received by the consumer and updating the weight of the subclass worklist queue based, at least in part, on the received acknowledgement.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Krebs/Yang/Moab to employ the feedback propagation technique of Howes to facilitate real-time adjustments to the task dispatch priorities that account for the most current conditions and measurements (Howes ¶0065-0067, 0057).
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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
10/18/2025
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights