DETAILED ACTION
This action is in reply to the request for continued examination filed on 12/22/2025.
Claim 1-20, 27, 37 and 41 were previously canceled.
Claims 25, 35 have been canceled.
Claims 21, 26, 31, 36 and 38 have been amended.
Claims 21-24, 26, 28-34, 36, 38-40, and 42-44 have been examined.
Claims 21-24, 26, 28-34, 36, 38-40, and 42-44 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 12/22/2025 has been entered.
Remarks
With regard to the 101 rejection, the arguments have been considered but they are not persuasive.
The applicant asserted in page 15 that “claim 21 enhance the technological field of electronic payment processing by providing machine-implemented routing optimization that dynamically excludes paths based on predefined threshold and distributes transaction value . . .” However, such excluding transaction based on predefined threshold value is rooted within the field of optimization. It is using a Mathematical calculations in addressing a business problem. Since the outcome of such mathematical concepts is dedicated to a business relations, the whole idea belongs to Certain Methods of Organizing Human Activity.
Under Step 2A – Prong Two analysis, the Applicant further asserted that the system “ encryption key caching demonstrate a specific technological improvement rather than an abstract concept . . .’”. However, excluding transaction in order to optimize the route of transaction is not an improvement in technology. At most, the improvement is related to an improvement in business transaction. As a result, these limitations are not indicative of integration into a practical application. They are adding the words “apply it” (or an equivalent) with the judicial exception, to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea – see MPEP 2106.05(f).
Similarly, under step 2B analysis, the limitations are also not indicative of an inventive concept (aka “significantly more”). They recite an abstract idea of “real-time handling, routing, and reconciliation of electronic transaction request”, pg. 19. They are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer – see MPEP 2106.05(f).
Therefore, the 101 rejection is maintained. See detailed analysis.
With regard to the 103 rejection, the arguments have been considered but they are not persuasive. The applicant amended the independent claims with added limitations “encrypting, by the reconciliation system, the transformed notification, wherein an encryption key . . . ”. However, per reviewing the cited references in light of the amended limitations, Fery discloses the added limitations in the independent claims. It would be obvious to one of ordinary skill in the effective time of filing to combine the features of encrypting the transformed data as disclosed by Fery with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to better transmitting encrypted data (Abstract). Therefore, the combination is obvious.
Please refer to the 103 rejection below for further details.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 21-24, 26, 28-34, 36, 38-40, and 42-44 are directed to a system, a method, or product which are one of the statutory categories of invention. (Step 1: YES).
Claims 21-24, 26, 28-34, 36, 38-40, and 42-44 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide generic computer functions that do not add meaningful limits to practicing the abstract idea.
Claims 21, 31, 38 are grouped together, Claim 31, for instance , recite in part, a method of receiving, by a reconciliation system, a notification for updating the transaction request from a transaction network; authenticating, by the reconciliation system, the notification by communicating with an authentication system; transforming, by the reconciliation system, the authenticated notification into a non-scheme specific format that is compatible for processing and communication; encrypting, by the reconciliation system, the transformed notification, wherein an encryption key for the encrypted notification is deleted from an encryption key cache upon exceeding a pre-determined time threshold and is replaced with a newly generated encryption key; transmitting, by the reconciliation system, the encrypted notification to a notification handler, wherein the notification handler communicates with a transaction query system to retrieve transaction data associated with the transaction request; receiving, by the reconciliation system, the transaction data from the notification handler; evaluating, by the reconciliation system, a value of the transaction request against predefined threshold corresponding to each of a plurality of paths, and dynamically excluding at least one of the plurality of paths for which the value exceeds the predefined threshold; splitting, by the reconciliation system, the value of the transaction request across remaining of the plurality of paths based on routing configuration data and path-specific preference weight; transmitting, by the reconciliation system, transaction status to a requestor system associated with the transaction request via an application programing interface call or a secure file transfer protocol message; and generating, based on the status message, a display of a transaction activity interface providing a real-time status of the transaction request. The limitations are directed to transaction reconciliation system – business relations (commercial interactions). Hence, they fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements such as a non-transitory computer-readable medium, one or more processors, a reconciliation system, a security system, a tokenization system, a routing system, an authentication systema notification handler, a display, an application programming interface call and other generic computer components to perform receiving, authenticating, translating, and transmitting. The generic computer components are recited at a high-level of generality (receiving, translating, and transmitting) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Hence, the claim is directed to an abstract idea
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claims 21, 31 and 38, do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of at least a computing device to perform receiving, adding and communicating data are merely additional elements performing the abstract idea on a generic device i.e., abstract idea and apply it. See MPEP 2106.05(f). There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c). Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) see MPEP 2106.05(d). Furthermore, the limitations are not indicative of integration into a practical application because they are merely adding the words “apply it” to a judicial exception on a generic computing device. See MPEP 2106.05(f). Given the above reasons, a generic processing device associated with the receiving a transaction update associated with a transaction request, authenticating the transaction update, translating the transaction update into a format, receiving transaction data associated with the transaction update, transmitting the transaction update to a transaction requestor is not an Inventive Concept. Thus, the claim is not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The Dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
Claims 22, 32, 39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) a process of generating a notification to show transaction updates . This judicial exception is not integrated into a practical application because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (such as requestor system, authentication system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claims 23, 24, 33, 34 and 40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of authenticating transaction requests . This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (requestor system, authentication system, a security system, a validation system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claim 26 and 36 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of searching data using hash algorithm . This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (hash algorithm, secure system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claims 28, 29, 30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of determining an optimal path to route transaction based on certain conditions or configurations. This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (a machine learning, account ledger system, notification handler, a transaction system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claim 42 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of calculating optimal paths and splitting values among the paths and generating tokenized value. This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (tokenization system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claim 43 is rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) real-time updates of the transaction request. This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (reconciliation system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Claim 44 is rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) receiving real-time feedback. This judicial exception is not integrated into a practical application because the limitations are Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). The claim(s) does/do not include additional elements (reconciliation system) that are sufficient to amount to significantly more than the judicial exception because the limitations are adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f).
Therefore, Claims 21-26, 28-36, and 38-40, 42 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 21, 31, 38, 23, 24, 33, 34, 38, 40 are rejected under 35 U.S.C. 103 as being unpatentable over Lopes et al. (US 2021/0350382 A1) in view of Schnitt (US 11, 171, 911 B2) in further view of UR, Shmuel (WO 2021/033184 A1) in further view of Fery et al. (US 2006/0190732 A1).
Claims 21, 31, 38 are grouped together. Claim 21, for instance, is disclosed: Lopes teaches: a system for determining real-time status of a transaction request, comprising: one or more computer readable media storing instructions for executing in real-time an electronic transaction;
and one or more processors configured to execute the instructions to perform operations comprising: receiving, by a reconciliation system (see at least par. [0015] “A transaction reconciliation system described herein uses machine learning to enable more transaction entries to be automatically matched (and more transactions to be automatically reconciled) compared to prior techniques.”), a notification for updating the transaction request from a transaction network, wherein the notification is in a scheme specific format (Lopes, see at least par. [0023] “. . . The matching model may be unable to match such transaction entries for a variety of reasons, including transaction amounts (e.g., credits and debits) that do not match or offset one another, unrecorded transactions (e.g., small interest payments), incorrect transaction data into a record (e.g., due to input error), delays in inputting transaction data in a record, incomplete transactions, trade breaks, and/or the like. As a result, one or more transactions may remain unreconciled. Using the techniques described below, the transaction reconciliation system can reconcile some or all of these transactions with greater accuracy, using fewer resources, and in less time than prior techniques” & see at least par. [0038] “. . . . Additionally, or alternatively, the transaction reconciliation system may query (e.g., submit a request to) a transaction data source to obtain one or more transaction entries having the characteristic. In some implementations, the transaction reconciliation system may identify a transaction data source to be queried based on the characteristics and/or based on transaction data associated with the transaction having missing transaction data . . .” & see at least par. [0056] “The transaction reconciliation system may determine this probability based on applying a machine learning model to a feature set, which may include the feature information determined from the set of matched transaction entries 210. Additional details regarding applying the machine learning model to the set of unmatched transaction entries 215 is described in more detail below in connection with FIG. 4.”) The cited portion disclose some of the “trade breaks (error or failure)” which correspond to one of the transaction schemes which create the transaction notification in par. [0059] of the specification. The transaction reconciliation system helps to reconcile such data inputs. “Feature sets” correspond to scheme specific format under BRI in which data is organized into data set;
receiving, by the reconciliation system, a notification for updating the transaction request from a transaction network, wherein the notification is a scheme specific format (see at least par. [0082] “. . . the machine learning system may provide a recommendation and/or output for determination of a recommendation, such as a recommendation to mark the first transaction entry and the second transaction entry as being associated with the same transaction, a recommendation to update a transaction record for the first transaction entry and the second transaction entry, and/or the like. Additionally, or alternatively, the machine learning system may perform an automated action and/or may cause an automated action to be performed (e.g., by instructing another device to perform the automated action), such as marking the first transaction entry and the second transaction entry as being associated with the same transaction (e.g., by updating a data structure to assign the same match identifier to the first transaction entry and the second transaction entry), outputting information associated with the first transaction entry and/or the second transaction entry (as described elsewhere herein), outputting a request for confirmation that the first transaction entry and the second transaction entry are associated with the same transaction . . .”) transaction update (or notification) could correspond to one of the trade break and the transaction update is then reconciled with the second transaction entry as being the same transaction;
transmitting, by the reconciliation system, the transformed notification to a notification handler, wherein the notification handler communicates with a transaction query system to retrieve transaction data associated with the transaction request, and wherein the notification handler generates a status message for the transaction request based on the retrieved transaction data (Lopes, par. [0147]) the system transmits, or provide, a transaction notification that identifies matched transaction (transaction data) which were reconciled.
generating, based on the status message, a display of a transaction activity interface providing a real-time status of the transaction request (Schnitt, see at least par. [0018] “. . . n some implementations, the transaction reconciliation system may receive transaction data from the data source(s) in real-time, where a transaction entry is provided to the transaction reconciliation system upon the transaction entry being input to a data source (e.g., immediately after input or within a threshold amount of time after input)” & par. [0034] “. . . The transaction reconciliation system may output the information for display (e.g., if the transaction reconciliation system is connected to and/or in communication with a display) or may output the information to another device (e.g., a user device) for storage and/or display by that device . . .”) Interpretation: the transaction notification is received in real-time and displayed on the device.
Lopes does not disclose the following; however, Schnitt teaches:
authenticating, by the reconciliation system, the notification by communicating with an authentication system (Schnitt, Col. 23 ln 56-62) the cited portion discloses authentication transaction message from the requestor ;
transforming, by the reconciliation system, the authenticated notification into a non-scheme specific format that is compatible for processing and communication (Schnitt, col. 23 ln 36-42) Interpretation: the message, or transaction update, is converted in to specific format for transmission such as JSON;
receiving, by the reconciliation system, the status message from the notification handler with event-topic stream (Schnitt, Col. 24 ln 44-51) Interpretation: The message command, which includes final status/alert, is transmitted and received from one end.
and transmitting, by the reconciliation system, the status message to a requestor system associated with the transaction request via an application programing interface call or a secure file transfer protocol message (Schnitt, see at least col. 24, ln 41-51) the notification handler corresponds to the communicator component which handles the message notifications or alerts;
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of authenticating transaction update, translating update into another format, and transmitting the transaction update to a notification handler as disclosed by Schnitt with the invention of reconciliating transactional data including update or status as taught by Lopes to better automate the transactional processes between organizations that do business together using incompatible pre-existing transactional systems (Schnitt, abstract). Therefore, the combination is obvious.
Lopes in view of Schnitt does not disclose the following; however, UR teaches:
evaluating, by the reconciliation system, a value of the transaction request against predefined threshold corresponding to each of a plurality of paths (UR, see at least par. [0140] “ . . . (c) calculating the expected value of log-likelihood function (e.g. calculating the probability that an FV belongs to a specific transaction cluster, given the K mean and standard-deviation values); and (d) adjusting the K mean and standard-deviation values to obtain maximum-likelihood. According to some embodiments, steps (c) and (d) may be repeated iteratively, until the algorithm converges, in the sense that the adjustment of the K values does not exceed a predefined threshold between two consecutive iterations . . .”) the request based on values does not exceed threshold, and dynamically excluding at least one of the plurality of paths for which the value exceeds the predefined threshold (UR, see at least par. [0251] “In some embodiments, neural network 214 may be configured to repeat the selection of an optimal routing path a predefined number of times, each time excluding the selected routing path from the list of available paths 208, so as to produce a predefined number of selected optimal (e.g., in descending order) routing paths.”) ;
splitting, by the reconciliation system, the value of the transaction request across remaining of the plurality of paths based on routing configuration data and path-specific preference weight (see at least par. [0375] “. . . As shown in Fig. 14A, the one or more OS elements may include one or more of: a first data element pertaining to one or more nodes (e.g., N1, N2, N3) of a computer network (e.g., an identification of one or more nodes of computer network 210 of Fig. 13); a second data element (e.g., PE1, PE2) pertaining to a physical entity (PE); a third data element (e.g., LE1, LE2) pertaining to a legal entity (LE); and a fourth data element (e.g., EE1, EE2) pertaining to an enabling entity (EE). The one or more OS elements may be linked, associated or interconnected in a unidirectional or bidirectional logical connection, as displayed by the arrows in Fig. 14A”) The cited portion discloses splitting between path specific based on weights;
It would be obvious to one of ordinary skill in the effective time of filing to combine the features of the evaluating transactional request and splitting the value of the transaction optimally as disclosed by UR with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt to better optimize the transfer of one or more transactions via network nodes (UR, par. [0061]).
Lopes in view of Schnitt in further view of UR does not disclose the following; however, Fery teaches:
encrypting, by the reconciliation system, the transformed notification (Fery, see at least par. [0070] “. . . The value transfer center (Postage Point) uses the key KT to encrypt the data key KD that is to be transmitted and then transfers said data key KD to the server of the payment assurance system (ZinS central system)”), wherein an encryption key for the encrypted notification is deleted from an encryption key cache upon exceeding a pre-determined time threshold and is replaced with a newly generated encryption key (Fery, par. [0089] “If an acknowledgement by the payment assurance system is absent for a prolonged period of time (time-out exceeded), then the value transfer center (Postage Point) can trigger an alarm via its direct or indirect user interface.” & par. [0090] “ As soon as a crypto-card receives a data key, it deletes all of the data keys that have the same generation counter value as the most recent transmission. This ensures that, in case of error-related multiple transmission, keys that could previously only be successfully loaded onto some of all of the crypto-cards are deleted. This allows a transaction-secure key transmission.”) data keys are deleted from expired key to ensure newly generated encryption key;
It would be obvious to one of ordinary skill in the effective time of filing to combine the features of encrypting the transformed data as disclosed by Fery with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to better transmitting encrypted data (Abstract). Therefore, the combination is obvious.
Dependent Claims 23, 33, 40 are grouped together. Dependent claim 23 is disclosed as follows: Lopes in view of Schnitt in further view of UR discloses the system of claim 21. However, Schnitt teaches: authenticating the notification by the authentication system based, at least in part, on information associated with the transaction request, the requestor system that transmitted the transaction request, transaction request receiver, or a combination thereof, wherein the authentication system utilizing at least one authentication protocol or the secure file transfer protocol message (Schnitt, Col. 23 ln 56-62, Col. 29 ln 21-25 ) the cited portion discloses authentication transaction message from the requestor via an FTP protocol.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of authenticating transaction message as disclosed by Schnitt with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to better automate the transactional processes between organizations that do business together using incompatible pre-existing transactional systems (Schnitt, abstract). Therefore, the combination is obvious.
Dependent Claims 24, 34 are grouped together. Claim 24, for instance, is disclosed as follows: Lopes in view of Schnitt discloses the system of claim 21. However, Schnitt teaches: authenticating the requestor system by the authentication system, wherein the authentication system communicates with an identity provider to verify authenticity of the requestor system and permissions to perform the transaction request; and verifying one or more deposit accounts associated with the transaction request are within transaction processor by an account validation system (Schnitt, Col. 23 ln 34-54 ) the cited portion discloses communicating to verify data by deserializing the embedded data.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of authenticating the system as disclosed by Schnitt with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to better automate the transactional processes between organizations that do business together using incompatible pre-existing transactional systems (Schnitt, abstract). Therefore, the combination is obvious.
Dependent Claim 30 is disclosed as follows: Lopes in view of Schnitt in further view of UR discloses the system of claim 21. However, Schnitt teaches: the operations further comprising: transmitting the transaction status to an account ledger system, an auditing system, and/or a transaction system by the notification handler via one or more transaction event-topic streams (Schnitt, see at least col. 24, ln 41-51) the notification handler corresponds to the communicator component which handles the message notifications or alerts.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of transmitting a transaction status as disclosed by Schnitt with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to better automate the transactional processes between organizations that do business together using incompatible pre-existing transactional systems (Schnitt, abstract). Therefore, the combination is obvious.
Claim 22, 32, 39, 43 are rejected under 35 U.S.C. 103 as being unpatentable over Lopes et al. (US 2021/0350382 A1) in view of Schnitt (US 11, 171, 911 B2) in further view of UR, Shmuel (WO 2021/033184 A1) in further view of Rule (US 2021/0342817 A1).
Dependent Claims 22, 32, 39 are grouped together. Claim 22, for instance, is disclosed by Lopes in view of Schnitt in further view of UR teaches the system of claim 21. However, Rule teaches: The computer-implemented method of claim 31, the method further comprising: generating, in real-time, the notification for updating the transaction by the transaction network based, at least in part, on an event associated with a transaction related to the transaction request, wherein the event includes a failed transaction, a rejected transaction, a pending transaction, or a settled transaction (Rule, Par. [0018] “. . . In other instances, a user may not even be aware of the transaction attempt. Thus, embodiments are directed to enabling a transaction card 102 to collect data associated with each transaction attempt and providing the data to the transaction system 106 to detect failures and notify customers and operators of transaction terminal(s) 108.)”) Interpretation: the cited portion discloses notification of the transaction statuses.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of notifying failed transactions as disclosed by Rule with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to improve the security aspects of the systems. Therefore, the combination is obvious.
Dependent Claim 43 are grouped together. Claim 22, for instance, is disclosed by Lopes in view of Schnitt in further view of UR teaches the system of claim 21. However, Rule teaches: wherein the status message transmitted to the requestor system provides real-time updates of the transaction request including failed, rejected, or settled statuses (Rule, Par. [0018] “. . . In other instances, a user may not even be aware of the transaction attempt. Thus, embodiments are directed to enabling a transaction card 102 to collect data associated with each transaction attempt and providing the data to the transaction system 106 to detect failures and notify customers and operators of transaction terminal(s) 108.)”) Interpretation: the cited portion discloses notification of the transaction statuses.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of notifying failed transactions as disclosed by Rule with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to improve the security aspects of the systems. Therefore, the combination is obvious.
Claim 26, 36 are rejected under 35 U.S.C. 103 as being unpatentable over Lopes et al. (US 2021/0350382 A1) in view of Schnitt (US 11, 171, 911 B2) in further view of UR, Shmuel (WO 2021/033184 A1) in further view of Fery et al. (US 2006/0190732 A1) in further view of Bohli et al. (US 2018/0336552 A1).
Claims 26 and 36 are grouped together. Lopes in view of Schnitt in further view of UR in further view of Fery discloses the system claim 25. However, Bohli teaches: wherein the security system utilizes a secure hash algorithm for searching the encrypted notification of the transaction request (Bohli, claim 15) the cited portion discloses using cryptographically secure hash function for searching encrypted data.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of using secure hash function as disclosed by Bohli with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR in further view of Fery to improve the security aspect while transmitting data. Therefore, the combination is obvious.
Claim 28, 29, 44 are rejected under 35 U.S.C. 103 as being unpatentable over Lopes et al. (US 2021/0350382 A1) in view of Schnitt (US 11, 171, 911 B2) in further view of UR, Shmuel (WO 2021/033184 A1) in further view of Cella et al. (US 2018/0284746 A1)
Claim 28. Lopes in view of Schnitt discloses a system The system of claim 21, wherein a machine learning system provides a non-real-time machine learning feedback to adjust the remaining of the plurality of paths (Cella, see at least Par. [0006] “. . . The optimization of the input selection configuration for the collector route may change a selected subset of the plurality of input channels for data collection from a first set of input channels to a second set of input channels to optimize data collection from a machine based on a determined life cycle of the machine, duty cycle of the machine, or operating stage of the machine. The learning feedback facility may be an expert system utilizing a neural network to identify optimizations of the input selection configuration. The cognitive input selection facility may store a distributed ledger for tracking of transactions associated with the collected data . . .”) Interpretation: the cited portion discloses feedback feature using to optimize the transaction path.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of using feedback features in optimizing an optimal path as disclosed by Cella with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to improve the optimizing the data transmission path. Therefore, the combination is obvious.
Claim 29 is disclosed. Lopes in view of Schnitt in further view of Cella discloses: The system of claim 21. However, Cella teaches: further comprising: wherein generating the transaction activity interface further comprises: receiving a modification request to alter the transaction re quest from the requestor system and at the transaction activity interface; and altering the transaction request based on the modification request (Cella, par. [0971]) The cited portion discloses using modification request and altering request based on such modification for smart routing system (with application on data transmission).
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of using modification request in optimizing an optimal path as disclosed by Cella with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to improve the optimizing the data transmission path. Therefore, the combination is obvious.
Claim 44. Lopes in view of Schnitt discloses a system The system of claim 21. However, Cella teaches: wherein evaluating the value of the transaction request and dynamically excluding the at least one of the plurality of paths includes receiving real-time feedback indicating a risk associated with the transaction request from a fraud monitoring system (Cella, see at least Par. [0006] “. . . The optimization of the input selection configuration for the collector route may change a selected subset of the plurality of input channels for data collection from a first set of input channels to a second set of input channels to optimize data collection from a machine based on a determined life cycle of the machine, duty cycle of the machine, or operating stage of the machine. The learning feedback facility may be an expert system utilizing a neural network to identify optimizations of the input selection configuration. The cognitive input selection facility may store a distributed ledger for tracking of transactions associated with the collected data . . .”) Interpretation: the cited portion discloses receiving feedback based on system.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of using feedback features in optimizing an optimal path as disclosed by Cella with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to improve the optimizing the data transmission path. Therefore, the combination is obvious.
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over Lopes et al. (US 2021/0350382 A1) in view of Schnitt (US 11, 171, 911 B2) in further view of UR, Shmuel (WO 2021/033184 A1) in further view of Lancashire et al. (US 2019/0044734 A1).
Claim 42 is disclosed. Lopes in view of Schnitt in further view of UR discloses: The system of claim 21. However, Lancashire teaches: the operations further comprising: transmitting the transaction data associated with the transaction request to a tokenization system (Lancashire, see at least par. [0034] “. . . embedding, by a first node among a plurality of nodes in a peer-to-peer blockchain network and into an unconfirmed transaction being propagated across said network for eventual inclusion in a block, a cryptographic signature and a network address that combines with other cryptographic signatures and network addresses that have been previously embedded in the unconfirmed transaction by one or more other nodes of the plurality of nodes in the blockchain network . . . wherein the burn fee is a cost denominated in a value of a token managed by the blockchain network . . .”) Interpretation: the blockchain network corresponds to a tokenization system under BRI and could be used to transmit transaction data; and generating one or more tokens by the tokenization system to represent the transaction data, wherein the one or more tokens include a low-value token or a high-value token (see at least par. [0034] “. . . quantifying, by the one or more third nodes and in accordance with the set of consensus rules of the blockchain, the value of one or more transactions being included in a candidate block by reducing it to a burn value, wherein the burn value is a figure denominated in a value of a token managed by the blockchain network . . .”) Interpretation: a burn value corresponds to a value token and is generated, or quantified, by the blockchain network.
It would be obvious to one of ordinary skill in the art before the effective filing date to combine the features of transmitting the transaction data with tokenization system as disclosed by Lancashire with the invention of reconciliating transactional data including update or status as taught by Lopes in view of Schnitt in further view of UR to provide optimal transaction for a cryptocurrency network in dividing revenue between nodes (Abstract). Therefore, the combination is obvious.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5: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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mike W. Anderson can be reached on (571) 270-0508. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TOAN DUC BUI/Examiner, Art Unit 3693
/BRUCE I EBERSMAN/Primary Examiner, Art Unit 3693