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 .
Response to Arguments
Applicant’s arguments, see Rejection Under 35 U.S.C. § 101, filed November 7, 2025, with respect to rejections of the claims under 35 U.S.C. § 101 have been fully considered and are persuasive. In particular Applicant’s arguments regarding the cited example 42 on page 16 of the arguments were persuasive, as the additional device elements integrate the message formatting abstract ideas into a practical application. The rejections of the claims under 35 U.S.C. § 101 has been withdrawn.
Applicant’s arguments, see Rejection Under 35 U.S.C. § 102, filed November 7, 2025, with respect to the rejection(s) of claims 1, 3-5, 7, 8, 12, and 14 under 35 U.S.C. § 102 have been fully considered and are persuasive. The cited Hersbach reference does not recite machine learning component as recited in the amended claims. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of new art found in a search of the prior art prompted by amendments.
Applicant’s arguments, see Rejection Under 35 U.S.C. § 103, filed November 7, 2025, with respect to the rejection(s) of claims 2, 6, 9-11, 13 and 15-20 under 35 U.S.C. § 103 have been fully considered and are persuasive, based on amendments to parent claims overcoming the rejection of record. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of new art found in a search of the prior art prompted by amendments.
Claim Objections
Claim 16 objected to because of the following informalities: The first use of the word “specification” should be plural. Appropriate correction is required.
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.
Claims 1, 3 – 5, 7, 8, 10, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over McGinlay et al. (US Patent 11,010,731, cited but not relied upon in previous action), hereinafter McGinlay, in view of Soultan et al. (US Patent Application Publication 2020/0076538), hereinafter Soultan.
Regarding claim 1, McGinlay teaches a specification mapping system for reducing message rejections (Column 3 line 54 – Column 4 line 9), the system comprising:
a processor (Column 4 line 26);
a computer-readable medium storing instructions that are operative upon execution by the processor (Column 4 line 47) to:
train a component (Fig. 1, the global transaction processing circuit 128 and its subcircuits) of a message correction manager (Fig. 1, the originating FI 106) using successful transaction requests (Column 8 lines 4 – 30, similar transactions in the past are used to analyze the current transaction);
map a transaction request generated by a user device (Fig. 1, the originator 104) to a message specification associated with a recipient device (Column 8 lines 4 – 30, determining what information is missing from the transaction; Column 12 lines 6 – 32, based on the message’s intended receiving FI 110, the originating FI 106 determines if the transaction is valid or contains errors), the message specification comprising a set of rules for acceptance of a message by the recipient device (Column 8 lines 4 – 30, the specification comprises the required information to be successfully processed);
automatically identify, using the trained component of the message correction manager, a noncompliant message element associated with the transaction request based on the mapping of the transaction request to the message specification (Column 13 lines 7 – 24, determining the defects / missing information);
automatically correct, using the trained component of the message correction manager, the noncompliant message element (Column 8 lines 38 – 47, the transaction correction circuit automatically corrects the message) prior to a first attempt to submit the transaction request to the recipient device from the user device (Figs. 5 and 6, the step of repairing transaction information 526 and 618 occur before attempting to send the transaction to the recipient. Referring to the applicant’s drawings, the user device, message correction manager, and recipient device are arranged in the same way, where the message correction manager acts as an in-between for the two devices), wherein correcting the noncompliant message element creates a corrected transaction request, wherein the noncompliant message is corrected automatically to comply with the message specification of the recipient device (Column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information); and
submit the corrected transaction request to the recipient device via a network (Column 13 line 24, the transaction is transmitted to the receiving FI), wherein the corrected transaction request is corrected to comply with the message specification of the recipient device without rejection of the transaction request by the recipient device based on noncompliance with the message specification, thereby reducing message rejections by the recipient device (Column 3 line 54 – Column 4 line 9).
McGinlay does not explicitly teach that the trained component of the message correction manager is a machine learning component (McGinlay only describes the transaction correction itself, and does not elaborate as to software implementation details).
Soultan teaches a similar system that automatically corrects transaction request messages (Paragraph 0014) to conform to a specification, wherein the correction is performed by a machine learning component (Paragraph 0015). Soultan additionally teaches the training of the component (Paragraph 0015).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that the transaction correction of McGinlay would be performed by a machine learning component similar to Soultan. It would be obvious because the additional of an intelligent machine learning component allows for the system to actively learn, rather than require downtime in updating the system or performing manual corrections (Soultan paragraphs 0014/0015). Additionally, machine learning components are widespread and cover a range of different techniques (Soultan paragraphs 0073, 0077). Although not explicitly taught, given that the task of McGinlay involves analyzing data, it would be reasonable for one of ordinary skill in the art to consider that the circuits taught by McGinlay include machine learning components.
Regarding claim 3, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further cooperative to:
perform automatic correction of a plurality of noncompliant message elements associated with an original version of the transaction request (McGinlay column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information) in real-time during a first attempt to submit the transaction request to the recipient device wherein a corrected version of the transaction request is created that is in condition for acceptance by the recipient device without a failed first attempt to submit the transaction request (McGinlay Figs. 5 and 6, the automatic correction occurs as part of the first submission).
Regarding claim 4, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further operative to:
check for an updated rule associated with a plurality of message specifications corresponding to a plurality of recipient devices from a source of message specification updates at an occurrence of a predetermined event (McGinlay column 8 lines 47 – 53, the originator profile is used to determine if a message can be repaired. According to McGinlay column 6 lines 27 – 42, this profile may be updated with the predetermined event of a new transaction. This can be considered updating the rules for the message specifications by updating the repository of past successful transactions; Alternatively, the machine learning component of Soultan checks for updated rules by learning new reference outputs during dual-mode operation in paragraph 0068, where the system checks for human corrections).
Regarding claim 5, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further operative to:
analyze a message format of the transaction request using the message specification, the message specification comprising a message format rule describing a requirement associated with format of the transaction request (McGinlay column 8 lines 12 – 16, analyzing previous messages; Soultan paragraph 0081, the formats are cognitively learned by the machine learning);
identify an error in the message format which fails to conform to the message format rule, wherein the noncompliant message element comprises the error in the message format (McGinlay column 8 lines 27 – 38, missing data/defective portions of the message are noted; Soultan paragraph 0081, errors are detected and extracted); and
correct the error in the message format automatically in real time (McGinlay column 8 lines 38 – 47, the transaction correction circuit automatically corrects the message; Soultan abstract);
submit the corrected transaction request to the recipient device in a first submission attempt (McGinlay Figs. 5 and 6, the automatic correction occurs as part of the first submission) via the network (McGinlay column 13 line 24, the transaction is transmitted to the receiving FI), wherein the corrected transaction request comprises the corrected message format (McGinlay column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information), wherein the message format is corrected without receiving a rejection message from the recipient device (McGinlay column 3 line 54 – column 4 line 9).
Regarding claim 7, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further operative to:
analyze a plurality of data fields associated with the transaction request using the message specification, the message specification a data fields rule describing a requirement associated with data fields of the transaction request (McGinlay column 8 lines 4 – 30, the specification comprises the required information to be successfully processed; Soultan paragraph 0076, certain data fields may need to be encrypted);
identify an error in a data field of the plurality of data fields which fails to conform to the data fields rule, wherein the noncompliant message element comprises the error in the data field (McGinlay column 13 lines 7 – 24, the missing information is identified; Soultan paragraph 0076, the field that is improperly not encrypted is identified); and
correct the error in the data field automatically in real time (McGinlay column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information; Soultan paragraph 0076, the data field is corrected by encrypting the field); and
submit the corrected transaction request to the recipient device in a first submission attempt (McGinlay Figs. 5 and 6, the automatic correction occurs as part of the first submission) via the network (McGinlay column 13 line 24, the transaction is transmitted to the receiving FI), wherein the corrected transaction request comprises a corrected data field (McGinlay column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information; Soultan paragraph 0076, the data field is corrected by encrypting the field).
Claim 8 recites similar language to claim 1, and is similarly rejected.
Regarding claim 10, McGinlay in view of Soultan teaches the method of claim 8, further comprising:
identifying that the corrected transaction request is rejected by the recipient device (McGinlay column 9 lines 1 – 4, the transaction correction circuit may not be able to automatically correct the defects. That is, it identifies that the corrected request would be still be rejected by the recipient device as in column 8 lines 15 – 20);
checking a plurality of records associated with corrected transaction requests within an audit log in response to detecting a rejection rate (McGinlay column 9 line 45 – column 10 line 7, in response to the processing circuit finding an originator consistently achieves low scores; McGinley column 15 lines 37 – 44, the score can indicate the likelihood of rejection of the transactions) exceeding a threshold maximum message rejection rate (McGinlay column 9 lines 37 – 44, there are different discrete categories of score quality; a “below average” or “poor” score are thresholds representing that a score is low);
identifying that a problem with the message correction manager prevented accurate correction of the transaction request (McGinlay column 10 lines 3 – 5, identifying a field that is commonly incorrect; McGinlay column 17 lines 39 – 60, if the correction manager cannot fix the transaction automatically, it provides an error report that identifies the issues);
in response to identifying the problem, troubleshooting the message correction manager using the plurality of records in the audit log (McGinlay column 20 lines 4 – 36, in cases where there is no manual correction, the user must correct the defects using the information from the error report; As per McGinlay column 6 lines 27 – 42, this may become part of the originator profile and resolve the correction manager’s inability to automatically solve the problem; Soultan paragraph 0068 permits manual corrections during operation).
Claim 12 recites similar language to claim 5, and is similarly rejected.
Claim 14 recites similar language to claim 7, and is similarly rejected.
Claims 2, 9, and 15 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over McGinlay in view of Soultan as applied to claim 1 above, and further in view of Ha (NPL, What is a Transaction ID? The basic knowledge of Transaction ID).
Regarding claim 2, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further operative to:
update an audit log in a data storage device with a record indicating correction of the noncompliant message element, the record comprising a description of the noncompliant message element which is corrected in the corrected transaction request (McGinlay column 19 lines 33 – 67, after correcting the transaction, the originating FI generates a score card for each user device which is transmitted to the user device. This score card may be a representation of the defects).
McGinlay in view of Soultan does not explicitly teach that the record comprises a message identifier (Although McGinlay teaches that each message receives its own score card, this does not explicitly state that the message has an identifier).
Ha teaches that a transaction identifier is logged (#1 PayPal Transaction ID, PayPal stores transaction IDs and records).
It would be obvious to one of ordinary skill in the art before the effective filing date of the invention to that the score card of McGinlay in view of Soultan would include a message identifier. It would be obvious because a transaction identifier is a well-known (Ha presumes that the reader has some awareness of what a transaction ID is) method for uniquely identifying a transaction if it is needed (What is a Transaction ID?). One of ordinary skill in the art would clearly understand that logging or providing a record of any transaction should include an element as common as an identifier.
Claim 9 recites similar language to claim 2, and is similarly rejected.
Claim 15 recites similar language to claim 2, and is similarly rejected.
Regarding claim 16, McGinlay in view of Soultan and Ha teaches the computer storage medium of claim 15, wherein the operations further comprise:
accessing a plurality of rules associated with a plurality of message specifications (McGinlay column 8 lines 47 – 53, the originator profile is used to determine if a message can be repaired) via a network (McGinlay column 4 lines 10 – 31, the computing systems may be a plurality of servers); and
updating a plurality of message specifications associated with a plurality of recipient devices in real-time using the plurality of rules, wherein the updated plurality of message specifications are used to identify noncompliant message elements in transaction requests being submitted to the plurality of recipient devices (McGinlay column 6 lines 27 – 42, the profile may be updated at a new transaction. This can be considered updating the rules for the message specifications by updating the repository of past successful transactions; Alternatively, the machine learning component of Soultan checks for updated rules by learning new reference outputs during dual-mode operation in paragraph 0068, where the system checks for human corrections).
Regarding claim 17, McGinlay in view of Soultan and Ha teaches the computer storage medium of claim 15, wherein the operations further comprise:
detecting a rejection rate (McGinlay column 9 line 45 – column 10 line 7, in response to the processing circuit finding an originator consistently achieves low scores; McGinley column 15 lines 37 – 44, the score can indicate the likelihood of rejection of the transactions) exceeding a threshold maximum message rejection rate (McGinlay column 9 lines 37 – 44, there are different discrete categories of score quality; a “below average” or “poor” score are thresholds representing that a score is low);
and
generating a notification including the rejection rate (Figs. 5 and 6, the score card and error reports).
Claim 18 recites similar language to claims 2 and 3, and is similarly rejected.
Regarding claim 19, McGinlay in view of Soultan and Ha teaches the computer storage medium of claim 15, wherein operations further comprise:
analyzing the transaction request using the message specification during a first message submission attempt without receiving a message rejection from the recipient device (McGinlay Figs. 5 and 6, the messages are analyzed and corrected before being sent to the recipient device);
determining whether a message format, message data and a plurality of message fields comply with the set of rules associated with the message specification (McGinlay column 8 lines 27 – 38, missing data/defective portions of the message are noted; Soultan paragraph 0081, errors are detected and extracted);
transmitting the transaction request to the recipient device without making corrections responsive to a determination that the message format, message data, and the plurality of message fields comply with the set of rules (McGinlay column 14 lines 35 – 39, if the transaction is valid, it is sent to the recipient);
identifying noncompliant elements associated with the transaction request in response to a determination the message format, the message data and the plurality of message fields fail to comply with the set of rules (McGinlay column 14 lines 39 – 45, determining that the transaction is not valid); and
correcting the noncompliant elements automatically in real-time during the first message submission attempt, wherein the noncompliant message element comprises at least one of a message format error, and a data field error (McGinlay column 14 lines 45 – 57, if data is missing from the message, it can be automatically corrected).
Claim 20 recites similar language to claims 2 and 4, and is similarly rejected.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over McGinlay in view of Soultan as applied to claim 1 above, and further in view of the SWIFT Standards MT (NPL), hereinafter SWIFT Standards.
Regarding claim 6, McGinlay in view of Soultan teaches the system of claim 1, wherein the instructions are further operative to:
analyze a plurality of data fields associated with the transaction request using the message specification (McGinlay column 8 lines 4 – 30, the specification comprises the required information to be successfully processed);
identify an error which fails to conform to a rule (McGinlay column 13 lines 7 – 24, the missing information is identified); and
correct the error in the data field automatically in real time (McGinlay column 13 lines 7 – 24, the transaction is automatically corrected by adding the missing information) at a first submission attempt (McGinlay Figs. 5 and 6, the automatic correction occurs as part of the first submission); and
submit the corrected transaction request to the recipient via the network (McGinlay column 13 line 24, the transaction is transmitted to the receiving FI).
McGinlay in view of Soultan does not explicitly teach that the error can be a data limit error, wherein the noncompliant message element comprises the data limit error.
The SWIFT Standards teach that SWIFT transaction messages have a maximum length per message that is limited on input for a computer-based terminal (Page 47).
McGinlay in view of Soultan teaches that one of the message specifications it complies with is SWIFT. It automatically converts the data to SWIFT format if it is valid (McGinlay column 12 lines 32 – 48).
It would have been obvious to one of ordinary skill in the art before the effective filing date that the conversion to SWIFT format of McGinlay in view of Soultan would include identifying and correcting any data limit errors associated with the request to conform with the SWIFT standards. It would be obvious because SWIFT is explicitly targeted for use by McGinlay in view of Soultan (McGinlay column 12 lines 32 – 48, Soultan paragraph 0014/0075), and because conforming to SWIFT standards provides a number of benefits including productivity and reduced risk of errors (SWIFT Standards page 16). SWIFT does not allow input to exceed a certain size as part of the definition of SWIFT (SWIFT Standards page 47). It would be clear to one of ordinary skill in the art that enforcing this data rule as part of the conversion allows the messages to properly conform to SWIFT and gain its associated benefits.
Claim 13 recites similar language to claim 6, and is similarly rejected.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over McGinlay in view of Soultan as applied to claim 8 above, and further in view of Ha and Wikipedia List box (NPL, cited in previous action).
Regarding claim 11, McGinlay in view of Soultan teaches the method of claim 8, further comprising:
generating a list of corrected transaction messages generated by the message correction manager (McGinlay Fig. 6, in the case of a batch transaction, the reports and score cards represent multiple repaired transaction messages); and
presenting the list of corrected transaction messages to a user via a user interface device (McGinlay Fig. 6, the score card and error reports are transmitted to the originator device; McGinlay column 5 line 12, the user device may have a user interface).
McGinlay in view of Soultan does not explicitly teach that the list includes a first corrected transaction message identifier (Although McGinlay teaches that each message receives its own score card, this does not explicitly state that the message has an identifier).
Ha teaches that a transaction identifier is logged (#1 PayPal Transaction ID, PayPal stores transaction IDs and records).
It would be obvious to one of ordinary skill in the art before the effective filing date of the invention to that the score card of McGinlay in view of Soultan would include a message identifier. It would be obvious because a transaction identifier is a well-known (Ha presumes that the reader has some awareness of what a transaction ID is) method for uniquely identifying a transaction if it is needed (What is a Transaction ID?). One of ordinary skill in the art would clearly understand that logging or providing a record of any transaction should include an element as common as an identifier.
McGinlay in view of Soultan and Ha does not explicitly teach that a first corrected transaction message identifier is placed at a top of the list for viewing (McGinlay does not teach the specific UI design for displaying batch reports).
Wikipedia List box teaches that list items are placed at the top of lists for viewing (The image in the article displays an item at the top of the list for viewing).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that the UI described in McGinlay in view of Soultan and Ha would display the list of corrected messages by placing a first corrected transaction message identifier at the top of the list as taught by Wikipedia List box. They would be motivated to do so as it is a standard method for displaying a list (Wikipedia List box Header, the list box is in the XForms standard). One of ordinary skill in the art would turn to standard UI design elements to present information given the lack of detail in the description of the UI in McGinlay in view of Soultan and Ha.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Shevchenko et al. (US Patent 10,594,757) teaches a method for automatic error correction in messages by a machine learning model before sending them. It is not relied upon as it is directed to generic messages rather than transaction requests, but it demonstrates there is work being done in the field of machine-learning-driven message correction systems.
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 BRYAN PAI SONG HUANG whose telephone number is (571)272-0510. The examiner can normally be reached Monday - Friday 11:30 AM - 8:30 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, ASHISH THOMAS can be reached at (571) 272-0631. 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.
/B.P.H./Examiner, Art Unit 2114
/ASHISH THOMAS/Supervisory Patent Examiner, Art Unit 2114