DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/19/2026 has been entered.
Response to Amendment
Claims 1-40, 48, 58, and 62 are canceled.
Claims 41 and 51 are currently amended.
Claims 41-47, 49-57, and 59-61 are currently pending examination.
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 41-47, 49-57, and 59-61 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 41-47, 49-57, and 59-62 is/are directed towards a statutory category (i.e., a process, machine, manufacture, or composition of matter) (Step 1, Yes).
Step 2A Prong One:
Claim 41 recites (additional elements underlined):
A computer-implemented system, comprising: a non-transitory computer-readable medium configured to store instructions; and
at least one processor configured to execute the instructions to perform operations comprising:
receiving a transaction request from a financial transaction system,
wherein:
the transaction request includes a customer identifier and a transaction amount; and
the customer identifier is a substitute value for a customer loyalty account number, wherein the customer identifier is formatted to resemble a payment card number, to facilitate routing the transaction request via a transaction processing network;
analyzing the customer identifier to identify a loyalty account number associated with a customer;
determining a point balance in a loyalty account associated with the loyalty account number;
determining a loyalty point exchange rate based on the transaction amount, wherein:
the loyalty point exchange rate varies based on a tiered structure of the transaction amount;
a first exchange rate is applied to a first portion of the transaction amount below a threshold; and
a second exchange rate is applied to a second portion of the transaction amount above the threshold;
calculating a loyalty point equivalence for a cash value of the transaction amount based on the determined loyalty point exchange rate;
determining whether the loyalty account has sufficient points to complete the transaction, by comparing the calculated loyalty point equivalence with the determined point balance;
on a condition that the loyalty account has sufficient points to complete the transaction:
sending a transaction approval to the financial transaction system; and
updating a point balance in the loyalty account based on the calculated loyalty point equivalence.
Under the broadest reasonable interpretation, the limitations outlined above that describe or set forth the abstract idea, cover performance of the limitations in the mind but for the recitation of generic computer(s) and/or generic computer component(s). That is, other than reciting the additional elements identified below, nothing in the claim precludes the limitations from practically being performed in the mind. These limitations are considered a mental process because the limitations include an observation, evaluation, judgment, and/or opinion. These limitations are also similar to “collecting information, analyzing it, and displaying certain results of the collection and analysis” and/or “collecting and comparing known information” which were determined to be mental processes in MPEP 2106.04(a)(2)(III)(A). The Examiner notes that “[c]laims can recite a mental process even if they are claimed as being performed on a computer” (see MPEP 2106.04(a)(2)(III)(C)). The mere nominal recitation of the additional elements identified above do not take the claims out of the mental process grouping. Therefore, the claim recite a mental process (Step 2A Prong One, Yes).
The limitations outlined above also describe or set forth a commercial interaction. Commercial interactions fall within the certain method of organizing human activity enumerated grouping of abstract ideas. The limitations outlined above also describe or set forth a fundamental economic principle or practice because commercial interactions are related to commerce and economy. The limitations outlined above also describe or set forth advertising, marketing or sales activities or behaviors, and/or business relations. The limitations outlined above also describe or set forth managing personal behavior or relationships or interactions between people (e.g., between a customer and a merchant). Therefore, the claim recites a certain method of organizing human activity (Step 2A Prong One, Yes).
The limitations outlined above that describe or set forth the abstract idea are also considered mathematical concepts at least because the above limitations determine a point balance in a loyalty account associated with the account number, determine a loyalty point exchange rate based on the transaction type; calculate a loyalty point equivalence for a cash value of the transaction amount based on the determined loyalty point exchange rate; determine whether the loyalty account has sufficient points to complete the transactions, by comparing the calculated loyalty point equivalence with the determined point balance, and update a point balance in the loyalty account based on the calculated loyalty point equivalence. These limitations are similar to “organizing information and manipulating information through mathematical correlations” which was determined to be a mathematical concept in MPEP 2106.04(a)(2)(II). Therefore, the claim recites a mathematical concept (Step 2A Prong One, Yes).
Step 2A Prong Two:
In Step 2A Prong Two, the additional element(s) outlined above are recited at a high level of generality, and under the broadest reasonable interpretation, are generic computer(s) and/or generic computer component(s) that perform generic computer functions. The additional element(s) are merely used as tools, in their ordinary capacity, to perform the abstract idea. The additional element(s) amount adding the words “apply it” with the judicial exception. Merely implementing an abstract idea on generic computer(s) and/or generic computer component(s) does not integrate the judicial exception similar to how the recitation of the computer in the claim in Alice amounted to mere instructions to apply the abstract idea of intermediated settlement on a generic computer. The Examiner notes that “the use of generic computer elements like a microprocessor or user interface do not alone transform an otherwise abstract idea into patent eligible subject matter" (see pp 10-11 of FairWarning IP, LLC. v. Iatric Systems, Inc. (Fed. Cir. 2016)). The additional elements also amount to generally linking the use of the abstract idea to a particular technological environment or field of use (e.g., in a computer environment). The courts have found that simply limiting the use of the abstract idea to a particular environment does not integrate the judicial exception into a practical application. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. There is no indication that the combination of elements improves the functioning of a computer, improves any other technology or technical field, applies or uses the judicial exception to effect a particular treatment or prophylaxis for disease or medical condition, applies the judicial exception with, or by use of a particular machine, effects a transformation or reduction of a particular article to a different state or thing, or applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claims as a whole is more than a drafting effort designed to monopolize the exception. Their collective functions merely provide generic computer implementation (Step 2A Prong Two, No).
Step 2B:
In Step 2B, the additional elements also do not amount to significantly more for the same reasons set forth with respect to Step 2A Prong Two. The Examiner notes that revised Step 2A Prong Two overlaps with Step 2B, and thus, many of the considerations need not be reevaluated in Step 2B because the answer will be the same. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. Their collective functions merely provide generic computer implementation (Step 2B, No).
Claims 42-47, 49-50, and 61 recite further limitations that also fall within the same abstract ideas identified above with respect to claim 41 (i.e., mathematical concepts, certain methods of organizing human activities and/or mental processes).
Claim 42 recites the additional elements of “from the financial transaction system via an application programming interface”. Claim 43 recites the additional element of “detokenization”. Claim 44 recites the additional elements of “encrypted by the system” and “decrypting.” Claim 47 recites the additional elements of “is formatted to conform to a programming structure”. Claims 49-50 recite the additional element of “device”. However, these additional elements also do not integrate the judicial exception into a practical application or amount to significantly more because they amount to adding the words “apply it” with the judicial exception, mere instructions to implement the idea on a computer, merely using a computer as a tool to perform an abstract idea, and generally linking the use of the judicial exception to a particular technological environment or field of use.
Claims 45-46 and 61 do not recite any other additional elements other than those recited in claim 41. Therefore, for the same reasons explained above with respect to claim 41, claim 45-46 and 61 also do not integrate the judicial exception into a practical application or amount to significantly more.
Claim 51 recites substantially similar limitations as claim 41. Therefore, for the same reasons explained above with respect to claim 41, claim 51 also recites an abstract idea in Step 2A Prong One (i.e., mathematical concept, certain method of organizing human activities, and mental processes). Claim 51 recites the additional elements of “computer-implemented”, “performed by a transaction processing server”, “from a financial transaction system”, “via a transaction processing network”, and “to the financial transaction system”. However, for the same reasons explained above with respect to claim 41, these additional elements also do not integrate the judicial exception into a practical application or amount to significantly more.
Claims 52-60 recite further limitations that also fall within the same abstract ideas identified above with respect to claim 51 (i.e., mathematical concepts, certain methods of organizing human activities and/or mental processes).
Claim 52 recites the additional elements of “from the financial transaction system via an application programming interface”. Claim 53 recites the additional element of “detokenizing”. Claim 54 recites the additional elements of “encrypted by the system” and “decrypting.” Claim 57 recites the additional elements of “is formatted to conform to a programming structure”. Claims 59-60 recite the additional element of “device”. However, these additional elements also do not integrate the judicial exception into a practical application or amount to significantly more because they amount to adding the words “apply it” with the judicial exception, mere instructions to implement the idea on a computer, merely using a computer as a tool to perform an abstract idea, and generally linking the use of the judicial exception to a particular technological environment or field of use.
Claims 55-56 does not recite any other additional elements. Therefore, for the same reasons explained above with respect to claim 51, claim 55-56 also do not integrate the judicial exception into a practical application or amount to significantly more.
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.
Claim(s) 41-42, 45, 49, 51-52, 55, 59, and 61 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurani et al. (US Patent No. 11,315,137 B1, hereinafter “Kurani”) in view of Kimberg et al. (US 2014/0180849 A1, hereinafter “Kimberg”), in view of Ameiss et al. (US 2010/0057553 A1, hereinafter “Ameiss”), in further view of Rose et al. (US 2018/0056179 A1, hereinafter “Rose”).
As per Claim 41, Kurani teaches A computer-implemented system, comprising (Col. 1 lines 15-20 “systems and methods for allowing users to pay with rewards points directly”. Also see citations below.):
a non-transitory computer-readable medium configured to store instructions (Col. 10 lines 29-35 “In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein.” Also see citations below.); and
at least one processor configured to execute the instructions to perform operations comprising (Col. 10 lines 49-67 “The “circuit” may also include one or more dedicated processors communicatively coupled to one or more dedicated memory or memory devices. In this regards, the one or more dedicated processors may execute instructions stored in the dedicated memory or may execute instructions otherwise accessible to the one or more dedicated processors.” Also see citations below.):
receiving a transaction request from a financial transaction system (Col. 1 lines 39-57 “receiving, by a financial institution computing system associated with a financial institution, a payment request from a merchant point-of-sale (POS) system for a transaction between a merchant and a customer. The payment request including a payment token and an amount of the transaction in currency.” Also see citations below.), wherein:
the transaction request includes a customer identifier and a transaction amount (Col. 1 lines 39-57 “The payment request includes a payment token and an amount of the transaction in currency. The payment token is associated with the rewards account and the rewards account stores a balance of rewards points.” Col. 4 line 45 – Col. 5 line 20 “The payment information includes a payment token that is a proxy of the payment account being used for the transaction with the merchant.” Col. 7 lines 35-55 “The payment token serves as a proxy for the PAN of the virtual account.” Col. 8 lines 20-55 “The method 300 begins a payment request is received and authenticated at 302. The financial institution computing system 108 receives the payment request. In some arrangements, the payment request is received from a merchant POS system 106 via a payment network or another payment processing entity. The payment request is routed to the financial institution computing system 108 based on the IIN of the token or PAN. The payment request includes, at least, a token or PAN, an amount of the payment request, and a merchant identifier. In arrangements where the payment request was initiated from a mobile wallet client on the mobile device 130, the payment request also includes a cryptogram. In such arrangements, the cryptogram may be decrypted to verify that the received token was transmitted from the mobile device 130 associated with the customer 102 as opposed to a different mobile device attempting to fraudulently transact with the token. If the cryptogram does not decrypt properly, the method ends and a denial message is transmitted (e.g., as discussed below with respect to step 312). However, the description of the method 300 continues under the assumption that the cryptogram was successfully decoded and verified. A rewards balance is determined at 304. The financial institution computing system 108 identifies the rewards account associated with the token or PAN and determines a balance of the rewards account. In some arrangements, the available balance of the rewards account is different than the actual balance of the rewards account. For example, for certain merchants, the financial institution 104 may offer a rewards multiplier that increases the value of the rewards point at the merchant. So, if the customer 102 is transacting with a merchant offering a two-times multiplier 100 rewards points may be worth $2 instead of $1.” Also see citations below.); and
the customer identifier is a substitute value for a customer [[loyalty account number]]1, wherein the customer identifier is formatted to resemble a payment card number, to facilitate routing the transaction request via a transaction processing network (Col. 4 line 45 – Col. 5 line 20 “The payment information includes a payment token that is a proxy of the payment account being used for the transaction with the merchant. […] The payment information received at the merchant POS system 106 is then routed to the financial computing system 108 via the network 132 (and sometimes via a payment network and/or a payment acquirer).” Also see citations above. );
analyzing the customer identifier to identify a [[loyalty account number]]1 associated with a customer (Col. 1 lines 39-57 “The payment token is associated with the rewards account”. Col. 3 lines 5-67 “the rewards account is associated with a payment account (e.g., a credit account, a line of credit, a demand deposit account, a prepaid account, etc.) maintained by the financial institution. […] The customer 102 is associated with various customer payment devices 126 that are linked to a rewards account associated with the customer 102. As described above, the rewards account includes a balance of rewards points that is maintained by the financial institution 104. The rewards account may be linked to different payment devices 126, including a traditional payment card 128 (e.g., having a magstripe and/or smartchip in the same manner as a traditional credit card) and a mobile wallet client running on a mobile device 130 associated with the customer.” Col. 8 lines 43-55 “A rewards balance is determined at 304. The financial institution computing system 108 identifies the rewards account associated with the token or PAN and determines a balance of the rewards account. In some arrangements, the available balance of the rewards account is different than the actual balance of the rewards account. For example, for certain merchants, the financial institution 104 may offer a rewards multiplier that increases the value of the rewards point at the merchant. So, if the customer 102 is transacting with a merchant offering a two-times multiplier 100 rewards points may be worth $2 instead of $1.” Also see citations above.);
determining a point balance in a [[loyalty]]1 account associated with the [[loyalty]]1 account [[number]] 1 (Col. 1 lines 25-57 “determining a number of rewards points in the rewards account”. Also see citations above.);
calculating a [[loyalty]]1 point equivalence for a cash value of the transaction amount based on the determined [[loyalty]]1 point exchange rate (Col. 9 line 49 – Col. 10 line 5 “Based on the determined location of the mobile device 130, a merchant multiplier 412 may be activated if the mobile device 130 is determined as being within a merchant that is participating in a multiplier promotion with the financial institution 104. As shown in FIG. 4, there is a two-times multiplier for the points at the current merchant. Accordingly, the available currency is $200 (at a conversion rate of 100 points per $2) instead of the non-multiplied available currency of $100 (at a conversion rate of 100 points per $1).” Also see citations above.);
determining whether the [[loyalty]]1 account has sufficient points to complete the transaction, by comparing the calculated [[loyalty]]1 point equivalence with the determined point balance (Col. 7 lines 23-37 “The virtual account payment information is linked with a backup funding source at 208. In some arrangements, the customer 102 may identify a backup funding source for the virtual account as part of the request received at 202. The backup funding source may be, for example, a credit card account, a demand deposit account, or the like. In transactions in which the balance of points in the rewards account is insufficient to contemplate a given purchase request, the backup funding source is used to supplement the points in the rewards account to approve the transaction, thereby eliminating denied transactions. Accordingly, the financial institution computing system 108 associates the backup funding source with the virtual account information stored in the accounts database 124.” Col. 8 lines 54-67 “Based on the balance determined at 304, the financial institution computing system 108 determines if there are enough rewards points to cover the cost of the payment request at 306. If there is a greater than or equal value of points in the rewards account needed to complete the payment request (e.g., based on a conversion rate of points to currency, which may vary by merchant), an approval message is transmitted at 308. The financial institution computing system 108 transmits the approval message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the approval message at the merchant POS system 106, the merchant can approve and complete the transaction with the customer 102.” Col. 9 lines 1-20 “If there are not enough rewards points to cover the cost of the payment request, the financial institution computing system 108 determines the availability of a backup funding source at 310. As described above with respect to the method 200, the customer 102 can link a backup funding source to the virtual account. The financial institution computing system 108 determines the presence of a valid (i.e., funded) backup funding source that can be used to fund the difference between the requested transaction amount and the points balance of the rewards account. If a backup funding source is available, an approval message is transmitted at 308 (in the same manner as discussed above). If a backup funding source is not available, a denial message is transmitted at 312. The financial institution computing system 108 transmits the denial message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the denial message at the merchant POS system 106, the merchant can deny the contemplated transaction with the customer 102 (or request an alternate payment form).” Claim 1 “determining, by the financial institution computing system, that the number of rewards points in the rewards account is not enough to cover the amount of the transaction based on the currency conversion value; approving, by the financial institution computing system, a portion of the transaction equal to the currency conversion value based on the payment request being authenticated; transmitting, by the financial institution computing system, a partial authorization message to the merchant POS system, the partial authorization message including an approval amount in currency corresponding to the currency conversion value; receiving, by the financial institution computing system, a second payment request from the merchant POS system for the transaction between the merchant and the customer, the second payment request comprising a remaining balance of the amount of the transaction in currency; identifying, by the financial institution computing system, a backup payment source linked to the rewards account, the backup payment source containing sufficient funds to cover the remaining balance of the amount of the transaction in currency; transmitting, by the financial institution computing system, an approval message to the merchant POS system, the approval message based on the partial authorization message and the identified backup payment source; updating, by the financial institution computing system, a balance associated with the rewards account and the backup payment source; transmitting, by the financial institution computing system, the updated balance associated with the rewards account to a mobile device of the customer; and transmitting, by the financial institution computing system, the updated balance associated with the backup payment source to the mobile device of the customer.” Also see citations above.);
on a condition that the [[loyalty]]1 account has sufficient points to complete the transaction (Col. 7 lines 23-37 “The virtual account payment information is linked with a backup funding source at 208. In some arrangements, the customer 102 may identify a backup funding source for the virtual account as part of the request received at 202. The backup funding source may be, for example, a credit card account, a demand deposit account, or the like. In transactions in which the balance of points in the rewards account is insufficient to contemplate a given purchase request, the backup funding source is used to supplement the points in the rewards account to approve the transaction, thereby eliminating denied transactions. Accordingly, the financial institution computing system 108 associates the backup funding source with the virtual account information stored in the accounts database 124.” Col. 8 lines 54-67 “Based on the balance determined at 304, the financial institution computing system 108 determines if there are enough rewards points to cover the cost of the payment request at 306. If there is a greater than or equal value of points in the rewards account needed to complete the payment request (e.g., based on a conversion rate of points to currency, which may vary by merchant), an approval message is transmitted at 308. The financial institution computing system 108 transmits the approval message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the approval message at the merchant POS system 106, the merchant can approve and complete the transaction with the customer 102.” Col. 9 lines 1-20 “If there are not enough rewards points to cover the cost of the payment request, the financial institution computing system 108 determines the availability of a backup funding source at 310. As described above with respect to the method 200, the customer 102 can link a backup funding source to the virtual account. The financial institution computing system 108 determines the presence of a valid (i.e., funded) backup funding source that can be used to fund the difference between the requested transaction amount and the points balance of the rewards account. If a backup funding source is available, an approval message is transmitted at 308 (in the same manner as discussed above). If a backup funding source is not available, a denial message is transmitted at 312. The financial institution computing system 108 transmits the denial message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the denial message at the merchant POS system 106, the merchant can deny the contemplated transaction with the customer 102 (or request an alternate payment form).” Claim 1 “determining, by the financial institution computing system, that the number of rewards points in the rewards account is not enough to cover the amount of the transaction based on the currency conversion value; approving, by the financial institution computing system, a portion of the transaction equal to the currency conversion value based on the payment request being authenticated; transmitting, by the financial institution computing system, a partial authorization message to the merchant POS system, the partial authorization message including an approval amount in currency corresponding to the currency conversion value; receiving, by the financial institution computing system, a second payment request from the merchant POS system for the transaction between the merchant and the customer, the second payment request comprising a remaining balance of the amount of the transaction in currency; identifying, by the financial institution computing system, a backup payment source linked to the rewards account, the backup payment source containing sufficient funds to cover the remaining balance of the amount of the transaction in currency; transmitting, by the financial institution computing system, an approval message to the merchant POS system, the approval message based on the partial authorization message and the identified backup payment source; updating, by the financial institution computing system, a balance associated with the rewards account and the backup payment source; transmitting, by the financial institution computing system, the updated balance associated with the rewards account to a mobile device of the customer; and transmitting, by the financial institution computing system, the updated balance associated with the backup payment source to the mobile device of the customer.” Also see citations above.):
sending a transaction approval to the financial transaction system (Col. 7 lines 23-37 “The virtual account payment information is linked with a backup funding source at 208. In some arrangements, the customer 102 may identify a backup funding source for the virtual account as part of the request received at 202. The backup funding source may be, for example, a credit card account, a demand deposit account, or the like. In transactions in which the balance of points in the rewards account is insufficient to contemplate a given purchase request, the backup funding source is used to supplement the points in the rewards account to approve the transaction, thereby eliminating denied transactions. Accordingly, the financial institution computing system 108 associates the backup funding source with the virtual account information stored in the accounts database 124.” Col. 8 lines 54-67 “Based on the balance determined at 304, the financial institution computing system 108 determines if there are enough rewards points to cover the cost of the payment request at 306. If there is a greater than or equal value of points in the rewards account needed to complete the payment request (e.g., based on a conversion rate of points to currency, which may vary by merchant), an approval message is transmitted at 308. The financial institution computing system 108 transmits the approval message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the approval message at the merchant POS system 106, the merchant can approve and complete the transaction with the customer 102.” Col. 9 lines 1-20 “If there are not enough rewards points to cover the cost of the payment request, the financial institution computing system 108 determines the availability of a backup funding source at 310. As described above with respect to the method 200, the customer 102 can link a backup funding source to the virtual account. The financial institution computing system 108 determines the presence of a valid (i.e., funded) backup funding source that can be used to fund the difference between the requested transaction amount and the points balance of the rewards account. If a backup funding source is available, an approval message is transmitted at 308 (in the same manner as discussed above). If a backup funding source is not available, a denial message is transmitted at 312. The financial institution computing system 108 transmits the denial message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the denial message at the merchant POS system 106, the merchant can deny the contemplated transaction with the customer 102 (or request an alternate payment form).” Claim 1 “determining, by the financial institution computing system, that the number of rewards points in the rewards account is not enough to cover the amount of the transaction based on the currency conversion value; approving, by the financial institution computing system, a portion of the transaction equal to the currency conversion value based on the payment request being authenticated; transmitting, by the financial institution computing system, a partial authorization message to the merchant POS system, the partial authorization message including an approval amount in currency corresponding to the currency conversion value; receiving, by the financial institution computing system, a second payment request from the merchant POS system for the transaction between the merchant and the customer, the second payment request comprising a remaining balance of the amount of the transaction in currency; identifying, by the financial institution computing system, a backup payment source linked to the rewards account, the backup payment source containing sufficient funds to cover the remaining balance of the amount of the transaction in currency; transmitting, by the financial institution computing system, an approval message to the merchant POS system, the approval message based on the partial authorization message and the identified backup payment source; updating, by the financial institution computing system, a balance associated with the rewards account and the backup payment source; transmitting, by the financial institution computing system, the updated balance associated with the rewards account to a mobile device of the customer; and transmitting, by the financial institution computing system, the updated balance associated with the backup payment source to the mobile device of the customer.” Also see citations above.); and
updating a point balance in the [[loyalty]]1 account based on the calculated [[loyalty]]1 point equivalence (Col. 7 lines 23-37 “The virtual account payment information is linked with a backup funding source at 208. In some arrangements, the customer 102 may identify a backup funding source for the virtual account as part of the request received at 202. The backup funding source may be, for example, a credit card account, a demand deposit account, or the like. In transactions in which the balance of points in the rewards account is insufficient to contemplate a given purchase request, the backup funding source is used to supplement the points in the rewards account to approve the transaction, thereby eliminating denied transactions. Accordingly, the financial institution computing system 108 associates the backup funding source with the virtual account information stored in the accounts database 124.” Col. 8 lines 54-67 “Based on the balance determined at 304, the financial institution computing system 108 determines if there are enough rewards points to cover the cost of the payment request at 306. If there is a greater than or equal value of points in the rewards account needed to complete the payment request (e.g., based on a conversion rate of points to currency, which may vary by merchant), an approval message is transmitted at 308. The financial institution computing system 108 transmits the approval message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the approval message at the merchant POS system 106, the merchant can approve and complete the transaction with the customer 102.” Col. 9 lines 1-20 “If there are not enough rewards points to cover the cost of the payment request, the financial institution computing system 108 determines the availability of a backup funding source at 310. As described above with respect to the method 200, the customer 102 can link a backup funding source to the virtual account. The financial institution computing system 108 determines the presence of a valid (i.e., funded) backup funding source that can be used to fund the difference between the requested transaction amount and the points balance of the rewards account. If a backup funding source is available, an approval message is transmitted at 308 (in the same manner as discussed above). If a backup funding source is not available, a denial message is transmitted at 312. The financial institution computing system 108 transmits the denial message to the merchant POS system 106 (e.g., via a payment network or another payment processing entity through the network 132). Upon receipt of the denial message at the merchant POS system 106, the merchant can deny the contemplated transaction with the customer 102 (or request an alternate payment form).” Claim 1 “determining, by the financial institution computing system, that the number of rewards points in the rewards account is not enough to cover the amount of the transaction based on the currency conversion value; approving, by the financial institution computing system, a portion of the transaction equal to the currency conversion value based on the payment request being authenticated; transmitting, by the financial institution computing system, a partial authorization message to the merchant POS system, the partial authorization message including an approval amount in currency corresponding to the currency conversion value; receiving, by the financial institution computing system, a second payment request from the merchant POS system for the transaction between the merchant and the customer, the second payment request comprising a remaining balance of the amount of the transaction in currency; identifying, by the financial institution computing system, a backup payment source linked to the rewards account, the backup payment source containing sufficient funds to cover the remaining balance of the amount of the transaction in currency; transmitting, by the financial institution computing system, an approval message to the merchant POS system, the approval message based on the partial authorization message and the identified backup payment source; updating, by the financial institution computing system, a balance associated with the rewards account and the backup payment source; transmitting, by the financial institution computing system, the updated balance associated with the rewards account to a mobile device of the customer; and transmitting, by the financial institution computing system, the updated balance associated with the backup payment source to the mobile device of the customer.” Also see citations above.).
While Kurani teaches reward accounts, Kurani does not appear to explicitly teach loyalty accounts and loyalty account “number”. However, Kimberg teaches loyalty accounts and loyalty account “number” in at least ¶ 43.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing to combine the account number as taught by Kimberg, into Kurani. One of ordinary skill in the art would have been motivated to do so for the advantage of identifying the specific loyalty account the user would like to redeem points from. Since each individual element and its function are shown in the prior art, albeit shown in separate reference, the difference between the claimed subject matter and the prior art rests not on any individual element or function, but in the very combination itself – that is in the substitution of the loyalty account and loyalty account numbers of Kimberg for the reward account of Kurani. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious (KSR Rationale B).
While the combination of Kurani/Kimberg teach all of the above limitations, they do not appear to explicitly teach the following limitations. However, Ameiss teaches: determining a loyalty point exchange rate based on the transaction amount, wherein (¶¶ 6, 30-40, 63, 77-78, Figure 3 and related paragraphs.): the loyalty point exchange rate varies based on a tiered structure of the transaction amount (¶¶ 6, 30-40, 63, 77-78, Figure 3 and related paragraphs.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the features of Ameiss into the combination of Kurani/Kimberg. One of ordinary skill in the art would have been motivated to do so to enable an loyalty program operator to decide how and at what rate loyalty points are earned and redeemed (Ameiss, ¶ 25), and to enable restrictions to be placed based on transaction amounts (Ameiss, ¶ 30). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
While the combination of Kurani/Kimberg/Ameiss teach all of the above limitations, including determining a loyalty point exchange rate based on the transaction amount, they do not appear to explicitly teach: a first exchange rate is applied to a first portion of the transaction amount below a threshold; and a second exchange rate is applied to a second portion of transaction amount above the threshold.
However, Rose teaches a first exchange rate is applied to a first portion of the transaction amount below a threshold (¶ 212 “wherein the identified virtual currency management rule includes a linear pricing rule that specifies a first constant virtual-to-real currency exchange rate up to a threshold sale price in the real currency, and a second constant virtual-to-real currency exchange rate above the threshold sale price in the real currency.” Also see at least ¶¶ 135 and 137).” Also see at least ¶¶ 135 and 137).; and
a second exchange rate is applied to a second portion of transaction amount above the threshold (¶ 212 “wherein the identified virtual currency management rule includes a linear pricing rule that specifies a first constant virtual-to-real currency exchange rate up to a threshold sale price in the real currency, and a second constant virtual-to-real currency exchange rate above the threshold sale price in the real currency.” Also see at least ¶¶ 135 and 137).” Also see at least ¶¶ 135 and 137).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the first exchange rate applied to a first portion of the transaction amount below a threshold and a second exchange rate applied to a second portion of the transaction amount above the threshold as taught by Rose, into the combination of Kurani/Kimberg/Ameiss. One of ordinary skill in the art would have been motivated to do so for the advantages of incentivizing users to purchase more in order to obtain a better exchange rate which would increase revenue for merchants. The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
As per Claim 42, Kurani teaches wherein the transaction request is received from the financial transaction system […] (Col. 1 lines 39-57 “receiving, by a financial institution computing system associated with a financial institution, a payment request from a merchant point-of-sale (POS) system for a transaction between a merchant and a customer. The payment request including a payment token and an amount of the transaction in currency.” Also see citations above.).
While Kurani teaches the transaction request being received, Kurani does not appear to explicitly teach that the transaction request is received via an application programming interface. However, Kimberg teaches this limitation in at least ¶¶ 25-29 and 56.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the API as taught by Kimberg into Kurani. One of ordinary skill in the art would have been motivated to do so for the advantage of enabling the system to support both an API transaction method and a payment card network transaction method (Kimberg, ¶ 56). Additionally, one of ordinary skill in the art would have been motivated to do so for the advantage of enabling transactions to be performed over API (Kimberg, ¶ 56). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
As per Claim 45, Kurani teaches wherein determining the point balance in the [[loyalty]]1 account includes querying a financial service provider to retrieve the point balance (Col. 1 lines 25-57 “determining a number of rewards points in the rewards account”. Also see claim 1 and citations above.).
As per Claim 49, Kurani teach further comprising:
on a condition that the [[loyalty]]1 account has sufficient points to complete the transaction, sending an updated point balance in the [[loyalty]]1 account to a customer device (Col. 9 lines 35-50. Also see citations above.).
As per Claim 51, it recites substantially similar limitations as 41. Therefore, it is rejected using the same rationale. The Examiner notes that the limitations “on a condition that the loyalty account has sufficient points to complete the transaction: sending a transaction approval to the financial transaction system; and updating a point balance in the loyalty account based on the calculated loyalty point equivalence” are not required to be performed if the loyalty account does not have sufficient loyalty points to complete the transaction. These limitations are contingent limitations.
As per Claim 52, it recites substantially similar limitations as 42. Therefore, it is rejected using the same rationale.
As per Claim 55, it recites substantially similar limitations as 45. Therefore, it is rejected using the same rationale.
As per Claim 59, it recites substantially similar limitations as 49. Therefore, it is rejected using the same rationale. The Examiner notes that the limitation “on a condition that the loyalty account has sufficient points to complete the transaction, sending an updated point balance in the loyalty account toa customer device” is not required to be performed if the loyalty account does not have sufficient loyalty points to complete the transaction. This limitation are contingent limitations.
As per Claim 61, while the combination of Kurani/Kimberg teach an exchange rate, they do not appear to explicitly teach wherein the first exchange rate is different from the second exchange rate. However, Ameiss teaches this limitation in at least ¶ 6, 30-40, 63, 77-78, Figure 3 and related paragraphs.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the first exchange rate being different from the second exchange rate as taught by Ameiss, into the combination of Kurani/Kimberg. One of ordinary skill in the art would have been motivated to do so for the advantages of enabling a loyalty program operator to decide how and at what rate loyalty points are earned and redeemed (Ameiss, ¶ 25), and enabling restrictions to be placed based on transaction amounts (Ameiss, ¶ 30). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
Claim(s) 43 and 53 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurani in view of Kimberg, in view of Ameiss, in view of Rose, in further view of Asefi et al. (US Patent No. 11,861,594 B1, hereinafter “Asefi”).
As per Claim 43, while Kurani analyzes the customer identifier to identity a reward account, the combination of Kurani/Kimberg/Ameiss/Rose do not appear to explicitly teach wherein analyzing the customer identifier includes detokenizing the customer identifier to identify the [[loyalty]]1 account number. However, Asefi teaches this limitation in at least Col. 3 line 10 – Col. 4 line 25, and Col. 9 line 60 – Col. 10 line 15.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine wherein the analyzing the customer identifier includes detokenizing the customer identifier to identify the account number as taught by Asefi, into the combination of Kurani/Kimberg/Ameiss/Rose. One of ordinary skill in the art would have been motivated to do so to improve security for electronic transactions (Asefi, Col. 1 lines 19-46). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
As per Claim 53, it recites substantially similar limitations as 43. Therefore, it is rejected using the same rationale.
Claim(s) 46-47 and 56-57 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurani in view of Kimberg, in view of Ameiss, in view of Rose, in further view of Warner (US Patent No. 11,669,815 B1, hereinafter “Warner”).
As per Claim 46, Kurani teaches wherein the transaction type includes a cash withdrawal transaction request or a point of sale transaction request (The Examiner notes that the above italicized and underline limitation is not given patentable weight because it is nonfunctional descriptive material. However, for the sake of advancing prosecution, see at least Col. 1 lines 39-55 “The method includes receiving, by a financial institution computing system associated with a financial institution, a payment request from a merchant point-of-sale (POS) system for a transaction between a merchant and a customer.” [The Examiner notes that Claim 46 further defines “transaction type” as a cash withdrawal transaction or a point of sale transaction request.] The payment request includes a payment token and an amount of the transaction in currency.” Also see citations above.).
Alternatively, Warner also teaches this limitation in at least Col. 17 lines 20-35 and Col. 18 lines 42-55. Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine wherein the transaction type includes a cash withdrawal transaction request or a point of sale transaction request as taught by Warner, into the combination of Kurani/Kimberg/Ameiss/Rose. One of ordinary skill in the art would have been motivated to do so to determine the transaction type in order to charge the customer and/or merchant with the appropriate transaction fees. The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
As per Claim 47, while Kurani teaches a transaction request, Kurani does not appear to explicitly teach wherein the transaction request is formatted to conform to a programming structure […]. However, Kimberg teaches this limitation in at least ¶¶ 25-29 and 56.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the transaction request being formatted to conform to a programming structure as taught by Kimberg, into Kurani. One of ordinary skill in the art would have been motivated to do so for the advantages of enabling the system to support both an API transaction method and a payment card network transaction method (Kimberg, ¶ 56), and to enable transactions to be performed over API (Kimberg, ¶ 56). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
While the combination of Kurani/Kimberg/Ameiss/Rose teach a the transaction request being formatted to conform to a programming structure, they do not appear to explicitly teach and includes a processing code to determine the transaction type. However, Warner teaches this limitation in at least Col. 4 lines 39-45, Col. 9 lines 54-63, Col. 17 lines 20-35, and Col. 18 lines 42-55.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine a processing code to determine the transaction type as taught by Warner, into the combination of Kurani/Kimberg/Ameiss/Rose. One of ordinary skill in the art would have been motivated to do so to determine the transaction type in order to charge the customer and/or merchant with the appropriate transaction fees. The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A). The Examiner notes that the above italicized and underlined limitations are not given patentable weight because it is nonfunctional descriptive material of the transaction request. However, for the sake of advancing prosecution, all limitations are considered and addressed.
As per Claim 56, it recites substantially similar limitations as 46. Therefore, it is rejected using the same rationale.
As per Claim 57, it recites substantially similar limitations as 47. Therefore, it is rejected using the same rationale.
Claim(s) 44 and 54 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurani in view of Kimberg, in view of Ameiss, in view of Rose, in further view of Tunnell et al. (US 2017/0039568 A1, hereinafter “Tunnell”).
As per Claim 44, which Kurani teaches the customer identifier, the combination of Kurani/Kimberg/Ameiss/Rose do not appear to explicitly teach the following limitations. However, Tunnell teaches wherein:
the customer identifier is encrypted by the system when the customer identifier is created (¶¶ 14-30 and 100-105. Also see at least claim 29.); and
analyzing the customer identifier further comprises decrypting the customer identifier to identify the loyalty account number (¶¶ 14-30 and 100-105. Also see at least claim 29.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine the features of Tunnell, into the combination of Kurani/Kimberg/Ameiss/Rose. One of ordinary skill in the art would have been motivated to do so for the advantage of preventing loyalty card numbers from being leaked to the public or stolen (Tunnell, ¶ 29). The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A).
As per Claim 54, it recites substantially similar limitations as 44. Therefore, it is rejected using the same rationale.
Claim(s) 50 and 60 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kurani in view of Kimberg, in view of Ameiss, in view of Rose, in further view of Velani (US 2011/0276418 A1, hereinafter “Velani”).
As per Claim 50, Kurani teaches further comprising: on a condition that the [[loyalty]]1 account does not have sufficient points to complete the transaction […] (Col. 9 lines 1-35. Also see citations above.).
While Kurani sends a message to a customer indicating that the transaction request was denied, the combination of Kurani/Kimberg/Ameiss/Rose do not appear to explicitly teach sending a message to a customer device indicating that the transaction request was denied. However, Velani teaches this limitation in at least ¶ 33 “Upon receipt of a purchase transaction request and authentication of the identity of the pre-registered customer, the remote payment processing system forwards the transaction information to an appropriate credit card network, institution, or alternative payment service and communicates a message to the retailer's point-of-sale device and the customer's mobile device indicating that the payment transaction has been approved or denied. Upon receipt of an approval message, the retailer may print a receipt for the customer before releasing the purchased items to the customer. Upon receipt of properly formatted transaction information, the appropriate credit card network, financial institution, or alternative payment service debits the customer's pre-registered payment account and credits a retailer account or bills the customer.”
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date to combine sending a message to a customer device indicating that the transaction request was denied as taught by Velani, into the combination of Kurani/Kimberg/Ameiss/Rose. One of ordinary skill in the art would have been motivated to do so for the advantage of providing the customer with proof that the transaction request was denied, and that the transaction was not denied due to an error from the customer not swiping or tapping the card the correct way. The claimed invention is also merely a combination of old elements, and in the combination each element would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable (KSR Rationale A). The Examiner notes that the above italicized and underlined limitations are not given patentable weight because they are contingent limitations that are not required to be performed if the loyalty account does have sufficient points. However, for the sake of advancing prosecution, all limitations are considered and addressed.
As per Claim 60, it recites substantially similar limitations as 50. Therefore, it is rejected using the same rationale. The Examiner notes that the limitation “on a condition that the loyalty account does not have sufficient points to complete the transaction, sending a message to a customer device indicating that the transaction request was denied” is not required to be performed if the loyalty account does have sufficient loyalty points to complete the transaction. This limitation is contingent limitations.
Response to Arguments
Applicant's arguments filed 03/19/2026 have been fully considered but they are not persuasive. In the Remarks, Applicant argues:
Argument: “Applicant submits that the Office has failed to identify an abstract idea that is allegedly recited in the claims. […] Applicant’s claims are directed to, among other features, solving technical problems associated with using existing payment networks to route a loyalty points-based transaction, even in circumstances where the customer wants to redeem loyalty points for a non-participating merchant that does not participate in the loyalty program. In such circumstances, the prior payment networks were not capable of processing loyalty points redemptions for non-participating merchants. In other words, the loyalty points were previously required to be redeemed only at the merchant that issued the loyalty points and the loyalty points transaction was processed on a different payment network than the payment network typically used to process ‘regular’ credit card payments. See Applicant’s specification, paragraphs 0003-0007. This solution to this technical problem is addressed by the elements recited in claim 41, including formatting ‘the customer identifier… to resemble a payment card number to facilitate routing the transaction request via a transaction processing network.’ In the Response to Arguments section of the Final Office Action, the Office responds to Applicant's prior arguments on this point by stating that "the claims here are ineligible because their innovation is an innovation in ineligible subject matter. Similar to the claimed invention in SAP, the advance here lies entirely in the realm of the abstract idea with no plausibly alleged innovation in the non-abstract application realm." Final Office Action, page 34. As noted above, claim 41 recites technical subject matter (by formatting "the customer identifier ... to resemble a payment card number to facilitate routing the transaction request via a transaction processing network") that enables a loyalty points transaction to be processed on the same payment network as used to process "regular" credit card payments. For at least these reasons, the claims are integrated into practical applications, thereby satisfying the subject matter eligibility requirement under 35 U.S.C. § 101. Accordingly, Applicant requests that this rejection be withdrawn.
. […] Moreover, like the claims in BASCOM, the pending claims do not preempt all ways of implementing the unknown alleged abstract idea that the Office relies on. […] This combination of steps operate in a non-conventional and non-generic way to solve technical problems associated with existing payment networks to route a loyalty points-based transaction, even in circumstances where the customer wants to redeem loyalty points for a non-participating merchant. […] In combination, these steps set up a sequence of events that address unique problems associated with using existing payment networks to route a loyalty points-based transaction, Thus, like in BASCOM, the claimed combination of additional elements presents a specific, discrete implementation of the alleged abstract idea. The additional elements in claim 41 thus represent significantly more (i.e., provide an inventive concept) because they are a practical implementation of the alleged abstract idea, even though the steps use well-known components. […] Applicant submits that claim 41 as amended does recite a non-conventional technical arrangement by formatting "the customer identifier ... to resemble a payment card number to facilitate routing the transaction request via a transaction processing network." This enables a loyalty points transaction to be processed on the same payment network as used to process "regular" credit card payments. Such a transaction was not possible prior to Applicant's invention as recited in the claims.”
In response, the Examiner respectfully disagrees. First, the Office Action clearly identifies the limitations that describe the abstract idea in Step 2A Prong One as can be seen above on pages 2-3 for claim 1. The Office Action then compares the identified abstract idea to the enumerated groupings of abstract ideas (i.e., mental process, certain methods of organizing human activities, and mathematical concepts). Therefore, the Office Action clearly identifies the abstract idea in Step 2A Prong one.
Second, the claims here are ineligible because their innovation is an innovation in ineligible subject matter. Similar to the claimed invention in SAP, the advance here lies entirely in the realm of the abstract idea with no plausibly alleged innovation in the non-abstract application realm. Unlike in DDR in which the claimed invention solved the business challenge of retaining website visitors that is particular to the Internet, here the claimed invention amounts to merely reciting the performance of a business practice along with the requirement to perform it on the Internet. The claimed invention here is not necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks. “We caution, however, that not all claims purporting to address Internet-centric challenges are eligible for patent” (see p. 22 of DDR Holdings, LLC v. Hotels.com, L.P. (Fed. Cir. 2014)).
Third, formatting the customer identifier to resemble a payment card number can be practically performed in the human mind or by a human using pen and paper. For example, a human can look at the customer identifier “2412751234123456” and make it resemble a payment card number by adding a space between certain digits (e.g., “2412 7512 3412 3456”). Additionally, a human can add extra digits to fill in for the typical 15-16 digits used in typical payment card numbers. For example, if a customer identifier is 390165, a human can make the customer identifier resemble a payment card number by adding zeros to get to a 15-16 digit number (e.g., 3901 6500 0000 0000). The Examiner notes that “the judicial exception alone cannot provide the improvement” (MPEP 2106.05(a)).
Fourth, unlike in BASCOM in which the particular arrangement of known elements provided a technical improvement over prior art ways of filtering content, here looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer, improves any other technology or technical field, applies or uses the judicial exception to effect a particular treatment or prophylaxis for disease or medical condition, applies the judicial exception with, or by use of a particular machine, effects a transformation or reduction of a particular article to a different state or thing, or applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claims as a whole is more than a drafting effort designed to monopolize the exception. Their collective functions merely provide generic computer implementation. The claims at issue do not require any non-conventional computer, network or display components, or even a non-conventional and non-generic arrangement of known conventional pieces.
Fifth, “[w]hile preemption is the concern underlying the judicial exceptions, it is not a standalone test for determining eligibility. […] [W]hile a preemptive claim may be ineligible, the absence of complete preemption does not demonstrate that a claim is eligible” (MPEP 2106.04(I)).
Sixth, with regard to the argument that the claimed invention provides a non-conventional technical arrangement by formatting the customer identifier to resemble a payment card number to facilitate routing the transaction request via a transaction processing network to enable a loyalty point transaction to be processed on the same payment network as regular credit card payments, the Examiner respectfully disagrees. The concept of formatting the customer identifier to resemble a payment card number is well-known in the art as explained by paragraph 2 of US 2016/0283942 A1 “One technique that has been used is known as payment tokenization, which involves substituting a payment Primary Account Number (PAN) with a payment token in the payments ecosystem. Payment tokens may be used to originate payment transactions, while non-payment tokens may be used for other purposes, such as loyalty program tracking. A payment token service provider may be authorized to provide payment tokens to token requestors, such as card on file merchants, acquirer processors, payment gateways, digital wallet providers, card issuers, and the like. The token service provider may be implemented to run on a server and to receive requests for payment tokens from one or more token requestors. For each payment token request, the token service provider generates a random payment token, which is in some cases a Bank Identification Number (BIN)/Issuer Identification Number (IIN) range that is not currently being used by any active payment card. The token may be given some expiration period and can be used in place of the PAN for a payment card until it expires.”
Therefore, the claims as currently amended still do not integrate the judicial exception into a practical application or amount to significantly more.
Argument: “Rose does not provide further explanation of the term "linear pricing rule." The closest Rose comes to describing a similar type of pricing rule is A discrete [sic] pricing algorithm may assign a variable exchange rate depending on the total value of the purchase price. For example, the exchange rate may be lowered (e.g., more beneficial to the user) when the total purchase price is higher than a threshold value, than when it the total purchase price is lower than the threshold value. Rose, paragraph 0104. Applicant submits that the "linear pricing rule" and the "discrete pricing algorithm" as the same type of pricing rule and that both apply a single exchange rate to the entire transaction. This is not the same as "a first exchange rate is applied to a first portion of the transaction amount below a threshold; and a second exchange rate is applied to a second portion of the transaction amount above the threshold" as claimed. Amended claim 41 applies two different exchange rate to a single transaction: the first exchange rate for the first portion of the transaction amount below the threshold and the second exchange rate for the second portion of the transaction amount above the threshold. See Applicant's specification as published, paragraph 0067.”
In response, the Examiner respectfully disagrees. Rose teach a first exchange rate that is applied to a first portion of the transaction amount below a threshold (¶ 212 “a first constant virtual-to-real currency exchange rate up to a threshold sale price in the real currency) and a second exchange rate is applied to a second portion of transaction amount above the threshold (¶ 212 “and a second constant virtual-to-real currency exchange rate above the threshold sale price in the real currency). Therefore, Rose clearly applies two different exchange rates to a single transaction.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAM REFAI whose telephone number is (313)446-4822. The examiner can normally be reached M-F 9:00am-6:00pm.
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, Waseem Ashraf can be reached at 571-270-3948. 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.
/SAM REFAI/Primary Examiner, Art Unit 3621
1 The Examiner notes that while Kurani teaches “reward” accounts, Kurani does not appear to explicitly teach “loyalty” accounts and “loyalty account numbers”. Kimberg teaches “loyalty” accounts and “loyalty account numbers” in at least ¶ 43 and Abstract. The motivation for combining Kimberg with Kurani is articulated below on page 22 and incorporated herein by reference.
Prosecution Insights