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 .
Remarks
This Office Action is in response to an RCE filed on 12/24/2025.
Independent claims 1, 9 and 13 are currently amended via Applicant’s amendment.
Claims 7 and 19 have been canceled via previous amendment.
Claims 1-6, 8-18 and 20-22 are currently pending.
This Office Action is made non-final after the RCE.
Request Continuation for Examination
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 12/24/2025 has been entered.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. 103 for claims 1-6, 8-18 and 20-22, filed on 09/10/2025, have been fully considered but they are moot in view of new ground of rejections necessitated by the amendment.
Applicant’s arguments, see pages 1-3 of remarks, filed on 12/24/205, with respect to 35 U.S.C. 101 rejection of claims 1-6, 8-18 and 20-22 have been fully considered and are persuasive. The rejection of claims 1-6, 8-18 and 20-22 under 35 U.S.C. 101 has been withdrawn.
Allowable Subject Matter
Claim 4 and 16 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 9, 13-14, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Castinado et al. (US 2021/0311788) (hereinafter Castinado) in view of Khare et al. (US 2022/0230174) (hereinafter Khare), further in view of Upton, Mitch (US 7,721,193) (hereinafter Upton), further in view of Honglin Qiu (US 2019/0310878 A1) (hereinafter Qiu) and further in view of Stephen et al. (US 2010/0017328 A1) (hereinafter Stephen).
As per claim 1, Castinado discloses (Currently Amended) A system comprising: at least one processor (see for example Castinado, this limitation is disclosed such that there is a processing device that includes a microprocessor; paragraph [0034]); and memory storing instructions that, when executed by the at least one processor, causes the system to perform a set of operations (see for example Castinado, this limitation is disclosed such that there is memory with computer-readable program code stored thereon executable by at least one processing device; paragraph [0006]. Also see [0034-0035].), the set of operations comprising: receiving an electronic resource transaction communication associated with a sender and a recipient (see for example Castinado, this limitation is disclosed such that resource request communications are received; Abstract, paragraph [0033]. The requests are electronic resource requests (paragraph [0051]) having a sender of the resource request and a recipient of the resource request; paragraph [0043]); processing the electronic resource transaction communication to extract transaction information from the electronic resource transaction communication, the processing comprising: the extracted transaction information comprising a sender alias and a resource indication (see for example Castinado, this limitation is disclosed such that the resource the resource platform extracts resource transfer metadata from the electronic resource request. Metadata transaction details for the resource request that are extracted include source account information, user identification information, resource type, and destination account information; paragraph [0051]).
Castinado does not explicitly teach generating a transaction entry for an electronic resource transaction communication, wherein the transaction entry comprises the sender alias and the resource indication; and processing a transaction for a resource indicated by the resource indication, thereby transferring the resource from the sender to the recipient. Castinado also fails to disclose evaluating, by the system and based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific communication template from the existing communication templates with which to extract data from the electronic resource transaction communication, wherein the specific communication template comprises: branching logic for processing scenario-specific information of a given electronic resource transaction communication; and a set of data validation rules to validate extracted transaction information.
However, Khare discloses generating a transaction entry for the electronic resource transaction communication, wherein the transaction entry: is associated with the recipient; and comprises the sender alias and the resource indication (see for example Khare, this limitation is disclosed such that resource transaction data is received for one or more resource transactions and stored on a distributed register (i.e. generating a transaction entry). The resource transaction data comprises a resource amount (i.e. resource indication), identification of the sender (i.e. sender alias), and identification of the recipient; paragraph [0005]); processing a transaction for a resource indicated by the resource indication, thereby transferring the resource from the sender to the recipient (see for example Khare, this limitation is disclosed such that the resource transfer activity is executed between user (sender) and entity (recipient); paragraphs [0005], [0025], [0027]).
Castinado in view of Khare is analogous art because they are from the same field of endeavor, task management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Castinado by storing transaction data as taught by Khare because it would enhance the teaching of Castinado with an effective means of improving the efficiency of resolving transactions (as suggested by Khare, see for example paragraph [0003]).
Although Castinado in view of Khare discloses the transaction information comprising a sender alias and a resource indication, Castinado in view of Khare does not explicitly teach evaluating, by the system and based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific communication template from the existing communication templates with which to extract data from the electronic resource transaction communication, wherein the specific communication template comprises: branching logic for processing scenario-specific information of a given electronic resource transaction communication; and a set of data validation rules to validate extracted transaction information; and processing, by the system using the specific communication template, the received electronic resource transaction communication to parse a layout of the electronic resource transaction communication, thereby extracting the transaction information from the layout as defined by the specific electronic communication template; and validating the extracted transaction information according to the set of data validation rules of the specific communication template.
However, Upton discloses evaluating, by the system and based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific communication template from the existing communication templates (see for example Upton, this limitation is disclosed such that there is a system that uses schemas (i.e. communication templates) to validate metadata associated with a request from a client application to an enterprise system (i.e. electronic resource transaction communication); col.2 line {61} – col.3 line {4}, clm.9 and associated text. There are a plurality of XML schemas for use, wherein an XML schema specific to a client application is retrieved when receiving a request from that application; clm. 14, 15 and associated text); processing, by the system using the specific communication template, the received electronic resource transaction communication to parse a layout of the electronic resource transaction communication, thereby extracting the transaction information from the layout as defined by the specific electronic communication template (see for example Upton, this limitation is disclosed such that request metadata (i.e. transaction information) details can be extracted into an XML document that conforms to the XML schema for the client application for a specific request/response; col.6 lines {50}-{64}, col.10 lines {33}-{67}, clm.9 and associated text. [Abstract] “Metadata associated with a request from a client application can be transformed into an XML document that conforms to an XML schema for the client application and portion of the XML document can be validated against the XML schema for the client application. Upton discloses selecting an XML schema for a request, transforming metadata into an XML document that conforms to that schema, and then parsing/extracting portions of the document and validating them against the schema (See Col. 10, lines 45-60). The schema is implied as “specific electronic communication template” and the XML document structure is the “layout” defined by the template.); a set of data validation rules to validate extracted transaction information; and validating the extracted transaction information according to the set of data validation rules of the specific communication template (see for example Upton, this limitation is disclosed such that the request metadata transformed into the XML document is validated against rules specified by the XML schema for the client application; col.6 lines {50}-{64}, col.10 lines {33}-{67}, clm.1 and associated text).
Castinado in view of Khare is analogous art with Upton because they are from the same field of endeavor, task management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method as taught by Castinado in view of Khare by validating request metadata against schemas as taught by Upton because it would enhance the teaching of Castinado in view of Khare with an effective means of extracting and validating many common elements or portions of a request (as suggested by Upton, see for example col.10 lines {33}-{51}).
As discussed above, Castinado and Khare teach receiving electronic resource transaction communications, extracting transaction information, generating transaction entries associated with a recipient including sender alias and resource indication, and processing transaction to transfer the resource from sender to recipient. Upton adds selection of a schema for a given request and parsing/validating according to the schema, but Upton selects schemas primarily by client/application, not by evaluating, based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific template. Furthermore, Upton’s schema rules are structural validation constraints rather than branching logic for scenario-specific outcomes. The combination of Castinado, Khare and Upton implies but does not expressly disclose evaluating, by the system and based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific communication template from the existing communication templates; wherein the specific communication template comprises: branching logic for processing scenario-specific information of a given electronic resource transaction communication.
However, Qiu discloses the processing comprising: evaluating, by the system and based on the electronic resource transaction communication, a plurality of existing communication templates to identify a specific communication template from the existing communication templates with which to extract data from the electronic resource transaction communication (e.g. Qiu: [0008-0012] discloses transaction processing method and apparatus, the method receives a transaction request for a target transaction, determines a transaction type of the target transaction, and then loads a transaction template that matches the transaction type of the target transaction. Loading a transaction template matching a transaction type of the target transaction comprises selecting the transaction template matching the transaction type from a plurality of configured transaction templates. [0045-0050] discloses transaction processing node receives a transaction request and determines a transaction type of the target transaction included in the transaction request. After the transaction processing node receives the transaction request, the node may determine which transaction template from the pre-stored transaction templates is able to process the target transaction included in the transaction request based on the transaction type. Also see [0017-0019] [0077] [0079] [0110] [claim 3].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Qiu’s template-selection mechanism into the combination of Castinado, Khare and Upton Qiu addresses the technical problem of efficiently supporting multiple transaction types using different transaction template. The combination of Castinado, Khare and Upton provides: (i) end-to-end resource transaction processing and transfer between sender and recipient (Castinado/Khare), and (ii) schema-based parsing and validation of the request for different clients (Upton), but it lacks and explicit mechanism to evaluate a plurality of templates per transaction type and dynamically select a specific template based on transaction-level characteristics derived from the communication itself. A POSITA would be motivated to incorporate Qiu’s template-selection mechanism into the existing system so that, upon receiving an electronic transaction communication, the system: derives transaction level-characteristics from the communication, evaluates a plurality of existing templates to determine a specific template that matches the transaction type, and then use that specific template, in conjunction with Upton-style schema parsing/validation, to extract transaction information before generating entries and executing transfers. Doing so would predictably increase flexibility and maintainability, allow the platform to support new communication formats or transaction types by adding or modifying templates rather than rewriting core logic, consistent with Qiu’s stated advantages of template-based transaction processing. Under KSR, this is a straightforward use of a known template-selection strategy from an analogous transaction-processing context to improve a similar template-driven resource transaction system.
As discussed above, the combination teaches multiple communication templates/schemas, evaluating those templates and selecting a specific template per transaction type (Qiu); using the selected template to define layout and extract data (Upton+Qiu); structural/data validate of extracted information against template/schema rules (Upton); and the transaction template comprising one or more rules (e.g. Qiu: [0015] check rule in the one or more rules to check whether the transaction request satisfies a preset condition according to the check rule; in response to determining that the request satisfies the preset condition, processing the transaction according to a processing rule; and in response to determining that the request does not satisfy the preset condition, prompting that the target transaction processing fails. Qiu also discloses [0019] obtaining transaction information and processing the transaction according to the transaction template). The combination of Castinado, Khare, Upton and Qiu does not expressly disclose wherein the specific communication template comprises: branching logic for processing scenario-specific information.
However, Stephen discloses wherein the specific communication template comprises: branching logic for processing scenario-specific information of a given electronic resource transaction communication; and a set of data validation rules to validate extracted transaction information (e.g. Stephen: [0016] [0018] discloses predefined template condition comprises specific placeholders for conditions, values and logical operators. Each template comprises and associated action which is the action to be taken if, upon evaluation, the template condition evaluates to “true”. [0110-0114] discloses conditions over transaction message field (e.g., Amount, MerchantCountry) with logical operators (AND, OR) and associated action (decline, pass to issuer, advise fraud manager, send notification) taken when those conditions evaluate to “true.” [Fig. 7 and related description] If the number prefix is that of a valid product in step 104 system rules are applied…Otherwise, in step 105 product rules are applied…Otherwise, the Cardholder rules are applied in step 106. The three possible outcomes are: decline, approve and pass to CMS. Stephen teaches applying rule-template conditions over authorization request data elements and taking actions (decline, pass, fraud queue, notify) depending on whether the conditions to true or false. This is validation of the transaction information according to template-specific rules. [0130] discloses templates have specific placeholders for conditions, values and logical operators. Also see [0117-0118] [Fig. 8] [0130-0153]. Thus, Stephen expressly discloses template-level branching logic that processes scenario-specific transaction information and drive different per-transaction outcomes.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of template comprising branching logic as taught by Stephen into the combination of Castinado, Khare, Upton and Qiu because Stephen is directed specifically to real-time authorization of payment transaction using cardholder, product, and system template rules, and provides a detailed, field-level rule-template and branching logic model that sits in the authorization chain and determines whether each transaction is declined, passed to issuer or flagged, with associated notifications. A POSITA would have recognized that integrating Stephen’s rule-template engine into a template-driven transaction-processing system such as Castinado/Khare/Upton/Qiu would be a predictable way to: enhance fraud-control and authorization decision using branching logic embedded in the selected communication template; and use the same template both to validate extracted transaction information against per-scenario conditions and to select an appropriate outcome, thereby satisfying the dual role of branching logic and validation rules in the specific communication template. Under KSR, combining Stephen’s known rule-template and branching logic mechanism with the existing template-selection and parsing framework of Castinado/Khare/Upton/Qiu would be predictable use of prior-art elements according to their established functions—namely improving transactional control, fraud mitigation, and scenario-specific decision making in electronic payment authorization and processing.
As per claim 2, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 1 [See rejection to claim 1 above], wherein: the electronic resource transaction communication is a first electronic resource transaction communication; the sender is a first sender; the sender alias is a first sender alias; the resource indication is a first resource indication; the transaction entry is a first transaction entry; and the set of operations further comprises: receiving a second electronic resource transaction communication associated with a second sender and the recipient, wherein the second sender is different from the first sender; and generating, based on the second electronic resource transaction communication, a second transaction entry associated with the recipient (see for example Khare, this limitation is disclosed such that there are one or more resource transactions (i.e. a first and second inclusive) for which resource transaction data is received and stored to the register; paragraph [0005]).
As per claim 9, this is a method claim having similar limitations as cited in system claim 1. Thus, claim 9 is also rejected under the same rationale as cited in the rejection of rejected claims 1. Khare further discloses generating a transaction entry for the electronic resource transaction communication; and storing, in a data store, the transaction entry in association with the recipient (see for example Khare, this limitation is disclosed such that resource transaction data is received for one or more resource transactions and stored on a distributed register (i.e. generating a transaction entry). The resource transaction data comprises a resource amount (i.e. resource indication), identification of the sender (i.e. sender alias), and identification of the recipient; paragraph [0005]).
As per claims 13 and 14, these are method claims having similar limitations as cited in system claims 1 and 2, respectively. Thus, claims 13 and 14 are also rejected under the same rationale as cited in the rejection of rejected claims 1 and 2, respectively.
As per claim 21, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 2 [see rejection of claim 2 above], wherein a second electronic communication is processed according to a different communication template than a first electronic resource communication (e.g. Qiu: [0045] expressly discloses “transaction templates may be pre-stored in the transaction processing node, and different transaction templates correspond to different transaction processing jobs; therefore, after the transaction processing node receives the transaction request sent by the user, the transaction processing node may determine which transaction template from the pre-stored transaction templates is able to process the target transaction included in the transaction request. The transaction processing node stores transaction templates corresponding to transaction types. Therefore, in the process of determining which transaction template is able to process the target transaction included in the transaction request, the transaction processing node may determine the transaction type of the target transaction, then determine the transaction template corresponding to the transaction type according to the pre-stored relationship between transaction types and transaction templates, and further process the target transaction included in the transaction request through the transaction template.” [0073] “after the transaction processing node receives transaction requests for these four types of transactions, the transaction processing node may load the pre-stored four types of transaction templates to process target transactions included in the four types of transaction requests, wherein the four types of transaction requests may be a tracing template, an authentication template, a contract template, and an exchange template, respectively.” Also see [0075-0080]. Thus, Qiu discloses using a plurality of transaction templates, each for a different transaction type; each transaction request causes loading of the template matching its transaction type. And different requests with different transaction types are processed according to different transaction templates.).
As per claim 22, this is a method claim having similar limitations as cited in system claim 21. Thus, claim 22 is also rejected under the same rationale as cited in the rejection of rejected claim 21.
Claims 3 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Castinado, Khare, Upton, Qiu, Stephen and further in view of Tang et al. (US 2020/0265046) (hereinafter Tang).
As per claim 3, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 2 [see rejection of claim 2 above], but does not explicitly teach wherein the second transaction entry is an aggregated transaction entry for the first electronic resource transaction communication and the second electronic resource transaction communication.
However, Tang discloses wherein the second transaction entry is an aggregated transaction entry for the first electronic resource transaction communication and the second electronic resource transaction communication (see for example Tang, this limitation is disclosed such that recorded transactions are tagged with a group identifier if they are for the same event, creating an event access record (i.e. there is a group of a plurality of transactions, a first resource transaction communication and second resource transaction communication inclusive); paragraph [0036]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine method of grouping or aggregating transaction entries as taught by Tang into the combination of Castinado, Khare, Upton, Qiu and Stephen because it would provide an effective means for applying event access policies to event transactions (as suggested by Tang, see for example paragraph [0036]).
As per claim 15, this is a method claim having similar limitations as cited in system claim 3. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of rejected claim 3.
Claims 5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Castinado, Khare, Upton, Qiu, Stephen and further in view of view of Barton, Loren (US 2014/0095334) (Hereinafter Barton).
As per claim 5, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 1 [see rejection of claim 1 above], but does not explicitly teach wherein the transaction is processed automatically as a result of a determination that the generated transaction entry is eligible for automatic processing.
However, Barton discloses wherein the transaction is processed automatically as a result of a determination that the generated transaction entry is eligible for automatic processing (see for example Barton, this limitation is disclosed such that for a record transaction, if the recorded data specifies eligibility, a process is initiated automatically to complete the transaction; paragraph [0021]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine method of automatically processing transaction based on eligibility as taught by Barton into the combination of Castinado, Khare, Upton, Qiu and Stephen because it would provide an effective means for quickly and easily upgrading transactions (as suggested by Barton, see for example paragraph [0007]).
As per claim 17, this is a method claim having similar limitations as cited in system claim 5. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of rejected claim 5.
Claims 6 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Castinado, Khare, Upton, Qiu, Stephen and further in view of view of Rapolu et al. (US 2022/0209952) (hereinafter Rapolu).
As per claim 6, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 1 [see rejection of claim 1 above], but does not explicitly teach wherein a transaction is processed in response to receiving, from a computing device associated with a recipient, an indication to process the transaction entry.
However, Rapolu discloses wherein a transaction is processed in response to receiving, from a computing device associated with a recipient, an indication to process the transaction entry (see for example Rapolu, this limitation is disclosed such that verification of a resource transaction request causes processing or rejection of a transaction, initiated by a recipient computer; paragraph [0127]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of processing transaction in response to receiving such indication from a recipient as taught by Rapolu into the combination of Castinado, Khare, Upton, Qiu and Stephen because it would allow a sender to share a credential of the sender with the recipient of a request (as suggested by Rapolu, see for example paragraphs [0005]-[0006]).
As per claim 18, this is a method claim having similar limitations as cited in system claim 6. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of rejected claim 6.
Claims 8, 10-11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Castinado, Khare, Upton, Qiu, Stephen and further in view of view of Bozkaya et al. (US 2017/0075953) (hereinafter Bozkaya).
As per claim 8, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The system of claim 1 [see rejection of claim 1 above], but does not explicitly teach, based on determining that transaction information was not successfully extracted, performing alternative processing of the electronic resource transaction communication to generate the transaction information.
However, Bozkaya discloses, based on determining that the transaction information was not successfully extracted, performing alternative processing of the electronic resource transaction communication to generate the transaction information (see for example Bozkaya, this limitation is disclosed such that when parsing a query (i.e. extracting transaction information), when there is a failure at parsing the query, the system can request an alternate parse of the query; paragraph [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of requesting/retrying alternate parse/extraction process upon unsuccessful extraction as taught by Bozkaya into the combination of Castinado, Khare, Upton, Qiu and Stephen because it would provide an effective means for dealing with failure at different states of query/transaction processing (as suggested by Bozkaya, see for example paragraph [0038]).
As per claim 10, the combination of Castinado, Khare, Upton, Qiu and Stephen discloses The method of claim 9 [see rejection of claim 9 above], but does not explicitly teach determining that the transaction information was not successfully extracted; and performing alternative processing of the electronic resource transaction communication to generate the transaction information.
However, Bozkaya discloses determining that the transaction information was not successfully extracted; and performing alternative processing of the electronic resource transaction communication to generate the transaction information (see for example Bozkaya, this limitation is disclosed such that when parsing a query (i.e. extracting transaction information), when there is a failure at parsing the query, the system can request an alternate parse of the query; paragraph [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of requesting/retrying alternate parse/extraction process upon unsuccessful extraction as taught by Bozkaya into the combination of Castinado, Khare, Upton, Qiu and Stephen because it would provide an effective means for dealing with failure at different states of query/transaction processing (as suggested by Bozkaya, see for example paragraph [0038]).
As per claim 11, the combination of Castinado, Khare, Upton, Qiu, Stephen and Bozkaya discloses The method of claim 10 [see rejection of claim 10 above], wherein alternative processing comprises at least one of: determining a fallback communication template from a fallback set of communication templates; or receiving user input to at least one of: update the determined template; or modify the extracted transaction information (see for example Bozkaya, this limitation is disclosed such that alternative parse include prompting a user to clarify a value of a query; paragraph [0038]. Qiu: also implies the fallback template / new template concept. For example, Qiu discloses [0012] “in response to determining that there is no transaction template matching the transaction type in the plurality of configured transaction templates, generating the transaction template matching the transaction type; and loading the generated transaction template.” [0051-0052] “after the transaction nodes determines that there is no transaction template matching the transaction type in the pre-configured transaction templates. Namely, none of the transaction template is able to process the target transaction included in the transaction request. Then, the node may generate a transaction template [a fallback communication template] capable of processing the target transaction according to the transaction code input by the user, and then process the target transaction through the generated template.” Also see [0053-0054][0102].).
As per claim 20, this is a method claim having similar limitations as cited in system claim 8. Thus, claim 20 is also rejected under the same rationale as cited in the rejection of rejected claim 8.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Castinado, Khare, Upton, Qiu, Stephen, Bozkaya and further in view of view of Ramavarjula et al. (US 2008/0015987) (Hereinafter Ramavarjula).
As per claim 12, the combination of Castinado, Khare, Upton, Qiu, Stephen and Bozkaya discloses The method of claim 11 [see rejection of claim 11 above], but does not explicitly teach wherein transaction information further comprises authorization information and a link; the method further comprises obtaining, based on the link, additional transaction information from a computing device associated with the link; and a transaction entry further comprises the authorization information and the obtained additional transaction information.
However, Ramavarjula discloses wherein the transaction information further comprises authorization information and a link (see for example Ramavarjula, this limitation is disclosed such that a transaction request includes an additional piece of information for verification and a customized hyperlink; paragraphs [0036], [0040]); the method further comprises obtaining, based on the link, additional transaction information from a computing device associated with the link (see for example Ramavarjula, this limitation is disclosed such that using the verification technique requested, including the customized hyperlink, additional information is collected; paragraphs [0036], [0040]); and a transaction entry further comprises the authorization information and the obtained additional transaction information (see for example Ramavarjula, this limitation is disclosed such that the information of the request including additional information is included into a transaction record; paragraphs [0036], [0040]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method/system of collecting additional information via customized hyperlink as taught by Ramavarjula into the combination of Castinado, Khare, Upton, Qiu, Stephen and Bozkaya because it would provide an effective means for verifying transaction (as suggested by Ramavarjula, see for example paragraph [0036]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bansal et al. (US 2021/0374689 A1) discloses “[0029] the trained model of the server system is configured to generate a plurality of authentication templates based at least on the plurality of user authentication factors received by the user device at pre-defined time intervals. An authentication key is further generated based on the plurality of authentication templates. The server system is configured to decrypt the transaction request message using the authentication key generated by the trained data model. After the decryption, the server system is configured to match the real-time user authentication factors with the plurality of authentication templates. If a match is found, the user is authenticated. Upon successful authentication, the server system is further configured to parse the transaction request message to determine a scheduled transaction instruction. The scheduled transaction instruction may include transaction information such as a payer account number, a recipient account number, amount of transaction, time and date for the transaction, etc. In cases where the user's bank and the recipient's bank are the same, only the recipient's mobile number is sufficient for the server system to process the payment.” “[0047] If the real-time user authentication factors decrypted from the transaction request message match with the plurality of user authentication templates, the server system 106 confirms the authenticity of the user 102. After successful authentication, the server system 106 is configured to parse the transaction request message to determine transaction information. The transaction information may include user account number, recipient account number and IFSC code, a sum of the payment amount, scheduled time for the payment, etc.” “[0065] If a match is found between the decrypted real-time user authentication factors and the stored authentication templates, the authenticity of the user 102 is confirmed. If a match is not found, the scheduled payment is cancelled by the server system 106. Upon successful authentication, the processor 120 is configured to parse the transaction information present in the decrypted transaction request message to determine a valid scheduled transaction instruction. The transaction information may include the name and account details of the user, name and account details of the recipient, transaction amount, and the scheduled time for payment. Based on the transaction information, the processor 120 is configured to forward a payment processing request to a payment network server such as the payment server 114 of FIG. 1. The processor 120 is configured to send the payment processing request to the payment server 114 when the current time is equal to the scheduled time.” “[0081] At 430, the server system 106 is configured to decrypt the transaction request message received from the user device 104. The decryption is facilitated using the authentication key generated by the processor 120 of the server system 106 as described in the step 320 of FIG. 3. In an embodiment, the authentication key is capable of decrypting the transaction request message which is encrypted using the encryption key. The authentication key is updated based on the updated authentication templates. In the example, the decrypted message may retrieve the transaction information such as user name and account—stored in the application, recipient account number—112233xy, IFSC code—XYZ69, amount—5,000 INR and scheduled time—4 PM today and the real-time user authentication factors which were encrypted by the payment application 118.”
Jain (US 10,489,758 B1) “A computer-implemented method for generating a payment file at a payor computing system containing a payment configuration computer and a network gateway, the payor computing system being remote from a payment facilitation computing system, the method comprising: receiving, by the payment configuration computer, a request instructing the payment configuration computer to initiate for a payment to a beneficiary using at least a template file within a plurality of template files previously received from the payment facilitation computing system; responsive to receiving the request, automatically identifying, by the payment configuration computer, a single template file from the plurality of template files in a database that is associated with the beneficiary in the request, wherein the identified template file contains a plurality of data fields and logic instructions configured to cause the payment configuration computer to generate the payment file and to modify the plurality of data fields of the identified template file; modifying, by the payment configuration computer, the identified template file based on determining which data fields to dynamically select based on the request for the payment, determining which information to extract for the included data fields, and formatting a data field based on the request for the payment according to the logic instructions; executing, by the payment configuration computer, an executable file based on the logic instructions in the identified template file to: scan and extract, by the payment configuration computer, information from the database to complete the data fields of the modified template file configured for the beneficiary; and generate and transmit, by the payment configuration computer via the network gateway to a file exchange server of the payment facilitation computing system, the payment file by completing the data fields of the modified template file according to the logic instructions configured based on the request for the payment, whereby the file exchange server validates the payment file before dissemination.”
Campbell et al. (US 2009/0150287 A1)
Aroli Veettil (US 2021/0118019 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
February 20, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196