FINAL REJECTION
Introduction
This Office action is responsive to the communications filed September 8, 2025. Claims 1, 2, 9, 10, 17 and 18 were amended. Claims 1-20 are pending.
Response to Arguments
Applicant’s arguments with respect to the 35 U.S.C. 103 rejection of the claims have been considered but are moot because the new ground of rejection necessitated by the amendment.
Applicant has amended the specification, thereby the objection has been withdrawn.
The drawings filed September 8, 2025 has been accepted.
Applicant asserts that the “claims are not directed to a mathematical concept, mental process, or other abstract idea.” However, the examiner respectfully disagrees. The claims recite an abstract idea of manipulating existing information to generate additional information, which categorized under the mathematical concepts grouping.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to the claimed invention is directed to abstract idea without significantly more. Claim 1 recite receiving, from multiple data sources, data related to a user account, generating a data staging table by margining the data related to the user account, generating, based on the data staging table, a scrubbed Metro2 file that comprises the data related to the user account but does not include personal identification information, validating the scrubbed Metro2 file by analyzing the data related to the user account and based upon validating the scrubbed Metro2 file generating an unscrubbed Metro2 file by adding the personal identification information to the scrubbed Metro2 file. Claims 9 and 17 recite similar language. The dependent claims recite steps such as generating one or more base tables, generating a set of data frames, merging the set of data frames, validating the set of data frames, converting the data staging table, encrypting a final instance of the unscrubbed Metro2 file, and receiving an indication of an authorized transaction.
Hence, claims 1-20 are directed to manipulating existing information to generate additional information. Digitech Image Techs., LLC v. Elecs. for Imaging, Inc., 758 F.3d 1344, 1344, 1351 (Fed. Cir. 2014). Under the broadest reasonable interpretation, the claims are directed to an abstract idea that is categorized under the mathematical concepts grouping. MPEEP 2106.04(a)(2)
The claims recite the following additional elements: inter-network facilitation system, transformation framework, and Metro2file.
The specification of the present invention states the following:
[0002] Indeed, conventional systems often utilize inefficient and insecure tools to create consumer credit files that comply with Metro2 file formatting.
[0033] Moreover, as used herein, the term “transformation framework” refers to a system that processes and converts data from one format and/or structure into another format and/or structure. For instance, the data merging system can use the transformation framework to connect to and extract data from various data sources (e.g., databases, APIs, etc.), data tables, and data systems. For example, the transformation framework can extract data from one or more data sources by performing a series of queries, following a set of predefined rules, or utilizing data connectors. Once extracted, the data merging system can utilize the transformation framework to generate the data staging table by cleansing, validating, transforming, and merging the necessary data.
[0037] In some cases, the inter-network facilitation system 104 is a centralized network system that facilitates access to online banking accounts, credit accounts, and other accounts within a central network location.
[0127] In particular embodiments, inter-network facilitation system 104 may be a network-addressable computing system that can interface between two or more computing networks or servers associated with different entities such as financial institutions (e.g., banks, credit processing systems, ATM systems, or others).
[0133] In particular embodiments, the inter-network facilitation system 104 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, the inter-network facilitation system 104 may include one or more of the following: a web server, action logger, API-request server, transaction engine, cross-institution network interface manager, notification controller, action log, third-party-content-object-exposure log, inference module, authorization/privacy server, search module, user-interface module, user-profile (e.g., provider profile or requester profile) store, connection store, third-party content store, or location store. The inter-network facilitation system 104 may also include suitable components such as network interfaces, security mechanisms, load balancers, failover servers, management-and-network-operations consoles, other suitable components, or any suitable combination thereof. In particular embodiments, the inter-network facilitation system 104 may include one or more user-profile stores for storing user profiles for transportation providers and/or transportation requesters.
However, the claims do not include additional elements that are significantly more than the judicial exception because the additional elements or combination of elements in the claims, other than the abstract idea per se, amount to no more than recitation of generic components that serves to perform generic functions. These functions are well-understood, routine, and conventional activities previously known to the pertinent industry.
Moreover, the limitations generically, referring to manipulating existing information to generate additional information categorized under the mathematical concepts grouping do not constitute significantly more because they are simply an attempt to limit the abstract idea to a particular technological environment. Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself.
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.
Claims 1, 2, 7-10, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2010/0205189 to Ebrahimi et al. (“Ebrahimi”) in view of U.S. Publication No. 2006/0206418 to Byrne et al. (“Bryne”) and U.S. Publication No. 2005/0216497 to Kruse et al. (“Kruse”).
As per claim 1, Ebrahimi discloses receiving data related to a user account (Fig. 4, element 410; Fig. 8), generating a data staging table by merging the data related to the user account (Fig. 4, element 420), generating, based on the data staging table, a scrubbed file that comprises the data related to the user account but does not include personal identification information (abstract, Fig. 4, elements 430-450), adding the personal identification information to the scrubbed file (paragraphs [0037] and [0039] - processing component 310 may replace the masked sensitive data elements, in the staging table, with the sensitive data elements)
Ebrahimi does not expressly disclose receiving the data from multiple data sources for a user account of an internetwork facilitation system, determining an activity status of a user account of an inter-network facilitation system; based on the activity status account of the user account, generate the staging table.
generating based on a scrubbed Metro2file, validating the scrubbed Metro2 file by analyzing the data related to the user account; and based upon validating the scrubbed Metro2 file, generating an unscrubbed Metro2 file.
Bryne discloses receiving data from multiple data sources for a user account of an internetwork facilitation system (abstract - the methods and apparatus provide a credit reporting transport server that stores credit information sent by the credit data providers), merging the data related to the user account of the inter-network facilitation system from the multiple data sources utilizing a transformation framework (Fig. 4, element 410; paragraph [0009] - a database that stores credit information sent by the credit data providers. The received data is matched and merged with existing data based on the credit data provider. The merged data is queued by the credit reporting transport server and forwarded to the credit bureau servers in a timely manner (e.g., daily) for storage in the credit bureau database; validating the scrubbed Metro2 file by analyzing the data related to the user account (Fig. 4, element 407); and based upon validating the scrubbed Metro2 file, generating an unscrubbed Metro2 file by adding the personal identification information to the scrubbed Metro2 file (Fig. 4, element 410), and Metro2 data format (paragraph [0037]- the credit bureau update module 322 may collect changes from hundreds of different credit data providers 106 each day and send those changes as one batch to each of the credit bureaus 104 using the Metro2 data format).
Kruse discloses determining an activity status of a user account and based on the activity status of the user account generate a data staging table (paragraphs [0027] – access data from general ledger database and returns the accessed data to report object; [0028] – the retrieved or accessed data is stored in staging table; [0036] – create and populate account staging table with the accounts required for the report… inserting records form a chart-of-accounts table of general ledger database or an frl_acct_code table if a server based index is used…server based index is a table that includes all valid accounts for an entity or entities).
At the time of the invention, it would have been obvious to one of ordinary skill in the art to modify Ebrahimi by including the features of Bryne and Kruse because it utilizes known methods to secure the data. Applying the known technique of Bryne and Kruse into the system of Ebrahimi would have been recognized by those of ordinary skill in the art as resulting in an improved system that would have yielded predictable results.
As per claim 2, Ebrahimi discloses wherein merging the data related to the user account of the inter-network facilitation system from the multiple data sources further comprises: generating one or more base tables from the multiple data sources; generating a set of data frames from the one or more base tables by performing a set of queries on the one or more base tables; and merging the set of data frames according to a pre-defined order of steps. See Figures 7-10.
As per claim 7, Bryne discloses receiving an indication of an authorized transaction; and based on the authorized transaction, requesting the data related to the user account of the inter-network facilitation system from the multiple data sources (see claim 11 of Bryne - the controller to receive credit data from a credit data provider via the network interface… determine if the credit data provider is authorized to view the credit data; transmit the credit data via the network interface to an online user interface associated with the credit data provider if the credit data provider is authorized to view the credit data… forward the update to the credit data to a credit bureau via the network interface.
As per claim 8, Ebrahimi in view of Bryne and Kruse do not expressly disclose wherein the authorized transaction is an automatic funds transfer from a secured account to a credit account. However, this difference is only found in the non-functional descriptive material and is not functionally involved in the steps recited. The receiving step would be performed the same regardless of what type of transaction. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability, see In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Claims 9 and 10 are rejected on the same rationale as claims 1 and 2, respectively.
Claims 15 and 16 are rejected on the same rationale as claims 7 and 8, respectively.
Claims 17 and 18 are rejected on the same rationale as claims 1 and 2, repetitively.
Claims 3, 4, 11, 12, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ebrahimi in combination with Bryne and Kruse as applied to claim 2 above, and further in view of U.S. Patent No. 11,514,448 to Liberman.
As per claim 3, Ebrahimi in view of Bryne and Kruse disclose the method of claim 2. The references do not expressly disclose validating the set of data frames by applying one or more validation scripts to the set of data frames. Liberman discloses validating the set of data frames by applying one or more validation scripts to the set of data frames (see col. 10, lines 43-47 – validation script).
At the time of the invention, it would have been obvious to one of ordinary skill in the art to modify Ebrahimi in combination with Bryne and Kruse by including the validation script of Liberman to ensure to the transaction or operation is valid. Applying the known technique of Liberman to the system of Ebrahimi in view Bryne and Kruse would have been recognized by those of ordinary skill in the art as resulting in an improved system that would have yielded predictable results.
As per claim 4, Liberman discloses wherein the one or more validation scripts comprises: a trend script, record comparison script, or logic script (col. 12, ll. 28-32). Also, this claim recites non-functional descriptive material and is not functionally involved in the steps recited. The validating using a validation script would be performed the same regardless of the validation step is being used. Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability, see In re Gulack, 703 F.2d 1381, 1385, 217 USPQ 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Claims 11 and 12 are rejected on the same rationale as claims 3 and 4, respectively.
Claims 19 and 20 are rejected on the same rationale as claims 3 and 4, respectively.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ebrahimi and Bryne and Kruse as applied to claim 1 above, and further in view of U.S. Publication No. 2013/0185251 to Garg.
As per claim 5, Ebrahimi in view of Bryne and Kruse disclose the method of claim 1. However, the references do not expressly disclose generating an intermediate instance of the scrubbed Metro2 file by converting the data staging table into a corresponding CVS file. Garg discloses converting data into CVS files (paragraph [0032]).
At the time of the invention, it would have been obvious to the system of Ebrahimi in combination with Bryne and Kruse in order to convert the data file into CVS file. Not only this is matter of design choice, but also, CSV file is a known format that is compatible with many systems for storing and exchanging data. Applying the known technique of Garg into the system of Ebrahimi in combination with Bryne and Kruse of would have been recognized by those of ordinary skill in the art as resulting in an improved system that would have yielded predictable results.
Claim 13 is rejected on the same rationale as claim 5 above.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ebrahimi and Bryne and Kruse as applied to claim 1 above, and further in view of U.S. Publication No. 2009/0178144 to Redlich et al. (“Redlich”).
As per claim 6, Ebrahimi in combination with Bryne and Kruse disclose the method of claim 1. The references do not expressly disclose encrypting a final instance of the unscrubbed Metro2 file; and sending an encrypted unscrubbed Metro2 file to a third-party system. Redlich discloses using encryption for data transfer (paragraph [0045]- Encryption can be utilized to further enhance the security levels of the system. All transfers of the filter between the client to the server may be encrypted, and all data (whether extracted data or remainder data) may be encrypted prior to storage in the distributed memory. Any transfer of extracted data or remainder data or maps or filters may include an encryption feature.) Hence, it would have been obvious to a person of ordinary skill in the art to encrypt and transmit a unscrubbed Metro2 file to prevent unauthorized access of the data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Ebrahimi in combination with Bryne and Kruse to include the features of Redlich. Applying the known technique of Redlich into the system of Ebrahimi in combination with Bryne and Kruse would have been recognized by those of ordinary skill in the art as resulting in an improved system that would have yielded predictable results.
Claim 14 is rejected on the same rationale as claim 6 above.
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 JALATEE WORJLOH whose telephone number is (571)272-6714. The examiner can normally be reached Monday-Friday 6:00am-2:00pm.
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, John Hayes can be reached at (571) 272-6708. 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.
/Jalatee Worjloh/Primary Examiner, Art Unit 3697