DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed June 8, 2026.
Claims 1, 8, 15 are currently amended. Claims 7, 14, 20 are currently cancelled.
Claims 1-6, 8-13, 15-19 are currently pending.
Claims 1-6, 8-13, 15-19 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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-6, 8-10, 12-13, 15-17, 19 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) in view of Dai (English translation of WO 2016078423 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.
consuming, by a promotion service module, all debit transactions from the pricing orchestrator module for promotion qualification; {[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.”}
retrieving, by the promotion service module, account-level promotion identifiers and promotion rules defined by product teams; {[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 [account level] 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 [promotion 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.”}
evaluating, by the promotion service module, each debit transaction using the retrieved promotion rules and at least one of transaction-level data, account-level data, customer-level data, or product-level data to determine eligibility for a promotional offer or a customer- requested offer; {[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 [promotional 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 [evaluating] 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.”}
in response to determining eligibility, creating, by the promotion service module, a promotion record comprising (i) a transaction key, (ii) applied promotion rule identifiers, and (iii) full promotion data, and storing the promotion record in a promotional database that serves as a system of record (SOR) for promotion data; {[0017] “Each incoming transaction 34 includes transaction data 42 which identifies the customer account and details of the particular transaction [transaction key]. The transaction level processor 32 analyzes the transaction data 42 using balance rules 44 retrieved from a balance rules database 46 associated with the customer's account 40. The transaction level processor 32 then allocates all or a portion of the incoming transaction 34 to a particular balance segment 36 associated with the applicable balance rule 44.”; [0033] “If the transaction conforms to the limitations, the processor 32 updates the Masterfile [storing] 38 associated with the account number 60 by updating the balance of the Promo B balance segment 90.”}
publishing, by the promotion service module, to the pricing orchestrator module a qualification response including (i) a promotion-qualified indicator and (ii) associated promotion data retrieved from the promotional database; {[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, by the pricing orchestrator module, the corresponding transaction to include the promotion-qualified indicator and associated promotion data; and {[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.”}
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”.
Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell does not teach, however Dai teaches:
wherein the pricing orchestrator module tracks execution status of the promotion service module and, upon failure after a predetermined number of retries, triggers a rollback using an audit module and a status tracker database. {Page 3 “When the transaction processing center server determines that the operation data is active, it determines whether the transaction operation has timed out, or whether the number of retries of the transaction operation exceeds a preset threshold number of retries, and if the timeout expires or exceeds the retries threshold, Perform a distributed rollback operation.”; Page 11 “The database monitoring module 208 uses the database log to find the transaction block in the log through the GTID and the time point, and then finds the SQL statement corresponding to the transaction operation and the before and after values of the operation data. Step 405, after the database monitoring module 208 finds the SQL statement and the before and after values of the operation data according to the GTID and the time point, it is necessary to construct a reverse SQL statement. After the reverse [rollback] SQL statement is constructed, the database monitoring module 208 directly issues the reverse SQL statement execution.”}
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 retries and rollback-in-case-of-failure of Dai to the transaction processing system of Behrenbrinker in view of Applicant Admitted Prior Art in view of Poilil in view of Farrell in order to improve processing reliability and maintain data consistency in the event of failures (Dai Page 6).
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.”}
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”.
Response to Arguments
Specification
The objection to the specification is withdrawn due to the amendment.
35 USC § 103
Applicant argues:
Behrenbrinker fails to teach or suggest: a promotion service module distinct from other processing components, a pricing orchestrator module coordinating multiple downstream services, or any inter-module communication involving publishing of responses between services. Rather, Behrenbrinker performs all processing within a single processor without any decomposition into discrete service modules. Accordingly, the cited reference does not disclose, and does not render obvious, the claimed distributed, service-oriented architecture.
However, this argument goes beyond the claims. Claim 8 (system claim) claims “a processor” which performs the recited functions. The recitations of various modules are merely logical labels assigned to the different parts of software running on a processor. The claims do not require a distributed, service-oriented architecture. The claimed inter-module communication is merely taking the output of one step and using it in the next step, since the modules are disclosed as logical divisions of software running on a processor.
Applicant further argues:
Behrenbrinker fails to teach or suggest: a separate promotional database, a promotion-specific record structure, or storage of promotion data, rule identifiers, or transaction-level promotion metadata. The Examiner's reliance on storage within a masterfile is misplaced. Allocation of a transaction to a balance segment is not equivalent to generating and persisting a structured promotion record containing transaction-specific promotion data in a dedicated system-of-record database.
Behrenbrinker teaches applying promotional rules to transaction to determine if they qualify and saving the results in a file. The term “database” is given its broadest reasonable interpretation as any data storage.
Applicant further argues:
Behrenbrinker also fails to teach or suggest publishing a qualification response to an orchestrator. Amended claim 1 (and similarly, claims 8 and 15) further recites: publishing, by accessing the promotional database, a qualification response (including a promotion-qualified indicator) back to the pricing orchestrator module. Behrenbrinker does not disclose any such operation. Instead, Behrenbrinker describes internal processing followed by updating account data in a masterfile. Behrenbrinker fails to teach or suggest: "publishing" of results between modules, returning a qualification response to a coordinating component, or any orchestrator- driven workflow. The Examiner's characterization of masterfile updates as "publishing" is unsupported by the reference and constitutes an overly broad and unreasonable interpretation of the claimed limitation.
See response above regarding modules. The claimed inter-module communication is merely taking the output of one step and using it in the next step, since the modules are disclosed as logical divisions of software running on a processor.
Applicant further argues:
Behrenbrinker is entirely silent as to: execution status tracking, retry mechanisms, failure handling, or rollback processing. These limitations are directed to reliability and coordination in a distributed processing environment, which are neither disclosed nor suggested in Behrenbrinker's single-processor system.
This argument is directed towards newly added subject-matter. A new reference, Dai, has been added to the rejection which teaches the claimed failure handling.
Applicant further argues:
Behrenbrinker does not teach the claimed use of multi-level data inputs. Amended claim 1 (and similarly, claims 8 and 15) further recites evaluating promotion eligibility using multiple data domains, including transaction-level, account-level, customer-level, and product-level data. Behrenbrinker relies on predefined rule variables associated with balance rules and transaction data. See [0033]. However, Behrenbrinker fails to teach or suggest: a framework for dynamically consuming and integrating heterogeneous data sources across multiple levels, or evaluation using customer-level or product-level attributes as claimed.
However, Behrenbrinker teaches:
[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.
[0025] The balance rule database 46 includes one or a plurality of balance rules 44 that may be applied to each incoming transaction 34. Each of the balance rules 44 include one or a plurality of variables 100 corresponding to the transaction data 42, which govern the allocation of the incoming transaction 34 to a balance segment 36. Referring to FIG. 2, where Balance Rule Z is shown retrieved within transaction level processor 32, typical variables 100 include, but are not limited to, start date 102, end date 104, MCC 106, transaction amount 108, transaction type 110, merchant name 112, and merchant identification number 114. The variables 100 may be values 116 or ranges 118, and are used to either include 120 or exclude 122 the incoming transaction 34 from being associated with a given balance rule 44. The particular variables 100, values 116, and ranges 118 associated with each balance rule 44, are preferably defined by the card issuer, or by the card issuer in conjunction with a merchant or other promotion sponsor.
Behrenbrinker teaches assigning promotional rules to accounts, where the promotional rules are then applied to that account’s transactions to determine whether or not a transaction qualifies for the promotion. The claim terms “transaction-level, account-level, customer-level, and product-level data” are non-functional descriptions of data. The function of applying rules to determine promotion qualification is taught by Behrenbrinker.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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 at (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
Prosecution Insights