DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant Amendment and Arguments filed on 04 December, 2025.
Claims 1, 3-6, 8-9, 11-15, 17-18 and 20 are pending in this application. Claims 2, 7, 10, 16 and 19 were cancelled.
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.
Claims 1, 3-6, 8-9, 11-15, 17-18 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1, Statutory Category: Yes, the claim 1 is a computer-implemented method that recites a series of steps and therefore falls in the statutory category of a process.
Step 2A- Prong 1: Judicial Exception Recited: Yes, the claim recites: “analyzing the transaction request based on a transaction record and a current server capacity metric to determine a handling action for handling the transaction request; monitoring a plurality of transactions processed by the transaction server; generating a new transaction record based on the server resource required to process the plurality of transactions and creating a queue of transaction requests based on the received transaction request, wherein the queue of transaction requests contain a maximum queue time restriction and maximum length of queue restriction and new transaction record becomes part of the transaction record; classifying the transaction request based on the analyzing of the transaction request; adding the classified transaction request to the transaction record, monitoring the server resource of the transaction server; determining the handling action for handling the transaction request in the queue transaction requests based on a classification of the transaction request further comprising: determining when a heavy weight transaction can be processed by the transaction server based on the monitoring of the server resource, monitoring the server resource of the transaction server; determining whether the heavy weight transaction can be processed concurrently with a light weight transaction by the transaction server based on the monitoring of the server resource.”. As drafted, the claim as a whole recites a computer-implemented method including steps that could be performed in the human mind, but for the recitation of generic computing components. The human mind can easily judging/evaluating/analyzing the transaction request based on a historical transaction record (i.e., historical resource usage) and current server system resource availability (i.e., a current server capacity metric) to determining/judging/evaluating if the current server system resources are sufficient to meet the requirement of the transaction request based the historical transaction resource usage for scheduling/handling the transaction requests based on the determination, monitoring/looking/evaluating the transactions that is processed in order to generating/writing/creating (i.e., by pen and paper) a transaction record based on the resource required, then classifying/grouping the transaction requests based on the analyzing, adding (by pen and paper) the classified transaction request to the transaction record, monitoring/determining the current resources, and determining/judging/evaluating the handling action (i.e., scheduling action) for processing the transaction request based on previous classifying, such that if the resource is enough for processing a heavy weight transaction and if it has enough resources based on the monitoring, determining that heavy weight transaction can be processed concurrently with a light weight transaction. Therefore, but for the recitation of generic computing components, these steps may be a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Therefore, yes, the claims do recite judicial exceptions.
Step 2A- Prong 2: Integrated into a practical Application: No, this judicial exception is not integrated into a practical application. In particular, the claim recites an additional limitations that “A computer-implemented method for handling a transaction request” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, “a transaction request received at a transaction server” and “responsive to receiving the transaction request at the transaction server” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). Moreover, “wherein the transaction request comprises a request for the transaction server to perform a transaction” and “a transaction record, which comprises a historical record of a server resource required to perform the transaction” and “wherein the historical record comprise of one record per transaction ID (identification) and each of the one record comprises of entries for critical resource footprints, which includes, peak virtual storage usage, total CPU (Computer Process Unit) usage, duration of transaction and TCB (Task Control Block) usage” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)) and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Further, the claimed limitation of “processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests” and “processing the heavy weight transaction concurrently with the light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) (The claim does not define any particular machine to “cause” this “transaction” other than a generic machine such as the “transaction server,” and no details what so ever on how the claimed function will occur). The combination of these additional elements is no more than mere instructions to apply the exception using a generic computer component (MPEP 2106.05(f)). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept: No. The additional elements “wherein the transaction request comprises a request for the transaction server to perform a transaction” and “a transaction record, which comprises a historical record of a server resource required to perform the transaction” and “wherein the historical record comprise of one record per transaction ID (identification) and each of the one record comprises of entries for critical resource footprints, which includes, peak virtual storage usage, total CPU (Computer Process Unit) usage, duration of transaction and TCB (Task Control Block) usage” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)) and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, the claimed limitation of “processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests” and “processing the heavy weight transaction concurrently with the light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) (The claim does not define any particular machine to “cause” this “transaction” other than a generic machine such as the “transaction server,” and no details what so ever on how the claimed function will occur). Moreover, the claimed limitation “A computer-implemented method for handling a transaction request” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Further, the limitation “a transaction request received at a transaction server” and “responsive to receiving the transaction request at the transaction server” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)) and they are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the “receiving” step was considered to be extra-solution activity in Step 2A as insignificant pre-solution data gathering which are well understood, routine, conventional activity in the field. The “receiving” step is for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that the receiving is well understood, routine, conventional activity is supported under Berkheimer options 2.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
Independent claims 15 and 18 are rejected for the same reason as claim 1 above. In addition, independent claim 15 further recites “A computer program product for handling a transaction request by way of a transaction server” and “the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processing unit to cause the processing unit to perform a method” and independent claim 18 further recites “A processing system for handling a transaction request by way of a transaction server” and “the system comprising: one or more computer processors; one or more non-transitory computer readable storage media; program instructions stored on the one or more non-transitory computer readable storage media for execution by at least one of the one or more computer processors, the program instructions to perform the steps of”. These additional elements are directed to generic computing components/Functions (MPEP § 2106.05(b) merely applying the abstract idea (MPEP § 2106.05(f)).
With respect to the dependent claim 3, the claim elaborates that wherein the transaction record comprises one or more transaction classifications (“wherein the transaction record comprises one or more transaction classifications” as being treated as directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))).
With respect to the dependent claims 4-6, the claim 4 elaborates that wherein generating the transaction record comprises classifying each of the plurality of transactions according to the one or more transaction classifications, wherein the one or more transaction classifications comprise: the heavy weight transaction; and a light weight transaction. The claim 5 elaborates that wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction exceeds a resource threshold. And the claim 6 elaborates that wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold. (“classifying each of the plurality of transactions” into a heavy weight transaction and a light weight transaction based on “resource threshold” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind (i.e., grouping/classifying the transactions). In addition, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion)).
With respect to the dependent claim 8, the claim elaborates that wherein determining the handling action for handling the transaction request based on the classification of the transaction request comprises: if the transaction request is classified as a light weight transaction, wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold, processing the transaction request; and if the transaction request is classified as a heavy weight transaction, wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction does exceed a resource threshold, queueing the transaction request (“if the transaction request is classified as a heavy weight transaction… queueing the transaction request” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind (i.e., scheduling/queueing the transaction request)).
With respect to the dependent claims 9 and 11, the claim 9 elaborates that wherein the computer-implemented method further comprises: monitoring the server resource of the transaction server; determining when a heavy weight transaction can be processed by the transaction server based on the monitoring of the server resource; and processing the transaction request, which has been queued, based on the determining when a heavy weight transaction can be processed. The claim 11 elaborates that wherein a plurality of transaction requests are received at the transaction server, the plurality of transaction request comprising one or more heavy weight transactions and one or more light weight transactions, and wherein the method further comprises: monitoring the server resource of the transaction server; determining whether the one or more heavy weight transactions can be processed concurrently with the one or more light weight transaction by the transaction server based on the monitoring of the server resource; and processing the one or more heavy weight transactions concurrently with the one or more light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction (“monitoring” and “determining” in claims 9 and 11 are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind. In addition, the claim as a whole is a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion). In addition, “processing” in claims 9 and 11 which are merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) (The claim does not define any particular machine to “cause” this “transaction” other than a generic machine such as the “transaction server,” and no details what so ever on how the claimed function will occur).
With respect to the dependent claim 12, the claim elaborates that wherein the server resource comprise one or more of: a memory usage metric; a peak memory usage metric; a trusted computing base usage metric; a processing time; and a processor usage metric (the server resource comprise different usage metrics as being treated as directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))).
With respect to the dependent claim 13, the claim elaborates that wherein the current server capacity metric comprises one or more of: a number of current transactions currently being processed; a memory usage metric; a processor usage metric; and a number of transaction requests in a queue (“current server capacity metric” comprises a number of current transactions currently being processed and different of usage metrics as being treated as directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))).
With respect to the dependent claim 14, the claim elaborates that wherein the handling action comprises one or more of: processing the transaction request; rejecting the transaction request; verifying the transaction request; and routing the transaction request (“handling action comprises one or more of”, “verifying the transaction request; and routing the transaction request” as being treated as part of abstract idea and is analogous to Mental processes (i.e., scheduling/queueing, verifying/evaluating, routing/scheduling), such that concept can be performed in the human mind).
Dependent claims 17 and 20 recite the same features as applied to claim 8 respectively above, therefore they are also rejected under the same rationale.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-4, 12, 14-15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al. (US Patent. 9,389,916 B1) in view of Shmuylovich et al. (US Patent. 7,600,229 B1) and further in view of Barnett et al. (US Pub. 2008/0270526 A1), Ash et al. (US Pub. 2019/0339897 A1), Park et al. (US Pub. 2020/0311045 A1) and Banks et al. (US Patent. 5,901,334).
Miller, Shmuylovich, Barnett, Ash, Park and Banks were cited in the previous Office Action.
As per claim 1, Miller teaches the invention substantially as claimed including A computer-implemented method for handling a job request received at a server, wherein the job request comprises a request for the server to perform a job (Miller, Fig. 3, 302 receive batch job; Col 9, lines 33-37, FIG. 3 is a flowchart illustrating a method 300…at block 302 the method 300 may include receiving a particular job (e.g., batch job) from a user; Col 14, lines 42-46, the computer system 500 is a multi-user mainframe computer system…or a server computer…receives requests from other computer systems (clients); also see Fig. 2, 210 performing the first job), the method comprising:
responsive to receiving the job request at the server, analyzing the job request based on a job record, which comprises a historical record of a server resource required to perform the job, and a current server capacity metric to determine a handling action for handling the job request (Miller, Fig. 3, 302, 304 Verification that resources are available, collection of system data (as current server capacity metric), 306 check for/collect the summary records for previous job, 308 determination of system resources used in previous instances, 310, 312, 314 and 318 (as determine a handling action); Col 9, lines 45-59, at block 304 the method 300 includes collecting system architecture limitation information for the computer system…The system architecture limitation information may indicate the total available resources that can be provided by the hardware of the computer system (e.g., maximum CPU MIPS, maximum device I/O throughput) (as a current server capacity metric); Col 10, lines 1-7, at block 306 the method 300 can collect summary records for previous executions of the particular job. The summary records may indicate the system resources utilized by the particular job (e.g., resource allocation for the particular job), as well as the duration of time (e.g., number of intervals) used for previous executions of the particular job; Col 10, lines 17-21, collect summary records for the particular job that satisfy a recency criterion. The recency criterion may be a period of time during which the summary records of the particular job are determined to be a valid indication of the resources required by the particular job; also see Col 10, line 62-Col 11, line 6, the system may determine whether or not the system architecture limitations are exceeded by the total system resource utilization estimation…in response to determining that the system limitations are not exceeded by the total system resource utilization estimation, the method 300 may proceed to block 314. If a specific date or time is requested for execution of the particular job at block 314, the particular job may be held in a wait queue at block 318 until the requested date or time is reached. If no specific date or time is requested, the method 300 may proceed to block 316 and perform the particular job (as determine a handling action for handling the job request)).
monitoring a plurality of jobs processed by the job server (Miller, Col 2, lines 41-47, The resource utilization data may be collected using a set of performance monitors. The resource utilization data may include performance records for a set of jobs. In certain embodiments, the resource utilization data may include historical resource utilization data as well as current resource utilization data for the set of system components; Col 14, lines 42-46, the computer system 500 is a multi-user mainframe computer system…or a server computer…receives requests from other computer systems (clients); also see Fig. 2, 210 performing the first job);
generating a new job record based on the server resource required to process the plurality of jobs, and creating a queue of job requests based on the received job request and the new job record becomes part of the job record (Miller, Fig. 4, 422 summary record location, 427 aggregate summary record generation (as new job record becomes part of the job record); Col 5, lines 35-52, the resource utilization data may include performance records for a set of jobs…the resource utilization data may include performance records for the set of jobs. The performance records may include data regarding the time, date, duration, memory address space, resource usage, and execution status of each job of the set of jobs (e.g., a particular job began on Tuesday March 19th at 4:00 PM, ran for 30 minutes, used 10 CPU MIPS, was executed in a first designated memory address space, and completed successfully). Col 2, lines 58-63, identifying the resource allocation for the particular job may include locating a set of summary records corresponding to a set of execution instances of the particular job. The summary records may include a job execution status and historical resource usage data for the set of execution instances of the particular job; Col 10, lines 11-15, the particular job may not have been executed in the last week, and thus summary records for the last week may not be available. Accordingly, in such situations, the method 300 may proceed to block 316 and continue with execution of the particular job (as the jobs are not processed yet, so the usage data will be collected to create new job record for later use); Col 7, lines 51-57, generating a set of aggregate summary records (as created new job record becomes part of the job record) regarding the set of address spaces. The aggregate summary records may be comprehensive or cumulative reports that include data regarding previous jobs that have been executed in each respective address space, as well as the execution status and resource usage of those jobs; Col 9, lines 50-66, collect a history of statistic intervals regarding the system resources used when writing to each address space of the computer system. In certain embodiments, the information may be collected by a batch monitoring parameter “Batchmon” configured to organize the information gathered by existing performance monitors. The system architecture limitation information may indicate the total available resources that can be provided by the hardware of the computer system (e.g., maximum CPU MIPS, maximum device I/O throughput). In certain embodiments, the system architecture limitation information may be collected from the recorded data on the previous usage of address spaces of the system components using a performance monitor independent of existing system performance monitors such as a batch monitor address space (BMAS). At block 304 the method 300 may also include querying the system to collect address space reports that indicate the address spaces that are currently being used for job execution; Col 11, lines 7-21, in response to determining that the system limitations are exceeded by the total system resource utilization estimation...determine the system resources used to execute a job on each address space for previous batch job execution instances…if the date and time requested for rescheduling of the particular job exceeds the first duration threshold (e.g., 24 hours), the method 300 may proceed to block 314 and place the particular job in a hold queue for later rescheduling (as including creating the queue of job requests).
Miller fails to specifically teach the job request is transaction request, the job is transaction, the transaction request received at a transaction server, classifying the transaction request based on the analyzing of the transaction request; adding the classified transaction request to the transaction record; monitoring the server resource of the transaction server; determining the handling action for handling the transaction request in the queue transaction requests based on a classification of the transaction request further comprising: determining when a heavy weight transaction can be processed by the transaction server based on the monitoring of the server resource; processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests; monitoring the server resource of the transaction server; determining whether the heavy weight transaction can be processed concurrently with a light weight transaction by the transaction server based on the monitoring of the server resource; and processing the heavy weight transaction concurrently with the light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction.
However, Shmuylovich teaches the job request is transaction request, the job is transaction, the transaction request received at a transaction server (Shmuylovich, Fig. 1, 130 management server computer system (as transaction server); Col 4, lines 14-18, The load manager (i.e., within the Fig. 1, 130) receives the store assignment request from the agent and assigns, using load-balancing techniques explained herein, a store process (i.e., of the plurality of operating and available store processes) for the agent to use to perform the agent transaction; Col 10, lines 15-17, the load manager 135 receives a store assignment request 181 from an agent 155 that has an agent transaction 182 to perform with a store process 145; also see Col 13, lines 5-6, use an agent wait table to queue store assignment requests on behalf of requesting agents);
classifying the transaction request based on the analyzing of the transaction request (Shmuylovich, Fig. 6, 267 when the current collective transaction weight is within an acceptable collective transaction weight threshold, 268, 269; Col 16, lines 33-41, The load manager 135 can maintain a separate agent entry (i.e., a different row) for each of multiple store assignment requests 181 (i.e., for different types of transactions 182) (as classifying the transaction request based on the different types of transaction requests (i.e., analyzing of transaction requests)) from the same agent. Thus in some cases, an agent 155 may submit multiple store assignment requests 181 for different types of agent transactions 182 to be processed by store processes 145. In such cases, the load manager 135 can keep an agent entry for each request 181 (i.e., a separate row) in the agent wait table 133);
monitoring the server resource of the transaction server (Shmuylovich, Fig. 6, 260 calculate load information based on current resource utilization within the sore process; Col 20, lines 49-52, In step 260, the store process 145 calculates (e.g., collects or computes) load information (i.e., for itself) based on current resource utilization of the store process 145 executing on the storage computer system 140 (as transaction server); Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing);
determining the handling action for handling the transaction request in the queue transaction requests based on a classification of the transaction request further comprising (Shmuylovich, Fig. 6, 265, 267 when the current collective transaction weight is within an acceptable collective transaction weight threshold, 268, selects an agent transaction from the agent transactions queue to be processed by the store process that has an associated transaction weight that, when summed with the current collective transaction weight of the store process, produces a new collective transaction weight that is within the acceptable collective transaction weight threshold; Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing [Examiner noted: the heavy transaction (as a classification of the transaction request) is queued (i.e., based on the threshold, see Fig. 6, 265 if the new collective transaction weight is not within an acceptable collective transaction weight threshold. Then queue the agent transaction in an agent transaction queue), and the resource is continually monitored to determine if the heavy transaction can be selected from the queue for processing based on the monitored resources]):
determining when a heavy weight transaction can be processed by the transaction server based on the monitoring of the server resource; processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182…Alternatively, other agent transactions 182 may include or may identify or may correspond with significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182 (as heavy weight transaction is associated with one or more transaction classifications (i.e., transaction weight); Col 21, line 57- Col 22, line 2, determines if the new collective transaction weight is not within an acceptable collective transaction weight threshold and if so, the store process 145 queues the newly received agent transaction 182 within an agent transaction queue. In other words, in step 265, if the additional transaction weight associated with the recently received agent transactions 182 would cause the value of the new collective transaction weight to exceed acceptable collective transaction weight threshold, then the store process 145 does not begin processing the newly assigned agent transaction, but rather queues this transaction 182 within an agent transaction queue of pending agent transactions 182 that are received; Fig. 6, 267, 268 and 269; Col 22, lines 17-20, 268 and 269 in order to continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing [Examiner noted: processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed (i.e., based on the resource monitoring), further comprising: executing the handling action for the queue transaction requests (the heavy transaction within the queue is selected and processed]; also see Col 22, lines 21-34, selects an agent transaction 162 from the agent transactions queue 195 to be processed by the store process 145 that has an associated transaction weight that, when summed with the current collective transaction weight of the store process 145, produces a new collective transaction weight that is within the acceptable collective transaction weight threshold. In this manner, in step 268, the store process 145 proceeds to select pending or queued agent transactions 182 that can be concurrently performed with the set of active or in-progress agent transactions but that will not cause the new collective sum of agent transaction weights to exceed the collective transaction weight threshold).
monitoring the server resource of the transaction server (Shmuylovich, Fig. 6, 260 calculate load information based on current resource utilization within the sore process; Col 20, lines 49-52, In step 260, the store process 145 calculates (e.g., collects or computes) load information (i.e., for itself) based on current resource utilization of the store process 145 executing on the storage computer system 140 (as transaction server); Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing);
determining whether the heavy weight transaction can be processed concurrently with a light weight transaction by the transaction server based on the monitoring of the server resource; and processing the heavy weight transaction concurrently with the light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction (Shmuylovich, Col 21, lines 12-35, receives agent transactions 182 to be processed in the store process 145. The agent transactions 182 have an associated transaction weight…The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182…a relatively low transaction weight indicating that the particular agent transactions 182 does not impose a significantly large processing burden upon the store process 145…significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182…use transaction weights associated with individual agent transactions to calculate the collective transaction weight as a sum of all transaction weights associated with all in-progress agent transactions 182 currently being assigned to, received by, and being performed by the store process 145; Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing; Col 22, lines 28-33, the store process 145 proceeds to select pending or queued agent transactions 182 that can be concurrently performed with the set of active or in-progress agent transactions but that will not cause the new collective sum of agent transaction weights to exceed the collective transaction weight threshold (as processing the heavy weight transaction (i.e., previously queued) concurrently with a light weight transaction (i.e. previously determined can be processed) based on the determining whether a heavy weight transaction can be processed concurrently with a light weight transaction (i.e., based on the resources monitored)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller with Shmuylovich because Shmuylovich’s teaching of different transaction types/classification that including light weight and heavy weight transactions and processing the light transaction if it is not exceeding the threshold and queueing the heavy weight transaction if it is exceeding the threshold and later for processing based on the resource monitoring would have provided Miller’s system with the advantage and capability to allow the system to scheduling different types of the transactions based on its resource utilization/usage in order to improve the system resource utilization and efficiency (see Shmuylovich Col 22, lines 43-46, “not exceeding processing resource limits which could results in efficiencies of processing agent transactions”).
Miller and Shmuylovich fail to specifically teach wherein the historical record comprise of one record per transaction ID (identification) and each of the one record comprises of entries for critical resource footprints, which includes, peak virtual storage usage, total CPU (Computer Process Unit) usage, duration of transaction and TCB (Task Control Block) usage, and adding the classified transaction request to the transaction record;
However, Barnett teaches wherein the historical record comprise of one record per transaction ID (identification) and each of the one record comprises of entries for critical resource footprints, which includes, virtual storage usage, total CPU (Computer Process Unit) usage, duration of transaction (Barnett, Fig. 8, 705 transaction resource log, 721 N, 723 Rj(t) (as resource usages), 724 T (as duration of transaction); [0010] Table 1, transaction log, Trans name (buy, sell, buy; as one record per transaction ID (identification)), CPU (as total CPU usage), Disk bytes read, Disk bytes written (as virtual storage usage; see [0004] lines 3-4, each transaction that is performed by the application; [0017] a plurality of applications will typically run on a plurality of real or virtual machines; [0057] multiple applications are consolidated onto a single hardware platform operating individual services on multiple virtual machines running simultaneously on the hardware platform (as the transaction is performed within the VM and using the virtual storage resource)), data bytes received, data bytes sent; [0104] lines 4-12, Each transaction is comprised of time stamp 722, labeled t, and a list of resource costs for the transaction 723, labeled Rj(t), where j is an index describing the system resource used. Note that the transaction times t are not periodic like the resource utilization measurement times t' and in general the two time series are not in synchronization with another. A subset of resource utilization times t' are contained within the test period T; [0101] lines 15-16, Transaction log 705 will describe transactions occurring in a given test period labeled as T (as duration of transaction) in step 724), and
adding the classified transaction request to the transaction record (Barnett, [0013] lines 1-5, Transaction logs may be generated by a software application for reasons other than performance monitoring, such as auditing, accounting, or recovery. But for measuring performance, the logs must contain a date/time stamp, the type and number of transactions performed (as adding the classified transaction request to the record).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller and Shmuylovich with Barnett because Barnett’s teaching of recording the resource usage with each transaction ID/name would have provided Miller and Shmuylovich’s system with the advantage and capability to allow the system to simulate resource cost for a given resource based on transaction throughput in order to improving the system performance and efficiency (see Barnett, Abstract “simulate resource cost for a given resource” and [0016] “improve performance of an application in system”).
Miller, Shmuylovich and Barnett fail to specifically teach the virtual storage usage is peak virtual storage usage.
However, Ash teaches the virtual storage usage is peak virtual storage usage (Ash, [0037] lines 1-7, The statistics module 502 may maintain statistics for each virtual storage drive 300 in the storage drives 204. These statistics may include, for example, average input/output operations per second (IOPS) for each virtual storage drive 300 during a specified time period (e.g., 24 hours), and peak TOPS for each virtual storage drive 300 during a specified time period (e.g., 24 hours) (as peak virtual storage usage)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich and Barnett with Ash because Ash’s teaching of maintaining peak TPOS for each virtual storage drive (as peak virtual storage usage) would have provided Miller, Shmuylovich and Barnett’s system with the advantage and capability to allow the system to easily identifying the peak resource usage during a specific period of time in order to prevent performance bottlenecks within the system (see Ash, [0002] “in order to prevent performance bottlenecks within the system”).
Miller, Shmuylovich, Barnett and Ash fail to specifically teach wherein the historical record further includes TCB (Task Control Block) usage.
However, Park teaches wherein the historical record further includes TCB (Task Control Block) usage (Park, Fig. 3A, 302 transaction control block (TCB); [0040] lines 3-10, The transaction manager 300 includes a transaction control block (TCB) table 302 and a transaction table 304. In some examples, the TCB table 302 provides a transaction state (e.g., active, committed) and a lock state (e.g., release, holding) of each transaction of a plurality of transactions. In some examples, the transaction table 304 relates each transaction of a plurality of transactions to a respective index in the TCB table 302; [0042] lines 6-14, Transaction 25511 (TCB: 1) acquires three locks: {(Table, 0x1010):IX, (Record, 0x88):X, (Record, 0x90):X} and Transaction 25517 (TCB: 2) acquires one lock: (Table, 0x1010):IX, and waits for one lock: (Record, 0x88):X, as depicted in the lock table 328 of FIG. 3B. Transaction 25517 (TCB: 2) adds the lock owner and the lock key pair to the LOM 326: LockOwnerMap={1: {(Record, 0x88)}}. Transaction 25511 (TCB: 1) completes and either a commit or a rollback is issued; [0048] lines 3-7, TCB in the TCB table 302 that corresponds to the transaction (i.e., based on the transaction's TCB index) is updated to reflect the changed status of the transaction and release status of the corresponding lock(s)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett and Ash with Park because Park’s teaching of TCB table that including the TCB usage for each transactions would have provided Miller, Shmuylovich, Barnett and Ash’s system with the advantage and capability to allow the system to easily manage and determining the TCB for different transactions in order to improving the system performance and efficiency.
Miller, Shmuylovich, Barnett, Ash and Park fail to specifically teach wherein the queue of transaction requests contain a maximum queue time restriction and maximum length of queue restriction.
However, Banks teaches wherein the queue of transaction requests contain a maximum queue time restriction and maximum length of queue restriction (Banks, Col 5, lines 44-47, each queue 130 are two parameters QUEUELIMIT and MAXQTIME stored in a control block, specified by the user of the local system 100, to allow control of the size of the respective queue 130. Col 5, lines 47-50, QUEUELIMIT is the maximum number of requests (as maximum length of queue restriction) that the queue management portion 111 of the allocator 110 should queue; Col 5, lines 66-67, MAXQTIME is the maximum amount of time (as maximum queue time restriction) that requests are expected to spend on the queue 130; please note: transaction queue was taught by Shmuylovich).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett, Ash and Park with Banks because Banks’s teaching of QUEUELIMIT and MAXQTIME of the queue would have provided Miller, Shmuylovich, Barnett, Ash and Park’s system with the advantage and capability to easily managing and controlling the incoming requests based on the QUEUELIMIT and MAXQTIME of the queue which improving the system resource utilization and performance.
As per claim 3, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 1 above. Barnett further teaches wherein the transaction record comprises one or more transaction classifications (Barnett, [0013] lines 1-5, Transaction logs may be generated by a software application for reasons other than performance monitoring, such as auditing, accounting, or recovery. But for measuring performance, the logs must contain a date/time stamp, the type and number of transactions performed).
As per claim 4, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 3 above. Miller further teaches generating the Job record (Miller, Fig. 4, 427 aggregate summary record generation; Col 10, lines 18-21, The recency criterion may be a period of time during which the summary records of the particular job are determined to be a valid indication of the resources required by the particular job; Col 7, lines 51-57, generating a set of aggregate summary records regarding the set of address spaces. The aggregate summary records may be comprehensive or cumulative reports that include data regarding previous jobs that have been executed in each respective address space, as well as the execution status and resource usage of those jobs; Col 9, lines 50-66, collect a history of statistic intervals regarding the system resources used when writing to each address space of the computer system. In certain embodiments, the information may be collected by a batch monitoring parameter “Batchmon” configured to organize the information gathered by existing performance monitors. The system architecture limitation information may indicate the total available resources that can be provided by the hardware of the computer system (e.g., maximum CPU MIPS, maximum device I/O throughput). In certain embodiments, the system architecture limitation information may be collected from the recorded data on the previous usage of address spaces of the system components using a performance monitor independent of existing system performance monitors such as a batch monitor address space (BMAS). At block 304 the method 300 may also include querying the system to collect address space reports that indicate the address spaces that are currently being used for job execution; Col 11, lines 7-21, in response to determining that the system limitations are exceeded by the total system resource utilization estimation...determine the system resources used to execute a job on each address space for previous batch job execution instances…if the date and time requested for rescheduling of the particular job exceeds the first duration threshold (e.g., 24 hours), the method 300 may proceed to block 314 and place the particular job in a hold queue for later).
In addition, Shmuylovich teaches job is transaction, and classifying each of the plurality of transactions according to the one or more transaction classifications comprises: wherein the one or more transaction classifications comprise: a heavy weight transaction; and a light weight transaction (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182. As an example, some agent transactions 182 provided from some agents 185 to store processes 145 have a relatively low transaction weight indicating that the particular agent transactions 182 does not impose a significantly large processing burden upon the store process 145 (as light weight transaction). Alternatively, other agent transactions 182 may include or may identify or may correspond with significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182 (as heavy weight transaction)).
As per claim 12, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 1 above. Miller further teaches wherein the server resource comprise one or more of: a memory usage metric; a peak memory usage metric; a trusted computing base usage metric; a processing time; and a processor usage metric (Miller, Col 5, lines 46-52, The performance records may include data regarding the time, date, duration, memory address space, resource usage, and execution status of each job of the set of jobs (e.g., a particular job began on Tuesday March 19th at 4:00 PM, ran for 30 minutes, used 10 CPU MIPS, was executed in a first designated memory address space, and completed successfully) (as processing time). also see Col 6, lines 44-49, The resource allocation may be a calculated estimate of the amount and type of system resources needed to facilitate successful execution of the particular job. The resource allocation may also include the time duration (as processing time) that the resources are needed, memory address spaces, or other conditions related to the particular job).
As per claim 14, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 1 above. Shmuylovich further teaches wherein the handling action comprises one or more of: processing the transaction request; rejecting the transaction request; verifying the transaction request; and routing the transaction request (Col 21, line 57- Col 22, line 2, determines if the new collective transaction weight is not within an acceptable collective transaction weight threshold and if so, the store process 145 queues the newly received agent transaction 182 within an agent transaction queue. In other words, in step 265, if the additional transaction weight associated with the recently received agent transactions 182 would cause the value of the new collective transaction weight to exceed acceptable collective transaction weight threshold, then the store process 145 does not begin processing the newly assigned agent transaction, but rather queues this transaction 182 within an agent transaction queue of pending agent transactions 182 that are received; Fig. 6, 267, 268 and 269; Col 22, lines 17-20, 268 and 269 in order to continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing).
As per claim 15, it is a computer program product claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 18, it is a processing system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, Miller further teaches one or more computer processors; one or more non-transitory computer readable storage media; program instructions stored on the one or more non-transitory computer readable storage media for execution by at least one of the one or more computer processors, the program instructions to perform the steps of: (Miller, Fig. 5, 500 computer system, 502 processor, 502A-B CPUs, 504 memory; Col 16, lines 15-22, These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks).
Claims 5-6, 8-9, 11, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Miller, Shmuylovich, Barnett, Ash, Park and Banks, as applied to claims 4, 1, 15 and 18 respectively above, and further in view of Marr et al. (US Pub. 2014/0082165 A1).
Marr was cited in the previous Office Action.
As per claim 5, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 4 above. Shmuylovich teaches wherein a transaction is classified as a heavy weight transaction (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182…Alternatively, other agent transactions 182 may include or may identify or may correspond with significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182 (as heavy weight transaction)).
Although Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the heavy weight transaction, Miller, Shmuylovich, Barnett, Ash, Park and Banks fail to specifically teach wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction exceeds a resource threshold.
However, Marr teaches wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction exceeds a resource threshold (Marr, [0021] lines 1-2, a server computer; [0030] lines 2-7, a number of virtual machine instance configurations, each associated with a different amount of network usage, may be categorized as "light network applications" or "heavy network applications" depending on whether the usage measurement exceeds or falls short of some threshold (as resource threshold); also see [0045] lines 9-11, while another virtual machine instance configuration, such as the one from which VM2 424 is instantiated, may be independently profiled as a heavy CPU application (as classifying the application/job as heavy if that exceeds a resource threshold; please note: transaction was taught by Shmuylovich).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett, Ash, Park and Banks with Marr because Marr’s teaching of determining that the application/job is heavy based on the usage measurement exceeds the threshold would have provided Miller, Shmuylovich, Barnett, Ash, Park and Banks’s system with the advantage and capability to allow the system to easily determining the different types of the jobs/application/transactions based on the comparison of the usage with the threshold in order to improving the system resource utilization and performance (see Marr, [0029] lines 6-7, “efficiently utilize the operating profiles to make placement decisions”).
As per claim 6, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 4 above. Shmuylovich teaches wherein a transaction is classified as a light weight transaction (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182. As an example, some agent transactions 182 provided from some agents 185 to store processes 145 have a relatively low transaction weight indicating that the particular agent transactions 182 does not impose a significantly large processing burden upon the store process 145 (as light weight transaction)).
Although Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the light weight transaction, Miller, Shmuylovich, Barnett, Ash, Park and Banks fail to specifically teach wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold.
However, Marr teaches wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold (Marr, [0021] lines 1-2, a server computer; [0030] lines 2-7, a number of virtual machine instance configurations, each associated with a different amount of network usage, may be categorized as "light network applications" or "heavy network applications" depending on whether the usage measurement exceeds or falls short of some threshold (as resource threshold); also see [0030] lines 27-30, often initiates small network transmissions may be categorized as a "light network application/light CPU application" if the CPU utilization of the virtual machine instances fall below a threshold. (as classifying the application/job as light if that does not exceed a resource threshold; please note: transaction was taught by Shmuylovich).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett, Ash, Park and Banks with Marr because Marr’s teaching of determining that the application/job is light based on the usage measurement does not exceed the threshold would have provided Miller, Shmuylovich, Barnett, Ash, Park and Banks’s system with the advantage and capability to allow the system to easily determining the different types of the jobs/application/transactions based on the comparison of the usage with the threshold in order to improving the system resource utilization and performance (see Marr, [0029] lines 6-7, “efficiently utilize the operating profiles to make placement decisions”).
As per claim 8, Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the invention according to claim 1 above. Shmuylovich teaches wherein determining the handling action for handling the transaction request based on the classification of the transaction request comprises: if the transaction request is classified as a light weight transaction, processing the transaction request (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182. As an example, some agent transactions 182 provided from some agents 185 to store processes 145 have a relatively low transaction weight indicating that the particular agent transactions 182 does not impose a significantly large processing burden upon the store process 145 (as light weight transaction; Col 22, lines 5-15, if the new collective transaction weight is within an acceptable collective transaction weight threshold, then the store process 145 processes the agent transactions 182 within the store process 145 in order to convert management data 162 in the agent transaction 182 into managed object data 160 in the management database 161 accessed by the management application 132. In this manner, if the additional agent transaction 182 would not cause the store process 145 to exceed its collective transaction weight threshold, processing of the newly received agent transactions 182 begins in step 266 (as processing the transaction request, if it is light weight transaction (i.e., does not exceed transaction weight threshold); and
if the transaction request is classified as a heavy weight transaction, queueing the transaction request (Shmuylovich, Col 21, lines 14-29, The agent transactions 182 have an associated transaction weight. This may be a value specified in the transaction 182 itself, or may be determined by the type of transaction 182 to be performed by the store process 145. The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182…Alternatively, other agent transactions 182 may include or may identify or may correspond with significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182 (as heavy weight transaction); Col 21, line 57- Col 22, line 2, determines if the new collective transaction weight is not within an acceptable collective transaction weight threshold and if so, the store process 145 queues the newly received agent transaction 182 within an agent transaction queue. In other words, in step 265, if the additional transaction weight associated with the recently received agent transactions 182 would cause the value of the new collective transaction weight to exceed acceptable collective transaction weight threshold, then the store process 145 does not begin processing the newly assigned agent transaction, but rather queues this transaction 182 within an agent transaction queue of pending agent transactions 182 that are received (as queueing the transaction request, if the transaction request is heavy weighted (i.e., exceed the transaction weight threshold)).
Although Miller, Shmuylovich, Barnett, Ash, Park and Banks teach the light weight transaction and heavy weight transaction, Miller, Shmuylovich, Barnett, Ash, Park and Banks fail to specifically teach wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold and wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction does exceed a resource threshold.
However, Marr teaches wherein a transaction is classified as a light weight transaction if the server resource required to process the transaction does not exceed a resource threshold (Marr, [0021] lines 1-2, a server computer; [0030] lines 2-7, a number of virtual machine instance configurations, each associated with a different amount of network usage, may be categorized as "light network applications" or "heavy network applications" depending on whether the usage measurement exceeds or falls short of some threshold (as resource threshold); also see [0030] lines 27-30, often initiates small network transmissions may be categorized as a "light network application/light CPU application" if the CPU utilization of the virtual machine instances fall below a threshold. (as classifying the application/job as light if that does not exceed a resource threshold; please note: transaction was taught Shmuylovich) and
wherein a transaction is classified as a heavy weight transaction if the server resource required to process the transaction does exceed a resource threshold (Marr, [0021] lines 1-2, a server computer; [0030] lines 2-7, a number of virtual machine instance configurations, each associated with a different amount of network usage, may be categorized as "light network applications" or "heavy network applications" depending on whether the usage measurement exceeds or falls short of some threshold (as resource threshold); also see [0045] lines 9-11, while another virtual machine instance configuration, such as the one from which VM2 424 is instantiated, may be independently profiled as a heavy CPU application (as classifying the application/job as heavy if that exceeds a resource threshold; please note: transaction was taught Shmuylovich).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett, Ash, Park and Banks with Marr because Marr’s teaching of determining whether the application/job is light or heavy based on comparing the usage measurement with the threshold would have provided Miller, Shmuylovich, Barnett, Ash, Park and Banks’s system with the advantage and capability to allow the system to easily determining the different types of the jobs/application/transactions in order to improving the system resource utilization and performance (see Marr, [0029] lines 6-7, “efficiently utilize the operating profiles to make placement decisions”).
As per claim 9, Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr teach the invention according to claim 8 above. Shmuylovich further teaches monitoring the server resource of the transaction server (Shmuylovich, Fig. 6, 260 calculate load information based on current resource utilization within the sore process; Col 20, lines 49-52, In step 260, the store process 145 calculates (e.g., collects or computes) load information (i.e., for itself) based on current resource utilization of the store process 145 executing on the storage computer system 140 (as transaction server); Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing);
determining when a heavy weight transaction can be processed by the transaction server based on the monitoring of the server resource and processing the transaction request, which has been queued, based on the determining when a heavy weight transaction can be processed (Shmuylovich, Fig. 6, 265, 267 when the current collective transaction weight is within an acceptable collective transaction weight threshold, 268, selects an agent transaction from the agent transactions queue to be processed by the store process that has an associated transaction weight that, when summed with the current collective transaction weight of the store process, produces a new collective transaction weight that is within the acceptable collective transaction weight threshold; Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing [Examiner noted: the heavy transaction is queued (i.e., based on the threshold, see Fig. 6, 265), and the resource is continually monitored to determine if the heavy transaction can be selected from the queue for processing based on the monitored resources]).
As per claim 11, Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr teach the invention according to claim 8 above. Shmuylovich further teaches wherein a plurality of transaction requests are received at the transaction server, the plurality of transaction request comprising one or more heavy weight transactions and one or more light weight transactions (Shmuylovich, Fig. 1, 182-1 to 182-3 (as plurality of transaction requests), 140 storage computer system; Col 21, lines 12-35, the store process 145 (as transaction server, see Fig. 1, storage computer system) receives agent transactions 182 to be processed in the store process 145. The agent transactions 182 have an associated transaction weight…The transaction weight indicates the relative processing burden that a store process 145 will incur when performing the agent transactions 182…a relatively low transaction weight indicating that the particular agent transactions 182 does not impose a significantly large processing burden upon the store process 145…significantly larger transaction weights that indicate that a store process 145 will experience significant processing burden when performing such a heavily weighted agent transaction 182), and
wherein the method further comprises: monitoring the server resource of the transaction server (Shmuylovich, Fig. 6, 260 calculate load information based on current resource utilization within the sore process; Col 20, lines 49-52, In step 260, the store process 145 calculates (e.g., collects or computes) load information (i.e., for itself) based on current resource utilization of the store process 145 executing on the storage computer system 140 (as transaction server); Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing;
determining whether the one or more heavy weight transactions can be processed concurrently with the one or more light weight transaction by the transaction server based on the monitoring of the server resource; and processing the one or more heavy weight transactions concurrently with the one or more light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction (Shmuylovich, Col 21, lines 12-35, receives agent transactions 182 to be processed in the store process 145. The agent transactions 182 have an associated transaction weight…use transaction weights associated with individual agent transactions to calculate the collective transaction weight as a sum of all transaction weights associated with all in-progress agent transactions 182 currently being assigned to, received by, and being performed by the store process 145; Col 22, lines 17-20, continually monitor the collective transaction weight being experienced by the store process 145 to determine if any current or pending agent transactions 182 can be selected for processing; Col 22, lines 28-33, the store process 145 proceeds to select pending or queued agent transactions 182 that can be concurrently performed with the set of active or in-progress agent transactions but that will not cause the new collective sum of agent transaction weights to exceed the collective transaction weight threshold (as processing the heavy weight transaction (i.e., previously queued) concurrently with a light weight transaction (i.e. previously determined can be processed) based on the determining whether a heavy weight transaction can be processed concurrently with a light weight transaction (i.e., based on the resources monitored)).
As per claim 17, it is a computer program product claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
As per claim 20, it is a processing system claim of claim 8 above. Therefore, it is rejected for the same reason as claim 8 above.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr, as applied to claim 1 above, and further in view of Cho (US Patent. 10,956,244 B1).
Cho was cited in the previous Office Action.
As per claim 13, Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr teach the invention according to claim 1 above. Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr fail to specifically teach wherein the current server capacity metric comprises one or more of: a number of current transactions currently being processed; a memory usage metric; a processor usage metric; and a number of transaction requests in a queue.
However, Cho teaches wherein the current server capacity metric comprises one or more of: a number of current transactions currently being processed; a memory usage metric; a processor usage metric; and a number of transaction requests in a queue (Cho, Col 32, lines 60-65, To measure CPU usage, API manager may monitor activity in computer resources in a server and/or by including agents that captures metrics such as CPU and memory usage. Memory usage metrics, like CPU usage, also measure resource utilization as CPU and memory capacity).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr with Cho because Cho’s teaching of collecting and captures the processor and memory usage metrics would have provided Miller, Shmuylovich, Barnett, Ash, Park, Banks and Marr’s system with the advantage and capability to allow the system to easily determining the current system processing capability in order to improving the jobs/transactions scheduling efficiency and performance.
Response to Arguments
In the remark applicant’s argue in substance:
(a), Applicant respectfully submits that the claims use any judicial exception found therein, in a manner that imposes a meaningful limit on the judicial exception, such that the claims are more than a drafting effort designed to monopolize the judicial exception. Specifically, the independent claims describe an approach by a computer-implemented method, system, and computer program product, for dynamically determining whether an incoming transaction request should be processed immediately or queued by the server based on a historical record of the server resources required to process the given transaction and the current processing capacity of the server.
(b), In conclusion, while the claim limitations may involve concepts that could be considered mental processes if considered in isolation, their implementation within a computer system with specific components and functionalities transforms them into practical applications that go beyond mere mental activities. The technical aspects, computational requirements, and integration of machine learning techniques distinguish these limitations as practical implementations rather than abstract mental processes.
(c), Applicant respectfully contends that the claims go beyond mere abstract ideas, offering accelerate job performance for transaction servers (or similar environment). The claims involve, dynamically adapting to the incoming transaction requests based on the current server capacity and the processing requirements of the requests…These unconventional steps and improvements in technology demonstrate a specific limitation that is not routine or conventional in the field, transforming the claims into patent- eligible inventions under the exceptions outlined in MPEP 2106.5(I) and MPEP 2106.05(I)(A).
(d), Applicant contends that MILLER, SHMUYLOVICH, BARNETT, PARK, BANKS and ASH teach or suggest all the limitations of amended independent claim 1. For example, the reference does not teach or suggest at least, "...generating a new transaction record based on the server resource required to process the plurality of transactions and creating a queue of transaction requests based on the received transaction request, wherein the queue of transaction requests contain a maximum queue time restriction and maximum length of queue restriction and the new transaction record becomes part of the transaction record (emphasis added).
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), in response to applicant’s argument that “the claims use any judicial exception found therein, in a manner that imposes a meaningful limit on the judicial exception…the independent claims describe an approach by a computer-implemented method, system, and computer program product, for dynamically determining whether an incoming transaction request should be processed immediately or queued by the server based on a historical record of the server resources required to process the given transaction and the current processing capacity of the server”. Examiner respectfully disagreed.
The recitation provided by applicant that is “dynamically determining whether an incoming transaction request should be processed immediately or queued by the server based on a historical record…” which is no more than mentally determination that determining how to scheduling the incoming transaction requests based on the historical record. And this is directly to Mental Processes. MPEP§ 2106.05(a) recites “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements”. Further, the claim recites “processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests” and “processing the heavy weight transaction concurrently with the light weight transaction based on the determining” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) (The claim does not define any particular machine to “cause” this “transaction” other than a generic machine such as the “transaction server,” and has no details what so ever on how the claimed function will occur). Therefore, Applicant’s argument has not been found to be persuasive.
As to point (b), in response to applicant’s argument that “their implementation within a computer system with specific components and functionalities transforms them into practical applications that go beyond mere mental activities. The technical aspects, computational requirements, and integration of machine learning techniques distinguish these limitations as practical implementations rather than abstract mental processes”. Examiner respectfully disagreed.
MPEP 2106.04(d) recites that “The courts have also identified limitations that did not integrate a judicial exception into a practical application: Merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f)”. Here, the claim recites the additional limitations that “A computer-implemented method for handling a transaction request” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, “a transaction request received at a transaction server” and “responsive to receiving the transaction request at the transaction server” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). Moreover, “wherein the transaction request comprises a request for the transaction server to perform a transaction” and “a transaction record, which comprises a historical record of a server resource required to perform the transaction” and “wherein the historical record comprise of one record per transaction ID (identification) and each of the one record comprises of entries for critical resource footprints, which includes, peak virtual storage usage, total CPU (Computer Process Unit) usage, duration of transaction and TCB (Task Control Block) usage” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)) and an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Further, the claimed limitation of “processing the transaction request, which has been queued, based on determining when a heavy weight transaction can be processed, further comprising: executing the handling action for the queue transaction requests” and “processing the heavy weight transaction concurrently with the light weight transaction based on the determining whether the heavy weight transaction can be processed concurrently with the light weight transaction” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)) (The claim does not define any particular machine to “cause” this “transaction” other than a generic machine such as the “transaction server,” and no details what so ever on how the claimed function will occur). The combination of these additional elements is no more than mere instructions to apply the exception using a generic computer component (MPEP 2106.05(f)). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea. (i.e., MPEP§ 2106.05(a) recites “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements”). Thus, Applicant’s argument has not been found to be persuasive
As to point (c), please refers to point (a) and (b) above. In addition, Examiner would like direct applicant to MPEP 2106.05(f) Mere Instructions To Apply An Exception
(1), it specifically recites “Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished). Here, the claim recites the steps of “processing…based on the determining…” which is only the idea of a solution or outcome (i.e., the claim fails to recite details of how a solution to a problem is accomplished)). Thus, Applicant’s argument has not been found to be persuasive.
As to point (d), Examiner would like to point out that MILLER clearly teaches generating a new job record based on the server resource required to process the plurality of jobs, and creating a queue of job requests based on the received job request and the new job record becomes part of the job record (see Miller, Fig. 4, 422 summary record location, 427 aggregate summary record generation (as new job record becomes part of the job record); Col 5, lines 35-52, the resource utilization data may include performance records for a set of jobs…the resource utilization data may include performance records for the set of jobs. The performance records may include data regarding the time, date, duration, memory address space, resource usage, and execution status of each job of the set of jobs (e.g., a particular job began on Tuesday March 19th at 4:00 PM, ran for 30 minutes, used 10 CPU MIPS, was executed in a first designated memory address space, and completed successfully). Col 2, lines 58-63, identifying the resource allocation for the particular job may include locating a set of summary records corresponding to a set of execution instances of the particular job. The summary records may include a job execution status and historical resource usage data for the set of execution instances of the particular job; Col 10, lines 11-15, the particular job may not have been executed in the last week, and thus summary records for the last week may not be available. Accordingly, in such situations, the method 300 may proceed to block 316 and continue with execution of the particular job (as the jobs are not processed yet, so the usage data will be collected to create new job record for later use); Col 7, lines 51-57, generating a set of aggregate summary records (as created new job record becomes part of the job record) regarding the set of address spaces. The aggregate summary records may be comprehensive or cumulative reports that include data regarding previous jobs that have been executed in each respective address space, as well as the execution status and resource usage of those jobs; Col 9, lines 50-66, collect a history of statistic intervals regarding the system resources used when writing to each address space of the computer system. In certain embodiments, the information may be collected by a batch monitoring parameter “Batchmon” configured to organize the information gathered by existing performance monitors. The system architecture limitation information may indicate the total available resources that can be provided by the hardware of the computer system (e.g., maximum CPU MIPS, maximum device I/O throughput). In certain embodiments, the system architecture limitation information may be collected from the recorded data on the previous usage of address spaces of the system components using a performance monitor independent of existing system performance monitors such as a batch monitor address space (BMAS). At block 304 the method 300 may also include querying the system to collect address space reports that indicate the address spaces that are currently being used for job execution; Col 11, lines 7-21, in response to determining that the system limitations are exceeded by the total system resource utilization estimation...determine the system resources used to execute a job on each address space for previous batch job execution instances…if the date and time requested for rescheduling of the particular job exceeds the first duration threshold (e.g., 24 hours), the method 300 may proceed to block 314 and place the particular job in a hold queue for later rescheduling (as including creating the queue of job requests).
In addition, Barnett teaches adding the classified transaction request to the transaction record (Barnett, [0013] lines 1-5, Transaction logs may be generated by a software application for reasons other than performance monitoring, such as auditing, accounting, or recovery. But for measuring performance, the logs must contain a date/time stamp, the type and number of transactions performed (as adding the classified transaction request to the record). And Banks teaches wherein the queue of transaction requests contain a maximum queue time restriction and maximum length of queue restriction (Banks, Col 5, lines 44-47, each queue 130 are two parameters QUEUELIMIT and MAXQTIME stored in a control block, specified by the user of the local system 100, to allow control of the size of the respective queue 130. Col 5, lines 47-50, QUEUELIMIT is the maximum number of requests (as maximum length of queue restriction) that the queue management portion 111 of the allocator 110 should queue; Col 5, lines 66-67, MAXQTIME is the maximum amount of time (as maximum queue time restriction) that requests are expected to spend on the queue 130; please note: transaction queue was taught by Shmuylovich). Please refers to 103 rejection above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
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 ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Z.X./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights