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 .
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 1/20/2026 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
Claim(s) 1, 3, 8, 9, 11, 16 17, 20 are/is rejected under 35 U.S.C. 103 as being unpatentable over Katzin et al. US2012/0011067 in view of Corneil et al. US2003/0065623 in view of Arbogast US8429527
Regarding claim 1, Katzin teaches: receiving, at an application on a computing device, one or more inputs in a first format; (Katzin see paragraph 0026 0027 0032 0106 transaction requests or messages for example a URL or IP address, entity or third party structures written in format such as JSON NVP)
determining whether the first format of the one or more inputs complies with a schema defined by a canonical model, the schema including a standardized format usable by one or more target applications, wherein the one or more target applications are different than the application; (Katzin see paragraph 0032 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema, merchant to format request to be fully integrated by complying with requirements such that third party message content is external to system with application layer which reads on target application being different)
transforming the one or more inputs into the standardized format to comply with the schema defined by the canonical model based on a determination that the transformation of the first format improves processing of the one or more inputs by the one or more target applications (Katzin see paragraph 0032 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema, merchant to format request to be fully integrated by complying with requirements such that third party message content is external to system with application layer)
Katzin does not distinctly disclose: generating a request using the transformed one or more inputs
transmitting, to the one or more target applications, the request;
receiving a response from the one or more target application, the response including one or more outputs in the standardized format;
transforming the one or more outputs into the first format; and
merging the one or more inputs and the one or more outputs to generate a product
However, Corneil teaches: generating a request using the transformed one or more inputs
transmitting, to the one or more target applications, the request; (Corneil see paragraph 0005 0011 0023 0035 0045 incoming message format from a trading partner and transforming to canonical format then transformed to output format to send output message to second trading partner such that trading partners are on distinct applications)
receiving a response from the one or more target application, the response including one or more outputs in the standardized format; (Corneil see paragraphs 0045 0046 messages to be used in network foundation are in a particular format such that messages sent to network foundation result in message alerts or notifications moving through network foundation or billing events being generated. Message alerts, notifications, billing events reads on response with output, all messages in network foundation being in a particular format reads on output being in standardized format)
transforming the one or more outputs into the first format; and (Corneil see paragraph 0040 transformed document can be returned to raw XML stream)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include format conversion as taught by Corneil for the predictable result of more efficiently organizing and managing data.
Katzin does not distinctly disclose: merging the one or more inputs and the one or more outputs to generate a product
Arbogast teaches: merging the one or more inputs and the one or more outputs to generate a product (Arbogast see col. 9 lines 28-53 document reassembly has a single output document and uses additional input data to be combined with results)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include data merging as taught by Arbogast for the predictable result of more efficiently organizing and managing data.
Regarding claim 3, Katzin teaches: transforming, at an application programming interface (API), the one or more inputs to a standardized format that complies with the schema defined by the canonical model and (Katzin see paragraph 0032 0049 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema where account validation request to canonical transformer in gateway abstraction layer and where translation happens to specific API)
validating that the transformed one or more inputs in the standardized format comply with the schema defined by the canonical model. (Katzin see paragraph 0032 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema, merchant to format request to be fully integrated by complying with requirements)
Regarding claim 8, Katzin teaches: further comprising receiving at least one of a content type, a content encoding, a source application identifier, or a target application identifier associated with the one or more inputs (Katzin see paragraphs 0087, 0090, 0091 0092 service identifiers, payment network identifier, use of single format)
Regarding claims 9, 11, 16-18, 20, note the rejection of claim(s) 1, 3, 8. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Claim(s) 2, 5, 10, 13, 19 are/is rejected under 35 U.S.C. 103 as being unpatentable over Katzin et al. US2012/0011067 in view of Corneil et al. US2003/0065623 in view of Arbogast US8429527 in view of Mischook et al. US2014/0122647
Regarding claim 2, Katzin teaches: further comprising recieving content information, and the content information represents the one or more inputs. (Katzin see paragraph 0032 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema)
Katzin does not distinctly disclose: header information and the header information includes format information representing the standardized format
However, Mischook teaches: header information and the header information includes format information representing the standardized format (Mischook see paragraph 0019 header data including fields identifying format of requested data and field identifying application)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include header data as taught by Mischook for the predictable result of more efficiently organizing and managing data.
Regarding claim 5, Katzin teaches: further comprising mapping the transformed one or more inputs in the standardized format to the one or more target applications, and receiving content information (Katzin see paragraph 0048 0049 translation between formats of information based on mapping)
Katzin does not distinctly disclose: header information, the header information includes a field representing the one or more target applications.
However, Mischook teaches: header information, the header information includes a field representing the one or more target applications. (Mischook see paragraph 0019 header data including fields identifying format of requested data and field identifying application)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include header data as taught by Mischook for the predictable result of more efficiently organizing and managing data.
Regarding claims 10, 13, 19, note the rejection of claim(s) 2, 5. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Claim(s) 4, 12 are/is rejected under 35 U.S.C. 103 as being unpatentable over Katzin et al. US2012/0011067 in view of Corneil et al. US2003/0065623 in view of Arbogast US8429527 in view of Mcllroy et al. US2020/0249877
Regarding claim 4, Katzin teaches: at the application, the first format (Katzin see paragraph 0032 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema)
Transforming the inputs into the standardized format (Katzin see paragraph 0032 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema where account validation request to canonical transformer in gateway abstraction layer)
Katzin does not distinctly disclose: compressing inputs to provide compressed one or more inputs;
decompressing, at the API, the compressed one or more inputs to provide decompressed inputs; and
However, Mcllroy teaches: compressing inputs to provide compressed one or more inputs; (Mcllroy see paragraph 0034 0200 compression of data at API)
decompressing, at the API, the compressed one or more inputs to provide decompressed inputs; (Mcllroy see paragraph 0034 0200 decompressing compressed data at API)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include compression and decompression as taught by Mcllroy for the predictable result of more efficiently organizing and managing data.
Regarding claim 12, see rejection of claim 4
Claim(s) 6, 14 are/is rejected under 35 U.S.C. 103 as being unpatentable over Katzin et al. US2012/0011067 in view of Corneil et al. US2003/0065623 in view of Arbogast US8429527 in view of Zaslavksy et al. US2014/0156684
Regarding claim 6, Katzin teaches: defined by the canonical model. (Katzin see paragraph 0032 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema, merchant to format request to be fully integrated by complying with requirements)
Katzin does not distinctly disclose: receiving a configuration file schema defined by a configuration file of an application- specific schema of the application used to obtain the one or more inputs in the first format, and
comparing the configuration file schema defined by the configuration file with the schema
However, Zaslavksy teaches: receiving a configuration file schema defined by a configuration file of an application- specific schema of the application used to obtain the one or more inputs in the first format, and
comparing the configuration file schema defined by the configuration file with the schema (Zaslavsky see paragraph 0045 compare schema of received request to schema identified in configuration file such that specific common format is used for given attribute)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include comparing schemas as taught by Zaslavksy for the predictable result of more efficiently organizing and managing data.
Regarding claim 14, see rejection of claim 6
Claim(s) 7, 15 are/is rejected under 35 U.S.C. 103 as being unpatentable over Katzin et al. US2012/0011067 in view of Corneil et al. US2003/0065623 in view of Arbogast US8429527 in view of Zaslavksy et al. US2014/0156684 in view of Kawaguchi et al. US7793255
Regarding claim 7, Katzin teaches: defined by the canonical model occurs (Katzin see paragraph 0032 0084 0095 0106-0108 messages and requests require translation to be in standard or canonical format based on XML schema, merchant to format request to be fully integrated by complying with requirements)
Zaslavksy teaches: wherein comparing the configuration file schema defined by the configuration file with the schema (Zaslavsky see paragraph 0045 compare schema of received request to schema identified in configuration file such that specific common format is used for given attribute)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include comparing schemas as taught by Zaslavksy for the predictable result of more efficiently organizing and managing data.
Katzin does not distinctly disclose: comparing the first schema when the application is compiled, at a run time of the application, or when the configuration file is updated.
Kawaguchi teaches: comparing the first schema when the application is compiled, at a run time of the application, or when the configuration file is updated. (Kawaguchi see col. 5 lines 12-23 comparing data to schema when compiling for API)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a translation of messages as taught by Katzin to include comparing schemas as taught by Kawaguchi for the predictable result of more efficiently organizing and managing data.
Regarding claim 15, see rejection of claim 7
Response to arguments
Applicant’s argument: Newly amended claims over come the 101 rejection
Examiner’s response: Applicant’s argument is persuasive and 101 rejection is withdrawn
Applicant’s argument: Newly amended claims over come the 103 rejection
Examiner’s response: Applicant’s argument is moot as newly amended claims are responded to in the above rejection
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLEN S LIN whose telephone number is (571)270-0612. The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALLEN S LIN/Primary Examiner, Art Unit 2153
Prosecution Insights