DETAILED ACTION
This Office Action has been issued in response to Applicant's Amendment filed December 18, 2025.
Claims 1 and 11 have been amended. Claims 1-7, 9-17, 19-21, and 23 have been examined and 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 .
Response to Arguments
Applicant's arguments filed December 18, 2025 have been fully considered but they are not persuasive.
Applicant argues Guo does not disclose a filtered listing of transfers.
A transfer in the current context is a nonfunctional descriptive label. It is simply text in a file.
Additionally, the rejection is made with respect to Bhakta in view of Guo and Bhakta explicitly discloses transfers. Paragraph [0023] of Bhakta discloses The banking system 101 may, in general, process any number of financial transactions, such as but not limited to processing checks, processing cash, implementing monetary transfers between accounts (within the financial institution and/or with other financial institutions), wiring funds, performing audits, providing information to customers about accounts, opening and closing accounts, investing funds, and implementing lockbox services.
Paragraph [0140] of Guo discloses the information importing solution of this specification may also be applied to other scenarios, such as importing financial information in a financial scenario. Thus, the techniques of Guo would be obvious to apply to the financial system of Bhakta.
Applicant argues Guo does not disclose identifying items “as likely to fail processing”. Likely to fail processing is not well defined but appears to be shorthand for identifying potential errors. For example, Figure 12 of applicant’s specification shows “account should be 9 digits” in response to an account having too many digits. Guo discloses this. Paragraph [0132] of Guo discloses a cause of an error may be “The format of the mobile phone number is incorrect.”
Applicant argues Guo does not disclose processing. Paragraph [0003] of Guo discloses a server can provide an interaction interface to a user through a web page or a client, for the user to fill in information based on the interaction interface, and upload the information to the server for processing or storage.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7, 9-17, 19-21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over US Pub. No. 2014/0195396 to Bhakta et al. (hereinafter “Bhakta”) and further in view of US Pub. No. 2022/0214996 to Guo et al. (hereinafter “Guo”).
As to Claim 1, Bhakta discloses a transfer processing system comprising: a communications module; a processor coupled to the communications module; and a memory coupled to the processor and storing instructions that, when executed by the processor, cause the transfer processing system to:
receive, using the communications module and from a remote device via an upload [interface displayed] on the remote device, a bulk transfer file, the bulk transfer file defining a plurality of requested transfers (Paragraph [0023] of Bhakta discloses financial transactions (and any defects associated with the financial transactions) may enter the banking system 101 through any of various channels, including but not limited to: mobile devices. Paragraph [0034] of Bhakta discloses a batch of a plurality of transactions being presented to the banking system 101 may be received); and
in real time or near real time upon completion of the upload of the bulk transfer file:
classify a plurality of the requested transfers defined in the bulk transfer file as being likely to fail processing (Paragraph [0037] of Bhakta discloses the defect detection system 102 (for example) may retrieve some or all of the transaction information stored in data storage 104 (which may at least include any new transaction information recently stored yet not yet analyzed by the defect detection system 102). The defect detection system 102 may then analyze the retrieved transaction information to determine defect patterns);
[after classifying, prepare a filtered listing of transfers, the filtered listing of transfers including the plurality of requested transfers not identified as likely to fail processing and excluding any of the plurality of requested transfers identified as likely to fail processing]; [process the filtered listing of transfers]; and
provide, to the remote device [a modified bulk transfer file including the plurality of requested transfers] classified as likely to fail processing and excluding the transfers identified in the filtered listing of transfers (Paragraph [0023] of Bhakta discloses financial transactions (and any defects associated with the financial transactions) may enter the banking system 101 through any of various channels, including but not limited to: mobile devices. Paragraph [0024] of Bhakta discloses the defect detection system 102 may receive information about the financial transactions via, for instance, any of the above-mentioned channels. Paragraph [0070] of Bhakta discloses the timing of any defect-related messages to a customer. The message may be sent in real time and/or immediately, such as in response to determining the defect).
Bhakta does not explicitly disclose interface displayed and after classifying, prepare a filtered listing of transfers, the filtered listing of transfers including the plurality of requested transfers not identified as likely to fail processing and excluding any of the plurality of requested transfers identified as likely to fail processing and process the filtered listing of transfers and a modified bulk transfer file including the plurality of requested transfers.
However, Guo disclose this. Figure 6 of Guo discloses an upload interface. Paragraph [0059] of Guo discloses in response to an operation of uploading the information importing file to the server by the user, the server may return an importing result page to the user, and display the statistical data in the importing result page for the user the view. The statistical data may include at least one of the following: a quantity of pieces of information that is successfully imported into the system, a quantity of pieces of information in the imported information that does not pass the verification, a quantity of pieces of information that does not pass the verification and that is not imported. Paragraph [0007] of Guo discloses verifying, by the server, the information included in the information importing file; marking, by the server, information in the information importing file that does not pass the verification, so as to generate an error comparison file; and returning, by the server, the error comparison file to the user. Paragraph [0003] of Guo discloses a server can provide an interaction interface to a user through a web page or a client, for the user to fill in information based on the interaction interface, and upload the information to the server for processing or storage.
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to combine the financial errors system as disclosed by Bhakta, with immediately processing the verified information as disclosed by Guo. One of ordinary skill in the art would have been motivated to combine to apply a known technique to a known device. Bhakta and Guo are directed toward error detecting systems and as such it would be obvious to use the techniques of one in the other. Paragraph [0140] of Guo discloses the information importing solution of this specification may also be applied to other scenarios, such as importing financial information in a financial scenario.
As to Claim 2, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the instructions further cause the transfer processing system to: train a classifier to identify transfers likely to fail processing using training data (Paragraph [0025] of Bhakta discloses to determine defect patterns, the defect detection system 102 may use predictive analytics, such as machine learning algorithms, that learn from accumulated transaction information history. Paragraph [0040] of Bhakta discloses the defect detection system 102 may create classifiers and train on (for example, apply) the classifiers using the historical transaction information stored in data storage 104).
As to Claim 3, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the classifier is configured to classify based on one or more of the following features: recipient account number format; recipient account number length; recipient account number; recipient jurisdiction; and recipient bank identifier (Paragraph [0024] of Bhakta discloses account number(s) involved in the financial transaction).
As to Claim 4, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the transfers represent payments (Paragraph [0024] of Bhakta discloses payee and payor information).
As to Claim 5, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the modified bulk transfer file is provided in a notification that includes a selectable option to accept a suggested correction and wherein the instructions further cause the transfer processing system to: receive an indication from the remote device and via the communications module that a transfer identified as likely to fail processing is believed to be correct (Paragraph [0055] of Bhakta discloses where the message is sent with the expectation of a response, the message might be, for instance: "This is to notify you that your recent deposit of check #XXX in the amount of $YYYY appears to have the following error: the account number indicated on the deposit slip of AAAAAAA should probably be BBBBBBB. Please respond with a text message of `change` if you would like us to make the correction." The above interactive example assumes that the message and the reply are in the form of text messages. However, the message and the reply may be in any type of message format desired. In other examples, more than once choice for responding may be provided, such as a plurality of user-selectable choices each for a different proposed resolution. As understood by the examiner, the option is to respond with ‘change’ in order to make the suggested correction and as such the alternative would be to not make a change and have the transaction processed as is); and
process the transfer associated with the indication (Paragraph [0053] of Bhakta discloses if the process has moved instead from step 503 to step 504, then step 506 may be put on hold (for instance, not yet performed or completed) until an expected response is received from the service system 106 at step 505, and/or until a predetermined timeout period has expired).
As to Claim 6, Bhakta-Guo discloses the transfer processing system of claim 5, wherein the instructions further cause the transfer processing system to: upon determining that the transfer associated with the indication has successfully completed processing, add the transfer to training data used to re-train the classifier, the training data indicating that the transfer has completed processing (Paragraph [0025] of Bhakta discloses to determine defect patterns, the defect detection system 102 may use predictive analytics, such as machine learning algorithms, that learn from accumulated transaction information history. Paragraph [0040] of Bhakta discloses the defect detection system 102 may create classifiers and train on (for example, apply) the classifiers using the historical transaction information stored in data storage 104).
As to Claim 7, Bhakta-Guo discloses the transfer processing system of claim 1, wherein classier is trained with training data that marks at least some of past requested transfers with corrected data, the corrected data indicating a correction made to such transfers for successful processing and wherein the classifier is trained to determine a suggested correction for a transfer identified as likely to fail processing, and wherein the modified bulk transfer file includes the determined suggested correction (Paragraph [0049] of Bhakta discloses the defect detection system 102 may provide a message indicating the defect, the financial transaction in which the defect occurred, and/or a recommended resolution. Paragraph [0043] of Bhakta discloses based on this historical pattern, a rule that may be generated could be as follows: (1) compare the account number written on the deposit slip with known information about the depositing customer; (2) if the account numbers are identical, then proceed with normal check processing; (3) if the account numbers are different, then perform (one or more identified) resolution steps).
As to Claim 9, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the instructions further cause the transfer processing system to: automatically perform a batch processing operation on the requested transfers classified as not likely to fail processing (Paragraph [0043] of Bhakta discloses a rule that may be generated could be as follows: (1) compare the check amount with the deposit slip amount; (2) if the amounts are identical, then proceed with normal check processing; (3) if the amounts are different, then perform (one or more identified) resolution steps).
As to Claim 10, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the modified bulk transfer file indicates a suggested correction for one or more of the requested transfers (Paragraph [0055] of Bhakta discloses where the message is sent with the expectation of a response, the message might be, for instance: "This is to notify you that your recent deposit of check #XXX in the amount of $YYYY appears to have the following error: the account number indicated on the deposit slip of AAAAAAA should probably be BBBBBBB. Please respond with a text message of `change` if you would like us to make the correction.").
As to Claim 11, Bhakta discloses a computer-implemented method comprising:
receiving, from a remote device via an upload [interface displayed] on the remote device, a bulk transfer file, the bulk transfer file defining a plurality of requested transfers (Paragraph [0023] of Bhakta discloses financial transactions (and any defects associated with the financial transactions) may enter the banking system 101 through any of various channels, including but not limited to: mobile devices. Paragraph [0034] of Bhakta discloses a batch of a plurality of transactions being presented to the banking system 101 may be received);
in real time or near real time upon completion of the upload of the bulk transfer file:
classifying a plurality of the requested transfers defined in the bulk transfer file as being likely to fail processing (Paragraph [0037] of Bhakta discloses the defect detection system 102 (for example) may retrieve some or all of the transaction information stored in data storage 104 (which may at least include any new transaction information recently stored yet not yet analyzed by the defect detection system 102). The defect detection system 102 may then analyze the retrieved transaction information to determine defect patterns); and
[after classifying, preparing a filtered listing of transfers, the filtered listing of transfers including the plurality of requested transfers not identified as likely to fail processing and excluding any of the plurality of requested transfers identified as likely to fail processing process the filtered listing of transfers including the plurality of requested transfers classified as not likely to fail processing]; and
provide, to the remote device, [a modified bulk transfer file including the plurality of requested transfers] classified as likely to fail processing and excluding the transfers identified in the filtered listing of transfers] (Paragraph [0023] of Bhakta discloses financial transactions (and any defects associated with the financial transactions) may enter the banking system 101 through any of various channels, including but not limited to: mobile devices. Paragraph [0024] of Bhakta discloses the defect detection system 102 may receive information about the financial transactions via, for instance, any of the above-mentioned channels. Paragraph [0070] of Bhakta discloses the timing of any defect-related messages to a customer. The message may be sent in real time and/or immediately, such as in response to determining the defect).
Bhakta does not explicitly disclose interface displayed and after classifying, prepare and immediately process a listing of transfers including the plurality of requested transfers classified as not likely to fail processing and a modified bulk transfer file including the plurality of requested transfers.
However, Guo disclose this. Figure 6 of Guo discloses an upload interface. Paragraph [0059] of Guo discloses in response to an operation of uploading the information importing file to the server by the user, the server may return an importing result page to the user, and display the statistical data in the importing result page for the user the view. The statistical data may include at least one of the following: a quantity of pieces of information that is successfully imported into the system, a quantity of pieces of information in the imported information that does not pass the verification, a quantity of pieces of information that does not pass the verification and that is not imported. Paragraph [0007] of Guo discloses verifying, by the server, the information included in the information importing file; marking, by the server, information in the information importing file that does not pass the verification, so as to generate an error comparison file; and returning, by the server, the error comparison file to the user. Paragraph [0003] of Guo discloses a server can provide an interaction interface to a user through a web page or a client, for the user to fill in information based on the interaction interface, and upload the information to the server for processing or storage.
Examiner recites the same rationale to combine used for claim 1.
As to Claim 12, Bhakta-Guo discloses the method of claim 11, further comprising: training a classifier to identify transfers likely to fail processing using training data (Paragraph [0025] of Bhakta discloses to determine defect patterns, the defect detection system 102 may use predictive analytics, such as machine learning algorithms, that learn from accumulated transaction information history. Paragraph [0040] of Bhakta discloses the defect detection system 102 may create classifiers and train on (for example, apply) the classifiers using the historical transaction information stored in data storage 104).
As to Claim 13, Bhakta-Guo discloses the method of claim 11, wherein the classifier is configured to classify based on one or more of the following features: recipient account number format; recipient account number length; recipient account number; recipient jurisdiction; and recipient bank identifier (Paragraph [0024] of Bhakta discloses account number(s) involved in the financial transaction).
As to Claim 14, Bhakta-Guo discloses the method of claim 11, wherein the transfers represent payments (Paragraph [0024] of Bhakta discloses payee and payor information).
As to Claim 15, Bhakta-Guo discloses the method of claim 11, wherein the modified bulk transfer file is provided in a notification that includes a selectable option to accept a suggested correction and wherein the method further includes: receiving an indication from the remote device that a transfer identified as likely to fail processing is believed to be correct (Paragraph [0055] of Bhakta discloses where the message is sent with the expectation of a response, the message might be, for instance: "This is to notify you that your recent deposit of check #XXX in the amount of $YYYY appears to have the following error: the account number indicated on the deposit slip of AAAAAAA should probably be BBBBBBB. Please respond with a text message of `change` if you would like us to make the correction." The above interactive example assumes that the message and the reply are in the form of text messages. However, the message and the reply may be in any type of message format desired. In other examples, more than once choice for responding may be provided, such as a plurality of user-selectable choices each for a different proposed resolution. As understood by the examiner, the option is to respond with ‘change’ in order to make the suggested correction and as such the alternative would be to not make a change and have the transaction processed as is); and
processing the transfer associated with the indication (Paragraph [0053] of Bhakta discloses if the process has moved instead from step 503 to step 504, then step 506 may be put on hold (for instance, not yet performed or completed) until an expected response is received from the service system 106 at step 505, and/or until a predetermined timeout period has expired).
As to Claim 16, Bhakta-Guo discloses the method of claim 15, further comprising: upon determining that the transfer associated with the indication has successfully completed processing, adding the transfer to training data used to re-train the classifier, the training data indicating that the transfer has completed processing (Paragraph [0025] of Bhakta discloses to determine defect patterns, the defect detection system 102 may use predictive analytics, such as machine learning algorithms, that learn from accumulated transaction information history. Paragraph [0040] of Bhakta discloses the defect detection system 102 may create classifiers and train on (for example, apply) the classifiers using the historical transaction information stored in data storage 104).
As to Claim 17, Bhakta-Guo discloses the method of claim 11, wherein classier is trained with training data that marks at least some of past requested transfers with corrected data, the corrected data indicating a correction made to such transfers for successful processing and wherein the classifier is trained to determine a suggested correction for a transfer identified as likely to fail processing, and wherein the modified bulk transfer file includes the determined suggested correction (Paragraph [0049] of Bhakta discloses the defect detection system 102 may provide a message indicating the defect, the financial transaction in which the defect occurred, and/or a recommended resolution. Paragraph [0043] of Bhakta discloses based on this historical pattern, a rule that may be generated could be as follows: (1) compare the account number written on the deposit slip with known information about the depositing customer; (2) if the account numbers are identical, then proceed with normal check processing; (3) if the account numbers are different, then perform (one or more identified) resolution steps).
As to Claim 19, Bhakta-Guo discloses the method of claim 11, further comprising: automatically performing a batch processing operation on the requested transfers classified as not likely to fail processing (Paragraph [0043] of Bhakta discloses a rule that may be generated could be as follows: (1) compare the check amount with the deposit slip amount; (2) if the amounts are identical, then proceed with normal check processing; (3) if the amounts are different, then perform (one or more identified) resolution steps).
As to Claim 20, Bhakta-Guo discloses the method of claim 11, wherein the modified bulk transfer file indicates a suggested correction for one or more of the requested transfers (Paragraph [0055] of Bhakta discloses where the message is sent with the expectation of a response, the message might be, for instance: "This is to notify you that your recent deposit of check #XXX in the amount of $YYYY appears to have the following error: the account number indicated on the deposit slip of AAAAAAA should probably be BBBBBBB. Please respond with a text message of `change` if you would like us to make the correction.").
As to Claim 21, Bhakta-Guo discloses the transfer processing system of claim 1, wherein the instructions that, when executed by the processor, cause the transfer processing system to provide, to the remote device, in real time or near real time upon upload of the bulk transfer file including the requested transfers classified as likely to fail processing and excluding the requested transfers classified as not likely to fail processing, the modified bulk transfer file (Paragraph [0023] of Bhakta discloses financial transactions (and any defects associated with the financial transactions) may enter the banking system 101 through any of various channels, including but not limited to: mobile devices. Paragraph [0024] of Bhakta discloses the defect detection system 102 may receive information about the financial transactions via, for instance, any of the above-mentioned channels. Paragraph [0070] of Bhakta discloses the timing of any defect-related messages to a customer. The message may be sent in real time and/or immediately, such as in response to determining the defect. Paragraph [0007] of Guo discloses verifying, by the server, the information included in the information importing file; marking, by the server, information in the information importing file that does not pass the verification, so as to generate an error comparison file; and returning, by the server, the error comparison file to the user),
include instructions that further cause the transfer processing system to provide, to the remote device and through the upload interface, in real time or near real time upon upload of the bulk transfer file, access to the modified bulk transfer including the requested transfers classified as likely to fail processing and excluding the requested transfers classified as not likely to fail processing (Paragraph [0056] of Guo discloses the server may provide an online viewing page or an online editing page for the error comparison file to the user, so that the user may view or modify the error comparison file online).
As to Claim 23, Bhakta-Guo discloses the transfer processing system of claim 2, wherein the classifier is a machine learning classifier (Paragraph [0025] of Bhakta discloses to determine defect patterns, the defect detection system 102 may use predictive analytics, such as machine learning algorithms, that learn from accumulated transaction information history. Paragraph [0040] of Bhakta discloses the defect detection system 102 may create classifiers and train on (for example, apply) the classifiers using the historical transaction information stored in data storage 104).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kevin S Mai whose telephone number is (571)270-5001. The examiner can normally be reached Monday to Friday 9AM to 5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached on 5712723951. 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.
/KEVIN S MAI/Primary Examiner, Art Unit 2499