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 .
DETAILED ACTION
This communication is responsive to Amendment, filed 08/10/2026.
Claims 2-21 are pending in this application. This action is made Final.
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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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.
Claims 2-21 are rejected under 35 U.S.C. 103 as being unpatentable over Shapley et al. (US Pat No. 10,163,156), in view of Dhandapani et al. (US Pub No. 2017/0178063).
As to claims 2, 8, 16, Shapley teaches a system for batch processing a data set that includes credit data of a plurality of consumers using a set of custom attributes, the system comprising (i.e. The server 102 may receive applicant data from one or more applicant computing devices 320 … receive data from one or more organization computing devices318 … receive credit bureau data from one or more credit bureau computing devices 322 via the network 316 … The server 102 may receive underwriting data from one or more underwriting organization computing devices 324 via the network 316, col. 13, lines 3-42):
a first computing node comprising one or more first processors, a first data store storing a first portion of the data set having a first format, and a first attribute processing agent comprising a calculation engine, a public application programming interface (API), and a first memory storing computer-executable code that, when executed by the one or more first processors, causes the first attribute processing agent to (i.e. Server 102 may communicate over network 316 with applicant computing device 320. Additionally, the server 102 may be accessed over the network 316 by user-interface 312B and organization computing device 318. Furthermore, the server 102 may communicate over the network 316 with an underwriting organization computing device 324 and/or a credit bureau computing device 322, col. 10, lines 48-62):
retrieve the first portion of data set from the first data source (i.e. The acquisition scoring module 308 may request credit data about applicant 150 in order to generate the acquisition score … the requested credit data may be retrieved over network 316 from credit bureau computing device 322. Once the credit data for the applicant 150 is received, acquisition scoring module 308uses the retrieved credit data to generate the acquisition score. The acquisition score may then be stored in the database 103 for the applicant 150, col. 11, lines 30-44); and
process, with the calculation engine, the first portion of the data set with the set of custom attributes at least in part by compiling one or more of the set of custom attributes into first object code or bytecode at run-time to eliminate the need of recoding the set of custom attributes to be executed with respect to a first format of the first portion of the data set and a first programming language utilized by the first computing node, wherein the first attribute processing agent and the first data store are embedded in the first computing node so that the first portion of the data set in the first data store is processed without converting the first portion of the data set into a common format for processing (i.e. Once the credit data for the applicant 150 is received, acquisition scoring module 308uses the retrieved credit data to generate the acquisition score. The acquisition score may then be stored in the database 103 for the applicant 150, col. 11, lines 30-44); By including a bankruptcy score filter into model 220 … Thus, a model 220 with a bankruptcy score filter reduces the risk incurred by an organization that generates vehicle loans for potential applicants, col. 23, lines 16-28; In FIG. 5A, the variables 520 through 530 are credit bureau attributes of the applicant 405 (see FIG. 4). However, the source of the variable inputs could be applicant application data, loan performance data, internal bureau data, credit bureau data, third-party data, and/or other data, col. 15, lines 4-16; FIG. 6 displays an acquisition scoring model contribution table 600 … The values in the contribution column 605 represent the numerical weights to assign to a variable when calculating an acquisition score. While the displayed embodiment shows different values assigned to each variable (e.g., “A %”, “B %”, etc.) … As a result, there may be more, less, and/or different values in contribution column 605 than the values displayed in FIG. 6, col. 15, lines 28-46):
a second computing node comprising one or more second processors, a second data store storing a second portion of the data set having a second format different form the first format, and a second attribute processing agent comprising the public APT, and a second memory storing computer-executable code that, when executed by the one or more second processors, causes the second attribute processing agent to (i.e. The database 103 may be configured or adapted to store data related to vehicle loan generation system 300. The database 103 may be used to store various data, including personal data and/or credit data about the applicant 150, vehicle information, loan performance data, vehicle loan data, credit bureau data, organizational vehicle loan data, organizational vehicle loan research data, underwriting data, and/or other data relevant to the vehicle loan generation system300. As mentioned earlier in FIG. 1, the database 103 may be located at server102. Alternatively, the database 103 may be located remotely from server 102. Furthermore, parts of the database 103 may be located at the server 102 while other parts of the database 103 may be located remotely from server 102, col. 13, line 64 to col. 14, line 10):
retrieve the second portion of the data set from the second data store (i.e. Next, vehicle loan generation module 312 calls automated underwriting module302. Automated underwriting module 302 includes instructions executed by processor 301 to automate the underwriting decision process. Specifically, the automated underwriting module will determine whether the vehicle loan application from applicant 150 should be automatically approved, automatically denied, or referred for manual underwriting. Automated underwriting module 302 may access database 103 to retrieve credit data about applicant 150 and the acquisition score generated by acquisition scoring module 308 for applicant 150. The retrieved credit data and acquisition score enable the automated underwriting module 302to then determine if applicant 150 should be automatically approved, denied, or referred for manual underwriting, col. 11, lines 45-59);
invoke the calculation engine via the public API (i.e. After this, vehicle loan generation module 312 may call credit limit assignment module 306 … call multiple offers module 309 … call prequalification module 304, col. 11, line 60 to col. 12, line 31); and
process, with the calculation engine, the second portion of the data set using the set of custom attributes at least in part by compiling one or more of the set of custom attributes into second object code or bytecode at run-time to eliminate the need of recoding the set of custom attributes to be executed with respect to a second format of the second portion of the data set and a second programming language utilized by the second computing node, wherein the second attribute processing agent and the second data store are embedded in the second computing node so that the second portion of the data set in the second data store is processed without converting the second portion of the data set into the common format for processing (i.e. Multiple offers module 309, similar to previous modules, may retrieve stored data from database 103. Alternatively, multiple offers module 309may retrieve data from credit bureau computing device 322 via network 316, col. 12, lines 7-17; Similar to the credit limit assignment module 306, the prequalification module 304 may retrieve credit data from database 103 or a credit bureau computing device 322 via network 316. The retrieved credit data may be used by prequalification module 304 to determine if applicant 150 qualifies for a vehicle loan, based on the value of his collateral, col. 12, lines 18-31; Similar to the acquisition scoring module 308, this credit data may be retrieved from database 103 and/or credit bureau computing device 322 via network 316. With this data, the credit limit assignment module 306 determines the maximum amount, term, and LTV for vehicle loans for applicant 150, col. 11, line 60 to col. 12, line 6); and
a data analysis system comprising a third memory storing instructions and one or more hardware processors configured to execute the instructions to cause the one or more hardware processors to (i.e. Organization 101 may send a request (174) to underwriting organization 170 to analyze a vehicle loan application from applicant 150 and determine if the underwriting organization 170 will underwrite the loan. The underwriting organization 170 may respond (172) to the request from organization101. The response (172) from underwriting organization 170 may be that it will underwrite the vehicle loan for applicant 150. Alternatively, the response (172) may be to decline underwriting the vehicle loan for applicant 150. Alternatively, the response (172) may be to approve the applicant 150 for underwriting by a different underwriting organization, col. 8, lines 52-64):
receive the set of custom attributes from a client system (i.e. FIG. 4 is a block diagram of an acquisition scoring model environment 400. The environment 400 includes the acquisition scoring model 210, inputs 406, and outputs 407. The acquisition scoring model 210 receives credit bureau attributes of an applicant 405 as an input 406. Additionally, the acquisition scoring model210 sends an acquisition score 410 as an output 407. The acquisition scoring model 210 determines the output 407 based on the received inputs 406. The subsequent figures explain how acquisition scoring model 210 determines outputs407. Outputs 407 may be used by one or more different models. In one embodiment, the acquisition score 410 is used by the automated underwriting model 220 to determine if an application should be approved or denied, col. 14, lines 34-47);
receive a request form the client system for batch processing the data set using the set of custom attributes (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55);
parse the request to identify the data set and the set of custom attributes for batch processing (i.e. In some embodiments, acquisition scoring model 210 may rely on more, less, and/or different inputs than those displayed in FIG. 4. For example, acquisition scoring model 210 may rely on applicant application data, loan performance data, internal bureau data, and/or other data to determine outputs 407. Acquisition scoring model 210 may include more, less, and/or different outputs than those displayed in FIG. 4. Acquisition scoring model 210 may also rely on one or more business rules to determine outputs 407, col. 14, lines 48-56):
in parallel, invoke the first attribute processing agent at the first computing node for batch processing the first portion of the data set using the set of custom attributes and invoke the second attribute processing agent at the second computing node for batch processing the second portion of the data set using the set of custom attributes (i.e. FIG. 7 is a block diagram of an automated underwriting environment 700. The automated underwriting environment 700 includes the automated underwriting model 220. The automated underwriting model 220 receives inputs 701, and uses inputs 701 to generate an output 716. The inputs 701 may include credit bureau attributes of an applicant 705, applicant application data 710, loan performance data 715, and an acquisition score 410 for an applicant 150. The output 716 may contain an auto-approve decision 720, an auto-decline decision 725, or a refer decision 730, col. 16, lines 22-31);
receive results from the first attribute processing agent and the second attribute processing agent (i.e. Environments 1400, 1405, 1406, 1900, 1901, 1902, and 1903 include a decision tree 1401 and inputs 1205. The received inputs 1205 by decision tree 1401 include vehicle attributes 1210, loan performance 1215, and bureau attributes 1220. The decision tree 1401 includes a product type decision 1410, a vehicle condition decision 1415 (only for FIGS. 14A, 19A, and 19B), and a FICO score decision 1420. Decision tree 1410 also shows low risk segments 1356, medium risk segments1357, high risk segments 1358, and a very high-risk segment 1359, col. 27, lines 19-35; the automated underwriting model 220 relies on a dual matrix along with inputs 701 to determine output 716 … the model 220 may use a combination of the aforementioned methods to determine output 716 based on inputs 701, col. 17, lines 3-11);
generate a response to the request based at least in part on the results from the first attribute processing agent and the second attribute processing agent (i.e. The automated underwriting model 220 uses inputs 701 to determine an output716. In the displayed embodiment, the output 716 could be an auto-approve decision 720, an auto-decline decision 725, or a refer decision 730. If an application is automatically approved 720, the credit limit assignment model is then invoked because the underwriting process is complete. Alternatively, if the application is automatically declined 725 (also referred to as automatically denied), no other models need to be called. However, if the application requires manual underwriting, a refer decision 730 occurs. The skill-based routing model 260 is then used to improve the manual underwriting process … While the displayed embodiment includes three possible decisions (auto-approve 720, auto-decline 725, refer 730), other embodiments may include more, less, and/or different decisions than those displayed. Also, other embodiments may include more, less, and/or different outputs 716 than those shown in FIG. 7, col. 16, line 48 to col. 17, line 2);
generate a user interface that is configured to display the response (i.e. In some cases, an underwriting rule is applied to the applicant's application to determine if it should be automatically denied or referred. If the application is automatically denied, the model 220 generates an output 716 (FIG. 7) indicating an auto-deny decision 725 (FIG. 7). No other models are needed because the underwriting process, along with any subsequent processing, of this application is complete. Alternatively, if the application is referred for manual underwriting, the model 220 sends an output 716 (FIG. 7) dictating a refer decision 730 (FIG. 7). The skill-based routing model 260 is called to process the referred applications for manual underwriting, col. 18, lines 24-34); and
display, via the user interface, the response to the client system (i.e. While the displayed embodiment includes three possible decisions (auto-approve 720, auto-decline 725, refer 730), other embodiments may include more, less, and/or different decisions than those displayed. Also, other embodiments may include more, less, and/or different outputs 716 than those shown in FIG. 7, col. 16, line 48 to col. 17, line 2; The automated underwriting model 220 relies on the acquisition score generated by acquisition scoring model 210 to further automate underwriting. The automated underwriting model 220 determines if the vehicle loan applicant is automatically denied, automatically approved, or referred for manual underwriting, col. 9, lines 38-57).
Although Shapley implicitly teaches the term “in parallel” (i.e. FIG. 7 is a block diagram of an automated underwriting environment 700. The automated underwriting environment 700 includes the automated underwriting model 220. The automated underwriting model 220 receives inputs 701, and uses inputs 701 to generate an output 716. The inputs 701 may include credit bureau attributes of an applicant 705, applicant application data 710, loan performance data 715, and an acquisition score 410 for an applicant 150. The output 716 may contain an auto-approve decision 720, an auto-decline decision 725, or a refer decision 730, col. 16, lines 22-31; one or more of the individual operations may be performed concurrently … These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein, col. 70, lines 35-49), Dhandapani specifically teaches this term (i.e. configuring advanced execution environments that are asynchronous and non-blocking in nature so as to allow the parallel execution of analytical models across multiple dimensions of data relevant to predicting optimal decisions, [0018]; Decision engine system 108 may be configured to receive a transaction proposal including a proposed transaction structure (e.g., a loan application proposing a set of terms), identifying flexible parameters of the proposed transaction structure (e.g., a loan amount, cash down required, annual percentage rate (APR), length of loan, warranty costs, etc.), coordinate parallel computing of analytical models against the potential variations of the transaction structure given the flexible transaction parameters, and score and rank the potential variations according to the preferences of those involved in the proposed transaction (e.g., a financial service provider, automotive dealer, and/or vehicle purchaser and loanee), [0024]).
It would have been obvious to one of ordinary skill of the art having the teaching of Shapley, Dhandapani before the effective filing date of the claimed invention to modify the system of Shapley to include the limitations as taught by Dhandapani. One of ordinary skill in the art would be motivated to make this combination in order to receive a transaction proposal including a proposed transaction structure, identifying flexible parameters of the proposed transaction structure, in view of Dhandapani ([0024]), as doing so would give the added benefit of coordinating parallel computing of analytical models against the potential variations of the transaction structure given the flexible transaction parameters, and score and rank the potential variations according to the preferences of those involved in the proposed transaction, as taught by Dhandapani ([0024]).
As per claim 3, Dhandapani teaches the system of claim 2, wherein the first computing node and the second computing node are part of a Hadoop file system (i.e. Each module among decisioning module(s) 292 may be independent to work on a given message as it is received/retrieved. Indeed, although operations discussed below may be described as occurring in a particular sequence for ease of discussion, it should be understood that disclosed operations, events, etc. may occur in parallel and/or simultaneously. Further, decisioning module(s) 292 may become replicated to scale out operations as needed to respond to a transaction proposal in real-time. Decisioning module(s) 292 may be deployed as remote actors or as components in big data systems such as Spark or Hadoop. In some embodiments, subsystem 300 may be packaged as a set of JAR (Java Archive) files or other packaged file format that compose the libraries and decisioning modules 292 used in the subsystem, [0044]).
As to claims 4, 10, 18, Shapley teaches the custom attribute comprises a custom-made attribute created by the client system, and wherein the custom-made attribute comprises at least one of a computer executable function comprising one or more data filters, a database query, or computer code encoding a metric for analyzing the data set (i.e. Once the credit data for the applicant 150 is received, acquisition scoring module 308uses the retrieved credit data to generate the acquisition score. The acquisition score may then be stored in the database 103 for the applicant 150, col. 11, lines 30-44); By including a bankruptcy score filter into model 220 … Thus, a model 220 with a bankruptcy score filter reduces the risk incurred by an organization that generates vehicle loans for potential applicants, col. 23, lines 16-28; In FIG. 5A, the variables 520 through 530 are credit bureau attributes of the applicant 405 (see FIG. 4). However, the source of the variable inputs could be applicant application data, loan performance data, internal bureau data, credit bureau data, third-party data, and/or other data, col. 15, lines 4-16; FIG. 6 displays an acquisition scoring model contribution table 600 … The values in the contribution column 605 represent the numerical weights to assign to a variable when calculating an acquisition score. While the displayed embodiment shows different values assigned to each variable (e.g., “A %”, “B %”, etc.) … As a result, there may be more, less, and/or different values in contribution column 605 than the values displayed in FIG. 6, col. 15, lines 28-46).
As to claims 5, 13, 20, Shapley teaches the one or more hardware processors are further configured to:
generate an alert based on the results from the first attribute processing agent and the second attribute processing agent (i.e. In the displayed embodiment of FIG. 8, dual matrix 800 can lead to an output 716of three different decisions, an auto-deny decision 725, an auto-approve decision720, and a refer decision 730 (FIG. 7). However, in other embodiments, the dual matrix 800 can lead to more, less, and/or different decisions and/or outputs than those shown in FIG. 8. Also, depending on the decision made, the skill based underwriting model 260 and/or the credit limit assignment model 230 may be called. However, in other embodiments, more, less, and/or different models are called depending on the decision and/or output that is generated, col. 19, lines 54-64); and
communicate the alert to the client system causing the client system to approve or decline a transaction (i.e. In some cases, an underwriting rule is applied to the applicant's application to determine if it should be automatically denied or referred. If the application is automatically denied, the model 220 generates an output 716 (FIG. 7) indicating an auto-deny decision 725 (FIG. 7). No other models are needed because the underwriting process, along with any subsequent processing, of this application is complete. Alternatively, if the application is referred for manual underwriting, the model 220 sends an output 716 (FIG. 7) dictating a refer decision 730 (FIG. 7). The skill-based routing model 260 is called to process the referred applications for manual underwriting, col. 18, lines 24-34).
As per claim 6, Shapley teaches the system of claim 2, wherein to invoke the first attribute processing agent and to invoke the second attribute processing agent, the one or more hardware processors are configured to communicate the set of custom attributes to the firs attribute processing agent and the second attribute processing agent as an input (i.e. The server 102 may receive applicant data from one or more applicant computing devices 320 … receive data from one or more organization computing devices318 … receive credit bureau data from one or more credit bureau computing devices 322 via the network 316 … The server 102 may receive underwriting data from one or more underwriting organization computing devices 324 via the network 316, col. 13, lines 3-42).
As per claim 7, Shapley teaches the system of claim 2, wherein to generate the response, the one or more hardware processors are configured to consolidate the results from the first attribute processing agent and the second attribute processing agent to generate a combined result (i.e. The automated underwriting model 220 uses inputs 701 to determine an output716. In the displayed embodiment, the output 716 could be an auto-approve decision 720, an auto-decline decision 725, or a refer decision 730. If an application is automatically approved 720, the credit limit assignment model is then invoked because the underwriting process is complete. Alternatively, if the application is automatically declined 725 (also referred to as automatically denied), no other models need to be called. However, if the application requires manual underwriting, a refer decision 730 occurs. The skill-based routing model 260 is then used to improve the manual underwriting process … While the displayed embodiment includes three possible decisions (auto-approve 720, auto-decline 725, refer 730), other embodiments may include more, less, and/or different decisions than those displayed. Also, other embodiments may include more, less, and/or different outputs 716 than those shown in FIG. 7, col. 16, line 48 to col. 17, line 2).
As per claim 9, Shapley teaches the computer-implemented method of claim 8 further comprising receiving the set of custom attributes from the client system, wherein the set of custom attributes comprises custom-made attributes generated by the client system, and wherein each attribute of the set of custom attributes comprises computer code that can be interpreted or executed by any of a plurality of different attribute processing agents that are each configured for a different database system (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55).
As per claim 11, Shapley teaches the computer-implemented method of claim
8, wherein identifying the first attribute processing agent based at least in part on
the input data and the set of custom attributes comprises:
determining a storage location of the input data in the first computing node (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55); and
identifying the first attribute processing agent based on the storage location of the first input data, wherein the first attribute processing agent is configured to process the input data using the set of custom attributes at the storage location (i.e. The server 102 may receive credit bureau data from one or more credit bureau computing devices 322 via the network 316. The server 102 may also request data from one or more credit bureau computing devices 322 via the network 316. The credit bureau data transmitted may be for applicant 150. The credit bureau computing device 322 may be a computer, laptop, mobile phone, PDA, tablet, or other computing device that can access the network 316, col. 13, lines 26-33).
As per claim 12, Shapley teaches the computer-implemented method of claim 8, wherein communication the set of custom attributes to the first attribute processing agent as the input comprises:
invoking the calculation engine of the first attribute processing agent (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55); and
inputting the input data into the calculation engine for processing using the set of custom attributes (i.e. The acquisition scoring module 308 may request credit data about applicant 150 in order to generate the acquisition score … the requested credit data may be retrieved over network 316 from credit bureau computing device 322. Once the credit data for the applicant 150 is received, acquisition scoring module 308uses the retrieved credit data to generate the acquisition score. The acquisition score may then be stored in the database 103 for the applicant 150, col. 11, lines 30-44).
As to claims 14, 21, Shapley teaches receiving a set of decision strategies from the client system, wherein the alert is generated based at least in part on the set of decision strategies (i.e. In some cases, the automated underwriting model 220 relies on a dual matrix along with inputs 701 to determine output 716. In other cases, model 220 may use underwriting rules along with inputs 701 to generate output 716. Alternatively, model 220 may use decision trees, statistical methods, and/or other methods for determining output 716 based on inputs 701. Further, the model 220 may use a combination of the aforementioned methods to determine output 716 based on inputs 701, col. 17, lines 3-11).
As per claim 15, Shapley teaches the computer-implemented method of claim 8 further comprising receiving the first attribute processing agent as a set executable code from a data analysis system provider (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55).
As per claim 17, Shapley teaches the data analysis system of claim 16, wherein the set of custom attributes is received from the client system and the set of custom attributes comprises a custom-made attribute generated by the client system (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55).
As per claim 19, Shapley teaches the data analysis system of claim 16, wherein the data analysis system is further configured to:
receive the first attribute processing agent as a set of executable code from a data analysis system provider (i.e. Text mining module 311 may be called by any one of the aforementioned modules to mine the text of retrieved data for entry into the database 103. The mined text may also be used by one or more of the aforementioned modules to assist with module execution. For example, vehicle loan generation module 312 may call text mining module 311 to mine a retrieved credit data file about applicant 150 for specific inputs (e.g. FICO score). The mined text (FICO score value) may then be stored at database 103 and used by vehicle loan generation module 312 to generate vehicle loans for an applicant 150, col. 12, lines 45-55); and
embed the first attribute processing agent in the first computer node (i.e. The acquisition scoring module 308 may request credit data about applicant 150 in order to generate the acquisition score … the requested credit data may be retrieved over network 316 from credit bureau computing device 322. Once the credit data for the applicant 150 is received, acquisition scoring module 308uses the retrieved credit data to generate the acquisition score. The acquisition score may then be stored in the database 103 for the applicant 150, col. 11, lines 30-44).
Response to Arguments
Applicant's arguments with respect to claims 2-21 have been considered but are moot in view of the new ground(s) of rejection.
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 extension fee 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 MIRANDA LE whose telephone number is (571)272-4112. The examiner can normally be reached M-F 7AM-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, 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 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.
/MIRANDA LE/ Primary Examiner, Art Unit 2153
Prosecution Insights