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’s Amendment and Remarks filed on 01 May 2026.
Claims 1-20 are pending in this application.
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-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: “determining a count value of a number of transactions of a class of transactions existing within the processing environment; determining the count value meets a first predetermined requirement; and setting a value of an availability indicator for the class based on the determining the count value meets the first predetermined requirement.” and “rejecting, based on the setting the value, a first transaction of the class of transactions” As drafted, the claim as a whole recites a 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/determining/counting a count value of the number of transactions of a class of transactions existing within the processing environment, judging/evaluating/determining/identifying the count value meets a first predetermined requirement, and setting/mark/writing/flagging a value of an availability indicator for the class based on the determining the count value meets the first predetermined requirement (by pen and paper), and rejecting based on the setting the value, a first transaction of the class of transactions. 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 determining availability of a transaction in a processing environment” 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, “wherein the predetermined requirement is based on a total number of transactions that cause a new transaction to be abended” and “wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment” which is 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 generic computer as a tool to perform an abstract idea (see 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 element A computer-implemented method for determining availability of a transaction in a processing environment” 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, “wherein the predetermined requirement is based on a total number of transactions that cause a new transaction to be abended” and “wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment” which is 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 generic 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.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
Independent claims 13 and 20 are rejected for the same reason as claim 1 above. Claim 13 further recites “one or more processors; and a memory comprising code stored thereon that, when executed by the processor, determines availability of a transaction in a processing environment, the transaction belonging to a class of transactions” (i.e., “One or more processors; and a memory comprising code stored thereon that, when executed by the processor” are directed to generic computing components/functions (MPEP § 2106.05(b). “determines availability of a transaction” which is being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind). Claim 20 further recites “one or more processors; and a memory comprising code stored thereon that, when executed, performs a method for handling an inbound request for a transaction in a processing environment, the method comprising: receiving a request for a transaction in the processing environment, the transaction belonging to a class of transactions” and “determining a handling action for the received request based on the value of the availability indicator for the class” (“one or more processors; and a memory comprising code stored thereon that, when executed, performs a method for handling an inbound request for a transaction in a processing environment” which is directed to generic computing components/functions (MPEP § 2106.05(b) merely applying the abstract idea (MPEP § 2106.05(f)). In addition, “receiving a request for a transaction in the processing environment, the transaction belonging to a class of transactions” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). 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))). 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 “receiving” is well understood, routine, conventional activity is supported under Berkheimer options 2. Further, “determining” which is being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 2, the claim elaborates that wherein the count value comprises a smoothed count of the number of transactions of the class existing within the processing environment (these limitation 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)).
With respect to the dependent claim 3, the claim elaborates that wherein determining a count value of the number of transactions of the class existing within the processing environment comprises: calculating the smoothed count of the number of transactions of the class present within the processing environment. (“calculating” which is being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 4, the claim elaborates that wherein the first predetermined requirement requires the count value to be greater than a first threshold value, wherein the first threshold value is greater than a maximum number of active transactions of the class permitted within the processing environment (these limitation 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)).
With respect to the dependent claim 5, the claim elaborates that wherein setting the value of the availability indicator is responsive to determining that the count value meets the first predetermined requirement (this limitation as being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 6, the claim elaborates that determining the count value meets a second predetermined requirement; and setting the value of an availability indicator for the class based on whether or not the count value is determined to meet the second predetermined requirement (“determining” and “setting” are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 7, the claim elaborates that wherein the second predetermined requirement requires the count value to be less than a second threshold value, the second threshold value being less than the first threshold value; and wherein the second threshold value is less than a maximum number of active transactions of the class permitted within the processing environment (these limitation 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)).
With respect to the dependent claim 8, the claim elaborates that wherein setting the value of the availability indicator for the class comprises: responsive to determining that the count value meets the second predetermined requirement, conditioned upon the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment, setting the value of the availability indicator to indicate that the transaction of the class is permitted within the processing environment (“responsive to determining that the count value meets the second predetermined requirement… setting the value…” as being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 9, the claim elaborates that wherein the processing environment comprises a transaction processing environment (this limitation 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))).
With respect to the dependent claim 10, the claim elaborates that receiving an inbound request for a transaction in the processing environment, the transaction belonging to the class of transactions, wherein the determining a count value of the number of transactions is in response to the receiving; and determining a handling action for the received request based on the value of the availability indicator for the class (“receiving” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). 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))). “determining a handling action” as being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 11, the claim elaborates that wherein determining a handling action for the received request based on the value of the availability indicator for the class comprises: conditioned upon the value of the availability indicator for the class indicating that a transaction of the class is not permitted to be executed or queued for execution within the processing environment, determining that the handling action is to reject the received request (these limitations are being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
With respect to the dependent claim 12, the claim elaborates that wherein determining a handling action for the received request based on the value of the availability indicator for the class comprises: conditioned upon the value of the availability indicator for the class indicating that a transaction of the class is permitted within the processing environment, determining that the handling action is to execute or queue the received request (“conditioned upon the value of the availability indicator for the class indicating that a transaction of the class is permitted within the processing environment, determining that the handling action is to execute or queue the received request” as being treated as part of abstract idea and is analogous to Mental processes, such that concept can be performed in the human mind).
Dependent claims 14-19 recite the same features as applied to claims 4-8 and 3 respectively above, therefore they are also rejected under the same rationale.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim 1-20 is rejected under 35 U.S.C. 112(b), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
As per claims 1, 13 and 20 (line# refers to claim 1):
In lines 5-6, it recites the phrase “the predetermined requirement”. However, prior to this phrase at line 5, it recites “a first predetermined requirement”. Thus, it is unclear whether the second recitation of “the predetermined requirement” is the same or different from the first recitation of “a first predetermined requirement”. If they are the same, same term name should be used. For examining purpose, examiner will interpret as the same one.
As per claims 2-12 and 14-19:
They are system claims that depend from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for the same reasons as 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-20 are rejected under 35 U.S.C. 103 as being unpatentable over BRUCE et al. (US Pub. 2018/0189097 A1) in view of Senn (US Pub. 2020/0202354 A1) and further in view of KUBOTA et al. (US Pub. 2019/0268824 A1).
BRUCE and Senn were cited in the previous Office Action.
As per claim 1, BRUCE teaches the invention substantially as claimed including A computer-implemented method for determining availability of a transaction in a processing environment, the method comprising (BRUCE, Fig. 1; [0005] lines 1-3, Outstanding transaction regulation can involve regulating transactions by allowing the initiator device to issue transactions subject to a limit on a maximum number of outstanding transactions; [0161] lines 4-6, determines the number of outstanding transactions, to allow or disallow requests by a modifier):
determining a count value of a number of transactions of a class of transactions existing within the processing environment (BRUCE, Fig. 13, 1300 request, 1365 OT Counter; Fig. 18, 1810, 1820 Trans class, 1830 No. of Ots (as a count value of the number of transactions of a class of transactions); [0138] lines 1-2, The OT counter 1110 acts to count outgoing requests via an input 1180; [0161] lines 4-6, determines the number of outstanding transactions, to allow or disallow requests by a modifier);
determining the count value meets a first predetermined requirement (BRUCE, Fig. 18, 1810, 1820 Trans class, 1830 No. of Ots, 1840 OT limit; Fig. 12, 1200 request, 1205 below OT limit and 1210 (as whole as including meets a first predetermined requirement, i.e., Below OT Max, ); [0157] lines 1-3, Returning to the step 1205, if the current number of outstanding transactions is below OT limit) wherein the predetermined requirement is based on a total number of transactions that cause a new transaction to be abended (BRUCE, Fig. 12, 1200, (as new transaction request), 1210, NO, to 1215 block request; [0155] when a request is provided on the input 1130 at a step 1200, the OT controller detects whether the current number of outstanding transactions as detected by the OT counter is below the threshold OT limit (at a step 1205). If the answer is no then control passes to a step 1210 at which the OT controller detects whether the current number of outstanding transactions is below the higher threshold OT max. If the answer is no then at a step 1215 the request is blocked by the modifier 1120, at least until this situation changes (as new transaction to be abended); and
setting an indicator based on the determining the count value meets the first predetermined requirement (BRUCE, Fig. 12, 1250 and 1220; Fig. 11, 1160 request mark; [0140] lines 1-8, The “request mark” 1160 can indicate to the downstream device either that the OT controller 1100 is requesting permission to increase the number of OTs (which, for example, the OT controller might indicate when the number of OTs is at or above the OT limit), and/or that the OT controller 1100 is offering to reduce its number of OTs (which, for example, the OT controller might indicate when the number of OTs is below OT limit but at least as high as OT min); [0157] lines 7-9, At a step 1250, the OT controller prepares a request marked (1160) to indicate that the limit is reduceable).
BRUCE fails to specifically teach when setting the indicator, it is setting a value of an availability indicator for the class based on the determining the count value meets the first predetermined requirement, wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment; and rejecting, based on the setting the value, a first transaction of the class of transactions.
However, Senn teaches setting an availability indicator for the class based on the determining the count value meets the first predetermined requirement, wherein the setting the availability indicator indicates that a transaction of the class is not permitted within the processing environment; and rejecting, based on the setting, a first transaction of the class of transactions (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type (as setting an availability indicator (i.e., flag) for the class based on the determining the count value meets the first predetermined requirement, and the first transaction of the same/similar class of transaction are rejected in the future); also see [0026] the transaction approval policy may specify a threshold transaction frequency that may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions).
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 BRUCE with Senn because Senn’s teaching of flag and deny any future transactions of similar type when the number of transactions has been exceeded the threshold would have provided BRUCE’s system with the advantage and capability to allow the system to preventing pontifical fraud associated with transactions/account which improving the system security and performance (see Senn, [0018] “ allow fine-tuned control over the types and amounts of transactions and increase account-holder security and comfort when multiple users or devices attempt purchases using the account”).
BRUCE and Senn fail to specifically teach when setting an availability indicator, it is setting a value of an availability indicator for the class, wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted; and rejecting, based on the setting the value.
However, KUBOTA teaches when setting an availability indicator, it is setting a value of an availability indicator for the class, wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted; and rejecting, based on the setting the value. (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
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 BRUCE and Senn with KUBOTA because KUBOTA’s teaching of providing a list that including an indication of types of applications which either allowed or blocked would have provided BRUCE and Senn’s system with the advantage and capability to allow the system to easily determining and identifying whether the particular type of process/transaction need to be allowed or blocked in order to improving the system performance and efficiency (see KUBOTA, [0005]).
As per claim 2, BRUCE, Senn and KUBOTA teach the invention according to claim 1 above. BRUCE further teaches wherein the count value comprises a smoothed count of the number of transactions of the class existing within the processing environment (BRUCE, Fig. 13, 1300 request, 1365 OT Counter; Fig. 18, 1810, 1820 Trans class, 1830 No. of Ots (as a smoothed count of the number of transactions of a class of transactions, i.e., number of Ots (as integer value/soothed count); [0138] lines 1-2, The OT counter 1110 acts to count outgoing requests via an input 1180; [0161] lines 4-6, determines the number of outstanding transactions, to allow or disallow requests by a modifier).
As per claim 3, BRUCE, Senn and KUBOTA teach the invention according to claim 2 above. BRUCE further teaches wherein determining a count value of the number of transactions of the class existing within the processing environment comprises: calculating the smoothed count of the number of active and queued transactions of the class present within the processing environment (BRUCE, Fig. 13, 1300 request, 1365 OT Counter; Fig. 18, 1810, 1820 Trans class, 1830 No. of Ots (as a smoothed count of the number of transactions of a class of transactions, i.e., number of Ots (as integer value/soothed count); [0138] lines 1-2, The OT counter 1110 acts to count outgoing requests via an input 1180; [0161] lines 4-6, determines the number of outstanding transactions, to allow or disallow requests by a modifier; [0111] FIG. 2 schematically illustrates a transaction issuing device 200 having a transaction queue 210 and outstanding transaction regulation (OTR) circuitry 220; [0112] In FIG. 3, an initiator device 300 issues transactions to an interconnect (part of which is shown as 310) having a queue 320 and OTR circuitry 330 associated with that initiator device 300. When the queue 320 contains a number of outstanding transactions equal to the outstanding transaction limit).
As per claim 4, BRUCE, Senn and KUBOTA teach the invention according to claim 1 above. BRUCE further teaches wherein the first predetermined requirement requires the count value to be greater than a first threshold value, wherein the first threshold value is greater than a maximum number of active transactions of the class permitted within the processing environment (BRUCE, Fig. 18, 1810, 1820 Trans class, 1830 No. of Ots, 1840 OT limit; Fig. 12, 1200 request, 1205 below OT limit and 1210 Below OT Max (as whole as including meets a first predetermined requirement, OT Max (as first threshold); [0155] If the answer is no then control passes to a step 1210 at which the OT controller detects whether the current number of outstanding transactions is below the higher threshold OT max. [Examiner noted: the first threshold value (i.e., OT Max) is greater than a maximum number of active transactions of the class permitted within the processing environment (i.e., the transaction will be blocked if that first threshold value is passed, so this first threshold value (i.e., OT Max) is greater than a maximum number of active transactions of the class permitted (i.e., the number of the transactions to be allowed must be at least equal to or less than the maximum number of active transactions)].
As per claim 5, BRUCE, Senn and KUBOTA teach the invention according to claim 1 above. Senn further teaches wherein setting the availability indicator is responsive to determining that the count value meets the first predetermined requirement (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type (as setting the value of an availability indicator (i.e., flag) for the class that is not permitted within the processing environment )). In addition, KUBOTA teaches setting the value (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
As per claim 6, BRUCE, Senn and KUBOTA teach the invention according to claim 4 above. BRUCE further teaches determining the count value meets a second predetermined requirement; and setting the value of indicator for the class based on whether or not the count value is determined to meet the second predetermined requirement (BRUCE, Fig. 18, 1820 class; Fig. 12, 1240 Below OT MIN? (as second predetermined requirement), NO to 1250 Mark as reduceable; [0157] At a step 1250, the OT controller prepares a request marked (1160) to indicate that the limit is reduceable).
In addition, KUBOTA teaches setting the value of an availability indicator (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
As per claim 7, BRUCE, Senn and KUBOTA teach the invention according to claim 6 above. BRUCE further teaches wherein the second predetermined requirement requires the count value to be less than a second threshold value, the second threshold value being less than the first threshold value; and wherein the second threshold value is less than a maximum number of active transactions of the class permitted within the processing environment (BRUCE, Fig. 12, 1240 Below OT min? (OT Min as second threshold); [0139] The threshold values are such that OT min is less than (or equal to) OT limit which in turn is less than (or equal to) OT max. OT limit represents the default limit on a number of outstanding transactions imposed, for example, by the system designer or at boot of the apparatus).
As per claim 8, BRUCE, Senn and KUBOTA teach the invention according to claim 6 above. KUBOTA teaches wherein setting the value of the availability indicator for the class comprises: the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment, setting the value of the availability indicator to indicate that a transaction of the class is permitted within the processing environment (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)); please note: transaction was taught by BRUCE and Senn)),
In addition, BRUCE further teaches responsive to determining that the count value meets the second predetermined requirement, conditioned upon that a transaction of the class is not permitted within the processing environment, indicate that a transaction of the class is permitted within the processing environment (BRUCE, Fig. 12, 1240 Below OT min? YES allow requests; [0123] the outstanding transaction limit applicable to an idle device can potentially be redistributed on a dynamic basis to one or more other busier devices. In this way, the apparatus of FIG. 1 provides an example of a data processing apparatus comprising: one or more transaction issuing devices configured to issue data processing transactions to be handled by a downstream device and to receive a completion acknowledgement in respect of each completed transaction; each transaction issuing device having associated transaction regulator circuitry configured to allow that transaction issuing device to issue transactions subject to a limit on a maximum number of outstanding transactions, an outstanding transaction being a transaction which has been issued but for which a completion acknowledgement has not yet been received; in which the downstream device is configured to issue an indication to a transaction issuing device, to authorise a change by the transaction regulator circuitry of the limit applicable to outstanding transactions by that transaction issuing device; [0157] if the current number of outstanding transactions is below OT limit then at a step 1240 the OT controller detects whether the current number is below OT min. If the answer is yes then the request is allowed at a step 1245; [Examiner noted: since the transaction processing system is regulating the transactions in dynamic way, therefore, the transaction maybe not permitted when below OT Min (see Fig. 12, 1260), and later once outstanding transactions count below the OT min again, the transactions will be allowed]).
As per claim 9, BRUCE, Senn and KUBOTA teach the invention according to claim 1 above. BRUCE further teaches wherein the processing environment comprises a transaction processing environment (BRUCE, Fig. 1; Abstract, Data processing apparatus comprises one or more transaction issuing devices configured to issue data processing transactions to be handled by a downstream device and to receive a completion acknowledgement in respect of each completed transaction).
As per claim 10, BRUCE, Senn and KUBOTA teach the invention according to claim 1 above. BRUCE further teaches receiving an inbound request for a transaction in the processing environment, the transaction belonging to the class of transactions, wherein the determining a count value of the number of transactions is in response to the receiving (BRUCE, Fig. 13, 1300 request (received), 1365 OT counter; Fig. 18, 1810, Trans Class, 1830 No of Ots; [0053] transactions which have been received from the two or more transaction issuing devices; [0176] FIG. 18 schematically illustrates a transaction issuing device 1800 maintaining data 1810 indicative of different classes of transaction identified by a transaction class 1820. Each transaction class is associated with a current number of outstanding transactions 1830 and one or more respective OT limit values 1840. This provides an example in which the one or more transaction issuing devices are configured to issue transactions relating to a transaction category selected from a group of two or more transaction categories; and the indication is applicable to a limit relating to a subset of the transaction categories).
In addition, Senn further teaches determining a handling action for the received request based on the availability indicator for the class (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type; (as a handling action for the received request; i.e., deny); [0065] deny a flagged transaction). Further, KUBOTA teaches the value of the availability indicator (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
As per claim 11, BRUCE, Senn and KUBOTA teach the invention according to claim 10 above. Senn further teaches wherein determining a handling action for the received request based on the value of the availability indicator for the class comprises: conditioned upon the availability indicator for the class indicating that a transaction of the class is not permitted to be executed or queued for execution within the processing environment, determining that the handling action is to reject the received request (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type; (as a handling action, reject the received request; i.e., deny); [0065] deny a flagged transaction). In addition, KUBOTA teaches the value of the availability indicator (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
As per claim 12, BRUCE, Senn and KUBOTA teach the invention according to claim 10 above. Senn teaches wherein determining a handling action for the received request based on the availability indicator for the class and determining that the handling action is to execute or queue the received request (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type; (as a handling action for the received request; i.e., deny); [0065] deny a flagged transaction; [Examiner noted: executing/processing the similar type of the transaction, if the quantity of transactions are not exceed threshold). KUBOTA teaches conditioned upon the value of the availability indicator for the class indicating that a transaction of the class is permitted within the processing environment (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
As per claim 13, it is a system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, BRUCE further teaches one or more processors; and a memory comprising code stored thereon that, when executed by the processor, determines availability of a transaction in a processing environment, the transaction belonging to a class of transactions (BRUCE, Fig. 1, 100, CPU, 195 memory; Fig. 18, 1810, 1820 trans class; Abstract, Data processing apparatus comprises one or more transaction issuing devices configured to issue data processing transactions to be handled by a downstream device; [0176] FIG. 18 schematically illustrates a transaction issuing device 1800 maintaining data 1810 indicative of different classes of transaction identified by a transaction class 1820. Each transaction class is associated with a current number of outstanding transactions 1830 and one or more respective OT limit values 1840. This provides an example in which the one or more transaction issuing devices are configured to issue transactions relating to a transaction category selected from a group of two or more transaction categories; and the indication is applicable to a limit relating to a subset of the transaction categories).
As per claims 14-15, they are system claims of claims 4-5 respectively above. Therefore, they are rejected for the same reasons as claims 4-5 respectively above.
As per claims 16-18, they are system claims of claims 6-8 respectively above. Therefore, they are rejected for the same reasons as claims 6-8 respectively above.
As per claim 19, it is a system claim of claim 3 above. Therefore, it is rejected for the same reason as claim 3 above.
As per claim 20, it is a system claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above. In addition, BRUCE further teaches A system comprising one or more processors; and a memory comprising code stored thereon that, when executed, performs a method for handling an inbound request for a transaction in a processing environment, the method comprising: receiving a request for a transaction in the processing environment, the transaction belonging to a class of transactions (BRUCE, Fig. 1, 100, CPU, 195 memory; Fig. 18, 1810, 1820 trans class; Abstract, Data processing apparatus comprises one or more transaction issuing devices configured to issue data processing transactions to be handled by a downstream device; [0176] FIG. 18 schematically illustrates a transaction issuing device 1800 maintaining data 1810 indicative of different classes of transaction identified by a transaction class 1820. Each transaction class is associated with a current number of outstanding transactions 1830 and one or more respective OT limit values 1840. This provides an example in which the one or more transaction issuing devices are configured to issue transactions relating to a transaction category selected from a group of two or more transaction categories; and the indication is applicable to a limit relating to a subset of the transaction categories).
Further, Senn teaches determining a handling action for the received request based on the availability indicator for the class (Senn, [0005] lines 28-32, determining, based on the timestamps of the first plurality of micro-transactions, that a quantity of the micro-transactions that occur within a predetermined amount of time exceeds the threshold transaction frequency; [0061] lines 1-10, the transaction approval policy may comprise a threshold transaction frequency. The threshold transaction frequency may represent a quantity of transactions of a certain type within a specified time period that, when exceeded, may cause financial services device 110 to flag or deny one or more transactions. For example, in some embodiments, when a threshold transaction frequency for a particular type of transaction has been exceeded, financial services device 110 may flag or deny any future transactions of a similar type; (as a handling action, reject the received request; i.e., deny); [0065] deny a flagged transaction). And KUBOTA teaches the value of the availability indicator (KUBOTA, [0098] The traffic exempt list and/or blocked traffic list may include an indication of types of traffic (e.g., applications) which are either allowed or blocked (respectively) (as value either allowed or blocked)).
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the remark applicant’s argue in substance:
(a), A claim reciting a judicial exception is not directed to the judicial exception if it also recites additional elements demonstrating that the claim as a whole integrates the exception into a practical application. One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field."… The rejecting reduces overhead, thereby increasing the overall efficiency of the computing system.
Examiner respectfully disagreed with Applicant’s argument for the following reasons:
As to point (a), in response to applicant’s argument that “ One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field."… The rejecting reduces overhead, thereby increasing the overall efficiency of the computing system”. Examiner respectfully disagreed.
MPEP 2106.05(a) discloses that “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements. See the discussion of Diamond v. Diehr, 450 U.S. 175, 187 and 191-92, 209 USPQ 1, 10 (1981)) in subsection II, below. In addition, the improvement can be provided by the additional element(s) in combination with the recited judicial exception”. Here, the claim recites additional limitations which is related to “A computer-implemented method for determining availability of a transaction in a processing environment”, and this 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, the claimed limitation of “wherein the predetermined requirement is based on a total number of transactions that cause a new transaction to be abended” and “wherein the setting the value of the availability indicator indicates that a transaction of the class is not permitted within the processing environment” which is 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 generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). And these additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept with increasing the overall efficiency of the computing system. Thus, merely rejecting a new transaction based on determining the total count of number of current transactions meets the threshold cannot providing the improvement since it is related to the judicial exception. Please see 101 rejection above.
For the reasons above, Applicant’s argument has not been found to be persuasive, and therefore the rejections are maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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