Prosecution Insights
Last updated: May 29, 2026
Application No. 17/656,991

TICKET QUEUE FOR CONTROLLING COMPUTE PROCESS ACCESS TO SHARED DATA AND COMPUTE RESOURCES

Non-Final OA §101§103
Filed
Mar 29, 2022
Examiner
TRAINOR, DANIEL BRENNAN
Art Unit
2198
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
3 (Non-Final)
100%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 100% — above average
100%
Career Allowance Rate
10 granted / 10 resolved
+45.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
11 currently pending
Career history
32
Total Applications
across all art units

Statute-Specific Performance

§101
1.6%
-38.4% vs TC avg
§103
95.2%
+55.2% vs TC avg
§102
1.6%
-38.4% vs TC avg
§112
1.6%
-38.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 10 resolved cases

Office Action

§101 §103
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 . Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “A computer-implemented method for compute process shared access management, the computer-implemented method, comprising: responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, creating, by the compute process, a ticket file belonging to the compute process in a ticket queue directory, wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; allowing the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process; implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; and placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process; and removing, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” Under Prong I Step 2A, the limitation “responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, creating, by the compute process, a ticket file belonging to the compute process in a ticket queue directory …” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a process is attempting to use a shared resource/data on a sheet of paper with pen or mentally based on common accessing of data/resources across a plurality of processes being submitted. Thus, the person can also then create a ticket file to place onto the ticket queue based on the previous determination of common access of shared resource/data. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “allowing the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a ticket file is first in line on a sheet of paper with pen or mentally based on tracking the ticket queue. Thus, the person can also then allow the compute task to be performed since it is its turn in line. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing …” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a resource is not available to be allocated to the ticket on the top of the queue on a sheet of paper with pen or mentally based on tracking the resource usage in a list compared to its maximum allowance. Thus, the person can make a judgement of what to do with the ticket at the front of the queue since it is its turn in line but the necessary resources are not available. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination of where to place the ticket in the queue on a sheet of paper with pen or mentally based on the priority level of the compute process associated with the ticket. Thus, the person can make a judgement of where in the queue to place the ticket if it has an increased priority level compared to other tickets already in the queue. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. This judicial exception is not integrated into a practical application. In particular under Prong II Step 2A, the claim recites the additional elements “… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; … disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and removing, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” The additional element ““… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process” is simply a description of the ticket file’s components. The additional elements “disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and removing, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” represent the “apply it” steps which are mere instructions to apply an exception (2106.05(f)). The claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract ideas into a practical application, the additional elements amount to mere instructions to apply an exception of executing computing instances to perform routine techniques in the technology, as discussed above, does not amount to significantly more, and is thus, not an inventive concept. Accordingly, the claim does not appear to be patent eligible under 35 U.S.C. 101. See MPEP 2106.05(f). As per claim 2, it incorporates the deficiencies of independent claim 1 upon which it depends, and further recites, “the ticket file contains information associated with the compute process, the information inclusive of at least one of a creating process identifier, a ticket creation time, a compute process priority, and a timeout threshold (analyzed under Prong II Step 2A & 2B as additional element); and an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory (analyzed under Prong II Step 2A & 2B as additional element).” These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 2 fails to correct the deficiencies of claim 1 and is rejected for similar reasoning as claim 1, above. As per claim 4, it incorporates the deficiencies of independent claim 1 upon which it depends, and further recites, “defining a timeout threshold for the compute process, wherein, an alternative compute process is allowed to perform an alternative compute task, notwithstanding whether the ticket file belonging to the alternative process is the first in line in the ticket queue, when the timeout threshold for the compute process has been exceeded (analyzed under Prong I Step 2A as directing to an abstract idea under the mental process).” If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Therefore, claim 4 fails to correct the deficiencies of claim 1 and is rejected for similar reasoning as claim 1, above. As per claim 5, it incorporates the deficiencies of independent claim 1 upon which it depends, and further recites, “assigning the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to (analyzed under Prong II Step 2A & 2B as additional element); and applying a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability, and a buffer of a minimum number of resources that must be kept available for alternative compute processes (analyzed under Prong II Step 2A & 2B as additional element)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 5 fails to correct the deficiencies of claim 1 and is rejected for similar reasoning as claim 1, above. As per claim 6, it incorporates the deficiencies of independent claim 1 upon which it depends, and further recites, “the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 6 fails to correct the deficiencies of claim 1 and is rejected for similar reasoning as claim 1, above. As per claim 7, it incorporates the deficiencies of dependent claim 5 upon which it depends, and further recites, “wherein the ticket queue directory is user-visible, and wherein a user is enabled to create the ticket file and assign the priority to the compute process (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 7 fails to correct the deficiencies of claim 5 and is rejected for similar reasoning as claim 5, above. Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “A system for compute process shared access management, the system comprising: a hardware memory; and a hardware processor executing instructions stored in the hardware memory; wherein, when executed, the instructions cause the hardware processor to: responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, create, by the compute process, a ticket file belonging to the compute process in a ticket queue directory, wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; allow the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process; implement a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; and placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process; and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” Under Prong I Step 2A, the limitation “responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, create, by the compute process, a ticket file belonging to the compute process in a ticket queue directory” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a process is attempting to use a shared resource/data on a sheet of paper with pen or mentally based on common accessing of data/resources across a plurality of processes being submitted. Thus, the person can also then create a ticket file to place onto the ticket queue based on the previous determination of common access of shared resource/data. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “allow the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a ticket file is first in line on a sheet of paper with pen or mentally based on tracking the ticket queue. Thus, the person can also then allow the compute task to be performed since it is its turn in line. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “implement a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing …” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a resource is not available to be allocated to the ticket on the top of the queue on a sheet of paper with pen or mentally based on tracking the resource usage in a list compared to its maximum allowance. Thus, the person can make a judgement of what to do with the ticket at the front of the queue since it is its turn in line but the necessary resources are not available. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination of where to place the ticket in the queue on a sheet of paper with pen or mentally based on the priority level of the compute process associated with the ticket. Thus, the person can make a judgement of where in the queue to place the ticket if it has an increased priority level compared to other tickets already in the queue. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. This judicial exception is not integrated into a practical application. In particular under Prong II Step 2A, the claim recites the additional elements “… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; … disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” The additional element ““… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process” is simply a description of the ticket file’s components. The additional elements “disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” represent the “apply it” steps which are mere instructions to apply an exception (2106.05(f)). The claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract ideas into a practical application, the additional elements amount to mere instructions to apply an exception of executing computing instances to perform routine techniques in the technology, as discussed above, does not amount to significantly more, and is thus, not an inventive concept. Accordingly, the claim does not appear to be patent eligible under 35 U.S.C. 101. See MPEP 2106.05(f). As per claim 9, it incorporates the deficiencies of independent claim 8 upon which it depends, and further recites, “the ticket file contains information associated with the compute process, the information inclusive of at least one of a creating process identifier, a ticket creation time, a compute process priority, and a timeout threshold (analyzed under Prong II Step 2A & 2B as additional element); and an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory (analyzed under Prong II Step 2A & 2B as additional element).” These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 9 fails to correct the deficiencies of claim 8 and is rejected for similar reasoning as claim 8, above. As per claim 11, it incorporates the deficiencies of independent claim 8 upon which it depends, and further recites, “when executed, the instructions further cause the hardware processor to define a timeout threshold for the compute process, wherein, an alternative compute process is allowed to perform an alternative compute task, notwithstanding whether the ticket file belonging to the alternative process is the first in line in the ticket queue, when the timeout threshold for the compute process has been exceeded (analyzed under Prong I Step 2A as directing to an abstract idea under the mental process).” If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Therefore, claim 11 fails to correct the deficiencies of claim 8 and is rejected for similar reasoning as claim 8, above. As per claim 12, it incorporates the deficiencies of independent claim 8 upon which it depends, and further recites, “when executed, the instructions further cause the hardware processor to assign the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to (analyzed under Prong II Step 2A & 2B as additional element); and apply a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability, and a buffer of a minimum number of resources that must be kept available for alternative compute processes (analyzed under Prong II Step 2A & 2B as additional element)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 12 fails to correct the deficiencies of claim 8 and is rejected for similar reasoning as claim 8, above. As per claim 13, it incorporates the deficiencies of independent claim 8 upon which it depends, and further recites, “the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 13 fails to correct the deficiencies of claim 8 and is rejected for similar reasoning as claim 8, above. As per claim 14, it incorporates the deficiencies of dependent claim 12 upon which it depends, and further recites, “wherein the ticket queue directory is user-visible, and wherein a user is enabled to create the ticket file and assign the priority to the compute process (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 14 fails to correct the deficiencies of claim 12 and is rejected for similar reasoning as claim 12, above. Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “A computer program product for compute process shared access management, the computer program product comprising a non-transitory computer-readable storage medium having program instructions embodied thereon, the program instructions executable by a processor to cause the processor to: responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, create, by the compute process, a ticket file belonging to the compute process in a ticket queue directory, wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process , and a timeout threshold for the compute process; allow the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process; implement a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; and placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process; and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” Under Prong I Step 2A, the limitation “responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task, create, by the compute process, a ticket file belonging to the compute process in a ticket queue directory” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a process is attempting to use a shared resource/data on a sheet of paper with pen or mentally based on common accessing of data/resources across a plurality of processes being submitted. Thus, the person can also then create a ticket file to place onto the ticket queue based on the previous determination of common access of shared resource/data. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “allow the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a ticket file is first in line on a sheet of paper with pen or mentally based on tracking the ticket queue. Thus, the person can also then allow the compute task to be performed since it is its turn in line. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “implement a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing …” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination that a resource is not available to be allocated to the ticket on the top of the queue on a sheet of paper with pen or mentally based on tracking the resource usage in a list compared to its maximum allowance. Thus, the person can make a judgement of what to do with the ticket at the front of the queue since it is its turn in line but the necessary resources are not available. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Under Prong I Step 2A, the limitation “placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. A person can make the determination of where to place the ticket in the queue on a sheet of paper with pen or mentally based on the priority level of the compute process associated with the ticket. Thus, the person can make a judgement of where in the queue to place the ticket if it has an increased priority level compared to other tickets already in the queue. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. This judicial exception is not integrated into a practical application. In particular under Prong II Step 2A, the claim recites the additional elements “… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; … disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” The additional element ““… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process” is simply a description of the ticket file’s components. The additional elements “disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; … and remove, by the compute process, the ticket file from the ticket queue directory upon completing the compute task.” represent the “apply it” steps which are mere instructions to apply an exception (2106.05(f)). The claim is directed to an abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract ideas into a practical application, the additional elements amount to mere instructions to apply an exception of executing computing instances to perform routine techniques in the technology, as discussed above, does not amount to significantly more, and is thus, not an inventive concept. Accordingly, the claim does not appear to be patent eligible under 35 U.S.C. 101. See MPEP 2106.05(f). As per claim 16, it incorporates the deficiencies of independent claim 15 upon which it depends, and further recites, “the ticket file contains information associated with the compute process, the information inclusive of at least one of a creating process identifier, a ticket creation time, a compute process priority, and a timeout threshold (analyzed under Prong II Step 2A & 2B as additional element); and an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory (analyzed under Prong II Step 2A & 2B as additional element).” These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 16 fails to correct the deficiencies of claim 15 and is rejected for similar reasoning as claim 15, above. As per claim 18, it incorporates the deficiencies of independent claim 15 upon which it depends, and further recites, “wherein the program instructions executable by the processor further cause the processor to define a timeout threshold for the compute process, wherein, an alternative compute process is allowed to perform an alternative compute task, notwithstanding whether the ticket file belonging to the alternative process is the first in line in the ticket queue, when the timeout threshold for the compute process has been exceeded (analyzed under Prong I Step 2A as directing to an abstract idea under the mental process); assign the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to (analyzed under Prong II Step 2A & 2B as additional element); and apply a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability, and a buffer of a minimum number of resources that must be kept available for alternative compute processes (analyzed under Prong II Step 2A & 2B as additional element).” These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 18 fails to correct the deficiencies of claim 15 and is rejected for similar reasoning as claim 15, above. As per claim 19, it incorporates the deficiencies of independent claim 15 upon which it depends, and further recites, “the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 19 fails to correct the deficiencies of claim 15 and is rejected for similar reasoning as claim 15, above. As per claim 20, it incorporates the deficiencies of dependent claim 18 upon which it depends, and further recites, “wherein the ticket queue directory is user-visible, and wherein a user is enabled to create the ticket file and assign the priority to the compute process (analyzed under Prong II Step 2A & 2B as additional elements)”. These additional elements do not integrate the abstract idea/mental process into a practical application and is not significantly more than the judicial exception. Therefore, claim 20 fails to correct the deficiencies of claim 18 and is rejected for similar reasoning as claim 18, above. 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, 4, 6, 8, 9, 11, 13, 15, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lloyd et al. (U.S. Pub. No 2012/0078944 A1) – hereinafter “Lloyd”, in view of Sevigny (U.S. Pub. No. 2017/0132037 A1) and Jensen et al. (U.S. Patent No. 9,727,372 B2) – hereinafter “Jensen”. Regarding independent claim 1, Lloyd discloses the method comprising: creating, by the compute process, a ticket file belonging to the compute process in a ticket queue directory … ([0080] “1. The Client 110 submits a Ticket Payload to the Provider Ticket Service 102 (PTS) (FIG. 3) and receives an unique token from the PTS 102. The handler 206 checks with the Status Manager 210 whether a checksum (ticket identifier) exists for the received ticket. The handler 206 can also generate a ticket if necessary and add a new checksum or update an existing checksum (ticket identifier) and optionally the status, and passes this information to the Status Manager 210. The handler 206 can also enqueue a new ticket or update a URI endpoint.” and [0007] “The method can further include: storing, using a ticket manager, the tickets in a ticket store according to a queue; identifying a status of each of the tickets and storing an indication of the status of each of the tickets, including the selected ticket, in a ticket status table;”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket file is created/generated from a client submission and stored in the ticket store/queue. … wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process; ([0099-0102] “The ticketId field is a ticket identifier that includes an MD5 (Message-Digest algorithm 5) checksum run over the Payload portion of the Ticket 202. This ticket identifier is the identifier used to uniquely identify this particular work request in the Provider Service 100. Note that another SubmitRequest call that passes in the same Payload will result in the generation of the same ticketId value. In this way, duplicate/redundant work requests can be identified. In fact, when the Provider Ticket Service 102 first generates the Ticket 202 for newly-passed in Payload, it checks with the Status Manager 210 component of the Provider Ticket Service 102 (a component that tracks the ongoing status of each work item) to see if an identical work request (i.e. a request with the same ticketId) is already in a Ticket Store 204 component of the Provider Ticket Service 102. If so, instead of creating new structures to track a new work request, the existing structures are updated in the Status Manager 210 to reflect the fact that a new request has been made against it, and the previously-stored Ticket (in the Ticket Store 204) is updated with the URI endpoint of the new requester. If an identical request is not present in the system, new structures in the Status Manager 210 are created to track the work, and the new Ticket is stored in the Ticket Store 204 component of the PTS 102. The calculationId field is a calculation identifier corresponding to a GUID used to uniquely identify the calculation being requested. In an example implementation, the calculation identifier corresponds directly to a single Provider 208. In other implementations involving chaining of multiple Providers together, a calculation identifier can correspond to an ordered list of Providers. An XML-based configuration file which resides on the machine that hosts the PTS 102 provides these mappings that indicates a sequence order that each of the Providers in the list are to be invoked. A priority field optionally allows callers (e.g., Clients, such as the client 110) to indicate that their calculation request has higher/lower priority than other calls. The creationDateTimeUtc field refers to the date and time in UTC (Coordinated Universal Time) format at which the Ticket (not the payload) was created. This information can be used to expire requests (i.e. indicate that they have timed out).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket includes parameters including a ticket ID to identify the compute request, creation date, expiration date, and a priority field. allowing the compute process to proceed performing the compute task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory… and ([0007] “…querying the ticket store for a first one of the tickets at the front of the queue; and identifying from the first ticket at least a provider to be invoked from the plurality of providers for carrying out the calculation indicated by the calculation identifier of the first ticket.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket at the front of the queue is identified and permitted to perform its task/calculation. implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue … performing: ([0007] “The method can further include: storing, using a ticket manager, the tickets in a ticket store according to a queue; identifying a status of each of the tickets and storing an indication of the status of each of the tickets, including the selected ticket, in a ticket status table; increasing a pending ticket counter each time the status of selected ones of the tickets is identified as pending; querying the ticket store for a first one of the tickets at the front of the queue; and identifying from the first ticket at least a provider to be invoked from the plurality of providers for carrying out the calculation indicated by the calculation identifier of the first ticket.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket is first in line in the queue and ready to be scheduled for calculation. disallowing the compute task from being performed; ([0136] “If a request to cancel the ticket is received while the ticket status is pending, the status of the ticket is changed to pending-canceled.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the compute task is disallowed from being performed by changing the ticket status from pending to pending-canceled. removing the ticket file belonging to the compute process from the ticket queue directory; ([0136] “If the ticket is canceled, the Ticket Manager 206 removes the ticket from the Ticket Store 204.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket is canceled and removed from the ticket store/queue. creating a new ticket file for the compute process; and ([0136] “Once in the failed state, the Ticket Manager 206 can resubmit the ticket to retry the calculation, in which case the ticket's status is changed back to pending and placed in the pending queue.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket file is resubmitted. placing the new ticket file in the ticket queue of the ticket queue directory. ([0136] “Once in the failed state, the Ticket Manager 206 can resubmit the ticket to retry the calculation, in which case the ticket's status is changed back to pending and placed in the pending queue.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket is again placed into the ticket queue. removing, by the compute process, the ticket file from the ticket queue directory upon completing the compute task. ([0009] “The method can further include, responsive to returning the result to the client associated with the selected ticket, deleting the selected ticket from the ticket store and deleting the status of the selected ticket from the ticket status table.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket is removed from the queue/store following the completion of the task and returning of result to the client. Lloyd does not explicitly disclose: responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task… … determining that the ticket file is first in line in a ticket queue … according to a ticket ordering algorithm independently applied by the compute process; implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process. However, Sevigny discloses: responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task… ([0021] “Some operating systems use memory locking to prevent simultaneous access to a shared memory location (e.g., a data structure such as a job queue). An operating system memory lock (or just “lock”), such as a mutex or a semaphore, is a synchronization mechanism that may be used to manage access to the shared memory location for multiple actors (e.g., multiple threads of execution that each use the shared memory location). For example, a lock may be given by the operating system (OS) to an application thread (referred to herein simply as a thread) so that the thread can have exclusive access to the shared memory location (e.g., the data structure) until the thread is done using that memory location.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the shared access of resources such as a shared memory location is locked to ensure singular access by the thread at the time of usage which is necessary to perform a compute task. … determining that the [job group] is first in line in a [job group] queue … according to a [job group] ordering algorithm independently applied by the compute process; ([0038] “When a job group 242 is received by the job scheduler 230, it is placed in the job group queue 232. The queue 232 is a first in/first out (FIFO) style queuing data structure and algorithm (e.g., illustrated from left to right in FIG. 2), although this queuing algorithm is modified as described herein (e.g., with stealing). The job scheduler 230 removes job groups 242 from the output side of the queue and resolves any dependencies before placing the jobs (e.g., from the associated job list 244) on the execution stack 236. The stack 236 is a last in/first out (LIFO) style data structure and algorithm, optionally modified as described herein. Jobs 246 are taken off the stack and executed by a processor 210, after which they are marked as finished.”); The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the job groups are placed into job group queues and are removed based on the FIFO ordering algorithm of the queue and LIFO ordering algorithm of the stack. The claimed invention’s limitation is derived from the combining of the concept of determining a job group is first in line in a queue according to a job group ordering algorithm in the secondary reference with the concept of allowing the compute process to perform the compute task based upon determining a ticket is first in line in a ticket queue in the primary reference. Thus, the idea of allowing the compute process to proceed performing the computing task upon determining that the ticket file is first in line in a ticket queue of the ticket queue directory, according to a ticket ordering algorithm independently applied by the compute process is taught by the primary reference with support from the secondary reference. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add responsive to a compute process determining that access to at least one of shared resources and shared data is necessary to perform a compute task and … determining that the [job group] is first in line in a [job group] queue … according to a [job group] ordering algorithm independently applied by the compute process as seen in Sevigny’s invention into Lloyd’s invention because these modifications allow access of shared resources to be ensured to be by one compute process at a time for the sake of data integrity and reordering tickets based on an algorithm until they are first in line. In addition, Jensen discloses: implementing a resource allocation policy constraining the [queue], wherein, responsive to determining that the [job] is the first in line in the [queue] however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: (Col. 5, Line 65 – Col. 6, Line 10 “The MJS bases its determination on when to schedule jobs based on resource utilization, in one embodiment. As an example, the MJS may analyze disk activity. If an application other than the application with the micro-job is using the disk, then the MJS waits until the other application is done to schedule the micro-job. The MJS continues to monitor the disk I/O utilization, and allows another micro-job to be scheduled if no other application is seeking access to disk I/O. However, if another application seeks utilization of disk I/O, then the MJS will not allow another micro-job to be scheduled, wherein the other application can utilize the disk I/O.”) (Col. 5, Line 65 – Col. 6, Line 10 “The MJS bases its determination on when to schedule jobs based on resource utilization, in one embodiment. As an example, the MJS may analyze disk activity. If an application other than the application with the micro-job is using the disk, then the MJS waits until the other application is done to schedule the micro-job. The MJS continues to monitor the disk I/O utilization, and allows another micro-job to be scheduled if no other application is seeking access to disk I/O. However, if another application seeks utilization of disk I/O, then the MJS will not allow another micro-job to be scheduled, wherein the other application can utilize the disk I/O.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket/micro-job is ready to be scheduled, but is not scheduled as there are not enough resources available at the current point in time. Another micro-job is allowed to jump the current first ticket/micro-job to be scheduled in the meantime. The claimed invention’s limitation is derived from the combining of the concept of determining that performing a job that is first in line in the queue would violate the resource allocation policy currently in the secondary reference with the concept of implementing a resource allocation policy that constrains the ticket queue directory and performing specific predetermined actions when the ticket file is first in line in the queue in the primary reference. Thus, the idea of implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing is taught by the primary reference with support from the secondary reference. placing the new [job group] in the [job group] queue … according to the [job group] ordering algorithm applied by the compute process. ([0038] “When a job group 242 is received by the job scheduler 230, it is placed in the job group queue 232. The queue 232 is a first in/first out (FIFO) style queuing data structure and algorithm (e.g., illustrated from left to right in FIG. 2), although this queuing algorithm is modified as described herein (e.g., with stealing). The job scheduler 230 removes job groups 242 from the output side of the queue and resolves any dependencies before placing the jobs (e.g., from the associated job list 244) on the execution stack 236. The stack 236 is a last in/first out (LIFO) style data structure and algorithm, optionally modified as described herein. Jobs 246 are taken off the stack and executed by a processor 210, after which they are marked as finished.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the job groups are placed into job group queues based on the FIFO ordering algorithm of the queue and LIFO ordering algorithm of the stack and can be place differently for reasons such as stealing another job group’s place. The claimed invention’s limitation is derived from the combining of the concept of placing a job group in the queue according to a job group ordering algorithm in the secondary reference with the concept of placing new tickets into ticket queues in the primary reference. Thus, the idea of placing the new ticket file in the ticket file queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process is taught by the primary reference with support from the secondary reference. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add implementing a resource allocation policy constraining the [queue], wherein, responsive to determining that the [job] is the first in line in the [queue] however allowing the compute process to be performed would violate the resource allocation policy at a current point in time and placing the new [job group] in the [job group] queue … according to the ticket ordering algorithm applied by the compute process as seen in Jensen’s invention into Lloyd’s invention because these modifications allow a ticket to be jumped in the queue if the ticket at the head of the queue would violate the currently available resources to maintain efficient utilization of available resources and placing tickets into a queue position based on algorithmic decisions like priority and resource type usage. Regarding claim 2, Lloyd discloses the method of claim 1, wherein: the ticket file contains information associated with the compute process, the information inclusive of at least one of a creating process identifier, a ticket creation time, a compute process priority, and a timeout threshold; and ([0090] “1. The Client 110 submits a Ticket Payload and the Provider Ticket Service 102 receives the Payload (see FIG. 3). In this example, a "Ticket Payload" describes a calculation that needs to be performed and can be, for example, an XML fragment or JSON string. A payload can take almost any form as long as the Provider plug-in it is intended for knows how to interpret its information. In this example, a "Ticket" is a well-formed XML document that wraps one or more Ticket Payloads, and provides additional "housekeeping" information about the request, such as the date and time of the request.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket files contains information including a ticket creation time. Lloyd does not explicitly disclose: an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory. However, Sevigny discloses: an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory. ([0028] “The job scheduler and methods described herein are designed such that the order of evaluation is under the control of the user (e.g., the developer, or a game player). This enables the job scheduler to adapt itself dynamically (e.g., using job stealing).” and [0075] “…the execution stack 236 is a LIFO structure and, as such, the queue is an ordered set of jobs (e.g., each of the jobs from the illustrated groups), where the top-most group in the stack 236 represents the top-most jobs. The jobs on the stack 236 are handled as individual jobs. In other words, they may be picked up by different threads and may be sent to different processors for execution. The job scheduler 230 may track the jobs of a particular job group 242 (e.g., with the job counter and generation counter).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the job scheduler adapts dynamically and allows different jobs to be picked for different processors from the ticket queue. The ordering algorithm of the LIFO stack and ordered queue are based on ticketing information. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add an ordering of the ticket queue directory is based on a deterministic function of the information according to the ticket ordering algorithm respectively applied by each ticket file in the ticket queue directory as seen in Sevigny’s invention into Lloyd’s invention because these modifications allow ticket information to decide the ordering of the ticketing queue that leads to the completion of computing tasks. Regarding claim 4, Lloyd discloses the method of claim 1, further comprising: defining a timeout threshold for the compute process, wherein, an alternative compute process is allowed to perform an alternative compute task, notwithstanding whether the ticket file belonging to the alternative process is the first in line in the ticket queue, when the timeout threshold for the compute process has been exceeded. ([0136] “While a ticket's status is in-progress, if an error occurs, for example a timeout limit is reached for completing the calculation, the ticket's status is changed to failed. Once in the failed state, the Ticket Manager 206 can resubmit the ticket to retry the calculation, in which case the ticket's status is changed back to pending and placed in the pending queue. Alternately, the Ticket Manager 206 can remove a failed ticket from the Ticket Store 204 and notify the client 110 of the removal and optionally the reason for the failure.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the timeout limit is reached for a ticket, so the ticket can be removed as a failed ticket from the store/queue and move onto the next ticket in the queue. Regarding claim 6, Lloyd discloses the method of claim 1, but does not explicitly disclose: the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes. However, Sevigny discloses: the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes. ([0041] “The job scheduler 230 creates and transmits a ticket to the application that submitted the job group 242. The ticket includes the memory location of the job group 242 (e.g., the memory location of the container for the job group 242) and a “ticket value” at which the group will be considered finished (also referred to herein as the “finished generation count”). The finished generation count for a group may be, for example, the starting generation count+2. The ticket and the generation count are used to track the state of the job group 242 as it passes through the job scheduler 230.” and [0032] “The job group queue 232 may include one or more job groups (or just “groups”) 242, such as “Group A” through “Group N”. Each group 242 includes an associated job list 244, where each job list 244 identifies one or more jobs 246 of the associated group 242. The execution stack (or just “stack”) 236 includes jobs from one or more of the groups 242 (e.g., the jobs 246 from the job lists 244 associated with each group 242, with each group 242 having one or more jobs 246).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket relating to a job is stored local to the compute process based on transmission from the job scheduler and the jobs are shared with all processes based on the job group queue. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add the ticket file is an empty file stored in a common writable directory and visible to all other operating processes; or the ticket file is stored local to the compute process and is shared with all other operating processes as seen in Sevigny’s invention into Lloyd’s invention because these modifications allow tickets to be stored and visible to all processes so that they can judge where their ticket is in the queue. Regarding claim 8, it is a system claim having the same limitations as cited in method claim 1. Thus, claim 8 is also rejected under the same rationale as addressed in the rejection of claim 1 above. Regarding claim 9, it is a system claim having the same limitations as cited in method claim 2. Thus, claim 9 is also rejected under the same rationale as addressed in the rejection of claim 2 above. Regarding claim 11, it is a system claim having the same limitations as cited in method claim 4. Thus, claim 11 is also rejected under the same rationale as addressed in the rejection of claim 4 above. Regarding claim 13, it is a system claim having the same limitations as cited in method claim 6. Thus, claim 13 is also rejected under the same rationale as addressed in the rejection of claim 6 above. Regarding claim 15, it is a product claim having the same limitations as cited in method claim 1. Thus, claim 15 is also rejected under the same rationale as addressed in the rejection of claim 1 above. Regarding claim 16, it is a product claim having the same limitations as cited in method claim 2. Thus, claim 16 is also rejected under the same rationale as addressed in the rejection of claim 2 above. Regarding claim 19, it is a product claim having the same limitations as cited in method claim 6. Thus, claim 19 is also rejected under the same rationale as addressed in the rejection of claim 6 above. Claims 5, 7, 12, 14, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lloyd et al. (U.S. Pub. No 2012/0078944 A1) – hereinafter “Lloyd” and Sevigny (U.S. Pub. No. 2017/0132037 A1) – hereinafter “Sevigny”, further in view of Jensen et al. (U.S. Patent No. 9,727,372 B2) – hereinafter “Jensen” and Walsh et al. (U.S. Pub. No. 2018/0095803 A1) – hereinafter “Walsh”. Regarding claim 5, Lloyd discloses the method of claim 1, but does not explicitly disclose: assigning the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to; and applying a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability, and a buffer of a minimum number of resources that must be kept available for alternative compute processes. However, Sevigny discloses: assigning the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to; ([0034] “For example, in some known priority queues, each job has a priority setting (e.g., often an integer), and the priority setting is used to identify a relative importance of the job to other jobs in the queue. When a job is picked to run off of the queue, the relative priority settings of all of the jobs on the queue may influence which job gets selected (e.g., the job with the highest priority setting on the queue may be selected).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the process class assigning a priority level to the ticket is set based on the class/job and the priority level is used to identify an importance of the job in comparison to other jobs in the queue. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add assigning the compute process to one of a plurality of process classes defined for the ticket queue directory, wherein the ticket ordering algorithm factors in a priority assigned to the compute process according to which of the plurality of process classes the compute process is assigned to as seen in Sevigny’s invention into Lloyd’s invention because these modifications allow the class of the process to be linked with the priority of the process such that processes in the queue are selected based on more than just the position in the queue. However, Jensen discloses: applying a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability… (Col. 2, Lines 9-17 “As previously mentioned, running the computing job can interfere with a user's ability to use the computer and can take resources away from other, possibly more pressing applications and jobs. Throttling is a technique for minimizing these negative impacts. Throttling prevents an application or job from using more than an allocated amount of resources. Types of throttling include disk I/O throttling, CPU throttling and network throttling.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the resource throttling consists of a compute task/application/job having a limit of allocated resources that it cannot exceed. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add applying a resource throttling policy to the compute process, wherein the resource throttling policy consists of a dynamic limit of resources available for use by the compute process to perform the compute task relative to a total resource availability as seen in Jensen’s invention into Lloyd’s invention because these modifications allow a limit of resources available to a computing task such that a plurality of computing tasks can be executed on the same grouping of physical resources. In addition, Walsh discloses: … a buffer of a minimum number of resources that must be kept available for alternative compute processes. (Fig. 2, Fence 230 and [0030] “In one embodiment, the fence portion of the resource is closely monitored and is used for handling unpredicted loads. If, for example, there is a spike in load and the native process requires some of the memory within the fence portion, the resource allocation mechanism can take action by emptying the allocated (60 GB) portion of the resource (e.g., by copying data to another resource or deleting the data).” and [0041] “The resource allocation fence is determined for the available portion of the sharable resource, 320. As described above, the resource allocation fence is the portion of the available sharable resource that is reserved as a buffer between the portion of the sharable resource used by the native process and the portion of the sharable resource that is to be allocated to one or more other processes.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the fence is a buffer of minimum resources that are kept available for alternative compute processes such as a spike in load for compute processes that need to be handled. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add a buffer of a minimum number of resources that must be kept available for alternative compute processes as seen in Walsh’s invention into Lloyd’s invention because these modifications allow a plurality of computing tasks to be executed on the same grouping of physical resources regardless of unexpected increases in resource usage. Regarding claim 7, Lloyd discloses the method of claim 5, but does not explicitly disclose: wherein the ticket queue directory is user-visible, and wherein a user is enabled to create the ticket file and assign the priority to the compute process. However, Sevigny discloses: wherein the ticket queue directory is user-visible, ([0042] “The state of a job group 242 and the value of the generation counter for that job group 242 may be linked to the ticket value for that job group. More specifically, when the generation counter is two less than the ticket value (e.g., generation counter=ticket value−2), then the job group 242 is in the queued state (e.g., the job group 242 is in the job group queue 232). When the generation counter is one less than the ticket value (e.g., generation counter=ticket value−1), then the job group 242 is in the pushed state (e.g., the job group 242 has been dequeued or stolen and it is in one of three places: on the stack, waiting to get on the stack, or being executed by a CPU 210). When the generation counter is equal to the ticket value (e.g., generation counter=ticket value), then the job group 242 is in the finished state (e.g., the job group 242 has left the stack and has been executed by a CPU).”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the ticket queue is user-visible based on the usage of counters to track the current status of a ticket as it moves in state from queued to pushed to finished. and wherein a user is enabled to create the ticket file and assign the priority to the compute process. ([0045] “1. Receiving a work request "Payload" (such as in the form of an XML fragment or JSON string) via a WCF call from a client, such as the gadget 110, requesting a calculation to be performed, embedding this Payload into a "Ticket" 202 (a properly-formed XML document) and returning a unique Ticket identifier (a GUID string) to the client as a token.” and [0101] “A priority field optionally allows callers (e.g., Clients, such as the client 110) to indicate that their calculation request has higher/lower priority than other calls.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the work request creates a ticket for a compute process and assigns a priority ranking to the process. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the ticket queue directory is user-visible, and wherein a user is enabled to create the ticket file and assign the priority to the compute process as seen in Sevigny’s invention into Lloyd’s invention because these modifications allow public access of the queue such that a user can track the progress of a task and assign priority to tasks to get the more important ones finished ahead of others, such as if other tasks depend on a particular task giving it the highest level of priority. Regarding claim 12, it is a system claim having the same limitations as cited in method claim 5. Thus, claim 12 is also rejected under the same rationale as addressed in the rejection of claim 5 above. Regarding claim 14, it is a system claim having the same limitations as cited in method claim 7. Thus, claim 14 is also rejected under the same rationale as addressed in the rejection of claim 7 above. Regarding claim 18, it is a product claim having the same limitations as cited in method claims 4 and 5. Thus, claim 18 is also rejected under the same rationale as addressed in the rejection of claims 4 and 5 above. Regarding claim 20, it is a product claim having the same limitations as cited in method claim 7. Thus, claim 20 is also rejected under the same rationale as addressed in the rejection of claim 7 above. Response to Arguments Applicant's arguments filed 08/12/2025 have been fully considered but they are not persuasive. The Examiner notes that as mentioned on the first page of the remarks, the independent claims 1, 8, and 15 have been amended and claims 3, 10, and 17 have been cancelled. The Examiner respectfully disagrees with the statements made under section “Claim Rejection – 35 USC § 101” on Remarks pages 19-23. First, the Attorney states that the claims are directed to “clear improvements to computer-related technology”, but the Examiner respectfully disagrees. The adaptation of ticketing systems used to attend to customers at a bakery implemented in a computer ticketing queue is something that can be seen in many queues whether it be in real world environments or in different computing systems such as print jobs, OS scheduling, network protocols, etc. Next, the Attorney states that the claims are not directed to a judicial exception because “the alleged abstract idea is integrated into a practical application.” The majority of the additional elements of the independent claims are considered as “apply it” steps. Finally, the Attorney states that the claims “recite an inventive concept”, but the Examiner respectfully disagrees as the features in the pending claims recite abstract ideas and additional elements reciting “apply it” steps. Thus, the rejections under 35 U.S.C. § 101 regarding independent claims 1, 8, and 15 will remain. Finally, the dependent claims from independent claims 1, 8, and 15 do not fix the problem of directing the claims to an abstract idea, and thus their rejections under 35 U.S.C. § 101 will remain, so claims 1-2, 4-9, 11-16, and 18-20 will remain rejected under 35 U.S.C. § 101. The Examiner respectfully disagrees with the statements made under section “Claim Rejections – 35 USC § 103” on Remarks page 23-25. The Attorney states that the amendment to independent claims 1, 8, and 15 that incorporate the features of claim 3 including “... implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing: disallowing the compute task from being performed; removing the ticket file belonging to the compute process from the ticket queue directory; creating a new ticket file for the compute process; and placing the new ticket file in the ticket queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process” and ticket file composition including “… wherein the ticket file includes an identifier of the compute process, a creation time of the ticket file, a priority level of the compute process, and a timeout threshold for the compute process.” The ticket file composition has been rejected via Lloyd [0099-0102] which contains a description of ticket parameters including a ticket ID to identify the compute request, creation date, expiration date, and a priority field. The rejection of the former claim 3 claimed language is rejected with the obvious combination of Lloyd and Jensen. Lloyd discloses the concept of implementing a resource allocation policy that constrains the ticket queue directory and performing specific predetermined actions when the ticket file is first in line in the queue and Jensen discloses the concept of determining that performing a job that is first in line in the queue would violate the resource allocation policy currently so they jointly teach implementing a resource allocation policy constraining the ticket queue directory, wherein, responsive to determining that the ticket file belonging to the compute process is the first in line in the ticket queue however allowing the compute process to be performed would violate the resource allocation policy at a current point in time, performing …” In addition, Lloyd and Jensen combine to create an obviousness rejection of “placing the new ticket file in the ticket file queue of the ticket queue directory according to the ticket ordering algorithm applied by the compute process” because Lloyd discloses the concept of placing new tickets into ticket queues, while Jensen discloses the concept of placing a job group in the queue according to a job group ordering algorithm. Therefore, the independent claims 1, 8, and 15 remain rejected under 35 USC § 103. Finally, the independent claims 1, 8, and 15 and the dependent claims relying on them are still rejected with respect to being unpatentable and thus, claims 1-2, 4-9, 11-16, and 18-20 will remain rejected under 35 U.S.C. § 103. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Taylor (U.S. Pub. No. 2013/0198358 A1) discloses ticket creation based on user input and a ticket queue that handles priority level and expiration timers similar to as described in this invention. THIS ACTION IS MADE FINAL. 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 DANIEL B TRAINOR whose telephone number is (571)272-3710. The examiner can normally be reached Monday-Friday 9AM-5PM. 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, Chat Do can be reached at (571) 272-3721. 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. /D.T./Examiner, Art Unit 2193 /Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Show 9 earlier events
Dec 03, 2025
Response after Non-Final Action
Jan 05, 2026
Request for Continued Examination
Jan 22, 2026
Response after Non-Final Action
Feb 23, 2026
Non-Final Rejection mailed — §101, §103
Mar 10, 2026
Interview Requested
Mar 31, 2026
Examiner Interview Summary
Mar 31, 2026
Applicant Interview (Telephonic)
Apr 13, 2026
Response Filed

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12639120
MANAGING USAGE OF RESOURCES IN A HYBRID COMPUTING ENVIRONMENT
3y 10m to grant Granted May 26, 2026
Patent 12632275
FAIR AND EFFICIENT GUEST TO HYPERVISOR VIRTUAL MACHINE SOCKET PROTOCOL
3y 10m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 2 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
100%
Grant Probability
99%
With Interview (+0.0%)
3y 3m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 10 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month