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
1. Claims 2 - 21 are pending. Claim 1 has been canceled. Claims 2, 16, 20 are independent.
2. This application was filed on 1-30-2024.
Claim Rejections - 35 USC § 103
3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
4. Claims 2 - 5, 7, 8, 12, 15 - 21 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US PGPUB No. 20090307134) in view Abbott et al. (US PGPUB No. 20160314528) and further in view of Nagla et al. (US PGPUB No. 20180075527).
Regarding Claims 2, 16, 20, Gupta discloses a computer-implemented method performed by a computing system having one or more hardware computer processors and a computing system and a non-transitory computer readable medium, the computer-implemented method and system and medium comprising:
a) receiving, from a user computing device, authorization to access account data items associated with the user stored by a financial institution; (see Gupta paragraph [0015]: A software facility is described that facilitates interactions between computing systems, such as by in some embodiments providing a third-party transaction authorization system that automatically authorizes transactions between parties and/or financial payments for such transactions in accordance with private authorization instructions that were previously specified by the parties.)
b) accessing, by an account access system, the account data items associated with the user from the financial institution, wherein the account data items include financial transaction data of individual transactions between the user and a plurality of third parties; (see Gupta paragraph [0048]: using payment instruction rule sets to authorize programmatic transactions, which in this example includes a user (named "Rob") who provides an application 960 to implement shopping cart functionality for third-party merchants via Web services. Such merchants can sign up for and use Rob's shopping cart functionality by including customer-selectable controls in the merchants' applications that interface with Rob's shopping cart application 960, which in turn maintains session information for each customer of each merchant. When customers check out via a merchant's application, Rob's shopping cart application 960 interacts with the Subway transaction authorization system 970 to process payments from the customers to the merchants.) wherein automatically inferring the account of the user comprises:
c) automatically inferring an account of the user with a third-party entity by identifying the third-party entity as a recipient of a transaction of the individual transactions based at least on an application by the account access system of an account identification rule to the account data items, wherein the account access system is operated by an entity other than the financial institution, wherein the account identification rule. (see Gupta paragraph [0022]: receiving a specified usage instruction rule set for a user, the transaction authorization system stores the instruction rule set in a manner associated with the user (e.g., associates it with an account of the user with the transaction authorization system), optionally after first approving the instruction rule set (e.g., based on verification that the instruction rule set includes required information, if any, and/or is in the correct form). The transaction authorization system also generates a reference token to refer to the instruction rule set, associates the reference token with the instruction rule set (e.g., by storing an indication of the reference token with the stored instruction rule set), and provides the reference token to the user for later use in referencing the instruction rule set.)
i) identifying an Application Programming Interface (API) token associated with the secured third-party credit bureau database, wherein the API token (a) comprises encrypted data, (b) is issued by a secured third-party credit bureau system and (c) is specific to the computing system; (see Gupta paragraph [0041]: PHS Transaction System 210 determines if the payment transaction is approved in the illustrated embodiment by first interacting with the Account System 220 to retrieve information about the usage instruction rule sets 235 corresponding to the reference tokens provided in the call to the Web service API 212, as well as further retrieving other information from the user accounts 230 to which those usage instruction rule sets belong. After obtaining the usage instruction rule sets and other information, the PHS Transaction System 210 then determines whether the rule sets are compatible and otherwise authorize the requested payment to be made, and if so the PHS Transaction System performs the payment (e.g., by charging a payment instrument associated with the application program's reference token 257 and by depositing at least some of that charge in a payment repository associated with the Transaction System 265's reference token 267) and provides confirmation to the Transaction System 265, with the Transaction System 265 subsequently providing the initially requested Web service to the application program)
j) transmitting the API token to the secured third-party credit bureau system to establish a secure API communication channel which enables direct communication between the computing system and the secured third-party credit bureau system; and transmitting the account creation data package to the secured third-party credit bureau system via the secure API communication channel established with the third-party credit bureau system, wherein the secured third-party credit bureau system is not provided with at least a subset of the financial transaction data of the individual transactions accessed from the financial institution by the account access system. (see Gupta paragraph [0047]: The user selection then causes the CellX application 905 to programmatically invoke a MapX Web service from the MapX application 910 in order to request a particular map corresponding to the customer's selection, with the invocation including supplying the CellX reference token previously associated with the CellX application 905. The MapX application 910 then submits to a Subway Web service 924 a pay authorization request that includes information about the transaction, MapX's credential, and the MapX and CellX reference tokens.; (transmit token via API channel))
Gupta does not specifically disclose grouping transaction based on description, determining time interval associated with grouped transactions, and determining time interval comprises identifying a number of days between a first and second transaction of grouped transactions.
However, Abbott discloses:
d) grouping transactions based on a description or memo associated with each of two or more individual transactions; (see Abbott paragraph [0079]: identifying patterns in the products and merchants associated with the transactions. In this way, the system may then compile the item and merchant level transaction data for the customer across the time total spend time period. The system may then group the transactions based on product category and/or merchant category. This grouping may provide identifications of patterns with respect to one category or another.)
e) determining a time interval associated with the grouped transactions, wherein determining the time interval comprises identifying a number of days between a first and second transaction of the grouped transactions; (see Abbott paragraph [0080]: Through the accumulation of transaction data the system compiles the data into a system learned techniques. The system evaluates the data points against learned models to determine the aggregate probability of a life event actually occurring at a future time. The frequency of transactions at merchant or for product categories aids in contributing to the determination of a life event.)
f) determining a likelihood that the grouped transactions are of an account type based on the time interval and the description or memo for at least one of the transactions of the grouped transactions. (see Abbott paragraph [0080]: Through the accumulation of transaction data the system compiles the data into a system learned techniques. The system evaluates the data points against learned models to determine the aggregate probability of a life event actually occurring at a future time. The frequency of transactions at merchant or for product categories aids in contributing to the determination of a life event.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for grouping transaction based on description, determining time interval associated with grouped transactions, and determining time interval comprises identifying a number of days between a first and second transaction of grouped transactions as taught by Abbott. One of ordinary skill in the art would have been motivated to employ the teachings of Abbott for the flexibility of a system that enabling the grouping of transactions thereby enabling the determination of patterns in processing. (see Abbott paragraph [0079]; paragraph [0080])
Furthermore, Gupta discloses for g) receiving, from the user computing device, a request to update credit data of the user to include the account, wherein the account is not included in the credit data prior to receiving the request; h) generating an account creation data package formatted for ingestion, the account creation data package including account information identifying the account, wherein the account information is formatted for ingestion. (see Gupta paragraph [0052]: a Web service provider user ABC interactively creates a user account, such as by filling in forms in a Web page provided by an Account System. In this illustrated example, the example interactive creation screen includes a heading area 111 with overview information, followed by an area 113 in which the user can specify various general information for the account, such as an account name, a password for access control to view and modify the account, any optional certifications, and any optional organization affiliations.; paragraph [0055]: after initially creating the user account, the user is then presented with the option of creating one or more usage instruction rule sets)
Gupta does not specifically disclose for c) a rule that impacts credit scores, and for g) receiving, from the user computing device, a request to update credit data of the user to include the account, wherein the account is not included in the credit data prior to receiving the request, and for h) initiate addition of the account to credit data of the user.
However, Nagla discloses for c) a rule that impacts credit scores; g) receiving, from the user computing device, a request to update credit data of the user to include the account, wherein the account is not included in the credit data prior to receiving the request; h) initiate addition of the account to credit data of the user. (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for c) a rule that impacts credit scores, and for g) receiving, from the user computing device, a request to update credit data of the user to include the account, wherein the account is not included in the credit data prior to receiving the request, and for h) initiate addition of the account to credit data of the user as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Furthermore, for Claim 16, Gupta discloses wherein a) a memory; and a hardware computer processor configured to perform operations (see Gupta paragraph [0070]: Such potential transactions may include transactions between an application program 359 executing in memory 357 of a Web service consumer system 350 and a Web service server 379 executing in memory 377 of a Web service provider system 370, and/or transactions between one or more such systems 350 and 370 and one or more other computing systems 390.)
Furthermore, for Claim 20, Gupta discloses wherein a non-transitory computer readable medium having processor-executable instructions stored thereon, wherein the processor-executable instructions when executed by a hardware computer processor configure the hardware computer processor to perform operations. (see Gupta paragraph [0070]: Such potential transactions may include transactions between an application program 359 executing in memory 357 of a Web service consumer system 350 and a Web service server 379 executing in memory 377 of a Web service provider system 370, and/or transactions between one or more such systems 350 and 370 and one or more other computing systems 390.)
Regarding Claim 3, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 2.
Gupta does not specifically disclose a plurality of historical transaction data items indicating a corresponding plurality of historical transactions.
However, Nagla wherein the account information includes a plurality of historical transaction data items indicating a corresponding plurality of historical transactions between the identified third-party entity and the user. (see Nagla paragraph [0121]: Credit data can include current and historical data from data sources 308 such as credit card data, bank account data, remittance data, transaction data, investment data, rental data (including car and housing rentals), employment data, education and qualification data, social data (e.g. social network data), retailer data, and so on.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for a plurality of historical transaction data items indicating a corresponding plurality of historical transactions as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 4, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 3.
Gupta does not specifically disclose requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including historical transaction data items.
However, Nagla further comprising discloses wherein requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including the plurality of historical transaction data items included in the credit data of the user. (see Nagla paragraph [0121]: Credit data can include current and historical data from data sources 308 such as credit card data, bank account data, remittance data, transaction data, investment data, rental data (including car and housing rentals), employment data, education and qualification data, social data (e.g. social network data), retailer data, and so on.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including historical transaction data items as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 5, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 4.
Gupta does not specifically disclose for a) receiving a credit score of the user based on execution of the credit scoring algorithm, and for b) transmitting a notification to user indicating credit score.
However, Nagla further comprising discloses:
a) receiving, from the secured third-party credit bureau system, a credit score of the user based on said execution of the credit scoring algorithm; (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.) and
b) transmitting a notification to the user indicating the credit score. (see Nagla paragraph [0229]: The alerts and notification unit 792 can also generate alerts in relation to responses to loan requests, request to access information, request to register or verify data,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for a) receiving a credit score of the user based on execution of the credit scoring algorithm, and for b) transmitting a notification to user indicating credit score. as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 7, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 3, further comprising:
c) transmitting the API token associated with the secured third-party credit bureau database and the account update data package to the secured third-party credit bureau system. (see Gupta paragraph [0041]: PHS Transaction System 210 determines if the payment transaction is approved in the illustrated embodiment by first interacting with the Account System 220 to retrieve information about the usage instruction rule sets 235 corresponding to the reference tokens provided in the call to the Web service API 212, as well as further retrieving other information from the user accounts 230 to which those usage instruction rule sets belong. After obtaining the usage instruction rule sets and other information, the PHS Transaction System 210 then determines whether the rule sets are compatible and otherwise authorize the requested payment to be made, and if so the PHS Transaction System performs the payment (e.g., by charging a payment instrument associated with the application program's reference token 257 and by depositing at least some of that charge in a payment repository associated with the Transaction System 265's reference token 267) and provides confirmation to the Transaction System 265, with the Transaction System 265 subsequently providing the initially requested Web service to the application program)
Gupta does not specifically disclose for a) the updated account information including a transaction data item not included in the plurality of historical transaction data items, and for b) initiate update of credit data of the user associated with the account.
However, Nagla discloses:
a) receiving updated account information regarding the account associated with the user, the updated account information including a transaction data item not included in the plurality of historical transaction data items; (see Nagla paragraph [0137]: Information in the blockchain for the credit record may need to be updated, such as for example due to errors entering credit information, or conflicts in information between authorized parties. In some embodiments, the platform provides a correction or dispute resolution mechanism for correcting information in the blockchain for the credit record. If an authorized entity 102, 104, 106, 108, 110, and 112 or individual wishes to correct information in a block that the authorized entity 102, 104, 106, 108, 110, and 112 or other party created, it may create a modification block, which references the prior block and indicates what data should be updated and how.) and
b) generating an account update data package formatted for ingestion at the secured third-party credit bureau database to initiate update of credit data of the user associated with the account. (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for a) the updated account information including a transaction data item not included in the plurality of historical transaction data items, and for b) initiate update of credit data of the user associated with the account as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 8, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 7.
Gupta does not specifically disclose requesting execution of a credit scoring algorithm using credit data of the user, wherein the credit scoring algorithm is based at least partly on portions of the plurality of historical transaction data items and the transaction data item.
However, Nagla discloses further comprising: wherein requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, wherein the credit scoring algorithm is based at least partly on portions of the plurality of historical transaction data items and the transaction data item. (see Nagla paragraph [0121]: Credit data can include current and historical data from data sources 308 such as credit card data, bank account data, remittance data, transaction data, investment data, rental data (including car and housing rentals), employment data, education and qualification data, social data (e.g. social network data), retailer data, and so on.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for requesting execution of a credit scoring algorithm using credit data of the user, wherein the credit scoring algorithm is based at least partly on portions of the plurality of historical transaction data items and the transaction data item as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 12, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 2, further comprising:
a) receiving, via a network communication with the user computing device, selection of a third-party entity from a plurality of third-party entities indicated in a user interface displayed on the user computing device; (see Gupta paragraph [0077]: User Account Manager routine 400. The routine allows users to create and modify accounts for use with a transaction authorization and handler system, including defining usage instruction rule sets for use with the account. In some embodiments, the routine may be implemented as part of an interactive user interface with which a user can interact (e.g., as part of one or more Web pages of a Web site),; paragraph [0078]: routine determines whether the instruction is related to creating an account, and if so continues to step 415 to receive various information related to the definition of the account. For example, in some embodiments a user may supply an account name, an account password or other security access mechanism, indications of one or more payment instruments for use with the account, indications of one or more payment repositories for use with the account, etc. (third-party entities))
b) credentials for directly accessing, by proxy on behalf of the user via an application programming interface (API), the account items associated with the user stored in one or more databases associated with the third-party entity; (see Gupta paragraph [0082]: The routine begins in step 505, where an indication is received of a multi-party transaction and of reference tokens for each of multiple of the parties (e.g., one for each of the two or more parties to the transaction). The routine then continues to step 510 to retrieve the usage instruction rule sets corresponding to the tokens, and may in some embodiments further retrieve or otherwise make available other information from the user accounts to which some or all of those usage instruction rule sets belong.)
c) transmitting at least an API token associated with the selected third-party and the credential to one or more databases associated with the selected third-party entity; and d) accessing the account data items associated with the user, via another API communication channel established with the one or more databases associated with the selected third-party entity. (see Gupta paragraph [0041]: PHS Transaction System 210 determines if the payment transaction is approved in the illustrated embodiment by first interacting with the Account System 220 to retrieve information about the usage instruction rule sets 235 corresponding to the reference tokens provided in the call to the Web service API 212 (API token access to account information), as well as further retrieving other information from the user accounts 230 to which those usage instruction rule sets belong. After obtaining the usage instruction rule sets and other information, the PHS Transaction System 210 then determines whether the rule sets are compatible and otherwise authorize the requested payment to be made, and if so the PHS Transaction System performs the payment (e.g., by charging a payment instrument associated with the application program's reference token 257 and by depositing at least some of that charge in a payment repository associated with the Transaction System 265's reference token 267) and provides confirmation to the Transaction System 265, with the Transaction System 265 subsequently providing the initially requested Web service to the application program)
Regarding Claim 15, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 14.
Gupta does not specifically disclose requesting execution of a credit scoring algorithm using credit data of the user, wherein credit scoring algorithm is based on portions of account data items in the credit data of the user and providing credit score change information to the user.
However, Nagla discloses further comprising wherein requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, wherein the credit scoring algorithm is based at least partly on portions of account data items or the account data included in the credit data of the user; and providing credit score change information to the user computing device. (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for requesting execution of a credit scoring algorithm using credit data of the user, wherein credit scoring algorithm is based on portions of account data items in the credit data of the user and providing credit score change information to the user. as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 17, Gupta-Abbott-Nagla discloses the computing system of Claim 16.
Gupta does not specifically disclose a plurality of historical transaction data items indicating a corresponding plurality of historical transactions.
However, Nagla discloses wherein the account information includes a plurality of historical transaction data items indicating a corresponding plurality of historical transactions between the identified third-party entity and the user. (see Nagla paragraph [0121]: Credit data can include current and historical data from data sources 308 such as credit card data, bank account data, remittance data, transaction data, investment data, rental data (including car and housing rentals), employment data, education and qualification data, social data (e.g. social network data), retailer data, and so on.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for a plurality of historical transaction data items indicating a corresponding plurality of historical transactions as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 18, Gupta-Abbott-Nagla discloses the computing system of Claim 17.
Gupta does not specifically disclose requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including historical transaction data items.
However, Nagla further comprising discloses wherein requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including the plurality of historical transaction data items included in the credit data of the user. (see Nagla paragraph [0121]: Credit data can include current and historical data from data sources 308 such as credit card data, bank account data, remittance data, transaction data, investment data, rental data (including car and housing rentals), employment data, education and qualification data, social data (e.g. social network data), retailer data, and so on.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for requesting execution of a credit scoring algorithm using credit data of the user at the secured third-party credit bureau database, including historical transaction data items as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 19, Gupta-Abbott-Nagla discloses the computing system of Claim 18.
Gupta does not specifically disclose for a) receiving a credit score of the user based on execution of the credit scoring algorithm, and for b) transmitting a notification to user indicating credit score.
However, Nagla further comprising discloses:
a) receiving a credit score of the user based on execution of the credit scoring algorithm; (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.) and
b) transmitting a notification to user indicating credit score. (see Nagla paragraph [0229]: The alerts and notification unit 792 can also generate alerts in relation to responses to loan requests, request to access information, request to register or verify data,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for a) receiving a credit score of the user based on execution of the credit scoring algorithm, and for b) transmitting a notification to user indicating credit score as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 21, Gupta-Abbott-Nagla discloses the non-transitory computer readable medium of Claim 20, wherein the API token comprises encrypted data representing a username and password, wherein the API token is associated with restrictions, wherein the restrictions comprise at least a limited life comprising a defined number of hours, days or weeks during which the API token is usable to facilitate secure communications with the secured third-party credit bureau system. (see Gupta paragraph [0041]: PHS Transaction System 210 determines if the payment transaction is approved in the illustrated embodiment by first interacting with the Account System 220 to retrieve information about the usage instruction rule sets 235 corresponding to the reference tokens provided in the call to the Web service API 212, as well as further retrieving other information from the user accounts 230 to which those usage instruction rule sets belong. After obtaining the usage instruction rule sets and other information, the PHS Transaction System 210 then determines whether the rule sets are compatible and otherwise authorize the requested payment to be made, and if so the PHS Transaction System performs the payment (e.g., by charging a payment instrument associated with the application program's reference token 257 and by depositing at least some of that charge in a payment repository associated with the Transaction System 265's reference token 267) and provides confirmation to the Transaction System 265, with the Transaction System 265 subsequently providing the initially requested Web service to the application program)
5. Claims 6, 9 - 11 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view Abbott and further in view of Nagla and Manning et al. (US PGPUB No. 20150206241).
Regarding Claim 6, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 5.
Gupta does not specifically disclose determining that the score is lower than a previous credit score of the user, and in response to determining that the score is lower than the previous score of the user, remove the account information from the data of the user
However, Manning discloses further comprising:
a) determining that the credit score is lower than a previous credit score of the user;
b) in response to determining that the credit score is lower than the previous credit score of the user, initiating activation of a user interface on the user computing device that includes an option to remove the account information from the credit data of the user; c) receiving a selection of the option to remove the account information; (see Manning paragraph [0041]: The system may report reputational scores (analogous to credit score) below a predetermined threshold to administrators for follow-up with the user or removal or suspension of the user's account. Alternatively the system may be automated and automatically suspend or terminate a user account with a reputational score below a predetermined threshold value.)
d) in response to receiving the selection of the option to remove the account information from the credit data of the user, e) generating an account removal data package formatted for ingestion at the secured third-party credit bureau database to initiate removal of the account from credit data of the user; and f) transmitting the account removal data package to the secured third- party credit bureau system via the secure API communication channel. (see Manning paragraph [0041]: The system may report reputational scores (analogous to credit score) below a predetermined threshold to administrators for follow-up with the user or removal or suspension of the user's account. Alternatively the system may be automated and automatically suspend or terminate a user account with a reputational score below a predetermined threshold value.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for determining that the score is lower than a previous credit score of the user, and in response to determining that the score is lower than the previous score of the user, remove the account information from the data of the user as taught by Manning. One of ordinary skill in the art would have been motivated to employ the teachings of Manning for the flexibility of a system that enables the utilization of multiple user data processing parameters such as score type information. (see Manning paragraph [0041])
Regarding Claim 9, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 8.
Gupta does not specifically disclose receiving a credit score of the user based on said execution of the credit scoring algorithm and in response transmitting a notification to the user.
However, Nagla discloses further comprising:
a) receiving, from the secured third-party credit bureau system, a credit score of the user based on said execution of the credit scoring algorithm; (see Nagla paragraph [0122]: Credit score platform 300 receives credit data from multiple data sources 308 to generate the credit score and credit history record. Credit score platform 300 can verify or validate data sources 308 and credit data to confirm reliability. Credit score platform 300 may interact with interface application to verify or validate data sources 308 and credit data. Data sources 308 can receive data from different databases 310. Credit score platform 300 receives an increased amount of credit data from an increased number of data sources 308 to compute a credit score that more accurately reflects the creditworthiness of a borrower.; paragraph [0127]: Scoring unit 328 interacts with identity unit 326 to compute the digital identity for the borrower which includes multiple identifiers stored as one or more blocks in storage 111 (or distributed storage across entities 104 . . . 112). Scoring unit 328 uses the identifiers to retrieve credit data relevant to the borrower. The identifiers can connect global data points (e.g. global banking network). Scoring unit 328 aggregates data points of the credit data in a cohesive manner to generate the score. Scoring unit 328 aggregates the data points of the credit data using weights so that some data points have a greater impact on the credit score than other data points. Machine learning rules 320 refines the score calculation or formulae based on training results to update credit score calculation.)
c) in response to determining that the credit score of the user is different than the prior credit score before transmitting the account update data package to the secured third-party credit bureau system, transmitting a notification to the user. (see Nagla paragraph [0229]: The alerts and notification unit 792 can also generate alerts in relation to responses to loan requests, request to access information, request to register or verify data,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for receiving a credit score of the user based on said execution of the credit scoring algorithm and in response transmitting a notification to the user.as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Gupta does not specifically disclose determining that the credit score of the user is different than a prior credit score.
However, Manning discloses:
b) determining that the credit score of the user is different than a prior credit score before transmitting the account update data package; (see Manning paragraph [0041]: The system may report reputational scores (analogous to credit score) below a predetermined threshold to administrators for follow-up with the user or removal or suspension of the user's account. Alternatively the system may be automated and automatically suspend or terminate a user account with a reputational score below a predetermined threshold value.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for determining that the credit score of the user is different than a prior credit score as taught by Manning. One of ordinary skill in the art would have been motivated to employ the teachings of Manning for the flexibility of a system that enables the utilization of multiple user data processing parameters such as score type information. (see Manning paragraph [0041])
Regarding Claim 10, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 9.
Gupta does not specifically disclose notification (push notification) configured to automatically activate an application on the user computing device to cause display of information associated with the notification.
However, Nagla discloses wherein the notification comprises a push notification to the user computing device, the push notification configured to automatically activate an application on the user computing device to cause display of information associated with the notification. (see Nagla paragraph [0229]: The alerts and notification unit 792 can also generate alerts in relation to responses to loan requests, request to access information, request to register or verify data,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for notification (push notification) push notification configured to automatically activate an application on the user computing device to cause display of information associated with the notification as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
Regarding Claim 11, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 10.
Gupta does not specifically disclose notification is transmitted to user in real-time from receiving the updated account information.
However, Nagla discloses wherein the notification is transmitted to the user in real-time from receiving the updated account information. (see Nagla paragraph [0229]: The alerts and notification unit 792 can also generate alerts in relation to responses to loan requests, request to access information, request to register or verify data,)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for notification is transmitted to user in real-time from receiving the updated account information as taught by Nagla. One of ordinary skill in the art would have been motivated to employ the teachings of Nagla for the flexibility of a system that enables multiple factors to be included in the generation of a credit score. (see Nagla paragraph [0122])
6. Claims 13, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view Abbott and further in view of Nagla and Walraven et al. (US PGPUB No. 20140324677).
Regarding Claim 13, Gupta-Abbott-Nagla discloses the computer-implemented method of Claim 12, further comprising:
a) selecting a first data item of the account data items; b) identifying the third-party entity in the first data item; c) identifying a subset of account data items each indicating the identified third-party entity, wherein the subset of account data items includes at least the first data item and one or more other account data items; (see Gupta paragraph [0048]: using payment instruction rule sets to authorize programmatic transactions, which in this example includes a user (named "Rob") who provides an application 960 to implement shopping cart functionality for third-party merchants via Web services. Such merchants can sign up for and use Rob's shopping cart functionality by including customer-selectable controls in the merchants' applications that interface with Rob's shopping cart application 960, which in turn maintains session information for each customer of each merchant. When customers check out via a merchant's application, Rob's shopping cart application 960 interacts with the Subway transaction authorization system 970 to process payments from the customers to the merchants.) and
e) applying a first account identification rule, associated with a first account type, to the account data. (see Gupta paragraph [0020]: the transaction authorization system can use various information about the parties to a transaction when determining whether to authorize transactions. In particular, users that are potential parties to such transactions may first define usage instruction rule sets of one or more types with the transaction authorization system for later use in authorizing the transactions, such as payment instruction rule sets for use in authorizing fee-based transactions and/or the associated financial payments for such transactions. Each such payment instruction rule set for a party may include one or more specified rules that regulate the conditions under which the payment instruction rule set can authorize a potential transaction for the party and/or its associated financial payment,)
Gupta does not specifically disclose determining account data associated with an account of the user associated with the identified third-party entity, the account data comprising at least one of: a number of account data items each having time stamps within a predetermined time period, or an average number of days between time stamps of sequential account data items.
However, Abbott discloses:
d) determining, based at least on the identified subset of account data items, account data associated with an account of the user associated with the identified third-party entity, the account data comprising at least one of: a number of account data items each having time stamps within a predetermined time period, or an average number of days between time stamps of sequential account data items; (see Abbott paragraph [0080]: Through the accumulation of transaction data the system compiles the data into a system learned techniques. The system evaluates the data points against learned models to determine the aggregate probability of a life event actually occurring at a future time. The frequency of transactions at merchant or for product categories aids in contributing to the determination of a life event.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for determining account data associated with an account of the user associated with the identified third-party entity, the account data comprising at least one of: a number of account data items each having time stamps within a predetermined time period, or an average number of days between time stamps of sequential account data items as taught by Abbott. One of ordinary skill in the art would have been motivated to employ the teachings of Abbott for the flexibility of a system that enabling the grouping of transactions thereby enabling the determination of patterns in processing. (see Abbott paragraph [0079]; paragraph [0080])
Gupta does not specifically disclose determining a first confidence level indicating likelihood that the account is the first type of account.
However, Walraven discloses:
f) determining, based on said application of the first account identification rule, a first confidence level indicating likelihood that the account is the first type of account. (see Walraven paragraph [0056]: The inputs having a confidence level above a predetermined threshold (e.g., 95%) may be kept and applied. According to an exemplary application, 42 of the 275 inputs may be applied in the clustering or prediction algorithm of an embodiment of the present invention.; paragraph [0064]: the analysis performed at step 320 may be merged with other data, such as a credit score or other indication of risk. According to an exemplary embodiment, the analysis generated with the predicative model of an embodiment of the present invention, which may be represented as a score or other indicator, may be merged with a credit score, such as an Experian.TM. score. Other credit scores, risk scores, indicators and/or measures of credit, risk, debt, status, etc. may be used.; paragraph [0065]: According to an exemplary embodiment of the present invention, segments may be created based on the joint use of the score from the predictive model of an embodiment of the present invention, as shown by 710, and of a credit score, e.g., the Experian score, as shown by 720.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for determining a first confidence level indicating likelihood that the account is the first type of account as taught by Walraven. One of ordinary skill in the art would have been motivated to employ the teachings of Walraven for the flexibility of a system that enables the utilization of multiple user parameters such as confidence level and credit scores for processing user financial type transactions. (see Walraven paragraph [0056]; paragraph [0065])
Regarding Claim 14, Gupta-Abbott-Nagla-Walraven discloses the computer-implemented method of Claim 13.
Gupta does not specifically disclose determining that the first confidence level is above a first threshold and applying a scoring model to the account data to determine an expected change to a current credit score associated with the user.
However, Walraven discloses further comprising:
a) determining that the first confidence level is above a first threshold; b) in response to determining that the first confidence level is above the first threshold, applying a first account scoring model to the account data, the first account scoring model configured to determine an expected change to a current credit score associated with the user. (see Walraven paragraph [0056]: The inputs having a confidence level above a predetermined threshold (e.g., 95%) may be kept and applied. According to an exemplary application, 42 of the 275 inputs may be applied in the clustering or prediction algorithm of an embodiment of the present invention.; paragraph [0064]: the analysis performed at step 320 may be merged with other data, such as a credit score or other indication of risk. According to an exemplary embodiment, the analysis generated with the predicative model of an embodiment of the present invention, which may be represented as a score or other indicator, may be merged with a credit score, such as an Experian.TM. score. Other credit scores, risk scores, indicators and/or measures of credit, risk, debt, status, etc. may be used.; paragraph [0065]: According to an exemplary embodiment of the present invention, segments may be created based on the joint use of the score from the predictive model of an embodiment of the present invention, as shown by 710, and of a credit score, e.g., the Experian score, as shown by 720.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Gupta for determining that the first confidence level is above a first threshold and applying a scoring model to the account data to determine an expected change to a current credit score associated with the user as taught by Walraven. One of ordinary skill in the art would have been motivated to employ the teachings of Walraven for the flexibility of a system that enables the utilization of multiple user parameters such as confidence level and credit scores for processing user financial type transactions. (see Walraven paragraph [0056]; paragraph [0065])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLTON JOHNSON whose telephone number is (571)270-1032. The examiner can normally be reached Work: 12-9PM (most days).
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, Shewaye Gelagay can be reached at 571-272-4219. 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.
/CJ/
January 12, 2026
/KHOI V LE/Primary Examiner, Art Unit 2436