DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s original application filed July 26, 2024.
Claims 1-20 are currently pending.
Claims 1-20 have been examined.
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 .
Specification
The disclosure is objected to because of the following informalities:
Paragraph [0005] contains mismatched parentheses. There are two more closing parentheses than opening parentheses.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claims 1-3, 5-10, 12-17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Behrenbrinker (US 20020062279 A1) in view of Applicant Admitted Prior Art in view of Poilil (US 20210358027 A1) in view of Farrell (US 20220076231 A1).
Regarding claims 1, 8, 15
Behrenbrinker teaches:
A method for transaction level pricing and balance management by utilizing one or more processors along with allocated memory, the method comprising: {[0009] “The systems and methods of the present invention include a transaction level processor, the processor operable for analyzing an incoming credit card transaction and allocating the transaction into one of a plurality of balance segments.”}
receiving a plurality of transactions associated with a card; {Abstract “Systems and methods for processing credit card transactions […] A system receives incoming transaction data by way of a conventional transaction system.”}
publishing the […] transactions onto a pricing orchestrator module for executing a transaction level pricing and balance management algorithm; {Fig. 2 32}
PNG
media_image1.png
655
535
media_image1.png
Greyscale
consuming the […] transactions; {Abstract “Systems and methods for processing credit card transactions”}
identifying type of each transaction from the consumed enriched transactions by applying predefined rules; and {[0009] “Thus, the credit card systems and methods enable the application of differing terms and conditions to credit card transactions based on the type of transaction determined [identifying] from the transaction data.”}
executing, for each type of transaction, the transaction level pricing and balance management algorithm to perform the following operations at transaction level {[0009] “The systems and methods of the present invention include a transaction level processor, the processor operable for analyzing an incoming credit card transaction and allocating the transaction into one of a plurality of balance segments.”} at the time of transaction posting instead of balance level calculations at cycle time {[0031] “It should be noted that the various actions of the above-described transaction processing method may be substantially performed over a short time duration or in real-time [time of transaction posting]”}: fee calculations {[0009] “Once an incoming transaction is directed into an appropriate balance segment, one of a plurality of terms and conditions associated with the balance segment allows balance variables, such as pricing, fee structure, payment, terms, etc., to be individually set for each balance segment.”}, interest charge calculations {[0034] “The multi-dimensional balance structure allows financial institutions to provide customers with special promotions, such as reduced interest rates, increased credit lines, reduced minimum payments, and reduced fees for credit card transactions at a particular merchant or for transactions of a particular nature, such as Internet purchases, automobile-related purchases, etc.”}, payment allocations {[0030] “The customer payments, accounted for as a credit toward the account, may designate portions of the payment to be allocated to any of the balance segments”}, […] balance management at transaction level {[0030] “The customer payments, accounted for as a credit toward the account, may designate portions of the payment to be allocated to any of the balance segments”}, […],
and remove account processing at accumulated balance level.
This is interpreted as a negative limitation. Behrenbrinker teaches processing at the transaction level, so each transaction can be assigned its own pricing, interest rate, etc., and transactions can be processed as granularly as desired. Behrenbrinker therefore teaches not processing at accumulated balance level.
Behrenbrinker does not teach, however Applicant Admitted Prior Art teaches:
payment reversal processing, {Specification [0005] “For example, conventional approaches/tools for calculating interests may include […] reversals”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to include the reversals of Applicant Admitted Prior Art because it is a well-known feature of credit card transaction systems, and Behrenbrinker teaches a credit card transaction processing system.
Behrenbrinker in view of Applicant Admitted Prior Art does not teach, however Poilil teaches:
service customers with intra cycle financial estimates {[0002] “In an electronic payment processing network, a financial institution may receive transaction information corresponding to a variety of recurring payment accounts from a consumer, such as a credit card account [...] The financial institution may provide a statement for an account balance and interest charges in a billing cycle. The financial institutions may notify their customers of the interest charges after they have accrued. However, customers in the conventional systems may lack insights into the projected interest charges before making a purchase or a payment, thereby limiting their ability to view their financial obligations in real-time and make informed decisions to minimize interest payments.”; [0015] “The electronic payment system may generate a calendar view that displays a daily [intra cycle] balance and a daily interest charge for each of the recurring payment accounts. In response to a projected payment amount provided by a user to be allocated to a specific recurring payment account, the electronic payment system may dynamically generate a projected calendar view in real-time with a projected daily balance and a projected daily interest charge for the specific recurring payment account.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add to the system of Behrenbrinker in view of Applicant Admitted Prior Art the daily balance and daily interest charge because it would provide the advantage to their customers that they can “make informed decisions to minimize interest payments.”
Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil does not teach the following bolded language, however Farrell teaches:
enriching the plurality of transactions by consuming external transaction data associated with each transaction, populating preconfigured internal attributes data, and outputting enriched transactions; {[0032] “According to one embodiment of the invention, a system and method are provided to cleanse, standardize and enrich the transaction string that may originate from a point of sale (POS) device to improve contextual information of the transaction.”; [0039] “The merchant tagging process requires two primary data sets as input: transaction data and a truth set. Transaction data can be obtained from an internal source such as an integrated consumer data warehouse (ICDW) or another source such as an external payment network source.”; [0091] “This derived data can thus be used for improved analytics conducted by the Bank.”}
publishing the enriched transactions onto a pricing orchestrator module for executing a transaction level pricing and balance management algorithm; {[0032] “According to one embodiment of the invention, a system and method are provided to cleanse, standardize and enrich the transaction string that may originate from a point of sale (POS) device to improve contextual information of the transaction.”}
consuming the enriched transactions; {[0032] “According to one embodiment of the invention, a system and method are provided to cleanse, standardize and enrich the transaction string that may originate from a point of sale (POS) device to improve contextual information of the transaction.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the transaction enrichment of Farrell to the credit card transaction processing system of Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil because it would provide the advantage of “improv[ing] contextual information of the transaction” allowing for “improved analytics”.
Regarding claims 2, 9, 16
Behrenbrinker teaches:
The method according to claim 1, wherein the card is a credit card or a debit card. {[0019] “The incoming transaction 34 is an authorized transaction performed utilizing a financial account, such as a credit, debit, securities, or like account. For example, the transaction may be performed utilizing a card from a card issuer”}
Regarding claims 3, 10, 17
Behrenbrinker teaches:
The method according to claim 1, wherein the accumulated balance level includes purchase, cash, and promotions.
This limitation is further describing processing that is claimed as being removed. It is taught by Behrenbrinker for the same reasons as given in claim 1.
Regarding claims 5, 12, 19
Behrenbrinker teaches:
The method according to claim 1, further comprising:
storing all transactions with corresponding pricing task execution status onto a database. {[0034] “The system then uses predetermined balance rules to decide the appropriate balance segment within the customer's masterfile to store the transaction data.”}
Regarding claims 6, 13
Behrenbrinker teaches:
The method according to claim 1, further comprising:
storing all transaction level updates onto a staging database. {[0034] “The system then uses predetermined balance rules to decide the appropriate balance segment within the customer's masterfile to store the transaction data.”}
Regarding claims 7, 14, 20
Behrenbrinker teaches:
The method according to claim 1, further comprising:
consuming all debits for promotion qualifications; {[0008] “In order to promote new goods and services, credit card issuers have a need to keep select credit card transactions in separate balances within a single customer account. For example, credit card issuers may offer special promotions, such as reduced interest rates, increased credit lines, reduced fees, and other special offers for credit card transactions made with a particular merchant, or, for transactions of a particular type, such as Internet purchases, automobile-related purchases, etc. Further, the present invention allows credit card issuers to monitor and view customer expenditure trends, and provide special promotions with multiple merchants or other interested parties.”}
applying preconfigured promotional rules; {[0023] “The promotional, or special balance segments 88 and 90, are predefined by the card issuer and may be associated with the customer's account 40 by the customer at the time of opening the account, or, at any later time. The promotional balance segments 88 and 90 are associated with given balance rules 44 and terms and conditions 48, thereby allowing the controller of the customer account, typically the card issuer or any other party associated with the card issuer, to offer the customer incentives for performing particular transactions.”}
consuming account level promotion identifiers to be used for the promotion qualifications; {[0033] “Continuing with the above example, if the transaction processor 32 determines that balance segment file 148 is active, it retrieves Balance Rule Z 44' (shown inside transaction level processor 32) from the plurality of balance rules 44 stored in balance rule database 46. According to balance segment file 148, Balance Rule Z 44' is associated with Promo Balance B balance segment 90 and includes a number of variables 100 that are compared to the transaction data 42 of an incoming transaction 34, to determine if the incoming transaction should be allocated to the Promo B balance segment 90. The variables 100 require: the purchase be made between Oct. 1, 1999 and Dec. 31, 2001; all MCC are considered; a transaction amount greater than $50.00; the transaction type needs to be a purchase; the transaction needs to be performed at the merchant MACY'S. […] If the transaction conforms to the limitations, the processor 32 updates the masterfile 38 associated with the account number 60 by updating the balance of the Promo B balance segment 90. The processor 32 may then identify other active balance segment files 130 and perform a similar analysis to determine if the incoming transaction 34 may be allocated to other balance segments 36.”}
evaluating whether the transaction is eligible for any promotional offer or customer requested offer based on applying preconfigured promotional rules; {[0033] “Continuing with the above example, if the transaction processor 32 determines that balance segment file 148 is active, it retrieves Balance Rule Z 44' (shown inside transaction level processor 32) from the plurality of balance rules 44 stored in balance rule database 46. According to balance segment file 148, Balance Rule Z 44' is associated with Promo Balance B balance segment 90 and includes a number of variables 100 that are compared to the transaction data 42 of an incoming transaction 34, to determine if the incoming transaction should be allocated to the Promo B balance segment 90. The variables 100 require: the purchase be made between Oct. 1, 1999 and Dec. 31, 2001; all MCC are considered; a transaction amount greater than $50.00; the transaction type needs to be a purchase; the transaction needs to be performed at the merchant MACY'S. […] If the transaction conforms to the limitations, the processor 32 updates the masterfile 38 associated with the account number 60 by updating the balance of the Promo B balance segment 90. The processor 32 may then identify other active balance segment files 130 and perform a similar analysis to determine if the incoming transaction 34 may be allocated to other balance segments 36.”}
creating a record of promotion data associated with the promotional offer or the customer requested offer along with a transaction key onto a promotional database; {[0016] “In one embodiment of the present invention, a transaction level processor receives incoming transaction data and identifies the customer account associated with the transaction. Using the transaction data, the transaction processor accesses a table of predetermined balance rules associated with the customer account and balance segment. Using the balance rules, the transaction level processor compares the transaction data to each balance rule, and stores each transaction in the appropriate balance segment in a masterfile.”}
publishing, by accessing the promotional database, a response indicating promotion qualified “Yes” or “No” back to the pricing orchestrator module; and {[0033] “Continuing with the above example, if the transaction processor 32 determines that balance segment file 148 is active, it retrieves Balance Rule Z 44' (shown inside transaction level processor 32) from the plurality of balance rules 44 stored in balance rule database 46. According to balance segment file 148, Balance Rule Z 44' is associated with Promo Balance B balance segment 90 and includes a number of variables 100 that are compared to the transaction data 42 of an incoming transaction 34, to determine if the incoming transaction should be allocated to the Promo B balance segment 90. The variables 100 require: the purchase be made between Oct. 1, 1999 and Dec. 31, 2001; all MCC are considered; a transaction amount greater than $50.00; the transaction type needs to be a purchase; the transaction needs to be performed at the merchant MACY'S. […] If the transaction conforms to the limitations, the processor 32 updates the Masterfile [publishing] 38 associated with the account number 60 by updating the balance of the Promo B balance segment 90. The processor 32 may then identify other active balance segment files 130 and perform a similar analysis to determine if the incoming transaction 34 may be allocated to other balance segments 36.”}
updating corresponding transaction among the plurality of transactions in correspondence with publishing the response. {[0016] “In one embodiment of the present invention, a transaction level processor receives incoming transaction data and identifies the customer account associated with the transaction. Using the transaction data, the transaction processor accesses a table of predetermined balance rules associated with the customer account and balance segment. Using the balance rules, the transaction level processor compares the transaction data to each balance rule, and stores [updating] each transaction in the appropriate balance segment in a masterfile.”}
Claims 4, 11, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell as applied to claims 1, 8, 15 above, and further in view of Wikipedia “ISO 8583” and further in view of Warren (US 20030101131 A1).
Regarding claims 4, 11, 18
Behrenbrinker teaches:
The method according to claim 1, wherein in identifying type of each transaction, the method further comprising:
identifying one or more of the following transactions: {[0009] “Thus, the credit card systems and methods enable the application of differing terms and conditions to credit card transactions based on the type of transaction determined [identifying] from the transaction data.”} credit card transaction; debit card transaction; {[0019] “The incoming transaction 34 is an authorized transaction performed utilizing a financial account, such as a credit, debit, securities, or like account. For example, the transaction may be performed utilizing a card from a card issuer, or utilizing an electronic certificate or other electronic representation of an account. The incoming transaction 34 includes transaction data 42, which is information sent with all standard transactions across the related networks. The details of the formatting of the incoming transaction and of the data included in a standard incoming transaction may be found in the ISO standard ISO8583 (which is readily available from the International Standards Organization, Visa.RTM., and MasterCard.RTM. associations) or other applicable transaction formats. Typical transaction data 42 may include, but is not limited to, account number 60, sales date 62, transaction amount 64, transaction type 66, Merchant Category Code (MCC) 68, merchant name 70, and merchant identification number 72 associated with the transaction.”}
Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell does not teach, however ISO 8583 teaches:
customer disputing a transaction; […]; payment transaction; and reversal transaction. {page 2 “Cardholder-originated transactions include purchase [payment], withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.”; page 13 “Customer dispute”}
Behrenbrinker states [0019] “The details of the formatting of the incoming transaction and of the data included in a standard incoming transaction may be found in the ISO standard ISO8583” and ISO 8583 gives the details of the standard. Therefore, the references themselves suggest the combination.
Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell in view of ISO 8583 does not teach, however Warren teaches:
customer requesting a change on annual percentage rate; {Abstract “Exemplary embodiments of the invention allow the user to specify various preferred terms such as cost (e.g., APR and annual fee)”; [0047] “In response to receiving the account number, the server retrieves the relevant account information, such as account terms, from its database 102. The account terms are then sent to the user in step 538. At this point, the user has the option to modify the existing account.”; [0003] “The account holder typically has no opportunity to negotiate or modify the terms of the account, but rather must accept the terms of an account as offered by the financial institution. If the account holder is dissatisfied with one or more of the terms, there is no effective means of modifying those terms.”}
Warren teaches a user requesting to modify account terms, which include APR. Because ISO 8583 teaches the message types including messages “for… other administrative purposes”, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell in view of ISO 8583 to include a message type to request to modify account APR, because doing so would have the advantage of preventing an account holder from becoming “dissatisfied with one more of the terms”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed in the enclosed PTO-892.
Muzik (US 20220229833 A1) teaches:
[0109] “For example, for data consistency, the ETUM 406 may be configured in a manner such that transaction level data tor assisted and unassisted servicing may only be available via the customer/product account transaction utility, thereby ensuring that consumers (and advisors) are always getting a consistent view of the data from a single source. Read access to transaction level data and enrichments outside of the customer/product account transaction utility may not be permitted—applications needing transaction data may get that data either through the consumption of well-defined APIs and/or the subscription to transaction level and enrichment data change events that are published from the customer/product account transaction utility.”
Gromada (US 20180225683 A1) teaches:
[0050] “In one embodiment, the transactions may be enriched with additional data, such as the time of day/month/year when the transaction occurred, environmental conditions (e.g., temperature, weather, etc.), the geographical location of the transaction, the individual's status (e.g., work, vacation, etc.), etc. In one embodiment, enrichment data may be received from external sources, such as weather sources, the individual's calendar, etc.”
Hamilton (US 8533111 B1) teaches:
Column 4 Line 59 “(12) Referring to FIG. 1, there is shown a block diagram illustrating an exemplary credit account 100 for providing promotional pricing according to an embodiment of the present invention. The exemplary account 100 may comprise a number of buckets each of which may have a separate balance, APR, and other terms.”
Hucal (US 5933817 A) teaches:
Abstract “A method and a system for operating a revolving credit program utilizing a table of tiered interest rates in which one of the interest rates is applied as a finance charge to a remaining outstanding balance of an account depending upon the percentage that payments made during a billing cycle comprise of an account parameter, such as the outstanding balance, a highest balance or a beginning balance. In the preferred embodiment the applied interest rate is determined by the percentage the outstanding balance is reduced by payments on the balance during a billing cycle. Also in a preferred embodiment of the invention, the tiered interest rate table is structured to apply progressively reduced interest rates to outstanding balances reduced by progressively greater payment percentages from the previous billing cycle, thereby encouraging a credit customer to make larger payments and pay down the outstanding balance faster. Also in the preferred embodiment, the system calculates and displays the minimum payments necessary to reduce the outstanding balance to meet each tier of the interest rate table.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698