DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Claims 1-15 recite the transaction request queue and transaction response queue. A “queue” is a data structure and functionally a logical FIFO (first in first out) structure implemented in memory/software and used to manage ordering, allocation, throughput of network transaction requests and responses among multiple entities. They are considered additional elements because they are concrete/structural/functional limitations beyond the abstract idea.
Claims 1, 3, and 13 recite a transaction response handler. A transaction response handler is a software component that processes the response to a transaction request, and is responsible for taking actions based on the transactions outcome. Such responses can include transaction status, processing payments, or sending notifications to the user or system, and help ensure that transactions are completed correctly and efficiently. They are implemented in various programming languages and frameworks, such as JAVA, PHP, and JavaScript.
Claims 1, 3, and 13 recite a transaction request handler. A transaction request handler is a specialized software component that processes and enriches incoming requests before presenting them to users. It is responsible for transforming raw events into user-friendly previews, adding validation, metadata, and human-readable information. Transaction request handlers are instantiated and registered during the initialization of the EventRouter, which is a component that manages the lifecycle of request handlers. They perform multiple validation steps with specific error detection to ensure the integrity of the transaction.
Claims 8 and 9 recite a transaction record. In relational databases, a record is a collection of fields that contain data about a specific entity, and is stored as a row in a table and represents the smallest unit of data that can be inserted, updated, or deleted from a table.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 1 recites a process, which is a statutory category of invention (Step 1: YES). Claim 13 recites an apparatus, which is a statutory category of invention (Step 1: YES). Claim 15 recites a system, which is a statutory category of invention (Step 1: YES). Claim 14 recites an apparatus, which is a statutory category of invention (Step 1: Yes).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claims 1, 13 and 14 recite a method performed by a transaction manager computing device for processing a plurality of transactions among a plurality of network entities, the method comprising: for each transaction: receiving, by the transaction manager computing device, from a first network entity, a first transaction request to perform a transaction with a second network entity; selecting, by the transaction manager computing device, a transaction request queue from a plurality of configured transaction request queues; adding, by the transaction manager computing device, the first transaction request to the back of the selected transaction request queue; when the first transaction request reaches the front of the selected transaction request queue, processing the first transaction request by a transaction request handler associated with the selected transaction request queue and sending, by the transaction manager computing device, a second transaction request to the second network entity; receiving a first transaction response from the second network entity, in response to the second transaction request; selecting, by the transaction manager computing device, a transaction response queue from a plurality of configured transaction response queues; adding, by the transaction manager computing device, the first transaction response to the back of the selected transaction response queue; and when the first transaction response reaches the front of the selected transaction response queue, processing the first transaction response by a transaction response handler associated with the selected transaction response queue and sending a second transaction response to the first network entity, the transaction manager computing device including the transaction response handler. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are fundamental economic practice, such as facilitating transactions. Also, the limitations are commercial interactions, such as business relations, as well as managing interactions between people, such as following instructions. Lastly, the claims are mental processes, as they are capable of being performed in the human mind or by pen and paper. More specifically, under fundamental economic practice, the claims involve mitigating risk. Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims do not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a transaction manager computing device, plurality of network entities, first network entity, transaction request queue, transaction response queue, transaction request handler, transaction response handler, and second network entity. The additional elements of a transaction manager, plurality of network entities, first network entity, transaction request queue, transaction response queue, transaction request handler, transaction response handler, and second network entity, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (transaction manager computing device, plurality of network entities, first network entity, transaction request queue, transaction response queue, transaction request handler, transaction response handler, and second network entity) in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 15 recites the plurality of network entities; and the transaction manager apparatus according to claim 14. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the plurality of network entities and the transaction manager apparatus are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 2 recites wherein: selecting, by the transaction manager computing device, the transaction request queue comprises performing load balancing for the plurality of configured transaction request queues; and selecting, by the transaction manager computing device, the transaction response queue comprises performing load balancing for the plurality of configured transaction response queues. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction request queue, transaction response queue, and transaction response queues are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 3 recites for at least one of the plurality of configured transaction request queues, a plurality of transaction request handlers are associated with the transaction request queue to process multiple transaction requests from the transaction request queue simultaneously; and/or for at least one of the plurality of configured transaction response queues, a plurality of transaction response handlers are associated with the transaction response queue to process multiple transaction responses from the transaction response queue simultaneously. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction request queue, transaction response queue, transaction request handlers, and transaction response handlers, are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 4 recites wherein: the method comprises discarding a transaction request from a transaction request queue if the transaction request exceeds a first predetermined age before being processed. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction request queue are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 5 recites wherein, after discarding the transaction request from the transaction request queue, the method comprises: sending a transaction failure message to the first network entity. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction request queue and first network entity are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 6 recites wherein: the method comprises discarding a transaction response from a transaction response queue if the transaction response exceeds a second predetermined age before being processed. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction response queue are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 7 recites after discarding the transaction response from a transaction response queue, the method comprises: re-sending the second transaction request to the second network entity. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the second network entity and transaction response queue are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 8 recites wherein: processing the first transaction request comprises adding a first transaction record to a database of ongoing transactions; and/or processing the first transaction response comprises updating the first transaction record. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the first transaction record and database are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 9 recites wherein the first transaction record comprises the first transaction request or the second transaction request. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the first transaction record and database are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 10 recites wherein: the first transaction request comprises a timestamp; and/or the first transaction response comprises a timestamp. These limitations are also part of the abstract idea identified in claim 1, and is similarly rejected under the same rationale as claim 1, supra.
Claim 11 recites wherein the network entities are bank entities configured to perform payment transactions via the transaction manager computing device. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the transaction manager are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim 12 recites wherein processing the first transaction response and sending the second transaction response to the first network entity comprises: sending, to a third network entity, a third transaction request based on the first transaction response; receiving a third transaction response from the third network entity, in response to the third transaction request; selecting a transaction response queue from a plurality of configured transaction response queues; adding the third transaction response to the back of the selected transaction response queue; when the third transaction response reaches the front of the selected transaction response queue, processing the third transaction response and sending the second transaction response to the first network entity. These limitations are also part of the abstract idea identified in claim 1, and the additional elements of the third network entity, first network entity, transaction response queue and transaction response queues are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1, supra.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 8-9, 11, 13, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Parkinson US 20090222823, in view of Dillow US 8578390 and Jensen US 6438528.
Regarding claim 1, 13, 14, and 15, Parkinson discloses a method performed by a transaction manager computing device for processing a plurality of transactions among a plurality of network entities, the method comprising (Parkinson, Abstract, “a distributed transaction processing environment having at least one transaction queue manager. An application request is received from a client to initiate a transaction. The request is placed in a transaction request queue by the transaction queue manager”; transaction manager computing device is recited as a “server”; Para. 49, “FIG. 4 illustrates the processing logic associated with the queued transaction processing system in a J2EE environment. The following paragraphs describes a basic flow of the queued transaction processing functionality that details a configuration of three machines: the client, the transaction queue manager (server)”; Further, Fig. 1 includes client 10, server 20, request queue 30, and response queue 40):
for each transaction: receiving, by the transaction manager computing device, from a first network entity, a first transaction request to perform a transaction with a second network entity (Applicant request received between an application server and a client); Fig. 1, Client 10 and Server 20; Client as “first network entity” and application server as “second network entity”; Para. 15, Client 10 issues the request that is enqueued);
selecting, by the transaction manager computing device, (Para. 5, “The request is enqueued in a transaction request queue by the transaction queue manager. The request is processed at the application server asynchronously relative to the receipt of the request. A response to the request is determined, and the response is enqueued in a transaction response queue for retrieval by the client”; Para. 49, Fig. 4, transaction queue manager that manages queues, where the manager selects an appropriate request queue for different transactions; See also Para. 15, “In transaction T1, the request from client 10 is enqueued on the recoverable request queue 30”);
Parkinson fails to disclose a transaction request queue from a plurality of configured transaction request queues. However, Dillow teaches a communications manager that selects and deposits a service request message onto an appropriate service queue chosen from a plurality of service queues (TSCM_SERVICE_nn queues with different service types; Col. 4, Lines 20-60; Col. 6, Lines 20-50; Fig. 4, and service queues 326 and 422).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the multi-queue selection mechanism of Dillow. Doing so supports concurrent processing of multiple transaction types, reduces queue congestion and improves throughput.
adding, by the transaction manager computing device, the first transaction request to the back of the selected transaction request queue (System performs a “rollback” of the request; Claim 9, “rolling back the transaction if at least one processing operation of the transaction is not completed successfully”; Para. 18, transaction is rolled back; Para. 15, request from client 10 is enqueued on recoverable request queue 30);
when the first transaction request reaches a front of the selected transaction request queue, processing the first transaction request by an [application server] associated with the selected transaction request queue and sending, by the transaction manager computing device, a second transaction request to the second network entity (Para. 5, The request is processed at the application server asynchronously relative to the receipt of the request. A response to the request is determined, and the response is enqueued in a transaction response queue for retrieval by the client; Claim 11, “processing the request and determining the transaction response are performed by the application server asynchronously with respect to receiving the transaction request from the client”),
Parkinson fails to disclose a transaction request handler and that the transaction manager computing device included the transaction request handler. However, Jensen discloses a transaction manager supporting a multi-currency environment with an input queue 19 and input and output handler 18’ and 18” where output handlers are components of the transaction manager and the system output data (reply) and input data (request) is sent from an assigned output handler to a receiving program according to the data format used by the client (Fig 1-3, Transaction manager 10, includes Handler 18, with request handlers (18’) and response handler 18”)
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the transaction response handler of Jensen. Doing so ensure that the transaction is handled in the most efficient manner, while shielding information between authorization requests.
Modified Parkison discloses receiving a first transaction response from the second network entity, in response to the second transaction request (Fig. 1, 40 receives enqueue reply from server 20; Manager receives response from processing resource; Para. 16, Facilitated in response to T2 transaction, a “second transaction request”);
Modified Parkison discloses selecting, by the transaction manager computing device, a transaction response queue from configured transaction response queues (Para. 5, “A response to the request is determined, and the response is enqueued in a transaction response queue for retrieval by the client”; Para. 16, “In transaction T3, the client dequeues the reply from the recoverable response queue 40. Using queued transaction processing: (1) the client 10 can enter requests even if the server 20 is unavailable; (2) the server 20 can return results even if the client 10 is unavailable; and (3) the request will ultimately be serviced even if the second transaction aborts”; Para. 46, “The server 20 enqueues the result into the transaction response queue 40. The server 20 then commits the global transaction. In FIG. 3, this is identified as Transaction 2”; Para. 54-55, “The Queued Transaction EJB proxy commits the transaction with the queued message (step 424). The Queued Transaction EJB proxy then begins the transaction and listens on the transaction response queue (step 426). An OC4J server, with a Queue Manager maintaining at least one transaction request queue and one transaction response queue, places the application work request submitted by the Queued Transaction EJB proxy in a transaction request queue”; Para. 57, Queue manger commits to global transaction after listening for response message – “The Queued Transaction EJB proxy listens for a response message on the transaction response queue (step 426). The queue manager commits the global transaction (step 444)”);
Parkinson fails to disclose a transaction response queue from a plurality of configured transaction response queues. However, Dillow teaches routing of response messages via associated response/write queues and threads (Dillow, Abstract, Col., 4-6, write thread and TSCM queues with response path).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the multi-queue selection mechanism of Dillow. Doing so supports concurrent processing of multiple transaction types, reduces queue congestion and improves throughput.
Modified Parkinson discloses adding, by the transaction manager computing device, the first transaction response to the selected transaction response queue (Claim 1, “placing the transaction response in a transaction response queue by the queue manager for retrieval by the client”);
Modified Parkinson discloses placing the transaction response in a transaction response queue, but fails to disclose placing the transaction in the back.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the position in the back of the transaction response queue since it has been held that mere rearrangement of parts does not hold patentable value. (In reJapikse, 181 F.2d 1019, 86 USPQ 70 (CCPA 1950) (Claims to a hydraulic power press which read on the prior art except with regard to the position of the starting switch were held unpatentable because shifting the position of the starting switch would not have modified the operation of the device.); In re Kuhle, 526 F.2d 553, 188 USPQ 7 (CCPA 1975) (the particular placement of a contact in a conductivity measuring device was held to be an obvious matter of design choice).
and when the first transaction response reaches the front of the selected transaction response queue, processing the first transaction response by a [client server] associated with the selected transaction response queue and sending a second transaction response to the first network entity (Parkinson, “The response is placed in a transaction response queue…for retrieval by the client”; Under broadest reasonable interpretation, the front can mean any number of different places in order; to respond to the first network; Fig. 1, can go through different transactions as many times as necessary, allowing the “second transaction”; Fig. 2A, 62 is second transaction, versus 54 as first transaction; Fig. 3, transactions can occur as many times as necessary).
Parkinson fails to disclose transaction response handler and the transaction manager computing device including the transaction response handler. However, Jensen discloses a transaction manager supporting a multi-currency environment with an input queue 19 and input and output handler 18’ and 18” where output handlers are components of the transaction manager and the system output data (reply) and input data (request) is sent from an assigned output handler to a receiving program according to the data format used by the client (Fig 1-3, Transaction manager 10, includes Handler 18, with request handlers (18’) and response handler 18”)
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the transaction response handler of Jensen. Doing so ensure that the transaction is handled in the most efficient manner, while shielding information between authorization requests.
Regarding claim 8, Parkinson discloses processing the first transaction request comprises adding a first transaction record to a database of ongoing transactions (Transaction manager uses a database to recover a transaction if necessary; Para. 4, “the transaction manager must log information to a non-volatile store that can be used to recover a transaction processing failure. A recovering transaction is one that is reconstructed as a result of a previous failure in the processing of a transaction”, and “logging” would utilize data storage; Claim 10; See also, Para. 2, “Accesses that are made to the data stored in such systems are known as transactions”; “Persistent data stored on a data storage device”, Claim 17).
Regarding claim 9, modified Parkisnon discloses where transactions records are held in a database (Para. 14, resource manager as a database; Para. 19, database system; and Para. 20), as well as transactions as concurrent and sequential order (Para. 3),; but fails to disclose wherein the first transaction record comprises the first transaction request or the second transaction request.
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with transaction records of a database being the first or second transaction request, since the users of the system would want to know what the first transaction or second is in order to make proper adjustments, or for the system to make adjustments accordingly for security reasons to predict potential security breaches based on first several orders.
Regarding claim 11, modified Parkinson discloses wherein the network entities are bank entities configured to perform payment transactions via the transaction manager computing device (Fig. 1, Client 10 is the ATM, and Bank is Server 20; Both are considered “bank entities”; Parkinson also discloses the transaction manager as a “Server” which is a computing device).
Claim(s) 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Parkinson US 20090222823, in view of Dillow US 8578390 and Jensen US 6438528, as related to claim 1 above, further in view of Russell US 20130179888.
Regarding claim 2, Modified Parkinson fails to disclose wherein: selecting, by the transaction manager computing device, the transaction request queue comprises performing load balancing for the plurality of configured transaction request queues. However, Russell discloses a load balancing utility (Abstract, and Claim 8), in a message queue, where a message queue holds the transaction request and a load balancing utility monitors the number of messages and “balances the number of transaction requests with the number of applications running’ (Para. 20, “The load balancing system 200 balances the number of messages by starting applications 230 as necessary to complete transaction requests contained in the received messages”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the load balancing of Russell. Doing so ensures efficient processing of the transaction loads.
Modified Parkinson fails to disclose selecting, by the transaction manager computing device, the transaction response queue comprises performing load balancing for the plurality of configured transaction response queues.
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with performing load balancing for all the transaction response queues since it has been held that mere duplication of parts does not hold patentable weight (“In reHarza, 274 F.2d 669, 124 USPQ 378 (CCPA 1960) (Claims at issue were directed to a water-tight masonry structure wherein a water seal of flexible material fills the joints which form between adjacent pours of concrete. The claimed water seal has a “web” which lies in the joint, and a plurality of “ribs” projecting outwardly from each side of the web into one of the adjacent concrete slabs. The prior art disclosed a flexible water stop for preventing passage of water between masses of concrete in the shape of a plus sign (+). Although the reference did not disclose a plurality of ribs, the court held that mere duplication of parts has no patentable significance unless a new and unexpected result is produced”).
Regarding claim 3, modified Parkinson fails to disclose for at least one of the plurality of configured transaction request queues, a plurality of transaction request handlers are associated with the transaction request queue to process multiple transaction requests from the transaction request queue simultaneously. However, Russell discloses processing transaction requests using load balancing utility and multiple operating parameters to process at least one transaction request of the transaction requests associated with the one or more messages in the message queue that have yet to be processed and balancing the number of transaction requests with the number of applications running (Claim 8 and Abstract; Para. 23, “The transaction requests may be processed on an application 230 simultaneously or sequentially. To process the transaction requests, the applications 230 may access databases or files containing information relating to the transaction requests”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the ability to process multiple transaction requests from the transaction response and request simultaneously of Russell. Doing so creates greater efficiency and speeds up the transactions processed.
Claim(s) 4-6 is rejected under 35 U.S.C. 103 as being unpatentable over Parkinson US 20090222823, in view of Dillow US 8578390 and Jensen US 6438528, as related to claim 1 above, further in view of Aoki US 20180089745.
Regarding claim 4, modified Parkinson fails to disclose wherein: the method comprises discarding a transaction request from a transaction request queue if the transaction request exceeds a first predetermined age before being processed. However, Aoki discloses the ability to discard selected transactions (Para. 83, discarding transactions, “If the payment system 112 determines not to process the selected requested transaction, the payment system 112 can discard the selected requested transaction that was de-queued at 450, and select and de-queue a next requested transaction from the transaction queue 216”; Para. 21, “if the second risk analysis indicates that the requested transaction is not to be processed, the payment system may discard the requested transaction, or simply not process the requested transaction”), including a time-defined trigger for de-queuing (Para. 21, “The “queued” items from an accepted cart may be stored in the transaction queue until an event (e.g., a customer-defined trigger, a merchant-defined trigger, a time-defined trigger) causes “de-queuing” of the items for further processing”; Para. 40, “The de-queue module 220 can also select the requested transaction based on Quality of Service (QoS) characteristics of the cart 114, such as priority, timeliness, maximum latency, among others”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the time-defined ability to de-queue of Aoki. Doing so allows the transaction system to increase security and efficiency by eliminating those potential transaction that fail to meet certain criteria for time.
Regarding claim 5, modified Parkinson fails to disclose discarding timed-out transactions, but fails to disclose wherein, after discarding the transaction request from the transaction request queue, the method comprises: sending a transaction failure message to the first network entity.
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with sending a message regarding the discarded message since doing so alerts the user that transaction has filed, and so users of the transaction know if they need to take next steps to re-initiate the transaction of abandon the transaction and to prepare accordingly.
Regarding claim 6, modified Parkinson fails to disclose the method comprises discarding a transaction response from a transaction response queue if the transaction response exceeds a second predetermined age before being processed. However, Aoki discloses different trigger moments such as a customer-defined trigger, merchant-defined trigger and time-defined trigger and the system can have multiple different threshold events that decide to discard a transaction response (Para. 20, The “queued” items from an accepted cart may be stored in the transaction queue until an event (e.g., a customer-defined trigger, a merchant-defined trigger, a time-defined trigger) causes “de-queuing” of the items for further processing”; Para. 25, “the operating parameters may allow the ten transaction requests to process simultaneously”; Para. 62, The de-queue capacity may be indicative of how many requested transactions can be de-queued at the same time, or substantially in parallel”; substantially in parallel is similar to first and second).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with different time moments to discard. Doing so allows the system to have back-up chances to discard a transaction response if necessary, and time certain events for discarding as well.
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Parkinson US 20090222823, in view of Dillow US 8578390 and Jensen US 6438528, as related to claim 1 above, further in view of Haller US 6026379.
Regarding claim 7, modified Parkinson fails to disclose wherein, after discarding the transaction response from a transaction response queue, the method comprises: re-sending the second transaction request to the second network entity. However, Haller discloses detecting a transaction response failure and resending a transaction from the first transaction database with appropriate modifications (Claim 2, “detecting a transaction response failure and resending the corresponding transaction from the first transaction database with appropriate modifications.”).
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with re-sending of a second transaction to a second network of Haller. Doing so allows the system to filter out necessary transactions, while allowing correct transactions to proceed, and avoids bottlenecks in the transaction processing system.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Parkinson US 20090222823, in view of Dillow US 8578390 and Jensen US 6438528, as related to claim 1 above, further in view of Chang US 6105012.
Regarding claim 10, modified Parkinson fails to disclose wherein: the first transaction request comprises a timestamp; and/or the first transaction response comprises a timestamp. However, Chang discloses a financial server and client web browser for transaction processing where the client send a transaction request to the server, and outgoing secure messages include digital signatures and timestamps and that a timestamp is stored in the return message, forming an audit trail that includes “the timestamp of the transaction.” (“The server then processes the transactions and updates an audit trail that tracks each transaction.”; “the web browser can interpret HTML extensions to the FORM tag that specify that an HTML form is encrypted as well as request the return transmission of HTML form data in one of three formats: (1) encrypted; (2) digitally signed with a timestamp; or (3) encrypted and digitally signed with a timestamp”: Fig. 1, 228; Fig. 3, 228)
It would have been considered obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Parkinson with the timestamp in Chang. Doing so ensures greater security for the transaction system.
Allowable Subject Matter
Although still being rejected under 101, Claim 12 is considered allowable subject matter for purposes of a prior art rejection under 102 or 103, given the claims processing of the first transaction response and sending the second transaction response to the first network entity also includes sending, to a third network entity, a third transaction request based on the first transaction; receiving a third transaction response from the third network entity, in response to the third transaction request; selecting a transaction response queue from a plurality of configured transaction response queues; adding the third transaction response to the back of the selected transaction response queue; and when the third transaction response reaches the front of the selected transaction response queue, processing the third transaction response and sending the second transaction response to the first network entity.
Response to Arguments
Applicant's arguments filed 6/5/2026 have been fully considered but they are not persuasive.
Applicant argues that the currently recited claims are not abstract. Examiner disagrees. The currently recited steps recite:
Receiving a transaction request
Selecting one of multiple queues and enqueuing the request
Dequeuing and forwarding a related request to another entity
Receiving a response
Selecting one of multiple response queues and enqueuing the response
Dequeuing and forwarding a final response
These steps are an abstract idea, specifically a method of organizing human activity (commercial, such as managing relationships between people), as well as a mental process that can be performed in human mind or with pen and paper (such as, receive request, choose a list/queue, put it at the end, when it reaches the front act, take action and send something else, and do the same for the reply). The “queues” are ordered lists, and the claim does not recite any particular data structure beyond the abstract concept for ordering in and out.
Applicant also argues that the currently recited claim is integrated into a practical application. Examiner disagrees. The additional element include a transaction manager computing device, the transaction request queues, the transaction response queues and the handlers, as well as the generic network communication between network entities. The claim simply automates the abstract queuing-and forwarding process using conventional computer components.
In Enfish, the court evaluated the patent eligibility of claims related to a self-referential database. Id. The court concluded the claims were not directed to an abstract idea, but rather an improvement to computer functionality. In contrast, the current claims are not directed to an improvement to computer functionality and instead merely recite the computer elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Similarly, in DDR Holdings LLC v. Hotels.com, LP, the claims were found eligible as they reflected improvements to the functioning of a computer, i.e. a modification of conventional Internet hyperlink protocol to dynamically produce a dual-source hybrid webpage. In contrast, the current claims do not contain limitations reflective of an improvement to computer functionality and instead merely recite the computer elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
Applicant argues that the Claims are synonymous with Claim 1, of Example 40 USPTO Subject Guidance. Examiner disagrees. In Claim 1, Example 40, the core idea was an adaptive, condition-based monitoring of network traffic metrics, whereas the currently recited claims deal with ordering and processing of commercial transaction requests and responses via queues. Further, the transaction manager computing device and other elements described above are recited at a high level of generality and amount to “apply it” on a computer, whereas the Claim 1, the network appliance and conditional collection of netflow data produced a concreate technical benefit.
In Finjan, the claims to a “behavior-based virus scan” were found to provide greater computer security and were thus directed to a patent-eligible improvement in computer functionality. In contrast, the current claims do not contain limitations reflective of an improvement to computer functionality and instead merely recite the computer database elements at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component.
The focus of the claims is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. The claims here are not directed to a specific improvement to computer functionality. Rather, they are directed to the use of conventional or generic technology in a well-known environment, without any claim that the invention reflects an inventive solution to any computer specific problem. More specifically, the claims are limited to a business solution to a technical problem, not a technical solution to a technical problem.
Lastly, the claims do not provide an inventive concept. As discussed above, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer. Even when viewed as whole, nothing in the claim adds significantly more (i.e. inventive concept) to the abstract idea. The currently recited claims solve transaction queuing issues, which is not a significant improvement to the functioning of a computer or to any other technology or technical field (MPEP 2106.05(a)).
Applicant argues that Parkinson fails to disclose selecting a transaction request queues from a plurality of configured transaction request queues. However, Applicants argument is moot given the rejection of Dillow.
Further, applicant argues that Parkinson fails to disclose sending a second transaction request to a second network entity. Examiner disagrees. Based on broadest reasonable interpretation, Parkinson teaches that when the request is dequed (reaches the front), the server processes it (transaction request handler functionality) and the processing results in the transaction being performed (“On transaction T2, the server 20 dequeues and services the request from the recoverable request queues 30,” Para. 15). See also Dillow that functions with handlers and threads with specific selected queues that support “handler associated with selected queue.”
Applicant also argues “selecting” for purposes of “selecting a transaction response queue from a plurality of configured transaction request queues.” Examiner disagrees. As noted in the above rejection, Dillow teaches a communications manager that selects and deposits a service request message onto an appropriate service queue chosen from a plurality of service queues (TSCM_SERVICE_nn queues with different service types; Col. 4, Lines 20-60; Col. 6, Lines 20-50; Fig. 4, and service queues 326 and 422).
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 BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693 /Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights