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 .
Status of Claims
• Claims 1-20 are currently pending and have been examined.
• This action is made Non-FINAL.
• The Examiner would like to note that this application is now being handled by Examiner Raven Yono.
Examiner Note
The Examiner notes the claims are not rejected under 35 USC 101.
The claimed invention recites limitations including: receiving a wire request transmitted from a first wire-transfer application… the wire request having a first protocol that is compatible with the first wire-transfer application and incompatible with a second wire-transfer application; generating a translated wire request by translating the wire request from the first protocol to a second protocol, wherein the second protocol is compatible with a second interface for the second wire-transfer application, and wherein the wire request is translated from the first protocol to the second protocol to prevent an interoperability problem between the first wire-transfer application and the second wire-transfer application, wherein generating the translated wire request involves: identifying a first configuration of fields in the wire request, wherein the first configuration of fields differs from a second configuration of fields required by the second protocol; and adjusting the fields in the wire request to the second configuration; and transmitting the translated wire request to the second wire-transfer application, wherein the second wire-transfer application is configured to process the translated wire request.
These are meaningful limitations that are more than applying the use of the abstract idea to a computer or generally linking the use of the judicial exception to a particular technological environment or field of use. These limitations, in combination, are indicative of a practical application. The claims address operability issues associated with communication between applications that communicate in different protocols. The claims provide a solution by translating a first message received by a first application in a first format by re-ordering message fields to comply with an order required by a second protocol of a second application that receives the translated message. The Specification at [0007]-[0008] states:
“The processing application and the third-party application may have different interfaces and different protocols for transmitting data related to the wire request. This may lead to interoperability problems resulting from incompatibilities of the protocols. In particular, the computing environment executing the processing application may have difficulty executing processing operations if the protocols do not match. For example, the computing environment may not process wire transfers as efficiently or may fail altogether as a result of the incompatibility between the protocols… Some examples of the present disclosure overcome one or more of the abovementioned problems by using an application programming interface that can receive wire requests transmitted through an interface for a third-party application with a particular protocol. The application programming interface can translate the wire requests to another protocol required by an application that processes wire requests. Thus, wire requests can be transmitted through third-party applications, without requiring requests to be transmitted to the processing application… These translations can avoid the interoperability issues described above, thereby reducing wasteful consumption of bandwidth and computing resources.”
Furthermore, as an ordered combination, the claim limitations are also not well-understood, routine, or conventional.
For the reasons stated above, claims 1-20 have been deemed to be patent eligible under 35 U.S.C. §101.
Double Patenting
Claims 1-20 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Pat. No. 12,298,930. Although the claims at issue are not identical, they are not patentably distinct from each other because both claims speak to receiving a wire request transmitted from a first wire-transfer application executed by a client device, the wire request being a request to perform a wire transfer between two entities, the wire request being provided via a first interface for the first wire- transfer application, and the wire request having a first protocol that is compatible with the first wire-transfer application and incompatible with a second wire-transfer application; generating a translated wire request by translating the wire request from the first protocol to a second protocol, wherein the second protocol is compatible with a second interface for the second wire-transfer application, and wherein the wire request is translated from the first protocol to the second protocol to prevent an interoperability problem between the first wire-transfer application and the second wire-transfer application, wherein generating the translated wire request involves: identifying a first configuration of fields in the wire request, wherein the first configuration of fields differs from a second configuration of fields required by the second protocol; and adjusting the fields in the wire request to the second configuration; and transmitting the translated wire request to the second wire-transfer application, wherein the second wire-transfer application is configured to process the translated wire request. The claims differ in the fact that claims 1-20 of U.S. Pat. No. 12,298,930 teaches limitations omitted from the instant application. Outside of this difference, the claims are substantially similar. Therefore, since the claims of U.S. Pat. No. 12,298,930 anticipates every limitation of the instant application’s independent claims, the claims are being rejected as being double-patenting (see MPEP 804(II)(B)(2)).
Dependent claims 2-7, 9-14, and 16-20 of the instant application recite substantially similar limitations to those of claims 2-7, 9-14, and 16-20 of U.S. Pat. No. 12,298,930, and therefore are anticipated by U.S. Pat. No. 12,298,930.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210182809 A1 (“Sukhija”) in view of US 20240289809 A1 (“Srivastava”).
Regarding claim 1, Sukhija discloses a system comprising: a processing device; and a memory storing instructions that are executable by the processing device for causing the processing device to perform operations including (see at least [0063]-[0071] and FIG. 2.):
receiving a request transmitted from a first application executed by a client device, the request being a request to perform a transfer between two entities (Receiving a payment transaction message for transferring funds from a user associated with a user device to a merchant associated with a merchant system. See at least [0072]-[0073] and FIG. 3, step 302. User device initiates the transaction, see at least [0091]. User device may include an application associated with user device (e.g., an application stored on user device such as a mobile device application, a native application for a mobile device, a mobile cloud application for a mobile device, an electronic wallet application, a peer-to-peer payment transfer application, and/or the like). See at least [0054].),
the request being provided via a first interface for the first application (User device initiates the transaction, see at least [0091]. User device may include an application associated with user device (e.g., an application stored on user device such as a mobile device application, a native application for a mobile device, a mobile cloud application for a mobile device, an electronic wallet application, a peer-to-peer payment transfer application, and/or the like). See at least [0054]. Determining a plurality of application programming interface (API) fields of the payment transaction message. See at least [0075] and FIG. 3, step 304.),
and the request having a first protocol that is compatible with the first application and incompatible with a second application; generating a translated request by translating the request from the first protocol to a second protocol (Receiving a second payment transaction message from an acquirer system, the transaction message associated with different data, see at least [0094] and see also FIG. 4C, transaction message with fields for “Address Verification,” “Payment Installation,” and “Transaction Value.” Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message. The Examiner is interpreting the fields of the Second Payment Transaction Message as the first protocol. The Examiner interprets the fields of the First Payment Transaction Message as the second protocol. The Examiner also interprets modifying a transaction message as generating a translated request.),
wherein the second protocol is compatible with a second interface for the second application (First Payment Transaction Message and Second Payment Transaction Message may each be associated with different acquirer systems or issuer systems, see at least [0093]-[0094]. Systems may include computing devices and software applications, see at least [0050], and acquirer systems, see at least [0053].), and
wherein the wire request is translated from the first protocol to the second protocol to prevent an interoperability problem between the first application and the second application (Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message. Increasing success rate for processing payment transactions, see at least [0099].),
wherein generating the translated request involves: identifying a first configuration of fields in the request, wherein the first configuration of fields differs from a second configuration of fields required by the second protocol; and adjusting the fields in the request to the second configuration (Receiving a second payment transaction message from an acquirer system, the transaction message associated with different data, see at least [0094] and see also FIG. 4C, transaction message with fields for “Address Verification,” “Payment Installation,” and “Transaction Value.” Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message.); and
transmitting the translated request to the second application, wherein the second application is configured to process the translated request (Transmitting the modified second payment transaction through the payment processing network to the issuer system for processing the request, see at least [0099] and see at least FIG. 4G. Request may be a request to transfer funds from one account to another, see at least [0077].).
While Sukhija discloses a request, Sukhija does not expressly disclose the request is a wire request. Furthermore, while Sukhija discloses applications, Sukhija does not expressly disclose the applications are wire-transfer application. Furthermore, while Sukhija discloses a transfer between entities, Sukhija does not expressly disclose a wire transfer between two entities. Furthermore, while Sukhija discloses a translated request, Sukhija does not explessly disclose a translated wire request.
However, Srivastava discloses the request is a wire request (transaction request may be for a wire transaction, see at least [0050]-[0052].);
the applications are wire-transfer application (Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045].);
a wire transfer between two entities (transaction request may be for a wire transaction, see at least [0050]-[0052]. Sending funds from payor account to payee account, see at least [0240], and see also [0278].);
a translated wire request (Transactions may be sent to transaction exchange platform via application programming interfaces (APIs). The APIs may validate aspects of the transaction details, and may package and/or standardize transactions into transaction objects suitable for processing on transaction exchange platform. In some implementations, transaction exchange platform may provide different APIs for each type of transaction. For example, API may correspond to ACH transactions while API corresponds to wire transactions See at least [0058].).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the request of Sukhija to be a wire request, as taught by Srivastava, and to modify the applications of Sukhija to be wire-transfer applications, as taught by Srivastava, and to modify the transfer between two entities of Sukhija to be a wire transfer between the two entities, as taught by Srivastava, and to modify the translated request of Sukhija to be a translated wire request, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 2, the combination of Sukhija and Srivastava disclose the limitations of claim 1, as discussed above. Sukhija does not expressly disclose receiving an indication of an error with respect to the translated wire request from the second wire-transfer application; in response to receiving the indication of the error, generating an error notification according to the first protocol; and transmitting the error notification to the first wire-transfer application.
However, Srivastava discloses receiving an indication of an error with respect to the translated wire request from the second wire-transfer application; in response to receiving the indication of the error, generating an error notification according to the first protocol; and transmitting the error notification to the first wire-transfer application (The validation platform may analyze the transaction to determine whether the transaction complies with the requirements set forth by the clearinghouse. Part of this analysis may include the validation platform determining whether the format of the transaction is valid. If the format of the transaction is invalid, the validation platform may deny the transaction. As part of the denial, the validation platform may send the transaction to the transaction exchange platform to remediate the issues (e.g., problems) identified by the validation platform. Additionally or alternatively, the validation platform may generate an alert. In this regard, the validation platform may send the alert to an administrator and/or a party to the transaction (e.g., payor, payee, financial institution of the payor, financial institution of the payee, etc.). The alert may identify the issue (e.g., problem) and/or one or more actions for remediating the issue. See at least [0247]. See also [0231]. Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045]. Alert may be sent to administrator via push notification or a notification in one or more applications, see at least [0253]. The Examiner interprets the validation platform as a second wire-transfer application. And, the Examiner interprets the administrator receiving the notification in an application as transmitting the error notification to the first wire-transfer application.).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Sukhija to receive an indication of an error with respect to the translated wire request from the second wire-transfer application, as taught by Srivastava, and to modify Sukhija to generate an error notification according to the first protocol in response to receiving the indication of the error, as taught by Srivastava, and to modify Sukhija to transmit the error notification to the first wire-transfer application, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 3, the combination of Sukhija and Srivastava discloses the limitations of claim 2, as discussed above. Sukhija does not expressly disclose subsequent to transmitting the error notification: receiving a correction to the first wire-transfer application; generating a translated correction by translating the correction from the first protocol to the second protocol; and transmitting the translated correction to the second wire-transfer application.
However, Srivastava discloses subsequent to transmitting the error notification: receiving a correction to the first wire-transfer application; generating a translated correction by translating the correction from the first protocol to the second protocol; and transmitting the translated correction to the second wire-transfer application (The request processor may perform a validation check on the received transaction object to ensure that the format of the received transaction object complies with the format of the downstream processor. The request processor may assign a batch identifier to the received transaction object, as well. The batch identifier may be another important layer in preventing the processing of duplicate transactions. That is, when the request processor receives a transaction, the request processor may append the batch identifier to each transaction, for example, after clearing the format check. See at least [0016]. If the format of the transaction is invalid, the validation platform may deny the transaction. As part of the denial, the validation platform may send the transaction to the transaction exchange platform to remediate the issues (e.g., problems) identified by the validation platform. Additionally or alternatively, the validation platform may generate an alert. In this regard, the validation platform may send the alert to an administrator and/or a party to the transaction (e.g., payor, payee, financial institution of the payor, financial institution of the payee, etc.). The alert may identify the issue (e.g., problem) and/or one or more actions for remediating the issue. See at least [0247]. See also [0231]. If transaction object contains errors, screening microservice may determine one or more remedial actions to cure the errors. In some instances, screening microservice may send a request to correct the deficiencies (e.g., errors, flaws), and, in response to receiving approval, perform the remedial action. The remediated transaction object may then be processed according to a workflow of the transaction object. See at least [0229]. Re-submitting and re-processing transaction, see at least [0206], and see also [0156]-[0157].).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Sukhija to receive a correction to the first wire-transfer application subsequent to transmitting the error notification, as taught by Srivastava, and to modify Sukhija to generate a translated correction by translating the correction from the first protocol to the second protocol, as taught by Srivastava, and to modify Sukhija to transmit the translated correction to the second wire-transfer application, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 4, the combination of Sukhija and Srivastava discloses the limitations of claim 1, as discussed above, and Sukhija further discloses the second application is configured to generate an automated process for processing the translated request, prior to performing the transfer between the two entities associated with the request (Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message. Fields include value of the funds transfer, see at least [0094]- [0097] and FIG. 4E. Transmitting the modified second payment transaction through the payment processing network to the issuer system for processing the request, see at least [0099] and see at least FIG. 4G. Request may be a request to transfer funds from one account to another, see at least [0077].).
While Sukhija discloses applications, Sukhija does not expressly disclose wire-transfer applications. Furthermore, while Sukhija discloses a translated request, Sukhija does not expressly disclose a translated wire request. Furthermore, while Sukhija discloses a transfer, Sukhija does not expressly disclose a wire transfer.
However, Srivastava discloses wire-transfer applications (Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045].);
a translated wire request (Transactions may be sent to transaction exchange platform via application programming interfaces (APIs). The APIs may validate aspects of the transaction details, and may package and/or standardize transactions into transaction objects suitable for processing on transaction exchange platform. In some implementations, transaction exchange platform may provide different APIs for each type of transaction. For example, API may correspond to ACH transactions while API corresponds to wire transactions See at least [0058].);
a wire transfer (transaction request may be for a wire transaction, see at least [0050]-[0052]. Sending funds from payor account to payee account, see at least [0240], and see also [0278].).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the applications of Sukhija to be wire-transfer applications, as taught by Srivastava, and to modify the translated request of Sukhija to be a translated wire request, as taught by Srivastava, and to modify the transfer of Sukhija to be a wire transfer, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 5, the combination of Sukhija and Srivastava discloses the limitations of claim 4, as discussed above, and Sukhija further discloses the second application is configured to generate the automated process for processing the translated request based on one or more characteristics of the translated request (Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message. Fields include value of the funds transfer, see at least [0094]- [0097] and FIG. 4E. Transmitting the modified second payment transaction through the payment processing network to the issuer system for processing the request, see at least [0099] and see at least FIG. 4G. Request may be a request to transfer funds from one account to another, see at least [0077].).
While Sukhija discloses applications, Sukhija does not expressly disclose wire-transfer applications. Furthermore, while Sukhija discloses a translated request, Sukhija does not expressly disclose a translated wire request.
However, Srivastava discloses wire-transfer applications (Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045].);
a translated wire request (Transactions may be sent to transaction exchange platform via application programming interfaces (APIs). The APIs may validate aspects of the transaction details, and may package and/or standardize transactions into transaction objects suitable for processing on transaction exchange platform. In some implementations, transaction exchange platform may provide different APIs for each type of transaction. For example, API may correspond to ACH transactions while API corresponds to wire transactions See at least [0058].).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the applications of Sukhija to be wire-transfer applications, as taught by Srivastava, and to modify the translated request of Sukhija to be a translated wire request, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 6, the combination of Sukhija and Srivastava discloses the limitations of claim 4, as discussed above, and Sukhija further discloses the second application is configured to, subsequent to generating the automated process for processing the translated request: perform the automated process to process the translated request; in response to performing the automated process, transmit the processed request to perform the transfer between the two entities requested by the request (Transmitting the modified second payment transaction through the payment processing network to the issuer system for processing the request, and transmitting along a route for successful processing, see at least [0099] and see at least FIG. 4G. Request may be a request to transfer funds from one account to another, see at least [0077].).
While Sukhija discloses applications, Sukhija does not expressly disclose wire-transfer applications. Furthermore, while Sukhija discloses a translated request, Sukhija does not expressly disclose a translated wire request. Furthermore, while Sukhija discloses a request, Sukhija does not expressly disclose a wire request. Furthermore, while Sukhija discloses transmitting, Sukhija does not expressly disclose transmitting to a third wire-transfer application configured to perform the transfer. Furthermore, while Sukhija discloses a transfer, Sukhija does not expressly disclose a wire transfer. Furthermore, Sukhija does not expressly disclose subsequent to transmitting the processed wire request to the third wire-transfer application, receive a status update related to the transmitted wire request; and transmit the status update to the first wire-transfer application.
However, Srivastava discloses wire-transfer applications (Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045].);
a translated wire request (Transactions may be sent to transaction exchange platform via application programming interfaces (APIs). The APIs may validate aspects of the transaction details, and may package and/or standardize transactions into transaction objects suitable for processing on transaction exchange platform. In some implementations, transaction exchange platform may provide different APIs for each type of transaction. For example, API may correspond to ACH transactions while API corresponds to wire transactions See at least [0058].);
transmitting to a third wire-transfer application configured to perform the transfer (The computer-implemented method may then transfer, by the adjudicator microservice and based on a determination that sufficient funds exist in the first account, funds from the first account to a second account prior to submitting the second file for processing by the automated clearinghouse. See at least [0292]. Transaction may be a wire transfer, see at least [0050]-[0052] and [0093]. Functions performed by applications on a computer operating software, see at least [0045].);
a wire transfer (transaction request may be for a wire transaction, see at least [0050]-[0052]. Sending funds from payor account to payee account, see at least [0240], and see also [0278].);
subsequent to transmitting the processed wire request to the third wire-transfer application, receive a status update related to the transmitted wire request; and transmit the status update to the first wire-transfer application (When the current workflow stage of a transaction object indicates it has completed the steps of the corresponding workflow, the transaction object may be removed from SDP and routed or otherwise made available to other components of the overall transaction system. For example, the approved transaction object, having passed through all steps of the corresponding workflow, may be published to a public streaming data platform accessible outside of the transaction exchange platform. Enterprise systems, applications, users, and others (e.g., enterprise services and users) may access the completed transaction objects on the public streaming data platform and further process for transaction settlement or other purposes. See at least [0070].).
From the teaching of Srivastava, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the applications of Sukhija to be wire-transfer applications, as taught by Srivastava, and to modify the translated request of Sukhija to be a translated wire request, as taught by Srivastava, and to modify the transmitting of Sukhija to transmit to a third wire-transfer application configured to perform the transfer, as taught by Srivastava, and to modify the transfer of Sukhija to be a wire transfer, as taught by Srivastava, and to modify Sukhija to receive a status update related to the transmitted wire request subsequent to transmitting the processed wire request to the third wire-transfer application, as taught by Srivastava, and to modify the transfer of Sukhija to transmit the status update to the first wire-transfer application, as taught by Srivastava, in order to improve transaction remediation for rejected transactions (see Srivastava at least at Abstract and [0006]), and in order to decrease burdens on payment processing systems and reduce delays in processing transactions and improve customer experiences and increase revenues (see Srivastava at least at [0007]-[0008]).
Regarding claim 7, the combination of Sukhija and Srivastava discloses the limitations of claim 1, as discussed above, and Sukhija further discloses the first protocol comprises a first file format, and wherein the second protocol comprises a second file format (Receiving a second payment transaction message from an acquirer system, the transaction message associated with different data, see at least [0094] and see also FIG. 4C, transaction message with fields for “Address Verification,” “Payment Installation,” and “Transaction Value.” Comparing the fields of the first payment transaction message to the fields of the second payment transaction message, and modifying the second payment transaction message to add a field to match the first payment transaction message. See at least [0096]-[0098] and see at least FIGs. 4D-4E, where the Second Payment Transaction Message is modified by adding a field, the field being added based on the First Payment Transaction Message.).
Claim 8 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Claim 9 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claim 10 has similar limitations found in claim 3 above, and therefore is rejected by the same art and rationale.
Claim 11 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Claim 12 has similar limitations found in claim 5 above, and therefore is rejected by the same art and rationale.
Claim 13 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale.
Claim 14 has similar limitations found in claim 7 above, and therefore is rejected by the same art and rationale.
Claim 15 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale. And Sukhija discloses a non-transitory computer-readable medium storing program code that is executable by one or more processors for causing the one or more processors to perform operations (See Sukhija at least at [0007] and at least at [0063]-[0071] and FIG. 2.).
Claim 16 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claim 17 has similar limitations found in claim 3 above, and therefore is rejected by the same art and rationale.
Claim 18 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Claim 19 has similar limitations found in claim 5 above, and therefore is rejected by the same art and rationale.
Claim 20 has similar limitations found in claim 6 above, and therefore is rejected by the same art and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200160285 A1 (“Thorson”) discloses a system for transferring funds can include a database with information about a routing number including ACH transfer information and wire transfer information. The system can include a conversion module configured to receive an ACH transfer file including an associated routing number, access the database to retrieve wire transfer information, and convert the ACH transfer file to a wire transfer file. The system can include an implementation module configured to perform a wire transfer using the wire transfer file. The wire transfer can be a batch wire transfer. The conversion module can use the associated routing number from the ACH transfer file to retrieve wire transfer information for the associated routing number from the database.
US 20050071512 A1 (“Kim”) discloses a credit card processing system that integrates between a variety of application software and a variety of processing engines. This allows companies the freedom to choose the method of communicating, technology, and price point that meet their needs based on the volume of credit card transactions. This may be accomplished by “wrapping” various processing engines with a unified standard to eliminate the need for the client to integrate certain processing engines that do not support certain processors.
US 20220122075 A1 (“Bardouille”) discloses performing data validation in distributed settings, to enable data validation of an electronic transaction request or command based on a template and validation definitions. In an example, techniques for data validation may include obtaining information processing rules for validating electronic data that is used to perform a financial transaction in a locality (e.g., internationally), generating an electronic data validation template for the locality using the validation rules, and transmitting the electronic data validation template to a computing device for use in validating electronic data using the one or more data field definitions. In further examples, the validation rules may indicate one or more payment validation rules, bank validation rules, or chronology rules. The validation may be automatically deployed to client systems (such as in an enterprise resource planning system) or incorporated into a server as part of data file processing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights