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
Preliminary Amendment
Applicant’s Preliminary Amendment, filed 10/08/2024, has been received, entered into the record, and considered.
Claims 2-21 are pending in this application. Claim 1 was cancelled.
Information Disclosure Statement
Applicants’ Information Disclosure Statement, filed 10/08/2024, has been received, entered into the record, and considered. See attached form PTO-1449.
Applicant should note that the large number of references in the attached IDS have been considered by the examiner in the same manner as other documents in Office search files are considered by the examiner while conducting a search of the prior art in a proper field of search. See MPEP 609.05(b). Applicant is requested to point out any particular reference in the IDS which they believe may be of particular relevance to the instant claimed invention in response to this office action.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: in claim 16, “a first computing node” and “a second computing node”, “a decision system”. The first and second “attribute processing agent” limitations are also recited in claims 9, 11, “data analysis system” in claim 19, “decision system” in claim 21.
Because these above claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. Specifically, FIG. 8 and paragraphs [0076] - [0083] of Applicants’ Specification.
If Applicants do not intend to have these limitation(s) interpreted under
35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, Applicants may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections – 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-21 are rejected under 35 U.S.C. 101 because the claimed invention are directed to non-statutory subject matter.
Claims 2-21 are rejected under 35 U.S.C. 101 because the claimed invention are directed to an abstract idea without significantly more.
Claims 2, recites a system for batch processing…,… comprising: a first computer node… to: retrieve a portion of data…; process… the first portion…; a second computing node…to: retrieve the second portion…; invoke the calculation engine…; process the second portion…; a data analysis system…to: receive the set of custom attributes…; receive a request… for batch processing…; parse the request…; in parallel, invoke the first attribute…; receive a results…; generate a response…; generate a user interface…; display the response…” these limitations are processes that, under their broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting "a computing node, processors, calculation engine", nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. For example, but for the “a computing node, processors, calculation engine” language, “a first computer node… to: retrieve a portion of data…; process… the first portion…; a second computing node…to: retrieve the second portion…; invoke the calculation engine…; process the second portion…; a data analysis system…to: receive the set of custom attributes…; receive a request… for batch processing…; parse the request…; in parallel, invoke the first attribute…; receive a results…; generate a response…; generate a user interface…; display the response…” in the context of this claim encompasses a user evaluating, collecting and organizing data mentally, with the aid of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
This judicial exception is not integrated into a practical application. In particular, the claims recite additional element – using “a non-transitory computer readable medium, a storage, computer memory devices” to “a first computer node… to: retrieve a portion of data…; process… the first portion…; a second computing node…to: retrieve the second portion…; invoke the calculation engine…; process the second portion…; a data analysis system…to: receive the set of custom attributes…; receive a request… for batch processing…; parse the request…; in parallel, invoke the first attribute…; receive a results…; generate a response…; generate a user interface…; display the response…”, these limitations amount to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
“invoke the first attribute…; display the response…”; these limitations are a mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
The computing nodes, processors, calculation engines are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of “a first computer node… to: retrieve a portion of data…; process… the first portion…; a second computing node…to: retrieve the second portion…; invoke the calculation engine…; process the second portion…; a data analysis system…to: receive the set of custom attributes…; receive a request… for batch processing…; parse the request…; in parallel, invoke the first attribute…; receive a results…; generate a response…; generate a user interface…; display the response…”. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)). The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and in combination, they do not add significantly more to the exception. Considered separately and as an ordered combination, the claim elements do not provide an improvement to another technology or technical field; do not provide an improvement to the functioning of the computer itself.
The limitations “a first computer node… to: retrieve a portion of data…; process… the first portion…; a second computing node…to: retrieve the second portion…; invoke the calculation engine…; process the second portion…; a data analysis system…to: receive the set of custom attributes…; receive a request… for batch processing…; parse the request…; in parallel, invoke the first attribute…; receive a results…; generate a response…; generate a user interface…; display the response…” amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Claims 8 recites a computer-implemented process of batch processing…, comprising: …a database system…a data store and system memory…to: receive a request…; identify a first attribute processing agent…; identify a second attribute processing agent…; communicate, in parallel, the set of custom attributes…; receive a result of the batch processing…; generate a response…; generate a user interface…; display, via the user interface, the response…” these limitations are processes that, under their broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components. That is, other than reciting "a computing node, processors, memory, calculation engine", nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. For example, but for the “a computing node, processors, memory, calculation engine” language, “a database system…a data store and system memory…to: receive a request…; identify a first attribute processing agent…; identify a second attribute processing agent…; communicate, in parallel, the set of custom attributes…; receive a result of the batch processing…; generate a response…; generate a user interface…; display, via the user interface, the response…” in the context of this claim encompasses a user evaluating, collecting and organizing data mentally, with the aid of pen and paper.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “Mental Processes” grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
This judicial exception is not integrated into a practical application. In particular, the claims recite additional element – using “a computing node, processors, memory, calculation engine” to “receive a request…; identify a first attribute processing agent…; identify a second attribute processing agent…; communicate, in parallel, the set of custom attributes…; receive a result of the batch processing…; generate a response…; generate a user interface…; display, via the user interface, the response…”, these limitations amount to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
“generate a user interface…; display, via the user interface, the response …”; these limitations are a mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g).
The computing nodes, processors, calculation engines are recited at a
high-level of generality (i.e., receive a request…; identify a first attribute processing agent…; identify a second attribute processing agent…; communicate, in parallel, the set of custom attributes…; receive a result of the batch processing…; generate a response…; generate a user interface…; display, via the user interface, the response…”. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (see MPEP 2106.05(f)). The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and in combination, they do not add significantly more to the exception. Considered separately and as an ordered combination, the claim elements do not provide an improvement to another technology or technical field; do not provide an improvement to the functioning of the computer itself.
The limitations “receive a request…; identify a first attribute processing agent…; identify a second attribute processing agent…; communicate, in parallel, the set of custom attributes…; receive a result of the batch processing…; generate a response…; generate a user interface…; display, via the user interface, the response…” amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Claim 16 recites a system to perform the method of claim 8, is similar in scope to claim 8, and is therefore, rejected under same preceding rationale of claim 12.
Dependent claims 2-7, 9-15, 17-21 merely add further details of the abstract steps recited in claims 1, 11 without including an improvement to another technology or technical field, an improvement to the functioning of the abstract idea to a particular technological environment. Therefore, dependent claims 2-10, 12-19 are also directed to non-statutory subject matter.
REJECTION 1
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 Nagarajan et al. (US Pub No. 2013/0297421), in view of Wen et al. (US Pub No. 2014/0156368).
As per claim 2, Nagarajan teaches a system for batch processing a data set that includes credit data of a plurality of consumers using a set of custom attributes (i.e. data relating to customers is gathered in order to generate a comprehensive customer data archive. The customer data archive may include transactional data and non-transactional data. Non-transactional data may include, for example, social media interactions, received input from a financial advisor, received input from the customer, customer-specific data such as age, family status, gender, etc., [0003]; The method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. The method additionally includes receiving non-transactional data relating to the customer. Furthermore, the method includes creating a customer data archive for associating offers comprising the transactional data and the non-transactional data. The method also includes storing the customer data archive in a database, [0004]), the system comprising:
a first computing node comprising one or more first processors, a first data store 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. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. Additionally or alternatively, the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase, a deposit, a withdrawal, a credit, a debit, etc., [0022]):
retrieve the first portion of data set from the first data source (i.e. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account, [0022]); and
process, with the calculation engine, the first portion of the data set with the set of custom attributes, 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. The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]);
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. Customer personal data may be another form of non-transactional data that may be useful in generating the customer's data archive. Personal data may be as simple as the customer's birthday, address, relationship with other financial institution customers, etc. which could have been obtained upon account generation at the financial institution or gathered by other means over time. A type of personal data may include various life events of the customer. Life events could include any significant event in the customer's life. Examples may include marriage, divorce, birth of a child, relocation, vacation, child's graduation, etc., [0030]):
retrieve the second portion of the data set from the second data store (i.e. Non-transactional data may be gathered from any number of sources. FIG. 2 illustrates various types of non-transactional data contemplated herein. As illustrated, non-transactional data may include input from a financial advisor, input from the customer, social media interactions, customer personal data such as age, family status, etc., customer life events, or any other external source, [0024]);
invoke the calculation engine via the public API (i.e. One embodiment of non-transactional data includes data inputted by a financial advisor that may be gleaned from other information known to the financial institution. For instance, the financial institution may have direct knowledge of a customer with investment accounts for children, joint accounts with spouse, etc. From that information, the number of family members, potentially birthdays of those in the family, etc. may be deduced. Of course, a financial advisor may input any type of data obtained directly from the customer if the customer consents to provide the information for generation of the customer data archive. Any information inputted into the financial institution system by the financial advisor for addition to the customer's comprehensive data archive may result in various triggered offers, [0026]);
process, with the calculation engine, the second portion of the data set using the set of custom attributes, 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. Another type of non-transactional data may be social media interactions. With the sharp rise in social media usage, a customer's social media interactions may be indicative of the customer's preferences—maybe even more so than transactional data. Examples of a customer's social media interactions include “liking” certain merchants on social media platforms, interaction with merchants, interaction with peers discussing particular products or merchants, etc., [0029]; the financial institution may gather transactional data on a product level which may trigger offers for other related products. For example, transactional data may indicate that a customer recently purchased a kitchen appliance such as a stove. Such data may aid in triggering an offer for other kitchen appliances such as a refrigerator, microwave, dishwasher, etc., [0037]);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. Referring now to FIG. 1, a general process flow 100 is provided for creating a customer data archive for associating offers. At block 110, the method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. At block 120, the method further includes receiving non-transactional data relating to the customer. Moving to block 130, the method comprises creating a customer data archive for associating offers. The customer data archive includes both transactional and non-transactional data. Once the customer data archive is created, the data archive is
stored in a database, as indicated in block 140, [0021]):
receive the set of custom attributes from a client system (i.e. Referring now to FIG. 1, a general process flow 100 is provided for creating a customer data archive for associating offers. At block 110, the method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. At block 120, the method further includes receiving non-transactional data relating to the customer. Moving to block 130, the method comprises creating a customer data archive for associating offers. The customer data archive includes both transactional and non-transactional data. Once the customer data archive is created, the data archive is stored in a database, as indicated in block 140, [0021]);
receive a request form the client system for batch processing the data set using the set of custom attributes (i.e. Of course, input from the customer may also be included in non-transactional data. In some embodiments, the customer may actively seek certain offers. As such, a customer could potentially trigger an offer simply by asking for it. In other embodiments, the offer triggering based at least in part on customer input may be more indirect. For instance, the customer may input a child's birthday which triggers an offer for a cake product a week prior to the child's birthday. As another example, the customer may travel away from home and input the destination he is travelling to in order to generate location-based offers away from home, [0027]);
parse the request to identify the data set and the set of custom attributes for batch processing (i.e. Determining a customer “merchant ecosystem” is another type of non-transactional data that may be incorporated into the customer data archive. The merchant ecosystem is essentially a determination of what merchants customers visit; interact with, etc. in order to determine merchant patterns. The merchant ecosystem data may be gathered, for instance, by determining what merchant websites a customer may visit, social media data collection (discussed below), etc., [0028]):
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. Turning now to FIG. 3, a general process flow 300 is provided for transmitting a targeted offer to a customer. As illustrated at block 310, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. Once the data archive is created, the method 300 progresses to block 320 where the customer data archive is analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, [0032]);
receive results from the first attribute processing agent and the second attribute processing agent (i.e. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]; Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]);
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. Utilizing transactional data with non-transactional data may provide unique benefits in targeting offers. For instance, non-transactional data may indicate that a customer frequents a particular book store, but transactional data does not indicate that the customer purchases from the book store. Rather, transactional data may indicate that the customer purchases from a discount online book store. Thus, such comparison of transactional data and non-transactional data may serve to trigger a particular offer for the book store, [0031]);
generate a user interface that is configured to display the response (i.e. FIG. 4 illustrates another process flow 400 for transmitting a targeted offer to a customer. As illustrated at block 410, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. The method 400 further includes block 420 where the financial institution may receive instructions from a third-party merchant for an advertising offer campaign, [0040]); and
display, via the user interface, the response to the client system (i.e. The
offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television, vehicle communication device, etc., [0039]).
Nagarajan implicitly teaches the term "display" (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television, vehicle communication device, etc., [0039]).
Nagarajan does not clearly state this term.
Wen teaches this term (i.e. a customer may receive the coupon offer by accessing a website displaying such coupons, [0062]).
It would have been obvious to one of ordinary skill of the art having the teaching of Nagarajan, Wen before the effective filing date of the claimed invention to modify the system of Nagarajan to include the limitations as taught by Wen. One of ordinary skill in the art would be motivated to make this combination in order to generate the merchant notification in the form of an electronic message or document (e.g., email, link to a website, SMS message, business software mechanisms in view of Wen ([0061]), as doing so would give the added benefit of a customer may receive the coupon offer
by accessing a website displaying such coupons as taught by as taught by Wen ([0062]).
As per claim 8, Nagarajan teaches a computer-implemented method for batch processing a data set that includes credit data of a plurality of consumers using a set of attributes, the method comprising:
under control of a database system comprising a data store and system memory that includes computer executable code that when executed by one or more processors of the database system causes the database system to (i.e. data relating to customers is gathered in order to generate a comprehensive customer data archive. The customer data archive may include transactional data and non-transactional data. Non-transactional data may include, for example, social media interactions, received input from a financial advisor, received input from the customer, customer-specific data such as age, family status, gender, etc., [0003]; The method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. The method additionally includes receiving non-transactional data relating to the customer. Furthermore, the method includes creating a customer data archive for associating offers comprising the transactional data and the non-transactional data. The method also includes storing the customer data archive in a database, [0004]):
receive a request from a client system for batch processing input data using the set of attributes (i.e. Of course, input from the customer may also be included in non-transactional data. In some embodiments, the customer may actively seek certain offers. As such, a customer could potentially trigger an offer simply by asking for it. In other embodiments, the offer triggering based at least in part on customer input may be more indirect. For instance, the customer may input a child's birthday which triggers an offer for a cake product a week prior to the child's birthday. As another example, the customer may travel away from home and input the destination he is travelling to in order to generate location-based offers away from home, [0027]);
identify a first attribute processing agent of a first computing node based at least in part on the input data and the set of attributes, wherein the first computing node comprises the first attribute processing agent and a first data store storing a first portion of the input data having a first format, wherein the first attribute processing agent comprises a calculation engine, a public application programming interface (API), and a first memory that includes computer-executable code, that when executed by one or more processors of the first computing node, causes the first attribute processing agent to process, with the calculation engine, the first portion of the input data with the set of custom attributes, 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 input data into a common format (i.e. Of course, input from the customer may also be included in non-transactional data. In some embodiments, the customer may actively seek certain offers. As such, a customer could potentially trigger an offer simply by asking for it. In other embodiments, the offer triggering based at least in part on customer input may be more indirect. For instance, the customer may input a child's birthday which triggers an offer for a cake product a week prior to the child's birthday. As another example, the customer may travel away from home and input the destination he is travelling to in order to generate location-based offers away from home, [0027]); Determining a customer “merchant ecosystem” is another type of non-transactional data that may be incorporated into the customer data archive. The merchant ecosystem is essentially a determination of what merchants customers visit; interact with, etc. in order to determine merchant patterns. The merchant ecosystem data may be gathered, for instance, by determining what merchant websites a customer may visit, social media data collection (discussed below), etc., [0028]; Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. Additionally or alternatively, the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase, a deposit, a withdrawal, a credit, a debit, etc., [0022]; The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]);
identify a second attribute processing agent of a second computing node based at least in part on the input data and the set of custom attributes, wherein the second computing node comprises the second attribute processing agent and a second data store storing a second portion of the input data having a second format that is different from the first format, wherein the second attribute processing agent comprises the public API and a second memory that includes computer-executable code, that when executed by one or more processors of the second computing node, causes the second attribute processing agent to invoke the calculation engine via the public API, process, with the calculation engine, the second portion of the input data with the set of custom attributes, 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 input data into the common format (i.e. Customer personal data may be another form of non-transactional data that may be useful in generating the customer's data archive. Personal data may be as simple as the customer's birthday, address, relationship with other financial institution customers, etc. which could have been obtained upon account generation at the financial institution or gathered by other means over time. A type of personal data may include various life events of the customer. Life events could include any significant event in the customer's life. Examples may include marriage, divorce, birth of a child, relocation, vacation, child's graduation, etc., [0030]; Non-transactional data may be gathered from any number of sources. FIG. 2 illustrates various types of non-transactional data contemplated herein. As illustrated, non-transactional data may include input from a financial advisor, input from the customer, social media interactions, customer personal data such as age, family status, etc., customer life events, or any other external source, [0024]; One embodiment of non-transactional data includes data inputted by a financial advisor that may be gleaned from other information known to the financial institution. For instance, the financial institution may have direct knowledge of a customer with investment accounts for children, joint accounts with spouse, etc. From that information, the number of family members, potentially birthdays of those in the family, etc. may be deduced. Of course, a financial advisor may input any type of data obtained directly from the customer if the customer consents to provide the information for generation of the customer data archive. Any information inputted into the financial institution system by the financial advisor for addition to the customer's comprehensive data archive may result in various triggered offers, [0026]); Another type of non-transactional data may be social media interactions. With the sharp rise in social media usage, a customer's social media interactions may be indicative of the customer's preferences—maybe even more so than transactional data. Examples of a customer's social media interactions include “liking” certain merchants on social media platforms, interaction with merchants, interaction with peers discussing particular products or merchants, etc., [0029]; the financial institution may gather transactional data on a product level which may trigger offers for other related products. For example, transactional data may indicate that a customer recently purchased a kitchen appliance such as a stove. Such data may aid in triggering an offer for other kitchen appliances
such as a refrigerator, microwave, dishwasher, etc., [0037]):
communicate, in parallel, the set of custom attributes to the first and second attribute processing agents as input (i.e. Turning now to FIG. 3, a general process flow 300 is provided for transmitting a targeted offer to a customer. As illustrated at block 310, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. Once the data archive is created, the method 300 progresses to block 320 where the customer data archive is analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, [0032]);
receive a result of the batch processing of the first and second portions of the input data from the first and second attribute processing agents, respectively (i.e. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]; Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]);
generate a response to the client system based at least in part on the result of the batch processing (i.e. Utilizing transactional data with non-transactional data may provide unique benefits in targeting offers. For instance, non-transactional data may indicate that a customer frequents a particular book store, but transactional data does not indicate that the customer purchases from the book store. Rather, transactional data may indicate that the customer purchases from a discount online book store. Thus, such comparison of transactional data and non-transactional data may serve to trigger a particular offer for the book store, [0031]);
generate a user interface that is configured to display the response (i.e. FIG. 4 illustrates another process flow 400 for transmitting a targeted offer to a customer. As illustrated at block 410, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. The method 400 further includes block 420 where the financial institution may receive instructions from a third-party merchant for an advertising offer campaign, [0040]); and
display, via the user interface, the response to the client system (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television,
vehicle communication device, etc., [0039]).
Nagarajan implicitly teaches the term "display" (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television, vehicle communication device, etc., [0039]).
Nagarajan does not clearly state this term.
Wen teaches this term (i.e. a customer may receive the coupon offer by accessing a website displaying such coupons, [0062]).
It would have been obvious to one of ordinary skill of the art having the teaching of Nagarajan, Wen before the effective filing date of the claimed invention to modify the system of Nagarajan to include the limitations as taught by Wen. One of ordinary skill in the art would be motivated to make this combination in order to generate the merchant notification in the form of an electronic message or document (e.g., email, link to a website, SMS message, business software mechanisms in view of Wen ([0061]), as doing so would give the added benefit of a customer may receive the coupon offer by accessing a website displaying such coupons as taught by as taught by Wen ([0062]).
As per claim 16, Nagarajan teaches data analysis system for batch processing a data set that includes credit data of a plurality of consumers using a set of custom attributes, the data analysis system comprising:
a data processing system comprising system memory that includes computer executable code that when executed by one or more processors of the data processing system causes the data processing system to (i.e. data relating to customers is gathered in order to generate a comprehensive customer data archive. The customer data archive may include transactional data and non-transactional data. Non-transactional data may include, for example, social media interactions, received input from a financial advisor, received input from the customer, customer-specific data such as age, family status, gender, etc., [0003]; The method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. The method additionally includes receiving non-transactional data relating to the customer. Furthermore, the method includes creating a customer data archive for associating offers comprising the transactional data and the non-transactional data. The method also includes storing the customer data archive in a database, [0004]):
receive a request from a client system for batch processing input data using the set of custom attributes (i.e. Of course, input from the customer may also be included in non-transactional data. In some embodiments, the customer may actively seek certain offers. As such, a customer could potentially trigger an offer simply by asking for it. In other embodiments, the offer triggering based at least in part on customer input may be more indirect. For instance, the customer may input a child's birthday which triggers an offer for a cake product a week prior to the child's birthday. As another example, the customer may travel away from home and input the destination he is travelling to in order to generate location-based offers away from home, [0027]);
identify, based at least in part on the input data and the set of custom attributes, a first attribute processing agent of a first computing node that is configured to process a first portion of the input data and a second attribute processing agent of a second computing node that is configured to process a second portion of the input data, wherein a first data store of the first computing node stores a first portion of input data and a second data store of the second computing node stores a second portion of the input data, the first portion having a first format and the second portion having a second format different from the first format, wherein the first attribute processing agent and the first data store are embedded in the first computing node and the second processing agent and the second data store are embedded in the second computing node to permit the first and second processing agents to process their corresponding portions of the input data without transforming formats of their corresponding portions of the input data into a common format during batch processing (i.e. Determining a customer “merchant ecosystem” is another type of non-transactional data that may be incorporated into the customer data archive. The merchant ecosystem is essentially a determination of what merchants customers visit; interact with, etc. in order to determine merchant patterns. The merchant ecosystem data may be gathered, for instance, by determining what merchant websites a customer may visit, social media data collection (discussed below), etc., [0028]; Turning now to FIG. 3, a general process flow 300 is provided for transmitting a targeted offer to a customer. As illustrated at block 310, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. Once the data archive is created, the method 300 progresses to block 320 where the customer data archive is analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, [0032]); and
invoke, in parallel, the first attribute processing agent at the first computing node and the second attribute processing agent at the second computing node to batch process the input data using the set of custom attributes, wherein the set of custom attributes are communicated to the first and second attribute processing agents as input (i.e. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]; Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]);
wherein the first attribute processing agent comprises a calculation engine, a public application programming interface (API), and a first memory that includes computer-executable code that when executed by one or more processors of the first computing node causes the first computing node to (i.e. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. Additionally or alternatively, the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase, a deposit, a withdrawal, a credit, a debit, etc., [0022]):
access the set of custom attributes from the data processing system (i.e. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account, [0022]);
without transforming the first format of the first portion of the input data into the common format for processing, perform computation, with the calculation engine, on the first portion of the input data with the set of custom attributes (i.e. Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]);
generate a first result of the batch processing from the computation on the
input data (i.e. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]); and
communicate the first result to a decision system (i.e. The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]); and
wherein the second attribute processing agent comprises the public application programming interface (API), and a second memory that includes computer-executable code that when executed by one or more processors of the second computing node causes the second computing node to (i.e. Customer personal data may be another form of non-transactional data that may be useful in generating the customer's data archive. Personal data may be as simple as the customer's birthday, address, relationship with other financial institution customers, etc. which could have been obtained upon account generation at the financial institution or gathered by other means over time. A type of personal data may include various life events of the customer. Life events could include any significant event in the customer's life. Examples may
include marriage, divorce, birth of a child, relocation, vacation, child's graduation, etc., [0030]):
access the set of custom attributes from the data processing system (i.e. Non-transactional data may be gathered from any number of sources. FIG. 2 illustrates various types of non-transactional data contemplated herein. As illustrated, non-transactional data may include input from a financial advisor, input from the customer, social media interactions, customer personal data such as age, family status, etc., customer life events, or any other external source, [0024]);
without transforming the second format of the second portion of the input data into the common format for processing, invoke the calculation engine via the public API, perform computation, with the calculation engine, on the second portion of the input data with the set of custom attributes (i.e. One embodiment of non-transactional data includes data inputted by a financial advisor that may be gleaned from other information known to the financial institution. For instance, the financial institution may have direct knowledge of a customer with investment accounts for children, joint accounts with spouse, etc. From that information, the number of family members, potentially birthdays of those in the family, etc. may be deduced. Of course, a financial advisor may input any type of data obtained directly from the customer if the customer consents to provide the information for generation of the customer data archive. Any information inputted into the financial institution system by the financial advisor for addition to the customer's comprehensive data archive may result in various triggered offers, [0026]);
generate a second result of the batch processing from the computation on the input data (i.e. Another type of non-transactional data may be social media interactions. With the sharp rise in social media usage, a customer's social media interactions may be indicative of the customer's preferences—maybe even more so than transactional data. Examples of a customer's social media interactions include “liking” certain merchants on social media platforms, interaction with merchants, interaction with peers discussing particular products or merchants, etc., [0029]; the financial institution may gather transactional data on a product level which may trigger offers for other related products. For example, transactional data may indicate that a customer recently purchased a kitchen appliance such as a stove. Such data may aid in triggering an offer for other kitchen appliances such as a refrigerator, microwave, dishwasher, etc., [0037]); and
communicate the second result to the decision system (i.e. Referring now to FIG. 1, a general process flow 100 is provided for creating a customer data archive for associating offers. At block 110, the method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. At block 120, the method further includes receiving non-transactional data relating to the customer. Moving to block 130, the method comprises creating a customer data archive for associating offers. The customer data archive includes both transactional and non-transactional data. Once the customer data archive is created,
the data archive is stored in a database, as indicated in block 140, [0021]);
the decision system configured to (i.e. Referring now to FIG. 1, a general process flow 100 is provided for creating a customer data archive for associating offers. At block 110, the method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. At block 120, the method further includes receiving non-transactional data relating to the customer. Moving to block 130, the method comprises creating a customer data archive for associating offers. The customer data archive includes both transactional and non-transactional data. Once the customer data archive is created, the data archive is stored in a database, as indicated in block 140, [0021]):
receive the first and second results of the batch processing from the first and second attribute processing agents (i.e. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]; Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]);
generate a response to the client system based at least in part on the first and second results of the batch processing (i.e. Utilizing transactional data with non-transactional data may provide unique benefits in targeting offers. For instance, non-transactional data may indicate that a customer frequents a particular book store, but transactional data does not indicate that the customer purchases from the book store. Rather, transactional data may indicate that the customer purchases from a discount online book store. Thus, such comparison of transactional data and non-transactional data may serve to trigger a particular offer for the book store, [0031]);
generating a user interface that is configured to display the response (i.e. FIG. 4 illustrates another process flow 400 for transmitting a targeted offer to a customer. As illustrated at block 410, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. The method 400 further includes block 420 where the financial institution may receive instructions from a third-party merchant for an advertising offer campaign, [0040]); and
display, via the user interface, the response to the client system (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television, vehicle communication device, etc., [0039]).
Nagarajan implicitly teaches the term "display" (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale or rebated after the sale, television, vehicle communication device, etc., [0039]).
Nagarajan does not clearly state this term.
Wen teaches this term (i.e. a customer may receive the coupon offer by accessing a website displaying such coupons, [0062]).
It would have been obvious to one of ordinary skill of the art having the teaching of Nagarajan, Wen before the effective filing date of the claimed invention to modify the system of Nagarajan to include the limitations as taught by Wen. One of ordinary skill in the art would be motivated to make this combination in order to generate the merchant notification in the form of an electronic message or document (e.g., email, link to a website, SMS message, business software mechanisms in view of Wen ([0061]), as doing so would give the added benefit of a customer may receive the coupon offer by accessing a website displaying such coupons as taught by as taught by Wen ([0062]).
As per claim 3, Wen 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. Server 220 may also be communicatively connected to one or more data repositories 226 as shown in FIG. 2. Server 220 may be communicatively connected to data repositories 226 through network 110. Data repository 226 may include one or more files or databases 227 that store information and are accessed and/or managed through server 220. By way of example, databases 227 may be Oracle™ databases, Sybase™ databases, or other relational databases or non-relational databases, such as Hadoop sequence files, HBase, or Cassandra. The databases or other files may include, for example, data and information related to the source and destination of a network request, the data contained in the request, etc. Systems and methods of disclosed embodiments, however, are not limited to separate databases. In one aspect, financial service provider 110 may include data repository 226. Alternatively, data repository 226 may be located remotely from financial service provider 110, [0035]).
As to claims 4, 10, 18, Nagarajan 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. The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]).
As to claims 5, 13, 20, Nagarajan 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. FIG. 4 illustrates another process flow 400 for transmitting a targeted offer to a customer. As illustrated at block 410, the method includes creating a customer data archive for associating offers comprising transactional data and non-transactional data relating to a customer. The method 400 further includes block 420 where the financial institution may receive instructions from a third-party merchant for an advertising offer campaign, [0040]); and
communicate the alert to the client system causing the client system to approve or decline a transaction (i.e. The offers may be transmitted to the customer by any means such as mail, e-mail, SMS message, loading the offer to a mobile device application, via a webpage interface such as the financial institution or the merchant webpage, loaded to a loyalty card, loaded to a debit/credit card or otherwise associated with the account such that the offer may be automatically redeemed at the point of sale
or rebated after the sale, television, vehicle communication device, etc., [0039]).
As per claim 6, Nagarajan 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. data relating to customers is gathered in order to generate a comprehensive customer data archive. The customer data archive may include transactional data and non-transactional data. Non-transactional data may include, for example, social media interactions, received input from a financial advisor, received input from the customer, customer-specific data such as age, family status, gender, etc., [0003]; The method includes receiving customer transaction data at a financial institution for a plurality of transactions by the customer over a period of time. The method additionally includes receiving non-transactional data relating to the customer. Furthermore, the method includes creating a customer data archive for associating offers comprising the transactional data and the non-transactional data. The method also includes storing the customer data archive in a database, [0004]).
As per claim 7, Nagarajan 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. Utilizing transactional data with non-transactional data may provide unique benefits in targeting offers. For instance, non-transactional data may indicate that a customer frequents a particular book store, but transactional data does not indicate that the customer purchases from the book store. Rather, transactional data may indicate that the customer purchases from a discount online book store. Thus, such comparison of transactional data and non-transactional data may serve to trigger a particular offer for the book store, [0031]).
As per claim 9, Nagarajan 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. The desired characteristics may be any particular trait or tendency of the customer as indicated by the data archive. For example, transaction data may indicate an increased frequency in charges at auto repair shops and rental cars while the customer does not make payments on a vehicle (i.e., vehicle presumed to be paid off and likely an older model vehicle). Such characteristics may trigger an offer for a new car, an auto repair shop, a rental car company, etc., [0033]; Once the customer data archive has been analyzed to determine if the customer meets desired characteristics for receiving a targeted offer, the process 300 advances to block 330 if it is determined that the customer meets the desired characteristics or to block 340 if it is determined that the customer does not meet the desired characteristics. If the customer does not meet the desired characteristics, the process may either end or revert back to the previous step 320 to determine if the customer meets desired characteristics of another offer. If the customer meets the desired characteristics, the process advances to block 350 and the targeted offer is transmitted to the customer, [0038]).
As per claim 11, Nagarajan 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. As another example, the customer may travel away from home and input the destination he is travelling to in order to generate location-based offers away from home, [0027]; Life events could include any significant event in the customer's life. Examples may include marriage, divorce, birth of a child, relocation, vacation, child's graduation, etc., [0031]); 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. In some instances, it may be beneficial to incorporate location data into the customer data archive. Location data may be a general “home” location of the customer or may be real-time location data from, for example, a mobile device of the customer. In some embodiments, non-transactional data may include data that the offer had been selected by the customer as an offer of interest to the customer as described in U.S. Provisional Application No. 61/641,700. Other data, such as location for instance, may be utilized to alert the customer again to the already selected offer, [0042]).
As per claim 12, Nagarajan 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. The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]); and
inputting the input data into the calculation engine for processing using the set of custom attributes (i.e. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. Additionally or alternatively, the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase, a deposit, a withdrawal, a credit, a debit, etc., [0022]).
As to claims 14, 21, Nagarajan teaches the computer-implemented method of claim 13 further comprising 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 instances, it may be beneficial to incorporate location data into the customer data archive. Location data may be a general “home” location of the customer or may be real-time location data from, for example, a mobile device of the customer. In some embodiments, non-transactional data may include data that the offer had been selected by the customer as an offer of interest to the customer as described in U.S. Provisional Application No. 61/641,700. Other data, such as location for instance, may be utilized to alert the customer again to the already selected offer, [0042]).
As per claim 15, Nagarajan 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. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. Additionally or alternatively, the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase,
a deposit, a withdrawal, a credit, a debit, etc., [0022]).
As per claim 17, Nagarajan 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. Non-transactional data may be gathered from any number of sources. FIG. 2 illustrates various types of non-transactional data contemplated herein. As illustrated, non-transactional data may include input from a financial advisor, input from the customer, social media interactions, customer personal data such as age, family status, etc., customer life events, or any other external source, [0024]).
As per claim 19, Nagarajan 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. The transactional data may be utilized in any desirable manner. For instance, a particular period of time may be important for offer triggering (e.g., transaction data indicates that more gasoline is utilized by the customer in the summer as opposed to the winter). In some embodiments, the customer's entire account history of transaction data may be utilized in the customer data archive. In other embodiments, only a particular window of transactions may be utilized. In some embodiments, the previous month of transaction data, in some embodiments, the previous one to six months of transaction data, in some embodiments, six to twelve months of transaction data, in some embodiments thirteen months of transaction data, and in some embodiments one to two years of transaction data is utilized. Again, any amount from one day to the entire account history of transaction data may be utilized in the comprehensive customer data archive, [0023]); and
embed the first attribute processing agent in the first computer node (i.e. Transactional data comprises any data related to the customer's transaction history associated with the financial institution account. The transaction history includes the types of transactions, frequency of transactions, amount of each transaction, merchants associated with transactions, account balance history, etc. the account information may or may not comprise information associated with incorrect, inconsistent, incomplete, or corrupted transactions. As used herein, a transaction may comprise a purchase, a deposit, a withdrawal, a credit, a debit, etc., [0022]).
REJECTION 2
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, 3, 5-9, 11-17, 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Mayr et al. (US Pat No. 7,376,603), in view of BARBER et al. (US Pub No. 2017/0200222), and further in view of Bryan et al. (US Pub No. 2014/0280905).
As per claim 2, Mayr teaches a system for batch processing a data set (i.e. the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67) that includes credit data of a plurality of consumers using a set of custom attributes (i.e. A request is sent to the customer database to retrieve the customer account information and all other data elements necessary for the assessment, and data is also retrieved from other sources such as credit bureaus, col. 12, lines 26-48):
a first computing node comprising one or more first processors (i.e. See Fig. 2, col. 14, lines 12-43; Extraction routine 30, col. 29, lines 34-57; col. 30, lines 10-36), a first data store a first portion of the data set having a first format (i.e. The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; the customer information database 24, the customer extract file 56, See Fig. 2), and a first attribute processing agent (i.e. the customer information database 24, the customer extract file 56, routine 30, See Fig. 2) 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 (i.e. the system software engine ... The assessment driver or module has both batch and on-line processing capabilities ... The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; as a tool for enabling efficient storage and access to current and historical value tag information, the customer relationship value database 28 is used, col. 23, lines 35-48; Fig. 2), causes the first attribute processing agent to:
retrieve the first portion of data set from the first data source (i.e. the customer information database extraction routine 30 selectively retrieves, transforms, and moves customer data from the customer information database 24 relational tables to the customer extract and customer account records. The routine 30 generates record images to ensure that all fields such as dates and numbers are expressed in standard format, col. 30, lines 10-36); and
process, with the calculation engine, the first portion of the data set with the set of custom attributes, 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. The parameter transaction driver 128 formats and writes a transaction to customer parameter transaction QSAM file 130. The assessment engine 26 reads QSAM file 130 and prepares the fields that are needed by the assessment driver 32 to process the accounts. The customer parameter loader 132 formats the fields into multiple instructions and writes them to the assessment parameters file 134. File 134 is then converted from QSAM format 134 to VSAM format 136. The assessment parameters file 136 is accessed by the assessment driver 32 to determine the number of accounts to process and the constants needed for present value calculation, col. 28, line 60 to col. 29, line 14; An assessing driver pre-processing procedure executes the assessment driver 32 to format a transaction extract file for the customer assessment batch decision engine 26. A customer assessment facility processing procedure runs the customer relationship assessment engine 26, col. 34, lines 37-55; A file is automatically formatted the extracted information, for example, by an assessment driver or module and transmitted automatically to the assessment engine, col. 3, lines 49-67; customer extract file 56 records are formatted and written to associated sequential files for a decisioned customer table, col. 15, line 54 to col. 16, line 15; The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3; The data is formatted according to a check point record layout, col. 28, lines 4-44; The data on the customer relationship value tag history record 146 is formatted and placed on the customer extract 56, col. 31, line 31 to col. 32, line 3; The main objective of the tags driver is to format the assessment engine instructions which are written to the customer database, col. 11, lines 20-38; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected, col. 29, lines 34-57; the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67);
b) a second computing node (See Fig. 2) comprising one or more second processors (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26. FIG. 16 is a schematic diagram which provides further detail regarding the assessment driver 32 process for an embodiment of the present invention. The assessment driver 32 accesses all of the customer records on the customer extract sequential file 56, col. 31, line 31 to col. 32, line 3; An acquisition system 22 state processor invokes the customer relationship value database 28 access program whenever the customer relationship value database 28 access indicator is “yes.” This program is invoked whenever the application is in the “add” mode or the user enters an activity code. The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8), a second data store storing a second portion of the data set having a second format different form the first format (i.e. The data is formatted according to a check point record layout, col. 28, lines 4-44; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3), and a second attribute processing agent (See Fig. 2) comprising the public APT, and a second memory storing computer-executable code that, when executed by the one or more second processors (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; The assessment driver 32 serves as the assessment engine 24 front-end processor to prepare all customer records for relationship value tags calculation. This processor initiates the evaluation of the customers that reside on the customer information database 24 customer extract sequential file 56 in batch. The processor reads the sequential file 56 for each customer, col. 30, lines 37-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26, col. 31, line 31 to col. 32, line 3), causes the second attribute processing agent to:
retrieve the second portion of the data set from the second data store (i.e. the customer information database extraction routine 30 selectively retrieves, transforms, and moves customer data from the customer information database 24 relational tables to the customer extract and customer account records. The routine 30 generates record images to ensure that all fields such as dates and numbers are expressed in standard format, col. 30, lines 10-36);
invoke the calculation engine via the public API; process, with the calculation engine, the second portion of the data set using the set of custom attributes, 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. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; See Fig. 2); and
c) a data analysis system comprising a third memory storing instructions and one or more hardware processors (i.e. An acquisition system 22 state processor invokes the customer relationship value database 28 access program whenever the customer relationship value database 28 access indicator is “yes.” This program is invoked whenever the application is in the “add” mode or the user enters an activity code. The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8; See Fig. 2) configured to execute the instructions to cause the one or more hardware processors to:
receive the set of custom attributes from a client system (i.e. The number
of customers processed by the assessment driver 32 is controlled by user-specified parameters on predefined relationship value tag parameter tables. The customer relationship assessment engine 26 is invoked to evaluate the customer records prepared by the assessment driver 32, col. 15, lines 29-53; The present value model uses a number of predefined parameters that will have different values for each financial institution and may change from time to time. To ensure maximum flexibility, the present value model parameters are established in the assessment engine 26 before an actual customer assessment is first executed to generate the relationship value tag parameters in the form of a record layout. The parameters are written to a file, where they are retrieved by the assessment driver 32. The relationship value tag parameters are implemented in the assessment engine 26 user interface. The relationship value tag tables are loaded to a mainframe computer where they are prepared for subsequent execution of the assessment driver 32, col. 17, lines 9-36);
receive a request form the client system for batch processing the data set using the set of custom attributes (i.e. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system. The request is entered, for example, by a customer representative of the financial institution on a financial institution terminal connected to the acquisition system. Analyzing the information is also automatically performed periodically according to predefined parameters such as date counters or by event triggers such as bankruptcy of
the customer, col. 4, lines 1-13);
parse the request to identify the data set and the set of custom attributes for batch processing (i.e. the customer relationship assessment engine 22 uses control tables to process customer level inbound transaction extract files created by the assessment driver 32. The assessment engine 22 evaluates customers with inbound activities based on management-defined risk parameters contained in the control tables. A tags update driver/back end processing procedure calls the tags update driver program 62, which splits the assessment engine 26 output instruction file into the customer treatment update file and customer score update file. It also strips unnecessary headers from each record and reformats each record into its table-defined format for the appropriate external file, col. 34, line 55 to col. 35, line 11; This process is used to supplement the batch assessment process and thereby refresh the treatment actions if new and significant data is available. An on-line re-evaluation is an alternative to the systematic override of the treatment actions that were derived in a previous off-line assessment. During the on-line assessment process, the assessment driver is invoked by an on-line trigger when significant information is received. A request is sent to the customer database to retrieve the customer account information and all other data elements necessary for the assessment, and data is also retrieved from other sources such as credit bureaus. The on-line assessment engine is invoked to generate the tags and their associated treatment codes and strategies. The treatment codes and tags are written to the staged treatment action file, where they are accessed by the acquisition system. The nightly assessment batch process consolidates the staged treatment action file with the customer treatment actions and updates the customer database. The on-line assessment engine is invoked to perform application decisioning, and the result of the acquisition evaluation is returned to the acquisition system, col. 12, lines 26-48);
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 (i.e. Periodically, extraction routine 30 is used by the customer information database 24 to create extract files with data on all customers. Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected. The rules are executed against the entire customer base. The customer data is then transformed into the relationship value tag predefined record layouts. The extraction routine 30 then writes the data to the customer extract sequential file 56, col. 29, lines 34-57) 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. the acquisition system invokes the on-line assessment engine to perform customer evaluation and application decisioning, which includes risk score calculation, line assignment, disaster processing, and the like, col. 11, line 55 to col. 12, line 8; At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions, col. 14, lines 12-43);
receive results from the first attribute processing agent and the second attribute processing agent (i.e. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43);
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. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system, col. 4, lines 1-13; The customer relationship value database is automatically accessed by a customer acquisition system connected to the database to retrieve the information about the assessed value of the customer and associated customer treatment action, for example, in response to entering a request for a financial institution product, such as a loan product, for the customer on the customer acquisition system by a financial institution customer representative at a terminal connected to the acquisition system, col. 4, lines 40-57);
generate a user interface that is configured to display the response; and display, via the user interface, the response to the client system (i.e. The tags driver transmits the information about the assessed value and associated customer treatment action to either or both of these databases, col. 4, lines 49-57; At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43; The tags update driver 62 distributes the assessment engine 26 assessment results to the appropriate target systems, col. 30, lines 37-67; The relationship value tag parameters are implemented in the assessment engine 26 user interface, col. 17, lines 9-36; The data is updated on a workstation parameter graphical user interface, committed, converted, and uploaded to the mainframe, col. 27, line 41 to col. 28, line 3; A customer relationship value screen program displays the customer relationship value tag data used in the acquisition system 22 for an application. The customer relationship value tag data is maintained on a record on the miscellaneous file, if applicable, col. 34, lines 9-36).
Mayr does not seem to specifically teach the following limitations, but
BARBER teaches:
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. In various embodiments, the ability to store a wide variety of information in different formats is facilitated by storing the information as a BLOB. Thus, any binary information can be stored in a storage space associated with a data set. As discussed above, the binary information may be stored on the financial transaction instrument or external to but affiliated with the financial transaction instrument. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using either fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first party, a second data set which may be stored may be provided by an unrelated second party, and yet a third data set which may be stored, may be provided by an third party unrelated to the first and second party. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data that also may be distinct from other subsets, [0069]);
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. As stated above, in various embodiments, the data can be stored without regard to a common format. However, the data set (e.g., BLOB) may be annotated in a standard manner when provided for manipulating the data onto the financial transaction instrument. The annotation may comprise a short header, trailer, or other appropriate indicator related to each data set that is configured to convey information useful in managing the various data sets. For example, the annotation may be called a “condition header”, “header”, “trailer”, or “status”, herein, and may comprise an indication of the status of the data set or may include an identifier correlated to a specific issuer or owner of the data. In one example, the first three bytes of each data set BLOB may be configured or configurable to indicate the status of that particular data set; e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of data may be used to indicate for example, the identity of the issuer, user, transaction/membership account identifier or the like. Each of these condition annotations are further discussed herein, [0070]);
in parallel (invoke the first attribute processing agent ... and invoke the
second attribute processing agent) (i.e. Referring to FIG. 2, a distributed file system (DFS) 200 is shown, in accordance with various embodiments. DFS 200 comprises a distributed computing cluster 202 configured for parallel processing and storage, [0019]; In various embodiments, DFS 200 may process hundreds of thousands of records from a single data source. DFS 200 may also ingest data from hundreds of data sources. The data may be processed through data transformations to generate output variables from input variables. In that regard, input variables may be mapped to output variables by applying data transformations to the input variables and intermediate variables generated from the input values. Nodes 204 may process the data in parallel to expedite the processing, [0023]; In various embodiments, a cluster computing engine 312 for high-speed, large-scale data processing may also be built on DFS 302. For example, cluster computing engine 312 may comprise an Apache SparkTM computing framework running on DFS 302. DFS 302 may further support a MapReduce layer 316 for processing big data sets in a parallel, distributed manner to produce records for data storage formats 301, [0027]);
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER before the effective filing date of the claimed invention to modify the system of Mayr to include the limitations as taught by BARBER. One of ordinary skill in the art would be motivated to make this combination in order to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets in view of BARBER ([0069]), as doing so would give the added benefit of the data can be stored without regard to a common format as taught by BARBER ([0070]).
Mayr, BARBER do not seem to specifically teach the following limitations, but
Bryan teaches:
a calculation engine (process, with the calculation engine, the first portion of the data set) (i.e. the provider system platform 102 includes a calculation engine 116. The calculation engine 116 receives the raw/unprocessed data and performs calculations and/or other processing, [0032]);
a public application programming interface (a second attribute processing agent comprising the public API) (i.e. The platform 204 gets data out of a tenant instance via the corresponding public API, [0135]);
invoke the calculation engine via the public API (i.e. The provider 142 supports the clients 104, 106, and 108 using a provider ERP system 144 that includes a calculation engine 146, [0037]);
process, with the calculation engine, the second portion of the data set (i.e. the client 104 may log into the client ERP system 144 and perform payroll processing using the calculation engine 146. This process entails the client 104 uploading information to the provider ERP system 144 and/or entering data directly into the system, [0038]).
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER, Bryan before the effective filing date of the claimed invention to modify the system of Mayr, BARBER to include the limitations as taught by Bryan. One of ordinary skill in the art would be motivated to make this combination in order to receive the raw/unprocessed data and perform calculations in view of Bryan ([0032]), as doing so would give the added benefit of effectively returning the results to the client ERP system from which it received the corresponding raw/unprocessed data as taught by Bryan ([0032]).
As per claim 8, Mayr teaches a computer-implemented method for batch processing a data set that includes credit data of a plurality of consumers using a set of attributes (i.e. the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67; A request is sent to the customer database to retrieve the customer account information and all other data elements necessary for the assessment, and data is also retrieved from other sources such as credit bureaus, col. 12, lines 26-48), the method comprising:
under control of a database system comprising a data store and system memory that includes computer executable code that when executed by one or more processors of the database system causes the database system to (i.e. FIG. 2, the creation and use of customer relationship value tags includes various steps. At S1, customer information is extracted from the customer information database 24 by extraction routine 30. The assessment driver or module 32 uses the customer-extract information to create a transaction file 56. At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43):
receive a request from a client system for batch processing input data using the set of attributes (i.e. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system. The request is entered, for example, by a customer representative of the financial institution on a financial institution terminal connected to the acquisition system. Analyzing the information is also automatically performed periodically according to predefined parameters such as date counters or by event triggers such as bankruptcy of the customer, col. 4, lines 1-13);
identify a first attribute processing agent of a first computing node based at least in part on the input data and the set of attributes (i.e. See Fig. 2; Extraction routine 30, col. 29, lines 34-57; col. 30, lines 10-36), wherein the first computing node comprises the first attribute processing agent and a first data store storing a first portion of the input data having a first format (i.e. The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; the customer information database 24, the customer extract file 56, See Fig. 2), wherein the first attribute processing agent (i.e. the customer information database 24, the customer extract file 56, routine 30, See Fig. 2) comprises a calculation engine, a public application programming interface (API), and a first memory that includes computer-executable code, that when executed by one or more processors of the first computing node (i.e. the system software engine ... The assessment driver or module has both batch and on-line processing capabilities ... The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; as a tool for enabling efficient storage and access to current and historical value tag information, the customer relationship value database 28 is used, col. 23, lines 35-48; Fig. 2), causes the first attribute processing agent to process, with the calculation engine, the first portion of the input data with the set of custom attributes (i.e. the customer information database extraction routine 30 selectively retrieves, transforms, and moves customer data from the customer information database 24 relational tables to the customer extract and customer account records. The routine 30 generates record images to ensure that all fields such as dates and numbers are expressed in standard format, col. 30, lines 10-36), 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 input data into a common format (i.e. The parameter transaction driver 128 formats and writes a transaction to customer parameter transaction QSAM file 130. The assessment engine 26 reads QSAM file 130 and prepares the fields that are needed by the assessment driver 32 to process the accounts. The customer parameter loader 132 formats the fields into multiple instructions and writes them to the assessment parameters file 134. File 134 is then converted from QSAM format 134 to VSAM format 136. The assessment parameters file 136 is accessed by the assessment driver 32 to determine the number of accounts to process and the constants needed for present value calculation, col. 28, line 60 to col. 29, line 14; An assessing driver pre-processing procedure executes the assessment driver 32 to format a transaction extract file for the customer assessment batch decision engine 26. A customer assessment facility processing procedure runs the customer relationship assessment engine 26, col. 34, lines 37-55; A file is automatically formatted the extracted information, for example, by an assessment driver or module and transmitted automatically to the assessment engine, col. 3, lines 49-67; customer extract file 56 records are formatted and written to associated sequential files for a decisioned customer table, col. 15, line 54 to col. 16, line 15; The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3; The data is formatted according to a check point record layout, col. 28, lines 4-44; The data on the customer relationship value tag history record 146 is formatted and placed on the customer extract 56, col. 31, line 31 to col. 32, line 3; The main objective of the tags driver is to format the assessment engine instructions which are written to the customer database, col. 11, lines 20-38; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected, col. 29, lines 34-57; the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67);
identify a second attribute processing agent of a second computing node (See Fig. 2) based at least in part on the input data and the set of custom attributes (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26. FIG. 16 is a schematic diagram which provides further detail regarding the assessment driver 32 process for an embodiment of the present invention. The assessment driver 32 accesses all of the customer records on the customer extract sequential file 56, col. 31, line 31 to col. 32, line 3; An acquisition system 22 state processor invokes the customer relationship value database 28 access program whenever the customer relationship value database 28 access indicator is “yes.” This program is invoked whenever the application is in the “add” mode or the user enters an activity code. The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8), wherein the second computing node comprises the second attribute processing agent and a second data store storing a second portion of the input data having a second format that is different from the first format (i.e. The data is formatted according to a check point record layout, col. 28, lines 4-44; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3), wherein the second attribute processing agent comprises the public API and a second memory that includes computer-executable code, that when executed by one or more processors of the second computing node (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; The assessment driver 32 serves as the assessment engine 24 front-end processor to prepare all customer records for relationship value tags calculation. This processor initiates the evaluation of the customers that reside on the customer information database 24 customer extract sequential file 56 in batch. The processor reads the sequential file 56 for each customer, col. 30, lines 37-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26, col. 31, line 31 to col. 32, line 3), causes the second attribute processing agent to invoke the calculation engine via the public API, process, with the calculation engine, the second portion of the input data with the set of custom attributes (i.e. the customer information database extraction routine 30 selectively retrieves, transforms, and moves customer data from the customer information database 24 relational tables to the customer extract and customer account records. The routine 30 generates record images to ensure that all fields such as dates and numbers are expressed in standard format, col. 30, lines 10-36), wherein the second attribute processing agent and the second data store are embedded in the second computing node (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; See Fig. 2) so that the second portion of the data set in the second data store is processed without converting the second portion of the input data into the common format;
communicate, in parallel, the set of custom attributes to the first and second attribute processing agents as input (i.e. Periodically, extraction routine 30 is used by the customer information database 24 to create extract files with data on all customers. Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected. The rules are executed against the entire customer base. The customer data is then transformed into the relationship value tag predefined record layouts. The extraction routine 30 then writes the data to the customer extract sequential file 56, col. 29, lines 34-57; (i.e. the acquisition system invokes the on-line assessment engine to perform customer evaluation and application decisioning, which includes risk score calculation, line assignment, disaster processing, and the like, col. 11, line 55 to col. 12, line 8; At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions, col. 14, lines 12-43);
receive a result of the batch processing of the first and second portions of the input data from the first and second attribute processing agents, respectively (i.e. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43);
generate a response to the client system based at least in part on the result of the batch processing (i.e. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system, col. 4, lines 1-13; The customer relationship value database is automatically accessed by a customer acquisition system connected to the database to retrieve the information about the assessed value of the customer and associated customer treatment action, for example, in response to entering a request for a financial institution product, such as a loan product, for the customer on the customer acquisition system by a financial institution customer representative at a terminal connected to the acquisition system, col. 4, lines 40-57);
generate a user interface that is configured to display the response; and
display, via the user interface, the response to the client system (i.e. The tags driver transmits the information about the assessed value and associated customer treatment action to either or both of these databases, col. 4, lines 49-57; At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43; The tags update driver 62 distributes the assessment engine 26 assessment results to the appropriate target systems, col. 30, lines 37-67; The relationship value tag parameters are implemented in the assessment engine 26 user interface, col. 17, lines 9-36; The data is updated on a workstation parameter graphical user interface, committed, converted, and uploaded to the mainframe, col. 27, line 41 to col. 28, line 3; A customer relationship value screen program displays the customer relationship value tag data used in the acquisition system 22 for an application. The customer relationship value tag data is maintained on a record on the miscellaneous file, if applicable, col. 34, lines 9-36).
Mayr does not seem to specifically teach the following limitations, but:
BARBER teaches:
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. In various embodiments, the ability to store a wide variety of information in different formats is facilitated by storing the information as a BLOB. Thus, any binary information can be stored in a storage space associated with a data set. As discussed above, the binary information may be stored on the financial transaction instrument or external to but affiliated with the financial transaction instrument. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using either fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first party, a second data set which may be stored may be provided by an unrelated second party, and yet a third data set which may be stored, may be provided by an third party unrelated to the first and second party. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data that also may be distinct from other subsets, [0069]);
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. As stated above, in various embodiments, the data can be stored without regard to a common format. However, the data set (e.g., BLOB) may be annotated in a standard manner when provided for manipulating the data onto the financial transaction instrument. The annotation may comprise a short header, trailer, or other appropriate indicator related to each data set that is configured to convey information useful in managing the various data sets. For example, the annotation may be called a “condition header”, “header”, “trailer”, or “status”, herein, and may comprise an indication of the status of the data set or may include an identifier correlated to a specific issuer or owner of the data. In one example, the first three bytes of each data set BLOB may be configured or configurable to indicate the status of that particular data set; e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of data may be used to indicate for example, the identity of the issuer, user, transaction/membership account identifier or the like. Each of these condition annotations are further discussed herein, [0070]);
in parallel (invoke the first attribute processing agent ... and invoke the second attribute processing agent) (i.e. Referring to FIG. 2, a distributed file system (DFS) 200 is shown, in accordance with various embodiments. DFS 200 comprises a distributed computing cluster 202 configured for parallel processing and storage, [0019]; In various embodiments, DFS 200 may process hundreds of thousands of records from a single data source. DFS 200 may also ingest data from hundreds of data sources. The data may be processed through data transformations to generate output variables from input variables. In that regard, input variables may be mapped to output variables by applying data transformations to the input variables and intermediate variables generated from the input values. Nodes 204 may process the data in parallel to expedite the processing, [0023]; In various embodiments, a cluster computing engine 312 for high-speed, large-scale data processing may also be built on DFS 302. For example, cluster computing engine 312 may comprise an Apache SparkTM computing framework running on DFS 302. DFS 302 may further support a MapReduce layer 316 for processing big data sets in a parallel, distributed manner to produce records for data storage formats 301, [0027]);
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER before the effective filing date of the claimed invention to modify the system of Mayr to include the limitations as taught by BARBER. One of ordinary skill in the art would be motivated to make this combination in order to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets in view of BARBER ([0069]), as doing so would give the added benefit that the data can be stored without regard to a common format as taught by BARBER ([0070]).
Mayr, BARBER do not seem to specifically teach the following limitations, but
Bryan teaches:
a calculation engine (process, with the calculation engine, the first portion of the data set) (i.e. the provider system platform 102 includes a calculation engine 116. The calculation engine 116 receives the raw/unprocessed data and performs calculations and/or other processing, [0032]);
a public application programming interface (a second attribute processing agent comprising the public API) (i.e. The platform 204 gets data out of a tenant instance via the corresponding public API, [0135]);
invoke the calculation engine via the public API (i.e. The provider 142 supports the clients 104, 106, and 108 using a provider ERP system 144 that includes a calculation engine 146, [0037]);
process, with the calculation engine, the second portion of the data set (i.e. the client 104 may log into the client ERP system 144 and perform payroll processing using the calculation engine 146. This process entails the client 104 uploading information to the provider ERP system 144 and/or entering data directly into the system, [0038]).
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER, Bryan before the effective filing date of the claimed invention to modify the system of Mayr, BARBER to include the limitations as taught by Bryan. One of ordinary skill in the art would be motivated to make this combination in order to receive the raw/unprocessed data and perform calculations in view of Bryan ([0032]), as doing so would give the added benefit of returning the results to the client ERP system from which it received the corresponding raw/unprocessed data as taught by Bryan ([0032]).
As per claim 16, Mayr teaches data analysis system for batch processing a data set that includes credit data of a plurality of consumers using a set of custom attributes (i.e. the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67; A request is sent to the customer database to retrieve the customer account information and all other data elements necessary for the assessment, and data is also retrieved from other sources such as credit bureaus, col. 12, lines 26-48), the data analysis system comprising:
a data processing system comprising system memory that includes computer executable code that when executed by one or more processors of the data processing system causes the data processing system to (i.e. FIG. 2, the creation and use of customer relationship value tags includes various steps. At S1, customer information is extracted from the customer information database 24 by extraction routine 30. The assessment driver or module 32 uses the customer-extract information to create a transaction file 56. At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43):
receive a request from a client system for batch processing input data using the set of custom attributes (i.e. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system. The request is entered, for example, by a customer representative of the financial institution on a financial institution terminal connected to the acquisition system. Analyzing the information is also automatically performed periodically according to predefined parameters such as date counters or by event triggers such as bankruptcy of the customer, col. 4, lines 1-13);
identify, based at least in part on the input data and the set of custom attributes, a first attribute processing agent of a first computing node that is configured to process a first portion of the input data (i.e. The parameter transaction driver 128 formats and writes a transaction to customer parameter transaction QSAM file 130. The assessment engine 26 reads QSAM file 130 and prepares the fields that are needed by the assessment driver 32 to process the accounts. The customer parameter loader 132 formats the fields into multiple instructions and writes them to the assessment parameters file 134. File 134 is then converted from QSAM format 134 to VSAM format 136. The assessment parameters file 136 is accessed by the assessment driver 32 to determine the number of accounts to process and the constants needed for present value calculation, col. 28, line 60 to col. 29, line 14; An assessing driver pre-processing procedure executes the assessment driver 32 to format a transaction extract file for the customer assessment batch decision engine 26. A customer assessment facility processing procedure runs the customer relationship assessment engine 26, col. 34, lines 37-55; A file is automatically formatted the extracted information, for example, by an assessment driver or module and transmitted automatically to the assessment engine, col. 3, lines 49-67) and a second attribute processing agent of a second computing node that is configured to process a second portion of the input data (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26. FIG. 16 is a schematic diagram which provides further detail regarding the assessment driver 32 process for an embodiment of the present invention. The assessment driver 32 accesses all of the customer records on the customer extract sequential file 56, col. 31, line 31 to col. 32, line 3), wherein a first data store of the first computing node stores a first portion of input data and a second data store of the second computing node stores a second portion of the input data (i.e. customer extract file 56 records are formatted and written to associated sequential files for a decisioned customer table, col. 15, line 54 to col. 16, line 15; The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3; The data is formatted according to a check point record layout, col. 28, lines 4-44; The data on the customer relationship value tag history record 146 is formatted and placed on the customer extract 56, col. 31, line 31 to col. 32, line 3; The main objective of the tags driver is to format the assessment engine instructions which are written to the customer database, col. 11, lines 20-38; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected, col. 29, lines 34-57; the customer assessment process includes batch processing of the customer information database 24 customer extract file 56 to produce a formatted assessment engine 26 transaction file, col. 30, lines 37-67; An acquisition system 22 state processor invokes the customer relationship value database 28 access program whenever the customer relationship value database 28 access indicator is “yes.” This program is invoked whenever the application is in the “add” mode or the user enters an activity code. The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8), the first portion having a first format and the second portion having a second format different from the first format (i.e. The data is formatted according to a check point record layout, col. 28, lines 4-44; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3), wherein the first attribute processing agent and the first data store are embedded in the first computing node (i.e. The data is extracted using structured query language queries and formatted onto the customer extract file 56 according to a predefined record layout, col. 26, line 59 to col. 27, line 17; the customer information database 24, the customer extract file 56, See Fig. 2) and the second processing agent and the second data store are embedded in the second computing node to permit the first and second processing agents to process their corresponding portions of the input data (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; See Fig. 2) without transforming formats of their corresponding portions of the input data into a common format during batch processing; and
invoke, in parallel, the first attribute processing agent at the first computing node and the second attribute processing agent at the second computing node to batch process the input data using the set of custom attributes, wherein the set of custom attributes are communicated to the first and second attribute processing agents as input (i.e. (i.e. Periodically, extraction routine 30 is used by the customer information database 24 to create extract files with data on all customers. Extraction routine 30 has a series of structured query language rules that ensure that the correct customers and product data are selected. The rules are executed against the entire customer base. The customer data is then transformed into the relationship value tag predefined record layouts. The extraction routine 30 then writes the data to the customer extract sequential file 56, col. 29, lines 34-57);
wherein the first attribute processing agent comprises a calculation engine, a public application programming interface (API), and a first memory that includes computer-executable code that when executed by one or more processors of the first computing node causes the first computing node to (i.e. the acquisition system invokes the on-line assessment engine to perform customer evaluation and application decisioning, which includes risk score calculation, line assignment, disaster processing, and the like, col. 11, line 55 to col. 12, line 8; At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions, col. 14, lines 12-43):
access the set of custom attributes from the data processing system (i.e. the customer information database extraction routine 30 selectively retrieves, transforms, and moves customer data from the customer information database 24 relational tables to the customer extract and customer account records. The routine 30 generates record images to ensure that all fields such as dates and numbers are expressed in standard format, col. 30, lines 10-36);
without transforming the first format of the first portion of the input data into the common format for processing, perform computation, with the calculation engine, on the first portion of the input data with the set of custom attributes (i.e. The parameter transaction driver 128 formats and writes a transaction to customer parameter transaction QSAM file 130. The assessment engine 26 reads QSAM file 130 and prepares the fields that are needed by the assessment driver 32 to process the accounts. The customer parameter loader 132 formats the fields into multiple instructions and writes them to the assessment parameters file 134. File 134 is then converted from QSAM format 134 to VSAM format 136. The assessment parameters file 136 is accessed by the assessment driver 32 to determine the number of accounts to process and the constants needed for present value calculation, col. 28, line 60 to col. 29, line 14; An assessing driver pre-processing procedure executes the assessment driver 32 to format a transaction extract file for the customer assessment batch decision engine 26. A customer assessment facility processing procedure runs the customer relationship assessment engine 26, col. 34, lines 37-55);
generate a first result of the batch processing from the computation on the input data (i.e. during an assessment, the assessment engine 26 generates customer value scores and acquisition treatments for every customer evaluated, col. 15, line 54 to col. 16, line 15; a customer treatment record layout contains all the customer level data elements that reflect the results of an assessment-by-assessment engine 26, col. 26, lines 15-35);
communicate the first result to a decision system (i.e. The tags driver transmits the information about the assessed value and associated customer treatment action to either or both of these databases, col. 4, lines 40-57; As seen in FIG. 2, the creation and use of customer relationship value tags includes various steps. At S1, customer information is extracted from the customer information database 24 by extraction routine 30. The assessment driver or module 32 uses the customer-extract information to create a transaction file 56. At S2, customer assessment is performed by batch processing of the customer extract file 56 by the assessment engine 26. During the assessment process, the assessment engine 26 calculates the customer's value and assigns the appropriate treatments for loan acquisitions. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43; The tags update driver 62 distributes the assessment engine 26 assessment results to the appropriate target systems, col. 30, lines 37-67); and
wherein the second attribute processing agent comprises the public application programming interface (API), and a second memory that includes computer-executable code that when executed by one or more processors of the second computing node causes the second computing node (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26. FIG. 16 is a schematic diagram which provides further detail regarding the assessment driver 32 process for an embodiment of the present invention. The assessment driver 32 accesses all of the customer records on the customer extract sequential file 56, col. 31, line 31 to col. 32, line 3; An acquisition system 22 state processor invokes the customer relationship value database 28 access program whenever the customer relationship value database 28 access indicator is “yes.” This program is invoked whenever the application is in the “add” mode or the user enters an activity code. The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8) to: access the set of custom attributes from the data processing system (i.e. The data is formatted according to a check point record layout, col. 28, lines 4-44; Each table in the customer relationship database management system contains specific information in a pre-defined table format, col. 23, line 49 to col. 24, line 3; The data is formatted according to an acquisition decisions record layout, col. 27, line 41 to col. 28, line 3); without transforming the second format of the second portion of the input data into the common format for processing, invoke the calculation engine via the public API, perform computation, with the calculation engine, on the second portion of the input data with the set of custom attributes; generate a second result of the batch processing from the computation on the input data; and communicate the second result to the decision system (i.e. The assessment driver or module has both batch and on-line processing capabilities. The main objective of this processor is to initiate the evaluation of the customers that reside on the customer database. The processor uses triggers to determine when a particular customer or group of customers should be assessed, col. 10, lines 38-67; The assessment driver 32 serves as the assessment engine 24 front-end processor to prepare all customer records for relationship value tags calculation. This processor initiates the evaluation of the customers that reside on the customer information database 24 customer extract sequential file 56 in batch. The processor reads the sequential file 56 for each customer, col. 30, lines 37-67; the assessment driver 32 is an assessment engine 26 front-end processor that prepares the customer extract and transaction records that are used by the assessment engine 26, col. 31, line 31 to col. 32, line 3);
the decision system configured to (i.e. the acquisition system-decisioned application matching driver 58 performs decision record matching to update the decisioned application table 52, the application report group table 54, and assessed customer table 36 on the customer relationship value database 28 ... FIG. 15 is a schematic diagram which provides further detail regarding the decision record matching process for an embodiment of the present invention. If an account number is found on the acquisition decisioned record 68, the matching process 58 performs an account number comparison against the customer extract file 56, col. 31, lines 1-30):
receive the first and second results of the batch processing from the first and second attribute processing agents (i.e. At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43);
generate a response to the client system based at least in part on the first and second results of the batch processing (i.e. In an embodiment of the present invention, the information is analyzed in response to a request for assessment of the customer. The request is transmitted, for example, automatically by a customer acquisition system of the financial institution in response to entering a request for a financial institution product, such as a loan, for the customer on the acquisition system, col. 4, lines 1-13; The customer relationship value database is automatically accessed by a customer acquisition system connected to the database to retrieve the information about the assessed value of the customer and associated customer treatment action, for example, in response to entering a request for a financial institution product, such as a loan product, for the customer on the customer acquisition system by a financial institution customer representative at a terminal connected to the acquisition system, col. 4, lines 40-57);
generating a user interface that is configured to display the response; and display, via the user interface, the response to the client system (i.e. The tags driver transmits the information about the assessed value and associated customer treatment action to either or both of these databases, col. 4, lines 49-57; At S3, assessment engine 26 instructions and assessment driver 32 output records are batch processed to load data into the appropriate tables on the customer relationship value database 28. At S4, the treatments are used on-line in the acquisitions process, col. 14, lines 12-43; The tags update driver 62 distributes the assessment engine 26 assessment results to the appropriate target systems, col. 30, lines 37-67; The relationship value tag parameters are implemented in the assessment engine 26 user interface, col. 17, lines 9-36; The data is updated on a workstation parameter graphical user interface, committed, converted, and uploaded to the mainframe, col. 27, line 41 to col. 28, line 3; A customer relationship value screen program displays the customer relationship value tag data used in the acquisition system 22 for an application. The customer relationship value tag data is maintained on a record on the miscellaneous file, if applicable, col. 34, lines 9-36).
Mayr does not seem to specifically teach the following limitations, but
BARBER teaches:
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. In various embodiments, the ability to store a wide variety of information in different formats is facilitated by storing the information as a BLOB. Thus, any binary information can be stored in a storage space associated with a data set. As discussed above, the binary information may be stored on the financial transaction instrument or external to but affiliated with the financial transaction instrument. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using either fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first party, a second data set which may be stored may be provided by an unrelated second party, and yet a third data set which may be stored, may be provided by an third party unrelated to the first and second party. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data that also may be distinct from other subsets, [0069]);
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. As stated above, in various embodiments, the data can be stored without regard to a common format. However, the data set (e.g., BLOB) may be annotated in a standard manner when provided for manipulating the data onto the financial transaction instrument. The annotation may comprise a short header, trailer, or other appropriate indicator related to each data set that is configured to convey information useful in managing the various data sets. For example, the annotation may be called a “condition header”, “header”, “trailer”, or “status”, herein, and may comprise an indication of the status of the data set or may include an identifier correlated to a specific issuer or owner of the data. In one example, the first three bytes of each data set BLOB may be configured or configurable to indicate the status of that particular data set; e.g., LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of data may be used to indicate for example, the identity of the issuer, user, transaction/membership account identifier or the like. Each of these condition annotations are further discussed herein, [0070]);
in parallel (invoke the first attribute processing agent ... and invoke the second attribute processing agent) (i.e. Referring to FIG. 2, a distributed file system (DFS) 200 is shown, in accordance with various embodiments. DFS 200 comprises a distributed computing cluster 202 configured for parallel processing and storage, [0019]; In various embodiments, DFS 200 may process hundreds of thousands of records from a single data source. DFS 200 may also ingest data from hundreds of data sources. The data may be processed through data transformations to generate output variables from input variables. In that regard, input variables may be mapped to output variables by applying data transformations to the input variables and intermediate variables generated from the input values. Nodes 204 may process the data in parallel to expedite the processing, [0023]; In various embodiments, a cluster computing engine 312 for high-speed, large-scale data processing may also be built on DFS 302. For example, cluster computing engine 312 may comprise an Apache SparkTM computing framework running on DFS 302. DFS 302 may further support a MapReduce layer 316 for processing big data sets in a parallel, distributed manner to produce records for data storage formats 301, [0027]);
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER before the effective filing date of the claimed invention to modify the system of Mayr to include the limitations as taught by BARBER. One of ordinary skill in the art would be motivated to make this combination in order to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets in view of BARBER ([0069]), as doing so would give the added benefit that the data can be stored without regard to a common format as taught by BARBER ([0070]).
Mayr, BARBER do not seem to specifically teach the following limitations, but
Bryan teaches:
a calculation engine (process, with the calculation engine, the first portion of the data set) (i.e. the provider system platform 102 includes a calculation engine 116. The calculation engine 116 receives the raw/unprocessed data and performs calculations and/or other processing, [0032]);
a public application programming interface (a second attribute processing agent comprising the public API) (i.e. The platform 204 gets data out of a tenant instance via the corresponding public API, [0135]);
invoke the calculation engine via the public API (i.e. The provider 142 supports the clients 104, 106, and 108 using a provider ERP system 144 that includes a calculation engine 146, [0037]);
process, with the calculation engine, the second portion of the data set (i.e. the client 104 may log into the client ERP system 144 and perform payroll processing using the calculation engine 146. This process entails the client 104 uploading information to the provider ERP system 144 and/or entering data directly into the system, [0038]).
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER, Bryan before the effective filing date of the claimed invention to modify the system of Mayr, BARBER to include the limitations as taught by Bryan. One of ordinary skill in the art would be motivated to make this combination in order to receive the raw/unprocessed data and perform calculations in view of Bryan ([0032]), as doing so would give the added benefit of returning the results to the client ERP system from which it received the corresponding raw/unprocessed data as taught by Bryan ([0032]).
As per claim 3, BARBER 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. The eligibility module 120 may comprise a software framework for distributed processing of very large data sets on computer clusters, such as Apache Hadoop®. The eligibility module 120 may prepare and aggregate the data received from the data source 110, [0013]).
As to claims 5, 13, 20, Mayr 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. an acquisition decisions record contains account and customer identification information. It also contains an indicator of whether the account was approved or turned down, col. 27, line 41 to col. 28, line 3); and
communicate the alert to the client system causing the client system to approve or decline a transaction (i.e. If the relationship value tag-approved indicator is set to “yes,” and if the customer last relationship value tag approved date is within the performance evaluation period, the decisioned application table 52 is accessed to retrieve the specific account for which a decision was mad, col. 32, lines 24-49; relationship value tag-based approved and turndown applications are written to the customer acquisition decision database 68. When a relationship value tag-based application is turned down, a customer relationship account decision status indicator is set to “turndown.” When a relationship value tag-based application is booked, the customer relationship account decision status indicator is set to “approve.”, col. 33, line 46 to col. 34, line 8; Applications that are relationship value tag-decisioned are assigned “yes” in a relationship value tab decision attribute. Otherwise the field is set to “no.” The relationship value tag decision indicator is written to the acquisition system 22 relationship value tags record. The relationship value tag decision indicator serves as an indicator to write applications to the customer acquisition decision database 68. Whenever an application is automatically or manually booked by the entry of a set-up activity code, a record is written to the customer acquisition decision database 68, col. 33, lines 13-45).
As per claim 6, Mayr 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 calculation of the customer present value is done by the assessment driver 32 using data from the customer information database 24, a customer future value history file, an account present value history file, and an assessment engine 26 parameter table. The assessment driver 32 writes the customer present value to an assessment engine 26 extract file that is the input to the assessment engine 26. For calculation of the customer future value, all the customer-level variables used to calculate the future value, are calculated by the assessment driver 32. The assessment driver 32 writes these values to the assessment engine 26 extract file that the assessment engine 26 uses as an input to a future value models calculations. The calculations for future value models are implemented in the assessment engine 26 as user exit score models. The present value model uses a number of predefined parameters that will have different values for each financial institution and may change from time to time. To ensure maximum flexibility, the present value model parameters are established in the assessment engine 26 before an actual customer assessment is first executed to generate the relationship value tag parameters in the form of a record layout. The parameters are written to a file, where they are retrieved by the assessment driver 32. The relationship value tag parameters are implemented in the assessment engine 26 user interface. The relationship value tag tables are loaded to a mainframe computer where they are prepared for subsequent execution of the assessment driver 32, col. 17, lines 9-36).
As per claim 7, Mayr 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 on-line assessment engine is invoked to generate the tags and their associated treatment codes and strategies. The treatment codes and tags are written to the staged treatment action file, where they are accessed by the acquisition system. The nightly assessment batch process consolidates the staged treatment action file with the customer treatment actions and updates the customer database. The on-line assessment engine is invoked to perform application decisioning, and the result of the acquisition evaluation is returned to the acquisition system, col. 12, lines 26-48).
As per claim 9, Mayr 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. the file marked or tagged with the assessed value of the customer and associated customer treatment action is accessed in an on-line environment, for example, by a tags update driver or connected to one or more databases, including for example, the customer information database and a customer relationship value tags database. The tags driver transmits the information about the assessed value and associated customer treatment action to either or both of these databases. The customer relationship value database is automatically accessed by a customer acquisition system connected to the database to retrieve the information about the assessed value of the customer and associated customer treatment action, for example, in response to entering a request for a financial institution product, such as a loan product, for the customer on the customer acquisition system by a financial institution customer representative at a terminal connected to the acquisition system, col. 4, lines 40-57).
As per claim 11, Mayr 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. Customer information database 2 is the collection of financial institution customer information stored in a computer storage medium. A computerized assessment system 4 processes customer information from database 2, assesses the customer's value to the financial institution, and assigns appropriate treatment actions, col. 13, lines 26-50); 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. Other financial institution computer systems 6 process and load customer value data from the assessment system into appropriate customer value database files. Reports relating to information concerning customer assessments and associated treatment actions are generated for financial institution representatives by print servers 8 and accessed by financial institution representatives, for example, on a financial institution computer terminal 10. The information concerning customer assessment and associated treatment actions is used by other computer systems of the financial institution, or by representatives of the financial institution interacting with a customer 12, for financial institution activities such as marketing 14, acquisition 16, servicing 18 and collections 20, col. 13, lines 26-50).
As per claim 12, Mayr 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. In an embodiment of the present invention, the calculation of the customer present value is done by the assessment driver 32 using data from the customer information database 24, a customer future value history file, an account present value history file, and an assessment engine 26 parameter table. The assessment driver 32 writes the customer present value to an assessment engine 26 extract file that is the input to the assessment engine 26. For calculation of the customer future value, all the customer-level variables used to calculate the future value, are calculated by the assessment driver 32. The assessment driver 32 writes these values to the assessment engine 26 extract file that the assessment engine 26 uses as an input to a future value models calculations. The calculations for future value models are implemented in the assessment engine 26 as user exit score models, col. 17, lines 9-36); and
inputting the input data into the calculation engine for processing using the set of custom attributes (i.e. The present value model uses a number of predefined parameters that will have different values for each financial institution and may change from time to time. To ensure maximum flexibility, the present value model parameters are established in the assessment engine 26 before an actual customer assessment is first executed to generate the relationship value tag parameters in the form of a record layout. The parameters are written to a file, where they are retrieved by the assessment driver 32. The relationship value tag parameters are implemented in the assessment engine 26 user interface. The relationship value tag tables are loaded to a mainframe computer where they are prepared for subsequent execution of the assessment driver 32, col. 17, lines 9-36).
As to claims 14, 21, Mayr teaches the computer-implemented method of claim 13 further comprising 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. the financial institution tracks the performance of each new value tags-based decision strategy, col. 9, lines 44-55; The treatment actions are then passed to the on-line assessment engine, where they are used in conjunction with account-based decision strategies. After a loan is decisioned, the system writes both the customer treatment actions and the final decision to the staged treatment action file, col. 11, lines 39-54; These tables, along with other decisioning strategies, are then uploaded to the mainframe computer for use by the assessment engine, col. 12, line 61 to col. 13, line 25; By using decision trees and matrices, the decision engine allows the deployment of numerous decisioning methods. For example, in final decisioning, the override tolerance of different score cutoffs are assigned for different customer segments. Alternatively, an “override” indicator is assigned for the very high value customers, so that the turndowns resulting from pre-existing financial institution decisioning processes are overridden, col. 7, lines 7-37; In an embodiment of the present invention, relationship value tag-based approved and turndown applications are written to the customer acquisition decision database 68 ... The state processor logic handles the customer acquisition decision record. It is added or updated whenever a set-up activity code has been entered or generated and an indicator is in the “yes” mode, col. 33, line 46 to col. 34, line 8).
As per claim 15, Mayr 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. for every future value score model, there are a set of predefined continuous and categorical variables and a predefined model offset. For each model variable, there are predefined values and coefficients ... The user exits follow the calculation logic as follows: as shown at S13 and S14 in FIG. 4, first, multiply the continuous variable values with the corresponding continuous variable coefficients; second, sum up the results; and third, sum the resulting sum with the values returned by the categorical attributes, col. 22, line 64 to col. 23, line 19).
As per claim 17, Mayr 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. during the data extraction process, the necessary data elements are retrieved from tables in the customer information database 24. Customer information database 24 stores customer demographic, financial, application, and transaction data on existing financial institution customers. All customers are retrieved for relationship value tag processing. On a periodic basis, the customer information database 24 is updated with data from financial institution servicing systems ... The customer relationship assessment engine 26 is invoked to evaluate the customer records prepared by the assessment
driver 32, col. 15, lines 29-53).
As per claim 19, Mayr 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. In an embodiment of the present invention, for every future value score model, there are a set of predefined continuous and categorical variables and a predefined model offset. For each model variable, there are predefined values and coefficients ... A different user exit is written for each of the predetermined number of future value models. The user exits follow the calculation logic as follows: as shown at S13 and S14 in FIG. 4, first, multiply the continuous variable values with the corresponding continuous variable coefficients; second, sum up the results; and third, sum the resulting sum with the values returned by the categorical attributes, col. 22, line 64 to col. 23, line 19);
embed the first attribute processing agent in the first computer node (i.e. In an embodiment of the present invention, the tags driver is triggered by the assessment engine. The main objective of the tags driver is to format the assessment engine instructions which are written to the customer database. The tags driver formats the instruction from the assessment engine and writes the appropriate information to the customer database ... Some of the data elements include customer current value calculated for the present value, which is stored in one field, with previous values maintained in other fields, as well as customer future value, which is the recently derived expected value to the financial institution for a predetermined number of
months in the future, with previous values maintained in other fields, col. 11, lines 20--38).
Claims 4, 10, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mayr et al. (US Pat No. 7,376,603), in view of BARBER et al. (US Pub No. 2017/0200222), and further in view of Bryan et al. (US Pub No. 2014/0280905), as applied to claims above, and further in view of Bowman-Amuah et al. (US Pat No. 6,601,234).
As to claims 4, 10, 18, Mayr 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. On a periodic basis, the customer information database 24 is updated with data from financial institution servicing systems ... The number of customers processed by the assessment driver 32 is controlled by user-specified parameters on predefined relationship value tag parameter tables. The customer relationship assessment engine 26 is invoked to evaluate the customer records prepared by the assessment driver 32, col. 15, lines 29-53; Value tags are used to directly override loan criteria such as risk score and line assignment, col. 33, lines 13-45).
Mayr, BARBER, Bryan do not seem to specifically teach "a computer executable function comprising one or more data filters".
Bowman-Amuah teaches this limitation (i.e. connectors are utilized for connecting at least two filters each having a processing step for creating a process. One of the filters is an input filter of the process and another of the filters is an output filter of the process. Connectors are also used in operation 5912 for connecting input and output filters of different processes for forming a scalable system, col. 196, lines 46-52).
It would have been obvious to one of ordinary skill of the art having the teaching of Mayr, BARBER, Bryan, Bowman-Amuah before the effective filing date of the claimed invention to modify the system of Mayr, BARBER, Bryan to include the limitations as taught by Bowman-Amuah. One of ordinary skill in the art would be motivated to make this combination in order to control access to data of a business object via an attribute dictionary in view of Bowman-Amuah (col. 2, lines 15-33), as doing so would give the added benefit of connecting input and output filters of different processes for forming a scalable system as taught by Bowman-Amuah (col. 196, lines 46-52).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Girulat et al. (US Pub. 2009/0089190) – discloses a method for monitoring financial activities of consumers.
Kapczynsk et al. (US Pat. 10,269,065) discloses a system for processing bill payments from a consumer to one or more creditors may provide the consumer with a credit report and options to make payments on tradelines present on the credit report.
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