DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
The following is a Non- Final Office Action in response to communications received December 16, 2025. Claims 2-4, 15, 17 and 19 have been canceled. Claims 1, 5, 14 and 18 have been amended. No new claims have been added. Therefore, claims 1, 5-14, 16, 18 and 20 are pending and addressed below.
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 has been entered.
Priority
Application No. 15949017 filed 04/09/2018 and having 4 RCE-type filing therein is a Continuation of 15058000 , filed 03/01/2016 ,now U.S. Patent # 9940668 and having 1 RCE-type filing therein 15058000 is a Continuation of 14036951 , filed 09/25/2013, now abandoned 14036951 Claims Priority from Provisional Application 61744398 , filed 09/25/2012
Assignee/Application Name: MX Technologies, Inc.
Inventor(s): Caldwell, John
Response to Amendment/Argument
Claim Rejections - 35 USC § 103
Applicant argues the prior art references fail to teach the amended claim limitations. Applicant’s argument is moot the 103 rejection has been withdrawn in response to the amendments submitted.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1 and 5-13; Claim(s) 14 and 16; Claim(s) 18 and 20: are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In reference to Claim(s) 1 and 5-13; Claim(s) 14 and 16; Claim(s) 18 and 20:
Independent claims 1, 14 and 18 recite the limitation “wherein the first API defines a first set of transaction fields having first semantic definitions”…”determining, at the PFM server, prior to transaction matching, that the first API and the second API are semantically incompatible based on at least one of differing transaction field names representing equivalent financial concepts, differing transaction field formats for representing transaction attributes, or differing presence or absence of transaction fields between the first API and the second API;”…”in response to determining the semantic incompatibility, generating, at the PFM server, an API-specific field-mapping model that maps transaction fields of the second API to corresponding canonical transaction fields associated with the first API”, “comparing, at the PFM server, the first account transaction data and the normalized second account transaction data over a specified period of time to determine whether the normalized second account transaction data corresponds to the first financial account, the comparing comprising a semantic field-level comparison rather than a direct syntactic comparison of API fields;”; which is new matter.
There is no support or possession of “wherein the first API defines a first set of transaction fields having first semantic definitions”. There is no support or possession of a first and second API being “semantically incompatible based on differing…field names…differing… field formats or differing presence or absence of transaction fields between the first API and the second API”. There is no support or possession of the limitation “generating, at the PFM server, an API-specific field-mapping model that maps transaction fields of the second API to corresponding canonical transaction fields associated with the first API” or “comparing, at the PFM server, the first account transaction data and the normalized second account transaction data over a specified period of time to determine whether the normalized second account transaction data corresponds to the first financial account, the comparing comprising a semantic field-level comparison rather than a direct syntactic comparison of API fields;”
The original written description has possession of:
[0010]… method and system for moving at least one account from one financial institution to another over a network of computers using an aggregation provider or direct access with an application programming interface in accordance with the principles and teachings of the disclosure…
[0017]… moving at least one account from one financial institution to another over a network of
computers using direct access with an application programming interface to collect user
account information and data where user accounts are compared to expected or anticipated
account information using transaction matching and also implementing an accuracy check.
[0038]… the retrieval process at 220, the old account data may be retrieved through a direct application programming interface (API) at 222. In an implementation of the retrieval process at 220, the old account data may be retrieved from an aggregation provider at 224. In an implementation
at 220, the old account data may be retrieved from a combination of both a direct application
programming interface and from an aggregation provider. At 230, the field values from the
old account data may be retrieved from computer memory and scraped. The data obtained or
scraped from the field values may be stored in computer readable memory for later use in
matching and merging at 240….
[0051]… method and system 900 for moving at least one account from one institution to another over
a network of computers using direct access with an application programming interface to
collect user account information and data where user accounts are compared to expected or
anticipated account information using transaction matching and also implementing an
accuracy check by the user… The method and system may further comprise directly accessing the application programming interface of an institution dependent on the first institution and the old account data and attributes.
[0052]… In order to make use of the vast amounts of financial data available from the various financial institutions 1125, a plurality of aggregation sources 1117 may be used by the system to aggregate financial information through an application program interface (API) 1123.
Please note the original description has support for data being retrieved, accessed, moved through an application program interface not a first and second API with different semantic definitions or the first and second API being incompatible based on differing…field names…differing… field formats or differing presence or absence of transaction fields between the first API and the second API or API-specific field-mapping model that maps transaction fields of the second API to corresponding canonical transaction fields associated with the first API. There is no possession of “comparing, at the PFM server, the first account transaction data and the normalized second account transaction data over a specified period of time to determine whether the normalized second account transaction data corresponds to the first financial account, the comparing comprising a semantic field-level comparison rather than a direct syntactic comparison of API fields;”
The specification has possession of mapping transaction fields of data stored that has been obtained for later use in matching and merging. Application programing interface tool are not part of the field by field mapping process.
[0030]… The problem is that the new data feed may not have the same fields available or may call those fields by different names or different identifying characteristics and therefore may determine that the new source is not just a new source for the same accounts at Acme Financial, but are mistaken as new accounts.
[0038]… At 230, the field values from the old account data may be retrieved from computer memory and scraped. The data obtained or scraped from the field values may be stored in computer readable memory for later use in matching and merging at 240. At 250, forms may be automatically or manually filled out. Form fields within the new account may be populated with field values retrieved from the computer memory as required by the second institution in order to create the at least one new
account with the second institution.
[0043] It will be appreciated that due to differences in the type of data organization used by different aggregators, or institutions, and differences in the descriptions or names of the fields of data, it may not be immediately apparent whether the data fields match or not the last 10 transactions or a specified a date range, for example 30 days, 60 days, 90 days, 120 days etc., depending on the type of transaction and the regularity or occurrence of the transactions, may be compared. If those transactions match for a large percentage of the fields compared, then the system can conclude that it is highly likely or probable that the accounts are the same. If the accounts are viewed as likely being the same then the system can
reformat the data if necessary and, where appropriate and/or desired, merge the data from the plurality of aggregators or institutions. For example, if the system determines that fields determined by a user to be important fields, such as transaction description, transaction amount, transaction date, vendor, etc., match for several transactions, then a match may be determined to have occurred and the data may be merged.
[0044] This process can be viewed as a field-by-field match or overlay. In an implementation, the system may conclude that there is a match if a certain specified percentage of the fields ( or verification criteria) match or is larger than a threshold, such as 80%, or between 80% and 99%, including all percentages in between, or some other desired match success threshold. It will be appreciated that the threshold may be any suitable measure or range, and may be predetermined or may be adjusted on the fly without departing from the scope of the disclosure. In an implementation, thresholds may be adjusted to control the output of any given process within the disclosure. For example, in a situation where a user is able to
check the accuracy of the matching, the number of transactions to check can be limited by tightening the threshold during operation of the method.
[0045]… For example, distinctive fields may be retrieved at 448 and compared from a plurality of accounts, for example two accounts, using transaction matching at 446 such that the accounts may be identified as being potentially the same account, but that may not initially meet a determined threshold. The comparison may help confirm or verify that the accounts are in fact the same and can be merged at 450 based on additional information retrieved at 448 that may be compared and matched at 446. The
distinctive fields that may be compared may include, but are not limited to, dates of the transactions, descriptions of the transactions, amounts of the transactions, and other identifying information, which may be overlaid.
Therefore, the limitations of the independent claim(s) 1, 14 and 18 include new matter. Dependent claims 5-13 of claim 1; dependent claim 16 of Claim 14 and dependent claim 20 of claim 18 contain the same deficiencies and are also rejected under 112(a) for new matter.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-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, Christine Behncke can be reached at 571-272-8103. 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.
/MARY M GREGG/Examiner, Art Unit 3695
Prosecution Insights