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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1, 6, 8-9, 11 and 16, filed on 03/24/2026 are acknowledged.
Claims 1-20 were pending.
Claims 4, 7, 13, 15, 18 and 20, are cancelled, therefore
Claims 1-3, 5-6, 8-14, 16-17 and 19, are hereby examined
Continued Examination Under 37 CFR 1.114
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 03/24/2026 has been entered.
Examiner’s Response to Amendment/Remarks
The amendment to the independent claims has resulted in a 112 rejection for failing to comply with the written description requirement.to the independent claim 1, 11 and 16. The claims recite “identifying, by the device, a banking rail, the identification comprising determining a type of the banking rail for executing an electronic transaction associated with the request… the type of the banking rail being determined based on a transport protocol supported by the network resource;” Emphasis added by the Examiner. Applicant’s specification does not have support for this limitation, therefore, this underlined language above is a new matter.
35 USC § 101
Applicant’s amendment/argument filed on 03/24/2026, is hereby acknowledged,
and found persuasive by the Examiner. The amendment has overcome the 101 rejection. For example, on pages 8-9, Applicant’s argument that [The Examiner Has Mischaracterized the Abstract Idea The Examiner characterizes the claims as directed to "a real time or near real time transfer of funds via a payment rail." See page 2 of the Office Action. This characterization is respectfully incorrect. The claims are not directed to a funds transfer. Rather, the claims are directed to a specific, computer-implemented method of retrieving and delivering requested data through banking rail infrastructure using KYD-protocol-authenticated access-a purpose and technical operation entirely distinct from payment processing. The banking rail in the claimed subject matter functions as a data transmission channel with inherent banking-grade security properties, not as a payment settlement conduit. The Examiner's characterization does not accurately reflect the claims as amended]. And further that [The amended claims recite concrete, computer-implemented operations: (1) - (7)… These are specific, technically defined computer operations, not abstract human activities or mental processes], has been found persuasive , therefore the 101 rejection is hereby withdrawn.
35 USC § 103
The amendment of claims 1, 11 and 16, filed on 08/20/2025 is acknowledged and the Applicant’s argument/remarks are not persuasive. Hecht teaches the newly add language added to the independent claim 1 “… the identity verification application performing biometric or credential-based authentication of a user of the device prior to establishing the login;” in {see at least Fig. 12A-12D, col 40 line 52-col 41 line 6}, as previously disclosed. Additionally, Hecht teaches he newly amended “determining…” step in {col 26 Table 1 step 7020-col 27 step 7160, and also col 27 line 57-col 28 line 51}. The newly added language in the identifying step “…the type of the banking rail being determined based on a transport protocol supported by the network resource;” has no support by the Applicant’s disclosure in the specification, and therefore declared a new matter by the Examiner, and therefore, rendering this recitation not having patentable weight. Applicant is advised to further amend this claim step.
As regards the remaining amendment, these amendments were lifted up from the canceled claims 4, 7, 13, 15, 18 and 20, which is taught by Hecht in view of Dunjic as previously disclosed, and as further disclosed below.
In pages 11-14, Applicant disclose that “…Neither Hecht nor Dunjic discloses, teaches, or suggests a KYD protocol. Hecht discloses OAuth tokens for customer-biller authorization in a bill payment system. Dunjic discloses physical payment tokens (payment cards, mobile devices) for POS transaction routing. Neither reference teaches a KYD protocol-a transport protocol specifically governing permissioned data access to network resources-nor does either reference suggest that banking rail access via such a transport protocol would be obvious to combine”.
Examiner respectfully disagrees with this argument. Firstly, there is no disclosure in the Applicant’s specification regarding “a transport protocol specifically governing permissioned data access to network resources” for the Examiner to apprise how and breath for what is claimed. Therefore, this language does not have support in the Applicant’s specification. And as regards the KYD protocol which performs and manage permission access to network resources. This is taught by Hecht as already disclosed, because have the OAuth does exactly the same network permissioned access to network data as disclosed in col 19 lines 49-64 “ In an example embodiment, the relationship between the financial institution 321 and the biller 305 is created using an OAuth protocol, although another suitable credential tokenization/authorization protocol can be used. OAuth (Open Authorization) is a standard for token-based authentication and authorization on the Internet. OAuth is used for access delegation and may be used as a way for internet users to grant websites or applications access to their information on other websites without giving them the passwords. In the context of the present arrangement, OAuth is used as a way for customers to grant online banking websites access to their information on biller websites without giving the financial institution or biller processor their passwords to the biller websites”. Emphasis added by the Examiner. Therefore, the OAuth is sufficient in art.
Applicant further disclosed that “the amended claims recite, inter alia, dynamically generating the network mapping based on a requestor identifier and access permission level to identify a network path to the hosting network resource … However, Hecht's mapping is between bill payment participants for routing payment transactions-not a dynamic, permissioned network path to a data-hosting resource”. Once again, the Applicant’s specification does not disclose how the dynamically generating the network mapping is performed that is generally different for the disclosed mapping in paragraph 0101-0102 “…in Step 508, engine 200 can determine a mapping to an entity associated with the data for fulfilling the request. In some embodiments, the mapping can be based on KYD information and/or the applied KYC/KYB information associated with the user (e.g., transferor) and/or the transferee (e.g., in some embodiments, the KYC/KYB and/or KYD information for the transferee can be determined as part of the processing of Step 504, discussed above). [0102] By way of a non-limiting example, a depiction of the mapping between a user (e.g., depicted as being associated with server 302) is provided in FIG. 4. For example, a mapping between a requesting user (e.g., associated with server 302, where in some embodiments, server 302 can be connected to by UE 102 for which the user accesses the ERM 400/network 106) to a location of the data requested to be interacted with/transacted can be established based on KYD for the user and the location…”. This is not dynamically generating the network mapping, and at best, this recitation is not in the Applicant’s specification and / or broader than the specification.
As regards the comment about “Requestor Information Comprising Access Permission Level” Applicant disclosed that”, Examiner has disclosed above the function of the OAuth above in providing permissioned access to the network resources above.
As regards the comment that “The amended independent claims recite, inter alia,
executing a webhook to create an audit trail recording the requestor identifier, timestamp, and identity of the network resource accessed. The Examiner relied on Cady for audit trail-related elements only in the context of dependent claims 9-10. However, neither Hecht nor Dunjic teaches webhook-based audit trail creation in the context of banking rail data retrieval. The inclusion of this element in the independent claims thus creates a non-obvious distinction from the Hecht/Dunjic combination for all independent claims. Examiner agrees that the combination of Hecht/Dunjic does not teach this element as prior art Cady teaches this Webhook audit trail element as disclosed in paragraph 0038, 0096, as disclosed.
Regarding the argument by the Applicant that “The amended claims recite, inter alia, transmitting the response message via the banking rail as a peer-to-peer (P2P) real-time transaction. The Examiner relied on Hecht (col. 5, lines 23-col. 6, line 11) for P2P functionality in the context of dependent claims”. Dunjic teaches this limitation in {see at least ¶ 0054 “After a transfer rail is identified, the POS terminal/acquirer system sends the transfer rail a message. The message may be sent through a network, such as the network 130…”, and ¶ 0055 “When the issuer system determines whether to approve or deny the transaction, it sends a message indicating the result of this determination to the POS terminal 110 via the transfer rail 120. The result may then be displayed or otherwise output at the POS terminal 110”}.
And finally, the Applicant disclosure that “The claimed subject matter is directed to a specific technological framework for using banking rail infrastructure with KYD-protocol access control, dynamic network mapping, and webhook-based audit trails as a data retrieval and delivery mechanism between network-connected entities. This framework is categorically different from both Hecht's bill payment system and Dunjic's touchless POS payment system” is not persuasive, therefore the 103 rejection is hereby maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL-The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-3, 5-6, 8-14, 16-17 and 19, are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11 and 16 recites “identifying, by the device, a banking rail, the identification comprising determining a type of the banking rail for executing an electronic transaction associated with the request… the type of the banking rail being determined based on a transport protocol supported by the network resource;” Emphasis added by the Examiner. Applicant specification does not have support for this limitation. The only instance of the word “transport” in the specification is in paragraph 0015 “Effectively, the current version of HTTP (e.g., HTTP/3) uses a multiplexed transport protocol built on user data protocol (UDP, which is a core communication protocol for sending messages to other hosts on an Internet Protocol (IP) network)…” This is not “the type of the banking rail being determined based on a transport protocol supported by the network resource”. This is new matter, as one of skill in the art would not have been able to conclude, based on the originally filed disclosure, that applicant had possession of the claimed invention. Therefore, claims 1, 11 and 16 are rejected, for failing to comply with the written description requirement. MPEP 2163.06 stipulates – If new matter is added to the claims, the examiner should reject the claims under 35 U.S.C. 112(a) – written description requirement.
Dependent claims 2-3, 5-6, 8-10, 12-14, 17 and 19 are also rejected since they depend from claims 1, 11 and 16, respectively.
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 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.
Claims 1-3, 5-6, 8-14, 16-17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hecht et al., (US Pat. 11599862 B1) in view of Dunjic et al., (US 20220108303 A1) and further in view of Tyler W. Cady (US 20230344845 A1).
With respect to claims 1, 11 and 16, Hecht teaches a method, a device and a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions that when executed by a device, perform a method comprising:
executing, by a device, via an identity verification application, a login to a network platform, the identity verification application performing biometric or credential-based authentication of a user of the device prior to establishing the login {see at least Fig. 12A-12D, col 40 line 52-col 41 line 6 “Upon detecting a user interaction with an item from the data set comprising relevant entries for selectable particular billers, the exchange bill pay application 1110 is structured to provide a user interface to facilitate the user's login to the particular biller's website, as shown in FIG. 12C. (171) As shown in FIG. 12C, the exchange bill pay application 1110 can be structured to redirect the user's browser to a URL associated with the login page for the selected biller. In some embodiments, the exchange bill pay application 1110 displays a sign-on page 1240 that allows the user to log into the selected biller's system. The sign-on page 1240 may be hosted by a biller processor computing system. When a user enters a username 1242, a password 1244, [credential-based] and taps on (or otherwise interacts with) the log-in control 1246, the exchange bill pay application 1110 is structured to transmit the username 1242 and the password 1244 to the biller computing system. Upon validating the user's credentials, the biller computing system may return a list of eligible accounts (e.g., an account data set) held by the user with the biller. An example list of eligible accounts is displayed on the screen of the device 1100, as shown in FIG. 12D”}.
receiving, by the device, upon the login, a request for data, the request comprising information related to the requestor {see at least col 30 lines 23-33 “…The customer's financial institution may send an electronic message that includes a customer signature payload. The customer signature may comprise information needed to identify the customer and/or the customer's financial institution to the biller. The message may be routed through the exchange computing system API 1263. The exchange computing system API 1263 may, in response to a validation request, validate a signature at 1269 (e.g., confirm that a customer is associated with the customer's financial institution), generate an authorization code at 1271, and sign the generated authorization code 1273”}.
determining, by the device, a network mapping between an entity and the requested data, the entity being associated with a network resource availing the network to the requested data the network mapping being dynamically generated by the device based on a requestor identifier and an access permission level to identify a network path from the device to the network resource hosting the requested data {see at least col 26 Table 1 step 7020-col 27 step 7160, and also col 27 line 57-col 28 line 51}.
“…the electronic transaction comprising communication of information from a network location to another network location as per information indicated in the request, the type of the banking rail being determined based on a transport protocol supported by the network resource” {see at least Fig. 2A, col 2 lines 28-32 “…Even with third-party processors, each financial institution typically still has to set up communication infra structures to accommodate the requirements of multiple, different third-party processors[i.e., networks in various locations]”, col 6 lines 53-67 “…The systems of FIG. 1 are shown from the perspective of a financial institution making a payment to a biller. The illustrated various systems may provide a data management and communication platform for entities associated with these individual providers to perform transactions [i.e., networks in various locations]. The configuration and arrangement of these systems, and the corresponding methods for procuring, storing, securing, managing, and communicating the data can substantially affect the efficiency and capabilities of transactions, such as payment transactions, among parties associated with these different providers”, and col 8 lines 40-56 “…FIG. 2A, FIG. 2A describes at a high level a centralized biller exchange computing system 210 that enables communication between multiple financial institutions and billers. The infrastructure of FIG. 2A is shown from the perspective of the biller exchange computing system 210, which provides the API features that connects multiple billers and financial institutions [i.e., networks in various locations]. The biller exchange computing system 210 may perform or enable both on-us and off-us billing transactions, among other various types of transactions”, col 22 lines 1-13 “Each respective entity can save its copy of the token in a data store associated with the entity, such as non-volatile memory, a token vault, etc. According to various embodiments, the data store of each respective entity may include a mapping data structure (such as a table) that correlates a reference to a specific system (such as a URL, an IP address, a MAC address, a network path, etc.) with biller financial institution relationship information (such as an account handle, user name, identification number, account number in combination with a reference to a specific system, email address, social media handle, name, telephone number, email address, business address, etc.)”, col 34 Table 3 9010-col 35 Table 3 9100 “9010 Consumer requests to pay their Biller via their FI computing system Bill Pay UI 9020 Consumer can select to pay their Biller manually or automatically when updated Biller info (e.g., updated bill) is received 9030 Bill Pay retrieves the OAuth Access Token tied to the Consumer and Biller 9040 Consumer’s FI computing system executes real-time payment remittance to the Biller’s FI computing system through a payment rail, passing the Payment Remittance data: Biller ID and Access Token 9050 Payment Rail computing system routes the real-time payment remittance to the Biller’s computing system, passing the Payment Remittance data: Biller ID and Access Token 9060 Biller’s computing system forwards the request to the Biller Processor computing system 9070 Biller Processor computing system validates the Access Token tied to the Biller and Consumer, and maps this to Consumer and Biller Account Number 9080 Biller Processor computing system remits the payment to the Biller, passing the payment data, the Consumer, and Biller Account Number 9090 Biller’s FI computing system returns the status and result of the payment”}.
accessing, by the device […], the cryptographic token and API corresponding to a Know Your Data (KYD) protocol [e.g., OAuth protocol], the KYD protocol governing authenticated, permissioned access to the network resource {see at least col 19 lines 49-64 “For each of the financial institution 321 and biller 305, the biller exchange computing system 330 can be structured to generate a secure enrollment record. In an example embodiment, the relationship between the financial institution 321 and the biller 305 is created using an OAuth protocol, although another suitable credential tokenization/authorization protocol can be used. OAuth (Open Authorization) is a standard for token-based authentication and authorization on the Internet. OAuth is used for access delegation and may be used as a way for internet users to grant websites or applications access to their information on other websites without giving them the passwords. In the context of the present arrangement, OAuth is used as a way for customers to grant online banking websites access to their information on biller websites without giving the financial institution or biller processor their passwords to the biller websites”, col 5 line 23-col 6 line 11 “For example, in some embodiments, example biller exchange computing systems and methods may use an API arrangement in which each participating entity (financial institutions, billers, and a centralized biller exchange computer system) exposes a set of APIs that are accessible to other participating entities. For example, each entity may offer an enroll customer to biller API, an inquire biller or bill API, a pay biller API, and a deliver bill API. For example, if a customer has a demand deposit account at bank A and has a mortgage with bank B, then bank B may offer an enroll customer to biller API that enables setting up bank B as a biller of the customer in the bill pay system of bank A. Thereafter, the customer may then go to online bill pay at bank A and perform other operations that are supported by the other afore-mentioned APIs (in this example, provided by bank B), such as inquire about bills, pay bills, or receive bills, without needing to visit the website of bank B. Similar functionality may be provided with respect to other billers (i.e., billers that are not financial institutions) that provide the aforementioned APIs. Hence, for example, a biller may offer an enroll customer to biller API that enables setting up the biller as a biller of the customer in the bill pay system of bank A. Thereafter, the customer may then go to online bill pay at bank A and perform other operations that are supported by the other afore-mentioned APIs (in this example, provided by the biller), such as inquiring about bills and paying bills… Advantageously, the embodiments of the biller exchange computing systems and methods described herein allow consortium members (e.g., financial institutions) to minimize fraud through advance counterparty verification and by securely exchanging sensitive customer and payment data, through an API of the biller exchange computing system, in a tokenized form”}.
Hecht does not explicitly disclose, however, Dunjic discloses “identifying, by the
device, a banking rail [e.g., transfer rail/payment rail], the identification comprising determining a type of the banking rail for executing an electronic transaction associated with the request”, […] {see at least ¶¶ 0051-0053 “…a point-of-sale (POS) terminal 110 may communicate with a transfer rail 120 which relays transaction data to an appropriate issuer system 124. Such communication may be via a network, such as the network 130. The transfer rail 120 may also be referred to as a payment rail. The point-of-sale terminal is associated with an acquirer and the communication between the POS terminal 110 and the transfer rail 120 may be by way of a back-end acquirer system. The POS terminal 110 may be located at a location that is associated with a merchant. By way of example, the merchant may be a store, restaurant, gym, etc. The acquirer is a merchant bank that accepts deposits associated with transactions made at the point-of-sale terminal and facilitates settlement and deposit of those deposits into an account associated with the merchant. While a single transfer rail 120 is illustrated in FIG. 1, in practice the POS terminal 110 may communicate with multiple transfer rails. By way of example, the transfer rail 120 may include any one or a combination of Amex™, Visa™ and/or Mastercard™. Other transfer rails may also be used. The POS terminal and/or a back-end acquirer system in communication with the POS terminal may, after obtaining data from a physical token, such as a value transfer card or a mobile device having a representation of a payment card which has engaged a physical token reader provided at the POS terminal, determine which of the transfer rails is to be used. For example, the POS terminal/acquirer system may determine that the physical token is associated with Visa™ and may, in response, select the Visa™ payment rail or it may, instead, determine that the physical token is associated with Mastercard™ and select the Mastercard™ payment rail”, and also ¶ 0082 “…the exchanged messages may be implemented as messages. However, in other embodiments, some or all of the illustrated messages may not correspond to messages per se when sent over the computer network but may instead be implemented using techniques such as for example remote procedure call (RPC) and/or web services application programming interfaces (APIs). For example, it may be that various message pairs illustrated in FIG. 5 correspond to an RPC or a web service API call and a reply or callback in response to that call”}.
accessing, by the device, the banking rail via cryptographic token and designed application program interface (API) associated with a type of the cryptographic token […] {see at least ¶¶ 0052-0054 “After a transfer rail is identified, the POS terminal/acquirer system sends the transfer rail a message. The message may be sent through a network, such as the network 130. The message includes a value amount representing an amount of value that is to be transferred to complete a transaction and physical token data such as a primary account number (PAN) associated with a physical token. The transfer rail identifies an associated issuer based on the physical token data and communicates with the identified issuer to process the transaction. More particularly, the transfer rail 120 routes the message received from the POS terminal to an issuer system 124 for the identified issuer…”, and also ¶ 0082 }
identifying, by the device, via the accessed banking rail, the requested data, the
identification comprising accessing the requested data from the network resource via the banking rail {see at least ¶¶ 0052-0054}.
sending, by the device, the requested data to the requestor via the banking rail, the sending comprising transmitting the response message via the banking rail such that the requested data is communicated as a peer-to-peer (P2P) real-time transaction
{see at least ¶ 0054 “After a transfer rail is identified, the POS terminal/acquirer system sends the transfer rail a message. The message may be sent through a network, such as the network 130…”, and ¶ 0055 “When the issuer system determines whether to approve or deny the transaction, it sends a message indicating the result of this determination to the POS terminal 110 via the transfer rail 120. The result may then be displayed or otherwise output at the POS terminal 110”}.
compiling, by the device, the requested data as a response message, the compilation comprising transforming the requested data to a format that is transferable over the banking rail and compliant with capabilities of a system associated with the requestor {see at least ¶¶ 0052-0054}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the payment transaction of Hecht to include the elements of Dunjic. One would have been motivated to do so, in order to identify which of the transfer rails is to be used in a payment transaction. Furthermore, Hecht discloses having APIs that support payment transaction. Dunjic is merely relied upon to illustrate the functionality of identifying which of the transfer rails is to be used in a payment transaction in the same or similar context. Because both having APIs that support payment transaction, as well as identifying which of the transfer rails is to be used in a payment transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Hecht, as well as Dunjic would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Hecht/Dunjic.
The combination of Hecht in view of Dunjic does not explicitly disclose “executing, by the device, a webhook to create an audit trail for the requested data, the audit trail recording at least the requestor identifier, a timestamp, and an identity of the network resource from which the requested data was accessed”
However, Cady discloses executing, by the device, a webhook to create an audit trail for the requested data, the audit trail recording at least the requestor identifier, a timestamp, and an identity of the network resource from which the requested data was accessed {see at least ¶ 0038 “…in near real-time, or in real-time, as events are observed by the API server 131 and/or logged to the API audit log 133, depending upon the particular auditing backend used (e.g., logs files versus webhooks to HTTP callbacks) and/or as events are observed by API(s) 143 of the monitored application and/or logged, for example, internally and/or to a separate file, a feature extraction stage may be performed followed by a continuous learning and anomaly detection stage…”, and also ¶ 0096 “…an administrative user of the cluster may establish an audit log policy file (e.g., audit log policy file 500 containing audit log policies 132 or
audit log policies 225) to filter and log various audit events observed within the cluster”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the payment transaction of Hecht in view of Dunjic, to include the elements of Cady. One would have been motivated to do so, in order to establish anti-fraud policy in a payment transaction. Furthermore, Hecht discloses having APIs that support payment transaction, and Dunjic discloses identifying which of the transfer rails is to be used in a payment transaction. Cady is merely relied upon to illustrate the functionality of establishing an audit log policy in a payment transaction in the same or similar context. Because both having APIs that support payment transaction, and identifying which of the transfer rails is to be used in a payment transaction as well as establish an audit log policy in a payment transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Hecht in view of Dunjic, as well as Cady would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Hecht/Dunjic/Cady.
With respect to claims 2, 12 and 17, the combination of Hecht in view of Dunjic teaches all the subject matter as disclosed in claims 1, 11 and 16 above, respectively.
Furthermore, Dunjic discloses further comprising: extracting from the network
resource, a portion of data that corresponds to the requested data, the network
resource comprising a plurality of data that may not correspond to the requested data {see at least ¶¶ 0053 “…The POS terminal and/or a back-end acquirer system in communication with the POS terminal may, after obtaining data from a physical token, such as a value transfer card or a mobile device having a representation of a payment card which has engaged a physical token reader provided at the POS terminal, determine which of the transfer rails is to be used…”, and also ¶ 0054}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the payment transaction of Hecht in view of Dunjic, to include the elements of Cady. One would have been motivated to do so, in order to establish anti-fraud policy in a payment transaction. Furthermore, Hecht discloses having APIs that support payment transaction, and Dunjic discloses identifying which of the transfer rails is to be used in a payment transaction. Cady is merely relied upon to illustrate the functionality of establishing an audit log policy in a payment transaction in the same or similar context. Because both having APIs that support payment transaction, and identifying which of the transfer rails is to be used in a payment transaction as well as establish an audit log policy in a payment transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Hecht in view of Dunjic, as well as Cady would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable.
Accordingly, the claimed subject matter is obvious over Hecht/Dunjic/Cady.
With respect to claim 3, the combination of Hecht in view of Dunjic teaches all the subject matter as disclosed in claims 1 above.
Furthermore, Hecht further disclose storing, via communication over the banking rail, the requested data, wherein the sending of the requested data comprises the storage {see at least col 7 line 45-col 8 line 17 “…Generally, a biller directory is a data store that contains payee information, such as routing information, account information, payee financial institution name and/or identifier, etc. The information in the biller directory may, for example, be provided by the biller itself during a biller registration (enrollment) process. The biller directory provides an easy way for the customer 101 to set up a new payee in the bill pay system 100, and ensures that the correct account information, routing information, etc., will be used for the newly set up biller when the customer 101 makes payments to the biller… The third-party processor system 108 may be configured to process payments made to “off-us” billers, including both banking and non-banking billers. The third-party processor system 108 may further be configured to process electronic bills from off-us billers. For example, some billers may have registered with the third-party processor system 108 and not with the financial institution. In such scenarios, the account information, routing information, etc., may be stored in the biller directory of the third-party processor system 108, and made accessible to the bill pay system 104 via, for example, an API connection, such that the bill pay system 104 can make a payment to the biller through the third-party processor
system 108}.
With respect to claims 5, 14 and 19, the combination of Hecht in view of Dunjic teaches all the subject matter as disclosed in claims 1, 11 and 16 above, respectively.
Furthermore, Hecht discloses, further comprising: analyzing, by the device, the request, and based on the analysis, determining that the request is permitted, the permission being based on the requestor information, wherein the determination of the network mapping is based on the determination that the request is permitted {see at least col 27 line 57-col 28 line 51“After authentication, the customer 701 may then interact with RDFI 761 through the biller exchange computing system 741. For example, the customer 701 may request authentication at step 722. The RDFI 761 may then display authorization selection page to the customer 701 at step 724. The customer 701 may submit selected on-we biller authorization at step 726. The RDFI 761 may then generate authorization code at step 728. At step 730, the RDFI 761 may save the mapping of the authorization codes. At step 732, a one-time OAuth authorization code is returned to the ODFI bill pay page 702… The biller exchange computing system 741 provides a live biller-customer OAuth token at step 746 and forwards or returns the OAuth token to the ODFI 721 at step 748. The ODFI 721 saves the customer biller enrollment token at step 750 and sends a confirmation of success of customer-biller enrollment notification to the ODFI bill pay page 702 at step 752. At step 754, the ODFI
bill pay page 702 displays an enrollment success notification to the customer 701”}.
With respect to claim 6, the combination of Hecht in view of Dunjic teaches all the subject matter as disclosed in claims 1 above.
Furthermore, Hecht further disclose, wherein the identification of banking rail is based on a geographic region associated with the request {col 12 line 57-col 13 line 2 “In some embodiments, data passing through the respective network interface circuits 310, 324, 328, 334 and 354 is tokenized such that sensitive data (for example, account number(s), user location, personally identifiable information, and the like) is obscured for transmission within or outside the computing environment. Various communication protocols can be used, including, for example, any of the Internet protocol (IP), transmission control protocol (TCP), hypertext transfer protocol (http), simple object access protocol (SOAP), file transfer protocol (FTP), etc. In some embodiments, secure versions of internet protocols may be used to exchange data via the network interface circuits 310, 324, 328, 334 and 354, such as IPsec, https://, etc.,”}.
With respect to claim 8, the combination of Hecht in view of Dunjic teaches all the subject matter as disclosed in claims 7 above.
Furthermore, Hecht discloses further disclose requested data is communicated via a peer-to-peer (P2P) real-time transaction {see at least col 5 line 23-col 6 line11}.
With respect to claim 9, the combination of Hecht in view of Dunjic, and in view of Cady teaches all the subject matter as disclosed in claims 1 above.
Furthermore, Cady discloses further comprising: executing a webhook to create an audit trail for the requested data; and verifying communication of the requested data based on the audit trail {see at least ¶ 0038 “…in near real-time, or in real-time, as events are observed by the API server 131 and/or logged to the API audit log 133, depending upon the particular auditing backend used (e.g., logs files versus webhooks to HTTP callbacks) and/or as events are observed by API(s) 143 of the monitored application and/or logged, for example, internally and/or to a separate file, a feature extraction stage may be performed followed by a continuous learning and anomaly detection stage…”, and also ¶ 0096 “…an administrative user of the cluster may establish an audit log policy file (e.g., audit log policy file 500 containing audit log policies 132 or audit log policies 225) to filter and log various audit events observed within the cluster”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the payment transaction of Hecht in view of Dunjic, to include the elements of Cady. One would have been motivated to do so, in order to establish anti-fraud policy in a payment transaction. Furthermore, Hecht discloses having APIs that support payment transaction, and Dunjic discloses identifying which of the transfer rails is to be used in a payment transaction. Cady is merely relied upon to illustrate the functionality of establishing an audit log policy in a payment transaction in the same or similar context. Because both having APIs that support payment transaction, and identifying which of the transfer rails is to be used in a payment transaction as well as establish an audit log policy in a payment transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Hecht in view of Dunjic, as well as Cady would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Hecht/Dunjic/Cady.
With respect to claim 10, the combination of Hecht in view of Dunjic, and in view of Cady teaches all the subject matter as disclosed in claims 9 above.
Furthermore, Cady discloses further comprising: storing information related to the audit trail in a database accessible by the device {see at least ¶¶ 0038, 0096}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the payment transaction of Hecht in view of Dunjic, to include the elements of Cady. One would have been motivated to do so, in order to establish anti-fraud policy in a payment transaction. Furthermore, Hecht discloses having APIs that support payment transaction, and Dunjic discloses identifying which of the transfer rails is to be used in a payment transaction. Cady is merely relied upon to illustrate the functionality of establishing an audit log policy in a payment transaction in the same or similar context. Because both having APIs that support payment transaction, and identifying which of the transfer rails is to be used in a payment transaction as well as establish an audit log policy in a payment transaction are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Hecht in view of Dunjic, as well as Cady would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Hecht/Dunjic/Cady.
Conclusion
The prior art made of record and not relied upon:
1) (US 20160180304 A1) – Carriles et al., Combined Electronic Payment and Transfer for Digital Banking Channels - relates to electronic payments and more particularly relates to a new way to schedule, process, review, and manage electronic payments and transfers, as well as the source and destination accounts, utilizing a digital banking channel, such as but not limited to Mobile Banking, Online Banking, Automatic Teller Machines (ATM), and Interactive Voice Response (IVR).
2) (US 20200327543 A1) – Singh et al., Facilitation of Real-Time Payment Network Transactions– Abstract -A request for payment message is received. The message includes transaction data. A transaction identifier is generated. The transaction data is stored in association with the transaction identifier. The transaction identifier is transmitted to an acquirer bank. A request to retrieve data is received from a payer's bank. The request to retrieve data includes the transaction identifier. At least some of the transaction data is transmitted to the payer's bank. A confirmation is received from the payer's bank. The confirmation indicates that a real-time payment has been made in accordance with the request for payment message.
3) (US 20180189781 A1) – McCann et al., Real-Time Approval and Execution of Data Exchanges between Computing Systems – relate to computer-implemented systems and processes that automatically initiate, approve, and execute exchanges of data between network-connected devices in a computing environment.
4) (US 20190266607 A1) – Mori et al., Message Delay Estimation System Method – generally relates to funds transfers including an intelligently-determined estimate of the clearing time to complete the transaction. The system 100 may include a computer network 102 that links one or more systems and computer components. In some embodiments, the system 100 includes a user computer system 104, a merchant computer system 106, a payment network system 108, a clearing delay estimation system 110, and a payment device issuer system 111.
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (571)272-7575. 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. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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
/V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights