DETAILED ACTION
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 XXXXXXXXXXXXXX has been entered.
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 .
Status of Claims
Claims X are canceled.
Claims X are amended.
Claims X are new.
Claims X are pending and have been examined.
This action is in reply to the papers filed on XXX (effective filing date xxx).
Claims 1-20 are pending and have been examined.
This action is in reply to the papers filed on 12/09/2024 (effective filing date 12/28/2016).
Information Disclosure Statement
The information disclosure statement(s) submitted: 12/09/2024, has/have been considered by the Examiner and made of record in the application file.
Amendment
The present Office Action is based upon the original patent application filed on xxx as modified by the amendment filed on xxx.
Terminal Disclaimer
The terminal disclaimer filed on xxx disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. No. xxxx has been reviewed and has been placed in the file.
Examiner acknowledges Applicant’s filed Terminal Disclaimer to prior art patent McCauley et al. US Pat. No. 5,930,775. A terminal disclaimer may be filed to overcome or obviate a nonstatutory double patenting rejection (37 CFR 1.321; MPEP 706.02; 1490).
Double Patenting - Withdrawn
The double patenting rejection is withdrawn per the filed terminal disclaimer noted above.
Reasons For Allowance
Prior-Art Rejection withdrawn
Claims xxx are allowed. The closest prior art (See PTO-892, Notice of References Cited) does not teach the claimed:
The invention teaches… and the prior-art teaches…, however, the prior-art does not teach…
The closest prior-art (xxx) teach the features as disclosed in Non-final Rejection (xxxx), however, these cited references do not teach and the prior-art does not teach at least the following combination of features and/or elements:
determining, at a second time after associating the information corresponding to the first loyalty card with the logged location, that a second user computing device is located within a specified distance of the logged location using a second positioning system of the second user computing device; in response to determining that the second user computing device is located within the specified distance of the logged location of the first user computing device at the first time of detecting: retrieving information corresponding to a second loyalty card, the second loyalty card being associated with the merchant and the second user computing device; and displaying, by the second user computing device, data describing the second loyalty card.
Claim Rejections - 35 USC §101 - Withdrawn
Per Applicant’s amendments and arguments and considering new guidance in the MPEP, the rejections are withdrawn. Specifically, in Applicant’s Remarks (dated 03/14/2017, pgs. 8-11), Applicant traverses the 35 USC §101 rejections arguing that the amended claims recite new limitations that are not abstract, amount to significantly more, are directed to a practical application, etc… For example, Applicant argues….
In support of their arguments, Applicant cites to the following recent Fed. Cir. court cases (i.e., Alice Corp. v. CLS Bank Int’l, SRI Int’l, Inc. v. Cisco Systems, Inc., Ultramercial, Inc. v. Hulu, LLC, Berkheimer, Core Wireless, McRO, Enfish, Bascom, DDR, etc…).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of anticipatory-nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,165,168.
18/974,447 – Claim 1. A computer-implemented method comprising:
US 12,165,168 – Claim 1. A computer-implemented method comprising:
18/974,447 – Claim 1. maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user;
US 12,165,168 – Claim 1. maintaining, by a computing system, one or more electronic databases comprising information associated with a payment account of a user and a rewards account of the user;
18/974,447 – Claim 1. establishing, by the computing system, via a network, a communication session with a user device of the user;
US 12,165,168 – Claim 1. establishing, by the computing system, via a network, a communication session with a user device of the user;
18/974,447 – Claim 1. receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device;
US 12,165,168 – Claim 1. receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards points in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device;
18/974,447 – Claim 1. determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account;
US 12,165,168 – Claim 1. determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a points balance in the rewards account;
18/974,447 – Claim 1. transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present:
US 12,165,168 – Claim 1. transmitting, by the computing system, to the user device during the communication session, the one or more graphical user interface elements to dynamically update a single application interface of the client application executing on the user device, causing the single application interface to present:
18/974,447 – Claim 1. (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer;
US 12,165,168 – Claim 1. (i) an insufficient funds message indicating that the points balance is too low to complete the funds transfer;
18/974,447 – Claim 1. (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account;
US 12,165,168 – Claim 1. (ii) a prompt for the user to specify, using the input/output device of the user device, a number of reward points to use for the funds transfer that is less than the points balance in the rewards account,
18/974,447 – Claim 1. (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and
US 12,165,168 – Claim 1. (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified number of reward points and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the updates to the number of reward points specified via the prompt using the input/output device, and
18/974,447 – Claim 1. (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and
US 12,165,168 – Claim 1. (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified number of reward points; and
18/974,447 – Claim 1. in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
US 12,165,168 – Claim 1. in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified number of reward points from the rewards account so that rewards points are used for completing the funds transfer; wherein the funds transfer includes a split transaction comprising a transfer of rewards points and a transfer of currency.
18/974,447 – Claim 2. The computer-implemented method of claim 1, further comprising debiting the remainder amount from a selected account associated with the user.
US 12,165,168 – Claim 17. … debiting the remainder amount from a selected account associated with the user.
18/974,447 – Claim 3. The computer-implemented method of claim 1, wherein the funds transfer is a peer-to-peer (P2P) funds transfer.
US 12,165,168 – Claim 2. The computer-implemented method of claim 1, wherein the funds transfer is a peer-to-peer (P2P) funds transfer.
18/974,447 – Claim 4. The computer-implemented method of claim 3, wherein the P2P funds transfer is funded with a combination of the reward points amount and currency.
US 12,165,168 – Claim 3. The computer-implemented method of claim 2, wherein the P2P funds transfer is funded with a combination of the reward points amount and currency.
18/974,447 – Claim 5. The computer-implemented method of claim 1, wherein the identification of the recipient comprises at least one of a recipient name or a recipient account number.
US 12,165,168 – Claim 4. The computer-implemented method of claim 1, wherein the identification of the recipient comprises at least one of a recipient name or a recipient account number.
18/974,447 – Claim 6. The computer-implemented method of claim 1, wherein rewards are used for the funds transfer without converting the specified amount of rewards to a currency value that is then used for completing the funds transfer.
US 12,165,168 – Claim 16. The computing system of claim 7, wherein rewards points are used for the funds transfer without converting the reward points amount to a currency value that is then used for completing the funds transfer.
18/974,447 – Claim 7. The computer-implemented method of claim 1, further comprising transmitting a funds transfer confirmation to the user device.
US 12,165,168 – Claim 5. The computer-implemented method of claim 1, further comprising transmitting a funds transfer confirmation to the user device.
18/974,447 – Claim 8. The computer-implemented method of claim 1, further comprising determining that a second rewards amount of a second funds transfer request is less than or equal to the balance in the rewards account following the funds transfer.
US 12,165,168 – Claim 6. The computer-implemented method of claim 1, further comprising determining that a second rewards amount of a second funds transfer request is less than or equal to the points balance in the rewards account.
The remaining independent claims contain feature similar to that of claim 1 and are rejected accordingly. The dependent claims are further rejected for their dependency upon a rejected independent base claim.
Claims 1-20 are rejected on the ground of anticipatory-nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,551,254.
18/974,447 – Claim 1. A computer-implemented method comprising:
US 11,551,254 – Claim 1. A computer-implemented method of performing rewards transactions using a computing system of a financial institution, the method comprising:
18/974,447 – Claim 1. maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user;
US 11,551,254 – Claim 1. maintaining, by the computing system, a plurality of electronic databases comprising (i) an accounts database configured to store information associated with accounts held by the financial institution, the accounts database comprising a payment account of a user, and (ii) a rewards account database configured to store information associated with reward accounts held by the financial institution, the rewards account database comprising a rewards account of the user;
18/974,447 – Claim 1. establishing, by the computing system, via a network, a communication session with a user device of the user;
US 11,551,254 – Claim 1. establishing, by the computing system, via a network, a communication session with a user device of the user;
18/974,447 – Claim 1. receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device;
US 11,551,254 – Claim 1. receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards points in the rewards account rather than currency in the payment account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user using an input/output device of the user device;
18/974,447 – Claim 1. determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account;
US 11,551,254 – Claim 1. determining, by the computing system, by accessing the rewards account database, that the transfer amount is higher than a conversion value corresponding to a points balance in the rewards account;
18/974,447 – Claim 1. transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and
US 11,551,254 – Claim 1. transmitting, by the computing system, during the communication session, the insufficient funds message to the user device for display in the client application executing on the user device, with (i) a prompt for the user to enter, using the input/output device of the user device, a reward points amount not exceeding the points balance to use for the funds transfer, (ii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the entered reward points amount and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the updates to the reward points amount entered into the prompt, and (iii) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the entered reward points; and
18/974,447 – Claim 1. in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
US 11,551,254 – Claim 1. in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the entered reward points amount from the rewards account, wherein the rewards points are used for the transfer without converting the reward points amount to a currency value that is then used for completing the funds transfer.
18/974,447 – Claim 2. The computer-implemented method of claim 1, further comprising debiting the remainder amount from a selected account associated with the user.
US 11,551,254 – Claim 2. The computer-implemented method of claim 1, further comprising debiting the remainder amount from a selected account associated with the user.
18/974,447 – Claim 3. The computer-implemented method of claim 1, wherein the funds transfer is a peer-to-peer (P2P) funds transfer.
US 11,551,254 – Claim 4. The computer-implemented method of claim 1, wherein the funds transfer is a peer-to-peer (P2P) funds transfer.
18/974,447 – Claim 4. The computer-implemented method of claim 3, wherein the P2P funds transfer is funded with a combination of the reward points amount and currency.
US 11,551,254 – Claim 5. The computer-implemented method of claim 4, wherein the P2P funds transfer is funded with a combination of the reward points amount and currency.
18/974,447 – Claim 5. The computer-implemented method of claim 1, wherein the identification of the recipient comprises at least one of a recipient name or a recipient account number.
US 11,551,254 – Claim 6. The computer-implemented method of claim 1, wherein the identification of the recipient comprises a recipient name.
US 11,551,254 – Claim 7. The computer-implemented method of claim 1, wherein the identification of the recipient comprises a recipient account number.
18/974,447 – Claim 6. The computer-implemented method of claim 1, wherein rewards are used for the funds transfer without converting the specified amount of rewards to a currency value that is then used for completing the funds transfer.
US 11,551,254 – Claim 10. … wherein the rewards points are used for the transfer without converting the reward points amount to a currency value that is then used for completing the funds transfer.
18/974,447 – Claim 7. The computer-implemented method of claim 1, further comprising transmitting a funds transfer confirmation to the user device.
US 11,551,254 – Claim 8. The computer-implemented method of claim 1, further comprising transmitting a funds transfer confirmation to the user device.
18/974,447 – Claim 8. The computer-implemented method of claim 1, further comprising determining that a second rewards amount of a second funds transfer request is less than or equal to the balance in the rewards account following the funds transfer.
US 11,551,254 – Claim 9. The computer-implemented method of claim 1, further comprising determining that a second rewards amount of a second funds transfer request is less than or equal to the points balance in the rewards account.
The remaining independent claims contain feature similar to that of claim 1 and are rejected accordingly. The dependent claims are further rejected for their dependency upon a rejected independent base claim.
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 1-20 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more. These claims recite a method and system for rewards integration as a funding account.
Claim 1 recites [a] computer-implemented method comprising: maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user; establishing, by the computing system, via a network, a communication session with a user device of the user; receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device; determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account; transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
The claims are being rejected according to the 2019 Revised Patent Subject Matter Eligibility Guidance (Federal Register, Vol. 84, No. 5, p. 50-57 (Jan. 7, 2019)).
Step 1: Does the Claim Fall within a Statutory Category?
Yes. Claims 1-8 and 18-20 recite a method and, therefore, are directed to the statutory class of a process. Claims 9-17 recite a system/apparatus and, therefore, are directed to the statutory class of machine.
Step 2A, Prong One: Is a Judicial Exception Recited?
Yes. The following tables identify the specific limitations that recite an abstract idea. The column that identifies the additional elements will be relevant to the analysis in step 2A, prong two, and step 2B.
Claim 1: Identification of Abstract Idea and Additional Elements, using Broadest Reasonable Interpretation
Claim Limitation
Abstract Idea
Additional Element
1. A computer-implemented method comprising:
No additional elements are positively claimed.
maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user;
This limitation includes the step(s) of: maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
maintaining, by a computing system, one or more electronic databases…
establishing, by the computing system, via a network, a communication session with a user device of the user;
This limitation includes the step(s) of: establishing, by the computing system, via a network, a communication session with a user device of the user.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
establishing, by the computing system, via a network, a communication session with a user device of the user
receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device;
This limitation includes the step(s) of: receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, … the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device
determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account;
This limitation includes the step(s) of: determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
determining, by the computing system, by accessing the one or more electronic databases…
transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and
This limitation includes the step(s) of: transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, … a prompt for the user to specify, using the input/output device of the user device, an amount of rewards … using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device …
in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
This limitation includes the step(s) of: in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
But for the computing system, databases, user device and/or GUI, this limitation is directed to processing and/or communicating known information to facilitate a method and system for rewards integration as a funding account which may be categorized as any of the following:
mental process – concepts performed in the human mind (including an observation, evaluation, judgment, opinion)
and/or
certain method of organizing human activity –
fundamental economic principles or practices (including hedging, insurance, mitigating risk), and/or
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations).
in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount…
As shown above, under Step 2A, Prong One, the claims recite a judicial exception (an abstract idea). The claims are directed to the abstract idea of rewards integration as a funding account, which, pursuant to MPEP 2106.04, is aptly categorized as a mental process and/or a method of organizing human activity. Therefore, under Step 2A, Prong One, the claims recite a judicial exception.
Next, the aforementioned claims recite additional functional elements that are associated with the judicial exception, including: graphical user interface for communicating information. Examiner understands these limitations to be insignificant extrasolution activity. (See Accenture, 728 F.3d 1336, 108 U.S.P.Q.2d 1173 (Fed. Cir. 2013), citing Cf. Diamond v. Diehr, 450 U.S. 175, 191-192 (1981) ("[I]nsignificant post-solution activity will not transform an unpatentable principle in to a patentable process.”).
The aforementioned claims also recite additional technical elements including: a computing system for implementing and executing the method and system, electronic databases for storing information, and GUI for communicating information. These limitations are recited at a high level of generality and appear to be nothing more than generic computer components. Claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp., 134 S. Ct. at 2358, 110 USPQ2d at 1983. See also 134 S. Ct. at 2389, 110 USPQ2d at 1984.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application?
No. The judicial exception is not integrated into a practical application. The additional elements listed above that relate to computing components are recited at a high level of generality (i.e., as generic components performing generic computer functions such as communicating, receiving, processing, analyzing, and outputting/displaying data) such that they amount to no more than mere instructions to apply the exception using generic computing components. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, the claims do not purport to improve the functioning of the computer itself. There is no technological problem that the claimed invention solves. Rather, the computer system is invoked merely as a tool. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, these claims are directed to an abstract idea.
Furthermore, looking at the elements individually and in combination, under Step 2A, Prong Two, the claims as a whole do not integrate the judicial exception into a practical application because they fail to: improve the functioning of a computer or a technical field, apply the judicial exception in the treatment or prophylaxis of a disease, apply the judicial exception with a particular machine, effect a transformation or reduction of a particular article to a different state or thing, or apply the judicial exception beyond generally linking the use of the judicial exception to a particular technological environment. Rather, the claims merely use a computer as a tool to perform the abstract idea(s), and/or add insignificant extra-solution activity to the judicial exception, and/or generally link the use of the judicial exception to a particular technological environment.
Step 2B: Does the Claim Provide an Inventive Concept?
Next, under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Simply put, as noted above, there is no indication that the combination of elements improves the functioning of a computer (or any other technology), and their collective functions merely provide conventional computer implementation. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements relating to computing components amount to no more than applying the exception using a generic computing components. Mere instructions to apply an exception using a generic computing component cannot provide an inventive concept. Furthermore, the broadest reasonable interpretation of the claimed computer components (i.e., additional elements) includes any generic computing components that are capable of being programmed to communicate, receive, send, process, analyze, output, or display data. Furthermore, Applicant’s Specification (PGPub. 2025/0104109 [0021; 0053-0055]) refers to a general computer system, but they do not include any technically-specific computer algorithm or code.
Additionally, pursuant to the requirement under Berkheimer, the following citations are provided to demonstrate that the additional elements, identified as extra-solution activity, amount to activities that are well-understood, routine, and conventional. See MPEP 2106.05(d).
Capturing an image (code) with an RFID reader. Ritter, US Patent No. 7734507 (Col. 3, Lines 56-67); “RFID: Riding on the Chip” by Pat Russo. Frozen Food Age. New York: Dec. 2003, vol. 52, Issue 5; page S22.
Receiving or transmitting data over a network. Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362; OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014).
Storing and retrieving information in memory. Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
Outputting/Presenting data to a user. Mayo, 566 U.S. at 79, 101 USPQ2d at 1968; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015); MPEP 2106.05(g)(3).
Using a machine learning model to determine user segment characteristics for an ad campaign. https://whites.agency/blog/how-to-use-machine-learning-for-customer-segmentation/.
Thus, taken alone and in combination, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea), and are ineligible under 35 USC 101.
Independent system claims 9 and independent method claim 18 also contains the identified abstract ideas, with the additional elements of a processor and storage medium, which are a generic computer components, and thus not significantly more for the same reasons and rationale above.
Dependent claims 2-8, 10-17, and 19-20 further describe the abstract idea. The additional elements of the dependent claims fail to integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea. Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
As such, the claims are not patent eligible.
Invention Could be Performed Manually
It is conceivable that the invention could be performed manually without the aid of machine and/or computer. For example, Applicant claims maintaining a database, communicating, receiving a transfer request, determining if an amount is higher than a conversion value, etc… Each of these features could be performed manually and/or with the aid of a simple generic computer to facilitate the transmission of data.
See also Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., and In re Venner, which stand for the concept that automating manual activity and/or applying modern electronics to older mechanical devices to accomplish the same result is not sufficient to distinguish over the prior art. Here, applicant is merely claiming computers to facilitate and/or automate functions which used to be commonly performed by a human.
Leapfrog Enterprises, Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 82 USPQ2d 1687 (Fed. Cir. 2007) "[a]pplying modern electronics to older mechanical devices has been commonplace in recent years…"). The combination is thus the adaptation of an old idea or invention using newer technology that is commonly available and understood in the art.
In In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958), the court held that broadly providing an automatic or mechanical means to replace manual activity which accomplished the same result is not sufficient to distinguish over the prior art. MPEP 2144.04, III Automating a Manual Activity.
MPEP 2144.04 III - Automating a Manual Activity and In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958) further stand for and provide motivation for using technology, hardware, computer, or server to automate a manual activity.
Therefore, the Office finds no improvements to another technology or field, no improvements to the function of the computer itself, and no meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Therefore, based on the two-part Alice Corp. analysis, there are no limitations in any of the claims that transform the exception (i.e., the abstract idea) into a patent eligible application.
Claim Rejections - Not an Ordered Combination
None of the limitations, considered as an ordered combination provide eligibility, because taken as a whole, the claims simply instruct the practitioner to implement the abstract idea with routine, conventional activity.
Claim Rejections - Preemption
Allowing the claims, as presently claimed, would preempt others from implementing a method and system for rewards integration as a funding account. Furthermore, the claim language only recites the abstract idea of performing this method, there are no concrete steps articulating a particular way in which this idea is being implemented or describing how it is being performed.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 9, 18 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040.
18/974,447 – Claim 1. Ameiss et al. 2010/0057553 teaches A computer-implemented method comprising: maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user (Ameiss et al. 2010/0057553 [0006 - querying a database associated with the at least one loyalty points account] In one aspect, the present invention provides a method for authorizing a redemption transaction in real-time, the method comprising: receiving, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, detecting that the account identifier is associated with a redemption card, communicating a redemption transaction message to a rewards system processor, identifying by the rewards system processor at least one loyalty account associated with the redemption card, determining a loyalty points equivalent to the transaction amount, querying a database associated with the at least one loyalty points account to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deducting the loyalty points equivalent from the at least one loyalty points account, determining a secondary payment mechanism to settle the redemption transaction, initiating a secondary payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount, receiving a secondary response to initiating the second payment transaction, and transmitting a financial transaction response message to said financial transaction message indicating that the financial transaction is authorized, in response to receiving the secondary response. [0007] In another aspect the present invention provides a points bank apparatus for authorizing a redemption transaction in real time, the apparatus comprising: a rewards system processor, a receiver configured to receive, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, the receiver further configured to receive a secondary response to the initiation of a secondary payment transaction, a routing unit, coupled to the receiver and to the rewards system processor, configured to detect that the account identifier is associated with a redemption card and to communicate a redemption transaction message to the rewards system processor, a database, coupled to the rewards system processor, associated with at least one loyalty points account associated with the redemption card, and a transmitter, coupled to the routing unit, configured to transmit a financial transaction response message to the financial transaction message indicating that the financial transaction is authorized in response to receiving the secondary response, wherein the rewards system processor is configured to identify the at least one loyalty points account associated with the redemption card, determine a loyalty points equivalent to the transaction amount, query the database to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deduct the loyalty points equivalent from the at least one loyalty points account, determine a secondary payment mechanism to settle the redemption transaction, and initiate the second payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount.); establishing, by the computing system, via a network, a communication session with a user device of the user (Ameiss et al. 2010/0057553 [0006 - communications] In one aspect, the present invention provides a method for authorizing a redemption transaction in real-time, the method comprising: receiving, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, detecting that the account identifier is associated with a redemption card, communicating a redemption transaction message to a rewards system processor, identifying by the rewards system processor at least one loyalty account associated with the redemption card, determining a loyalty points equivalent to the transaction amount, querying a database associated with the at least one loyalty points account to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deducting the loyalty points equivalent from the at least one loyalty points account, determining a secondary payment mechanism to settle the redemption transaction, initiating a secondary payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount, receiving a secondary response to initiating the second payment transaction, and transmitting a financial transaction response message to said financial transaction message indicating that the financial transaction is authorized, in response to receiving the secondary response. [0053 – messaging the cardholder/user] Additional account features may also be set up during registration. For example, if the LPO allows SMS messaging for account alerts and the cardholder has registered for this service, the points bank may set up these features. The points bank determines whether SMS and/or e-mail messaging information has been provided by the cardholder in 518. Messaging information may include whether the cardholder has chosen to receive the alerts, the predetermined events which will trigger notification, and a phone number or other address where the alerts are to be sent. If the cardholder has provided messaging information, the points bank sets up the messaging services in 520. Once all the account configurations have been set up, the points bank completes the registration at 522.[0070 - network]); receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account (Ameiss et al. 20100057553 [0044 – transfers…][0050 - rules for transferring the balance of the old loyalty points account to the loyalty points account linked with] After the points bank has received cardholder registration data, the points bank determines whether the cardholder has an existing loyalty points account in 504. If the cardholder does not have a pre-existing loyalty points account, the points bank may create a loyalty points account for the cardholder in the points bank in 506. The loyalty points account may then be linked with the redemption card at 508. More specifically, the loyalty points account may be linked with a redemption card number specified by the issuer. The redemption card number may be a PAN which is or will be located on the front of the redemption card and/or on other computer readable media on the card, such as an IC chip or magnetic stripe. If the cardholder already has an existing loyalty points account, the points bank may link a redemption card number specified by the issuer with the existing loyalty points account in 508. Alternatively, the LPO may specify that a new account should be created even if there is a pre-existing account to separate the new loyalty program from the old loyalty program. If this is the case, the LPO may also set rules for transferring the balance of the old loyalty points account to the loyalty points account linked with the redemption card. [0077 - If the requested transaction passes all rules and restrictions, the rewards system 716 determines whether the cardholder has sufficient points in the loyalty points account associated with the redemption card to cover the transaction amount… determining whether the loyalty points account contains sufficient points to cover the redemption transaction is illustrated in FIG. 9. … parameters are used to determine a loyalty points equivalent to the transaction amount. In FIG. 9, the rewards system 716 first converts the transaction amount of the requested transaction into a transaction amount points equivalent …] If the requested transaction passes all rules and restrictions, the rewards system 716 determines whether the cardholder has sufficient points in the loyalty points account associated with the redemption card to cover the transaction amount at 810. An exemplary embodiment of the process for determining whether the loyalty points account contains sufficient points to cover the redemption transaction is illustrated in FIG. 9. The rewards system 716 looks up VPP parameters at 902. VPP parameters may include base VPP levels and any VPP overrides. The VPP parameters have been set by the LPO 712 and/or the issuer 710. The VPP parameters are used to determine a loyalty points equivalent to the transaction amount. In FIG. 9, the rewards system 716 first converts the transaction amount of the requested transaction into a transaction amount points equivalent using the base VPP values at 904. For example, consider a redemption transaction in which the transaction amount is $100. Referring again to FIG. 3, the VPP for a transaction amount greater than or equal to $100 is 50 bps as seen in Table 302. 50 bps is equivalent to 1 pt per $0.50, so the rewards system 716 would calculate the transaction amount points equivalent (TAPE) as: [0098 - value of the points may also be transferred in person to person transfers or for person to business payment of bills. In such transfers, the accumulated points would be converted to cash in the same way they are for personal use of points for purchases. The cardholder may transfer the value of the points to any person, business, or entity] While the transfer of the value of the points has been described in relation to a transaction between the cardholder and a merchant, the process is not limited to such an embodiment. The value of the points may also be transferred in person to person transfers or for person to business payment of bills. In such transfers, the accumulated points would be converted to cash in the same way they are for personal use of points for purchases. The cardholder may transfer the value of the points to any person, business, or entity. [0102 - uniquely identify a cardholder's loyalty points account] In 1304, the consumer-facing interface, which may be the issuer, sends a request for the cardholder balance to the points bank. The request should contain some information which can be used to identify the loyalty points account to which the request pertains. This information may be the loyalty points account number, the redemption account number, or any other information which may be used to uniquely identify a cardholder's loyalty points account. [0105 - points bank may look up the necessary information (loyalty points account points balance, VPP levels associated with the loyalty points account) and send a response to the…] The points balance inquiry may also be initiated with the points bank. The points bank may have online and customer-service call-in channels to receive such requests. Other channels may also be used. For example, a cardholder may present the redemption card to the merchant at the point of sale and request a points balance inquiry. The merchant device will send the request to acquirer, which will send the request to the points bank. The points bank may look up the necessary information (loyalty points account points balance, VPP levels associated with the loyalty points account) and send a response to the acquirer without contacting the issuer. Alternatively, the points bank may send some information, such as a balance inquiry advice message, to the issuer. The acquirer forwards the balance inquiry response to the merchant, and the merchant presents the information to the cardholder in the form of a printed receipt or a visual display at the terminal.), the transfer request including a transfer amount and an identification of a recipient of the funds transfer (Ameiss et al. 20100057553 [0006 - account identifier and a transaction amount] In one aspect, the present invention provides a method for authorizing a redemption transaction in real-time, the method comprising: receiving, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, detecting that the account identifier is associated with a redemption card, communicating a redemption transaction message to a rewards system processor, identifying by the rewards system processor at least one loyalty account associated with the redemption card, determining a loyalty points equivalent to the transaction amount, querying a database associated with the at least one loyalty points account to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deducting the loyalty points equivalent from the at least one loyalty points account, determining a secondary payment mechanism to settle the redemption transaction, initiating a secondary payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount, receiving a secondary response to initiating the second payment transaction, and transmitting a financial transaction response message to said financial transaction message indicating that the financial transaction is authorized, in response to receiving the secondary response. [0077-0078 – determination is made about whether a cardholder has sufficient loyalty points] [0077] If the requested transaction passes all rules and restrictions, the rewards system 716 determines whether the cardholder has sufficient points in the loyalty points account associated with the redemption card to cover the transaction amount at 810. An exemplary embodiment of the process for determining whether the loyalty points account contains sufficient points to cover the redemption transaction is illustrated in FIG. 9. The rewards system 716 looks up VPP parameters at 902. VPP parameters may include base VPP levels and any VPP overrides. The VPP parameters have been set by the LPO 712 and/or the issuer 710. The VPP parameters are used to determine a loyalty points equivalent to the transaction amount. In FIG. 9, the rewards system 716 first converts the transaction amount of the requested transaction into a transaction amount points equivalent using the base VPP values at 904. For example, consider a redemption transaction in which the transaction amount is $100. Referring again to FIG. 3, the VPP for a transaction amount greater than or equal to $100 is 50 bps as seen in Table 302. 50 bps is equivalent to 1 pt per $0.50, so the rewards system 716 would calculate the transaction amount points equivalent (TAPE) as: TAPE = $100 .times. 1 point $0 .50 = 200 points ##EQU00001## [0078] Referring again to FIG. 9, if the rewards system 716 determines that any of the VPP overrides associated with the cardholder's loyalty points account apply to the requested transaction at 906, the rewards system 716 calculates the transaction amount points equivalent using the appropriate VPP override rate. For example, consider the situation in which the merchant 704 is Merchant 2 referenced in Table 304 of FIG. 3. The override VPP rate in Table 304 would apply to the requested transaction with Merchant 2. Assuming that 100 bps is equal to 1 pt per $1, the rewards system 716 would calculate the transaction amount points equivalent as: [0102] In 1304, the consumer-facing interface, which may be the issuer, sends a request for the cardholder balance to the points bank. The request should contain some information which can be used to identify the loyalty points account to which the request pertains. This information may be the loyalty points account number, the redemption account number, or any other information which may be used to uniquely identify a cardholder's loyalty points account.), the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface (Ameiss et al. 2010/0057553 [0041; 0047; 0058; web interface interpreted as GUI][0102; 0104 – consumer-facing interface interpreted as GUI]) of the client application using an input/output device of the user device (Ameiss et al. 2010/0057553 [0047 - using a web interface, the cardholder may, prior to conducting a transaction at the point of sale, specify particular merchants, merchant categories, transaction amounts, or other transaction characteristics for transactions that should be applied to the cardholder's loyalty points account, or that should not be applied to a cardholder's loyalty points account] The cardholder may further be required or choose to provide cardholder-supplied controls, rules, or restrictions for redemption transactions. For instance, using a web interface, the cardholder may, prior to conducting a transaction at the point of sale, specify particular merchants, merchant categories, transaction amounts, or other transaction characteristics for transactions that should be applied to the cardholder's loyalty points account, or that should not be applied to a cardholder's loyalty points account. For example, the cardholder may request that payment card A be used to fund gas and food purchases, but payment card B be used to fund all other purchases. Processing of the transaction would then proceed accordingly. In this manner, a cardholder is able to use a single payment card at all merchants, but have the individual transaction settled using different payment mechanisms, including loyalty point accounts, depending on the transaction details, while requiring no modifications to the merchant/acquirer infrastructure. [0058 - The cardholder enters transaction parameters for a selected transaction] However, the cardholder may use the points balance of a loyalty points account before the card is activated. A virtual card account number (VCN) may be generated by the issuer of the redemption card, or by the points bank. The cardholder may log on to a web interface configured to generate a VCN. The cardholder enters transaction parameters for a selected transaction. The transaction parameters may include merchant information for a transaction. Generally, the merchant information will identify a website where the cardholder wishes to shop. The transaction parameters may include a dollar amount instead of, or in addition to a merchant identifier. The dollar amount may refer to the price for a particular item, or it may be a general limit on the amount that can be spent using that VCN. Other information may also be entered by the cardholder. The issuer generates a VCN such as a virtual PAN (VPAN) and links the VCN with the cardholder's loyalty points account. During authorization of a transaction, if the points bank receives the VCN, the points bank will check that the transaction parameters are met for the requested redemption transaction. If all of the transaction parameters are not met, the authorization request will be denied. If all of the transaction parameters are met, the requested redemption transaction will be processed as a regular redemption transaction as described herein. A VCN may also be used after the cardholder has received and activated the redemption card. [0080 - query of the points database may be performed using well-known techniques, such as a web API or other approaches to querying a database] Referring again to FIG. 9, the rewards system 716 looks up the points balance of the loyalty points account associated with the cardholder 702 at 910. This query of the points database may be performed using well-known techniques, such as a web API or other approaches to querying a database. Finally, the rewards system 716 compares the points balance to the transaction amount points equivalent at 912.); determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account (Ameiss et al. 20100057553 [Figs. 8-9; 0083-0084] [0083] Referring again to FIG. 8, the rewards system determines whether the cardholder's loyalty points account has sufficient points to pay for the transaction at 810. If the cardholder's point balance is greater than the transaction amount point equivalent, the rewards system 716 updates the points balance of the cardholder's loyalty points account to reflect the transaction at 812. The transaction amount points equivalent is subtracted from the points balance to calculate an updated points balance for the cardholder's loyalty points account. The rewards system 716 also selects the loyalty program funding account as the secondary payment account for the transaction at 814. For example, the rewards system may select the LPO's corporate card account by selecting a PAN associated with the LPO's corporate card. [0084] If the cardholder's loyalty points account does not have sufficient points to fund the transaction (i.e., the cardholder's points balance is less than the transaction amount point equivalent), the rewards system 716 determines whether an alternate funding account has been specified by the cardholder 702 at 816. If no alternate funding account has been specified by the cardholder 702, the transaction may be declined at 818. If the cardholder 702 has specified an alternate funding account, the rewards system 716 selects the alternate funding account as the funding account for the requested transaction. The rewards system 716 may also update the usage count and check to make sure the use of the alternate funding account is acceptable based on limits of consecutive usage of the alternate funding account. If the updated usage count is higher than the allowed usage count, the points bank declines the transaction.); transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify (Ameiss et al. 2010/0057553 [0042 - if the amount of points is insufficient to fund a transaction, and whether SMS or other messaging is enabled] In addition to rules, restrictions, controls, and VPP levels, the LPO may also configure additional settings. For example, the LPO may configure a way for points to be activated/deactivated. Generally, points will be activated when they are earned. Additionally, the points will have a LPO-provided expiration date and will expire if they are not used within a pre-determined period, such as 6 months. A first in-first out (FIFO) processing system might be used to redeem the points, so that the oldest points (i.e., the points with the earliest expiration date) will be used to cover a redemption transaction before the newest points. The LPO may also specify whether an alternate funding source may be used if the amount of points is insufficient to fund a transaction, and whether SMS or other messaging is enabled. [0094 - message may include the reasons for the denial (insufficient points, rules fail) and the current points balance of the cardholder's loyalty points account] The redemption authorization process may include additional features. For example, the points bank or issuer may send SMS text messages to or otherwise communicate with the cardholder upon the occurrence of predetermined events defined by the cardholder or the LPO. The issuer may send a message to the cardholder if the transaction is denied (e.g., in FIG. 8 at 808). The message may include the reasons for the denial (insufficient points, rules fail) and the current points balance of the cardholder's loyalty points account. The issuer may also send a message to the cardholder if the cardholder's alternate funding account is used to fund the transaction. The message may include the reasons that the redemption card was not approved and any transaction information including, if available, the current balance of the alternate funding account. The issuer may further send a message to the cardholder if the redemption card is authorized. The message may include the transaction amount points equivalent and the updated balance of the cardholder's loyalty points account. The message may be sent by SMS text, email, or any other method. [0056 - the cardholder may be prompted at the point of sale to indicate…] While the redemption card may be a new card, the redemption card may also be the original loyalty program card, wherein a cardholder may use the same card to earn and burn (accumulate and redeem) loyalty points. In such a one-card solution, the cardholder may specify in advance when the redemption card features should be used, as previously described. Alternatively, the cardholder may be prompted at the point of sale to indicate whether the redemption card features should be used. In another embodiment, the card may have two magstripes, and the cardholder determines whether to use the redemption card features by swiping the appropriate magstripe.), using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account (Ameiss et al. 20100057553 [Figs. 9, 13, 14 – balance inquiry process; 0094 - message may include the reasons for the denial ( insufficient points, rules fail) and the current points balance of the cardholder's loyalty points account] The redemption authorization process may include additional features. For example, the points bank or issuer may send SMS text messages to or otherwise communicate with the cardholder upon the occurrence of predetermined events defined by the cardholder or the LPO. The issuer may send a message to the cardholder if the transaction is denied (e.g., in FIG. 8 at 808). The message may include the reasons for the denial ( insufficient points, rules fail) and the current points balance of the cardholder's loyalty points account. The issuer may also send a message to the cardholder if the cardholder's alternate funding account is used to fund the transaction. The message may include the reasons that the redemption card was not approved and any transaction information including, if available, the current balance of the alternate funding account. The issuer may further send a message to the cardholder if the redemption card is authorized. The message may include the transaction amount points equivalent and the updated balance of the cardholder's loyalty points account. The message may be sent by SMS text, email, or any other method.); (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device (Ameiss et al. 2010/0057553 [0080-0087 – rewards system determines balance, converts points to cash equivalents, determine if account has sufficient or insufficient points or other balance to complete a transaction or transfer, etc…][0042 - The LPO may also specify whether an alternate funding source may be used if the amount of points is insufficient to fund a transaction, and whether SMS or other messaging is enabled] In addition to rules, restrictions, controls, and VPP levels, the LPO may also configure additional settings. For example, the LPO may configure a way for points to be activated/deactivated. Generally, points will be activated when they are earned. Additionally, the points will have a LPO-provided expiration date and will expire if they are not used within a pre-determined period, such as 6 months. A first in-first out (FIFO) processing system might be used to redeem the points, so that the oldest points (i.e., the points with the earliest expiration date) will be used to cover a redemption transaction before the newest points. The LPO may also specify whether an alternate funding source may be used if the amount of points is insufficient to fund a transaction, and whether SMS or other messaging is enabled. [0006-0007; 0083; 0099] [0006] In one aspect, the present invention provides a method for authorizing a redemption transaction in real-time, the method comprising: receiving, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, detecting that the account identifier is associated with a redemption card, communicating a redemption transaction message to a rewards system processor, identifying by the rewards system processor at least one loyalty account associated with the redemption card, determining a loyalty points equivalent to the transaction amount, querying a database associated with the at least one loyalty points account to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deducting the loyalty points equivalent from the at least one loyalty points account, determining a secondary payment mechanism to settle the redemption transaction, initiating a secondary payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount, receiving a secondary response to initiating the second payment transaction, and transmitting a financial transaction response message to said financial transaction message indicating that the financial transaction is authorized, in response to receiving the secondary response. [0007] In another aspect the present invention provides a points bank apparatus for authorizing a redemption transaction in real time, the apparatus comprising: a rewards system processor, a receiver configured to receive, from an acquirer financial message generation system, a financial transaction message comprising transaction data, the transaction data comprising an account identifier and a transaction amount, the receiver further configured to receive a secondary response to the initiation of a secondary payment transaction, a routing unit, coupled to the receiver and to the rewards system processor, configured to detect that the account identifier is associated with a redemption card and to communicate a redemption transaction message to the rewards system processor, a database, coupled to the rewards system processor, associated with at least one loyalty points account associated with the redemption card, and a transmitter, coupled to the routing unit, configured to transmit a financial transaction response message to the financial transaction message indicating that the financial transaction is authorized in response to receiving the secondary response, wherein the rewards system processor is configured to identify the at least one loyalty points account associated with the redemption card, determine a loyalty points equivalent to the transaction amount, query the database to determine if the balance of loyalty points associated with the account is at least as large as the loyalty points equivalent and, if the result is that sufficient points are present, deduct the loyalty points equivalent from the at least one loyalty points account, determine a secondary payment mechanism to settle the redemption transaction, and initiate the second payment transaction against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount. [0083] Referring again to FIG. 8, the rewards system determines whether the cardholder's loyalty points account has sufficient points to pay for the transaction at 810. If the cardholder's point balance is greater than the transaction amount point equivalent, the rewards system 716 updates the points balance of the cardholder's loyalty points account to reflect the transaction at 812. The transaction amount points equivalent is subtracted from the points balance to calculate an updated points balance for the cardholder's loyalty points account. The rewards system 716 also selects the loyalty program funding account as the secondary payment account for the transaction at 814. For example, the rewards system may select the LPO's corporate card account by selecting a PAN associated with the LPO's corporate card. [0099] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars. [0096 – appropriate processing is performed to settle the remainder of the transaction using the cardholder's alternate funding account] However, if the LPO does allow split tender transactions, the split tender transaction is processed at 1212. For example, the entire balance of loyalty points may first be deducted from the account and the remaining portion of the transaction amount may be applied to the cardholder's alternative funding account, including an alternative loyalty points account. Alternatively, if the LPO requires points to be deducted in batch units (i.e., only in groups of 50, 100, etc.), appropriate processing is performed to settle the remainder of the transaction using the cardholder's alternate funding account. Regardless of how the split tender transaction is processed, the points bank updates the points balance using the split tender points amount at 1214 and selects the loyalty program funding account, such as the LPO's corporate card account, for the points portion of the split tender transaction at 1216. The split tender points amount is the points equivalent of the points portion of the split tender transaction.); and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards (Ameiss et al. 20100057553 [0083 – updating points balance in user’s account to reflect transaction interpreted as debiting customer rewards amount of points…] Referring again to FIG. 8, the rewards system determines whether the cardholder's loyalty points account has sufficient points to pay for the transaction at 810. If the cardholder's point balance is greater than the transaction amount point equivalent, the rewards system 716 updates the points balance of the cardholder's loyalty points account to reflect the transaction at 812. The transaction amount points equivalent is subtracted from the points balance to calculate an updated points balance for the cardholder's loyalty points account. The rewards system 716 also selects the loyalty program funding account as the secondary payment account for the transaction at 814. For example, the rewards system may select the LPO's corporate card account by selecting a PAN associated with the LPO's corporate card. [0096] However, if the LPO does allow split tender transactions, the split tender transaction is processed at 1212. For example, the entire balance of loyalty points may first be deducted from the account and the remaining portion of the transaction amount may be applied to the cardholder's alternative funding account, including an alternative loyalty points account. Alternatively, if the LPO requires points to be deducted in batch units (i.e., only in groups of 50, 100, etc.), appropriate processing is performed to settle the remainder of the transaction using the cardholder's alternate funding account. Regardless of how the split tender transaction is processed, the points bank updates the points balance using the split tender points amount at 1214 and selects the loyalty program funding account, such as the LPO's corporate card account, for the points portion of the split tender transaction at 1216. The split tender points amount is the points equivalent of the points portion of the split tender transaction. [0099] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars.); and in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer (Ameiss et al. 20100057553 [0099 – completing a transaction without converting points or rewards to currency] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars. [0058] However, the cardholder may use the points balance of a loyalty points account before the card is activated. A virtual card account number (VCN) may be generated by the issuer of the redemption card, or by the points bank. The cardholder may log on to a web interface configured to generate a VCN. The cardholder enters transaction parameters for a selected transaction. The transaction parameters may include merchant information for a transaction. Generally, the merchant information will identify a website where the cardholder wishes to shop. The transaction parameters may include a dollar amount instead of, or in addition to a merchant identifier. The dollar amount may refer to the price for a particular item, or it may be a general limit on the amount that can be spent using that VCN. Other information may also be entered by the cardholder. The issuer generates a VCN such as a virtual PAN (VPAN) and links the VCN with the cardholder's loyalty points account. During authorization of a transaction, if the points bank receives the VCN, the points bank will check that the transaction parameters are met for the requested redemption transaction. If all of the transaction parameters are not met, the authorization request will be denied. If all of the transaction parameters are met, the requested redemption transaction will be processed as a regular redemption transaction as described herein. A VCN may also be used after the cardholder has received and activated the redemption card.), wherein the funds transfer includes a transfer of rewards and a transfer of currency (Ameiss et al. 20100057553 [0044 - Settlement may occur in U.S. dollars or in any other currency acceptable by both parties to the settlement transaction] Clearing and settlement may occur by any of the techniques well known in the art, including through the MasterCard Global Clearing Management System (GCMS). The clearing system as described herein may be the GCMS, but it also may be any other system capable of performing clearing functions. Clearing generally occurs periodically (e.g., once a day), but may occur at any periodic or non-periodic interval. The merchant's bank (the acquirer) sends purchase information to the clearing system. This may be done individually or in combination with purchase information regarding other transactions. The purchase information may include the amount due to the acquirer. The clearing system then identifies an issuer associated with the payment mechanism used to fund the transaction (e.g., the loyalty program funding account used to fund the redemption transaction). The clearing system calculates the amount that needs to be transferred between the issuer and the acquirer to reconcile the transaction in combination with any other transaction using a payment mechanism associated with the same issuer. The clearing system may also validate the purchase information. The clearing system then sends a message to the issuer. This message may indicate the amount that needs to be transferred to the acquirer to reconcile the transactions, the purchase information, and any other information regarding the reconciliation. The acquirer and the issuer will later settle the transaction. The actual exchange of funds takes place between a clearing bank and a settlement bank. Settlement may occur in U.S. dollars or in any other currency acceptable by both parties to the settlement transaction.).
Ameiss et al. 20100057553 may not expressly disclose the “a transfer request to make a funds transfer using rewards” features, however, Hunt 2010/0257040 teaches these features as follows (Hunt 2010/0257040 [Claim 19 – using reward points to make a funds transfer where points are converted to an amount of money at an agreed exchange rate] 19. A method of electronic payment using reward points, comprising: (a) enabling a shopper to interactively specify a number of reward points to be withdrawn from a reward account provided by a reward program manager; (b) electronically requesting that said program manager redeem said number of reward points from said reward account; (c) redeeming by said program manager said number of reward points from said reward account by electronically transferring a corresponding amount of money, using an agreed to exchange rate to convert from points to money, into a card funding account that is used to pay for purchases by the shopper; (d) creating a virtual credit card for said card funding account to enable payment for the items purchased by the shopper using money in the card funding account; (e) providing to the shopper a unique shopper identifier that links to said virtual credit card to be used for purchases of items at merchants' e-commerce websites; (f) enabling the shopper to interactively select one or more items from one or more merchants' e-commerce websites; (g) enabling the shopper to provide said unique shopper identifier as a means of payment to the merchants' e-commerce websites; (h) enabling each merchant to request information about the virtual credit card that corresponds to said unique shopper identifier; and (i) providing said information about the virtual credit to each merchant for obtaining payment for the shopper's purchases. [0045 - e-commerce server 110 prompts shopper 105 to pay the balance of the order, i.e the portion not covered by his/her reward points using an additional payment method] Shopper 105 may use multiple payment methods to pay for an order. For example, shopper 105 may pay for one part of an order using reward points and the remaining part using a credit card. Also, it may occur that the reward program account for shopper 105 does not contain sufficient reward points to pay for the full order. In this case, e-commerce server 110 prompts shopper 105 to pay the balance of the order, i.e the portion not covered by his/her reward points using an additional payment method. Shopper 105 may select another reward program account as the method of payment for the balance. Alternatively, shopper 105 may select a credit card as the method of payment for the balance. In this case, e-commerce server 110 sends credit card settlement instructions to a shopper's bank 125. Shopper's bank 125 then makes the requested payment into the card funding account for shopper 105 located in payment system bank 115. It may be appreciated by one skilled in the art that payment methods in addition to reward points and credit card including inter alia debit card and electronic funds transfer systems such as PAYPAL may be provided by reward points payment system 100. PAYPAL is an online payment system owned and operated by eBay, Inc. of San Jose, Calif. [0053 - Shopper 105 is further prompted in reward points dialog box 226 to provide his/her reward program account name and reward program account password] Reference is now made to FIG. 2B which is an example shopper interface that enables a shopper to pay for his/her selections using reward points and to provide shipping, payment and billing information for his/her order, in accordance with an embodiment of the present invention. Typically, every web page provided by the multi-merchant website includes a navigation control that enables shopper 105 to visit his/her shopping cart. Several of the capabilities provided by a shopping cart are shown in example shopper interface 220. Shopper 105 may select a ship to address from a menu of ship to addresses 222 that he/she has previously supplied. Alternatively, shopper 105 may add a new ship to address. Shopper 105 may select a payment method using a payment method menu 224. If shopper 105 selects "Reward Points" as the payment method then a reward points dialog box 226 appears that enables shopper 105 to select a reward program account that he/she wishes to use to pay for the items he/she has added to the shopping cart. Shopper 105 is further prompted in reward points dialog box 226 to provide his/her reward program account name and reward program account password. The amount of the order, in reward points, appears in an amount requested field within reward points dialog box 226. Shopper 105 may change the amount requested. If he/she changes the amount requested to be less than the order total then he/she must subsequently provide another method of payment to pay the remaining balance. If he/she requests an amount greater than the order total then his/her account will be credited with the difference. [0058 - e-commerce server 110 prompts shopper 105 to provide information including method of payment] At step 310 e-commerce server 110 prompts shopper 105 to provide information including method of payment. At step 315 shopper 105 selects "REWARD POINTS" as his/her method of payment, provides the requested reward program account information and indicates the number of points requested. At step 320 e-commerce server sends a redemption request message to reward points system 120 to redeem the number of reward points requested at step 315. At step 325 reward points system 120 makes a payment by electronically transferring the requested amount, based on the agreed to reward points to currency exchange rate, to the card funding account for shopper 105 in payment system bank 115. [0060 - is informed that the amount of money paid by reward points system 120 at step 325 is insufficient to cover the order and is prompted to select a supplemental method of payment to pay the remaining amount] Steps 335-355 are only performed if the payment made by reward points system 120 is less than the amount of the order. This may happen if there are insufficient reward points in the reward program account of shopper 105 to cover the full amount of the order or if shopper 105 requested a number of points at step 315 that is less than the number of points required to pay for the entire order. At Step 335 shopper 105 is informed that the amount of money paid by reward points system 120 at step 325 is insufficient to cover the order and is prompted to select a supplemental method of payment to pay the remaining amount. In one embodiment, shopper 105 may select any method of payment that has not previously failed to generate the full amount of money or points requested. For example, shopper 105 may select a credit card, different reward program, or PAYPAL as a supplemental method of payment. [0084 - If shopper 105 is not a registered shopper, then transaction manager 640 prompts shopper 105 to register with e-commerce server] After shopper 105 makes his/her selection of items, a transaction manager 640 enables shopper 105 to check out, i.e. provide information necessary to complete the order, and review details of the order. If shopper 105 is not a registered shopper, then transaction manager 640 prompts shopper 105 to register with e-commerce server 110. In this case, transaction manager 640 creates a new record in shopper account database 625 for the new shopper.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Ameiss et al. 20100057553 to include the transfer request to make a funds transfer using rewards points features as taught by Hunt 2010/0257040. One of ordinary skill in the art would have been motivated to do so to provide a convenient way for customers to use a combination of reward points and cash or credit to pay for food/goods or services which should prove to improve user experience, maximize profits, and optimize revenue.
18/974,447 – Claim 18. Ameiss et al. 2010/0057553 further teaches A computer-implemented method comprising: … debiting the specified amount of rewards from the rewards account and debiting the remainder amount from a selected payment account associated with the user (Ameiss et al. 2010/0057553 [0099] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars.).
18/974,447 – Claim 9. A computing system comprising: a network interface structured to facilitate data communication via a network; an electronic accounts database storing information associated with a rewards account of a user; and one or more processors configured to: establish, via the network interface, a communication session with a user device of the user; receive, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device; determine, by accessing the electronic accounts database, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account; transmitting, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and in response to receiving, from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account so that rewards are used for completing the funds transfer, wherein the funds transfer includes a transfer of rewards and a transfer of currency.
18/974,447 – Claim 18. A computer-implemented method comprising: maintaining, by a computing system, one or more electronic databases comprising information associated with a rewards account of a user; establishing, by the computing system, via a network, a communication session with a user device of the user; receiving, by the computing system via the network, during the communication session with the user device, from a client application executing on the user device, a transfer request, initiated by the user using the client application, to make a funds transfer using rewards in the rewards account, the transfer request including a transfer amount and an identification of a recipient of the funds transfer, the transfer amount and the identification of the recipient having been entered by the user via a graphical user interface of the client application using an input/output device of the user device; determining, by the computing system, by accessing the one or more electronic databases, that the transfer amount is higher than a conversion value corresponding to a balance in the rewards account; transmitting, by the computing system, in response to determining that the transfer amount is higher than the conversion value, to the user device during the communication session, an indication that the transfer request is to be carried out using a combination of the rewards and a second source of funds, causing the client application to present: (i) an insufficient funds message indicating that the balance is insufficient to complete the funds transfer; (ii) a prompt for the user to specify, using the input/output device of the user device, an amount of rewards to use for the funds transfer that is equal to or less than the balance in the rewards account; (iii) a remainder amount indicating funds needed to cover a shortfall of the funds transfer, the shortfall determined based on a difference between the specified amount of rewards and the transfer amount, wherein the displayed remainder amount is updated, in the client application, based on the amount of rewards specified via the prompt using the input/output device; and (iv) a submit transfer prompt to allow the user to use the input/output device of the user device to select to proceed with the funds transfer using the specified amount of rewards; and in response to receiving, by the computing system from the user device during the communication session, a submit transfer input via the submit transfer prompt in the client application executing on the user device, debiting the specified amount of rewards from the rewards account and debiting the remainder amount from a selected payment account associated with the user.
Claims 9 and 18, have similar limitations as of Claim 1, therefore they are REJECTED under the same rationale as Claim 1.
Claims 2, 10, 11 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040.
18/974,447 – Claim 2. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 1, further comprising debiting the remainder amount from a selected account associated with the user (Ameiss et al. 2010/0057553 [0043 - settle with the issuer through a debit account] Returning to FIG. 2, the issuer may extend a line of credit to the LPO in 208. The line of credit may be associated with a payment mechanism, such as by the issuance of a corporate card with a credit line. The corporate card may have large transaction frequency limits. The line of credit may be used to fund redemption transactions. An acquiring bank must receive funds from the issuer in a credit or debit transaction. However, a loyalty points account cannot fund this transaction because loyalty points have no inherent value outside of the loyalty program. The line of credit may be used to fund the issuer's payment to the acquirer. The issuer settles with the acquirer and charges the LPO through the LPO's corporate card. The issuer later reconciles with the LPO through the LPO's corporate card account by receiving payment from the LPO on the credit balance of the account. In other embodiments, the LPO may settle with the issuer through a debit account linked to a corporate card account or through any other funding account such as ACH, or other funding mechanisms. The account through which the LPO settles with the issuer is called the loyalty program funding account. While the authorization process is described using a payment card account associated with the corporate card, it should be understood that the points bank and/or issuer may identify any account as the loyalty program funding account without departing from the scope of the invention. [0067 - points bank may debit the transaction amount from a debit account used as the secondary payment account, or it may post the transaction amount against a credit account used as the secondary payment amount] In 606, a secondary payment transaction is initiated against the secondary payment mechanism in an amount sufficient to satisfy the transaction amount. This may consist of the points bank deducting the transaction amount from the secondary payment account. For example, the points bank may debit the transaction amount from a debit account used as the secondary payment account, or it may post the transaction amount against a credit account used as the secondary payment amount. Note that the amount charged to the secondary account may not match the amount of the redemption transaction. For instance, a premium or other service fees may be applied to the transaction amount before settlement, as will be understood by persons skilled in the art. The initiation of the secondary payment transaction may also consist of sending an authorization request to the issuer requesting authorization of the transaction and specifying the secondary payment account as the funding account. The issuer will then process the request in the regular manner, as though it was an authorization request from the acquirer wherein a payment device associated with that secondary account had been presented to the merchant. [0099] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars.).
18/974,447 – Claim 10. The computing system of claim 9, wherein the one or more processors are further configured to transfer the remainder amount from a selected account associated with the user.
18/974,447 – Claim 11. The computing system of claim 10, wherein the one or more processors are configured to debit the remainder amount from a payment account of the user.
Claims 10 and 11, have similar limitations as of Claim(s) 2, therefore it is REJECTED under the same rationale as Claim(s) 2.
Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040; in further view of Rahman et al. 2014/0279417.
18/974,447 – Claim 3. The computer-implemented method of claim 1, Ameiss et al. 20100057553 may not expressly disclose the “peer-to-peer” features, however, Rahman et al. 2014/0279417 teaches wherein the funds transfer is a peer-to-peer (P2P) funds transfer (Rahman et al. 2014/0279417 [0025 - the system enables collaborative peer-to-peer fund transfers between registered users] These components may have various configurations, as further described herein. Together, the system enables collaborative peer-to-peer fund transfers between registered users. Registered users receive a debit card, and the debit card's balance (i.e. the funds available) is stored at the funding source 190. The registered users can transfer funds between cards. A sender may initiate a transfer of funds to a recipient via a SMS message sent to the SMS Gateway 120.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Ameiss et al. 20100057553 to include the peer-to-peer features as taught by Rahman et al. 2014/0279417. One of ordinary skill in the art would have been motivated to do so to provide a convenient way for users to transfer funds directly (e.g., peer-to-peer) which should prove to improve user experience, maximize profits, and optimize revenue.
18/974,447 – Claim 12. The computing system of claim 9, wherein the funds transfer is a peer-to-peer (P2P) funds transfer.
Claim 12, has similar limitations as of Claim(s) 3, therefore it is REJECTED under the same rationale as Claim(s) 3.
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040; in further view of Rahman et al. 2014/0279417; in view of Salmon et al. 2010/0211469.
18/974,447 – Claim 4. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 3, wherein the P2P funds transfer is funded with a combination of the reward points amount and currency (Ameiss et al. 2010/0057553 [0044] Clearing and settlement may occur by any of the techniques well known in the art, including through the MasterCard Global Clearing Management System (GCMS). The clearing system as described herein may be the GCMS, but it also may be any other system capable of performing clearing functions. Clearing generally occurs periodically (e.g., once a day), but may occur at any periodic or non-periodic interval. The merchant's bank (the acquirer) sends purchase information to the clearing system. This may be done individually or in combination with purchase information regarding other transactions. The purchase information may include the amount due to the acquirer. The clearing system then identifies an issuer associated with the payment mechanism used to fund the transaction (e.g., the loyalty program funding account used to fund the redemption transaction). The clearing system calculates the amount that needs to be transferred between the issuer and the acquirer to reconcile the transaction in combination with any other transaction using a payment mechanism associated with the same issuer. The clearing system may also validate the purchase information. The clearing system then sends a message to the issuer. This message may indicate the amount that needs to be transferred to the acquirer to reconcile the transactions, the purchase information, and any other information regarding the reconciliation. The acquirer and the issuer will later settle the transaction. The actual exchange of funds takes place between a clearing bank and a settlement bank. Settlement may occur in U.S. dollars or in any other currency acceptable by both parties to the settlement transaction. [0051] The points bank next determines whether an alternate funding source has been provided by the cardholder in 510. This step may be skipped if the LPO has specified that the redemption card may not be linked to an alternate funding source. The alternate funding source may be the points earning card, a credit card, a debit card, a home equity line of credit, or any other funding account. If the cardholder has provided an alternate funding source, the points bank links the alternate funding source to the loyalty points account and/or the redemption card in 512. Alternatively, the LPO may indicate that the co-branded card must be the alternate funding source.).
Ameiss et al. 20100057553 may not expressly disclose the “combination” features, however, Salmon et al. 2010/0211469 teaches is funded with a combination of the reward points amount and currency (Salmon et al. 2010/0211469 [0076 – split tender sale where customer pays with points and credit card] When undertaking a transaction against multiple accounts (including a combination of monetary and non-monetary points-based accounts), customer 1308 may elect to enter into a split tender sale. A split tender sale involves a transaction where customer 1308 may pay for part of a transaction with points, and part with another form of payment such as a credit, debit or prepaid account. For example, customer 1308 may wish to purchase an item for $100 using two accounts, one a conventional credit card account and the other a non-monetary points-based account. At the POS provided by merchant 1310, customer 1308 can check the monetary value or balance of the points available in customer 1308's non-monetary points-based account. If the monetary value of the non-monetary points-based account is insufficient, the customer 1308 may instruct the merchant 1310 via the POS to pay for the $100 using all available points, and applying the balance of the transaction to the credit card account. During operation of the present system, the customer 1308 can elect to the cancel the transaction, or select an alternative payment method at any time prior to the merchant 1310 transmitting the request for authorization and related transaction information to the transaction handler 1302.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Ameiss et al. 20100057553 to include the combination features as taught by Salmon et al. 2010/0211469. One of ordinary skill in the art would have been motivated to do so to provide a convenient way for customers to use a combination of reward points and cash or credit to pay for food/goods or services which should prove to improve user experience, maximize profits, and optimize revenue.
18/974,447 – Claim 13. The computing system of claim 12, wherein the P2P funds transfer is at least partly funded with the reward amount.
Claim 13, has similar limitations as of Claim(s) 4, therefore it is REJECTED under the same rationale as Claim(s) 4.
Claims 5, 14, 15 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040.
18/974,447 – Claim 5. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 1, wherein the identification of the recipient comprises at least one of a recipient name or a recipient account number (Ameiss et al. 20100057553 [0046] The cardholder may be required to provide certain registration data to the merchant, LPO and/or issuer. This registration data may include personal identification information such as the cardholder's name, address, phone number, or similar information. The registration information may also include loyalty points account information for cardholders who are previously enrolled in the linked loyalty program. Alternatively, the merchant and/or issuer may have all necessary information for cardholders previously enrolled in the loyalty program. The cardholder may also be required or choose to provide additional information. For example, the cardholder may choose to receive messages from the merchant, issuer, or points bank for various reasons. For example, the cardholder may choose to receive notification of predetermined events or promotional and/or marketing messages. If the cardholder chooses to receive such messages, the cardholder can provide a mobile phone number and specify the predetermined events which will result in messages.).
18/974,447 – Claim 14. The computing system of claim 9, wherein the identification of the recipient comprises a recipient name.
18/974,447 – Claim 15. The computing system of claim 9, wherein the identification of the recipient comprises a recipient account number.
Claims 14 and 15, have similar limitations as of Claim 5, therefore they are REJECTED under the same rationale as Claim(s) 5.
Claims 6, 17, 19 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040.
18/974,447 – Claim 6. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 1, wherein rewards are used for the funds transfer without converting the specified amount of rewards to a currency value that is then used for completing the funds transfer (Ameiss et al. 20100057553 [0099 – completing a transaction without converting points or rewards to currency] While the authorization process above turns points into a monetary value for the purposes of settling a transaction, the redemption card program may also include other ways of spending points. A redemption card program need not exclude the features of prior art loyalty programs. For example, the LPO may offer pre-existing catalogs with special offers as an alternate option for the redemption of points. Other features of prior art loyalty programs may also be incorporated. Another way loyalty points can be used is in exchange for a discount on a selected item. A merchant may indicate that in exchange for a certain amount of points, the cardholder will receive a discount on an item. If the merchant includes this information in the transaction message sent to the acquirer and then to the points bank, the points bank may deduct this points amount from the loyalty points account associated with the cardholder and charge the discounted rate to the alternate funding account. Notably, in this embodiment, it may not be necessary to convert a transaction amount into an equivalent points value, as the points amount be directly able to be deducted. However, if the redemption card being used is associated with a different loyalty points program than the one operated by the merchant, the LPO may need to convert the points value associated with the transaction into an equivalent number of loyalty points for the loyalty program associated with the redemption card being used. In such a case, conversion tables, similar to those shown in FIG. 3, could be used, but with points to points conversion ratios employed, rather than points to dollars. [0058] However, the cardholder may use the points balance of a loyalty points account before the card is activated. A virtual card account number (VCN) may be generated by the issuer of the redemption card, or by the points bank. The cardholder may log on to a web interface configured to generate a VCN. The cardholder enters transaction parameters for a selected transaction. The transaction parameters may include merchant information for a transaction. Generally, the merchant information will identify a website where the cardholder wishes to shop. The transaction parameters may include a dollar amount instead of, or in addition to a merchant identifier. The dollar amount may refer to the price for a particular item, or it may be a general limit on the amount that can be spent using that VCN. Other information may also be entered by the cardholder. The issuer generates a VCN such as a virtual PAN (VPAN) and links the VCN with the cardholder's loyalty points account. During authorization of a transaction, if the points bank receives the VCN, the points bank will check that the transaction parameters are met for the requested redemption transaction. If all of the transaction parameters are not met, the authorization request will be denied. If all of the transaction parameters are met, the requested redemption transaction will be processed as a regular redemption transaction as described herein. A VCN may also be used after the cardholder has received and activated the redemption card.).
18/974,447 – Claim 17. The computing system of claim 9, wherein rewards are used for the funds transfer without converting the reward points amount to a currency value that is then used for completing the funds transfer.
18/974,447 – Claim 19. The computer-implemented method of claim 18, wherein rewards are used for the funds transfer without converting the specified amount of rewards to a currency value that is then used for completing the funds transfer.
Claims 17 and 19, have similar limitations as of Claim(s) 6, therefore they are REJECTED under the same rationale as Claim(s) 6.
Claims 7, 16, 20 are rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040.
18/974,447 – Claim 7. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 1, further comprising transmitting a funds transfer confirmation to the user device (Ameiss et al. 20100057553 [0105] The points balance inquiry may also be initiated with the points bank. The points bank may have online and customer-service call-in channels to receive such requests. Other channels may also be used. For example, a cardholder may present the redemption card to the merchant at the point of sale and request a points balance inquiry. The merchant device will send the request to acquirer, which will send the request to the points bank. The points bank may look up the necessary information (loyalty points account points balance, VPP levels associated with the loyalty points account) and send a response to the acquirer without contacting the issuer. Alternatively, the points bank may send some information, such as a balance inquiry advice message, to the issuer. The acquirer forwards the balance inquiry response to the merchant, and the merchant presents the information to the cardholder in the form of a printed receipt or a visual display at the terminal.).
18/974,447 – Claim 16. The computing system of claim 9, wherein the one or more processors are further structured to transmit a funds transfer confirmation to the user device.
18/974,447 – Claim 20. The computer-implemented method of claim 18, further comprising transmitting a funds transfer confirmation to the user device.
Claims 16 and 20, have similar limitations as of Claim 7, therefore they are REJECTED under the same rationale as Claim(s) 7.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over: Ameiss et al. 20100057553; in view of Hunt 2010/0257040; in further view of Blackhurst et al. 2014/0081736.
18/974,447 – Claim 8. Ameiss et al. 2010/0057553 further teaches The computer-implemented method of claim 1, further comprising determining that a second rewards amount of a second funds transfer request is less than or equal to the balance in the rewards account following the funds transfer (Ameiss et al. 20100057553 [Figs. 8-12][0084] If the cardholder's loyalty points account does not have sufficient points to fund the transaction (i.e., the cardholder's points balance is less than the transaction amount point equivalent), the rewards system 716 determines whether an alternate funding account has been specified by the cardholder 702 at 816. If no alternate funding account has been specified by the cardholder 702, the transaction may be declined at 818. If the cardholder 702 has specified an alternate funding account, the rewards system 716 selects the alternate funding account as the funding account for the requested transaction. The rewards system 716 may also update the usage count and check to make sure the use of the alternate funding account is acceptable based on limits of consecutive usage of the alternate funding account. If the updated usage count is higher than the allowed usage count, the points bank declines the transaction.).
Ameiss et al. 2010/0057553 may not expressly disclose the “less than or equal” features, however, Blackhurst et al. 2014/0081736 teaches less than or equal to the rewards balance (Blackhurst et al. 2014/0081736 [0137 – less than or equal to amount…] The system may also be configured to receive transaction information and subsequently apply funds associated with the rewards points to the transaction. Applying funds associated with the rewards points to the transaction comprises determining whether an amount of the transaction is greater than an amount associated with the rewards points. If the amount associated with the transaction is not greater than (e.g., less than or equal to) the amount associated with the rewards points, the funds associated with the rewards points are applied to the transaction. Consequently, the rewards points balance is reduced. If the amount associated with the transaction is greater than the amount associated with the rewards points, the funds associated with the rewards points are applied to the transaction, and general funds (e.g., non-gift card funds) associated with the account are applied to the remainder of the transaction. Therefore, the rewards points balance is reduced to zero. For example, in one embodiment, the user may process a transaction where the transaction amount is equal to 50 rewards points. The user may have a total of 100 rewards points associated with their account. The system may then determine that the user's point's balance exceeds the transaction amount. Thus, the 50 rewards points will be applied to the transaction and the rewards points balance is reduced from 100 rewards points to 50 rewards points. In another embodiment, the user may process a transaction where the transaction amount is equal to 50 rewards points. The user may have a total of 45 rewards points associated with their account. The system may then determine that the user's point's balance does not exceed the transaction amount. Thus, the 45 rewards points will be applied to the transaction and the rewards points balance is reduced from 45 rewards points to 0 rewards points. Alternative fund may then be additionally applied to the transaction to compensate for the deficit of 5 rewards points. The system may be further configured to send an updated rewards point's balance to the user. In one embodiment, the rewards point's balance is sent in response to reducing the rewards points after a transaction has been processed. The point's balance may be sent to the user using various methods, including but not limited to, text message, sms message, email, online banking portal, social networking site, and the like.). Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified Ameiss et al. 20100057553 to include the less than or equal to features as taught by Blackhurst et al. 2014/0081736. One of ordinary skill in the art would have been motivated to do so in order to employ basic accounting and financial management features which should prove to improve user experience, maximize profits, and optimize revenue.
Examiner’s Response to Arguments
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §112
Per Applicants’ amendments/arguments, the rejections are withdrawn.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Examiner’s Response: Claim Rejections – 35 USC §101
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping 35 USC 101 rejection including Applicant’s amendments, arguments, lack of abstract idea, and practical integration.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claims 1-15, on page(s) 6-12 of Applicant’s Remarks (dated 12/27/2016), Applicants traverse the 35 USC §101 rejections arguing the following:
Examiner’s Response: Claim Rejections – 35 USC § 102 / § 103
Per Applicants’ amendments/arguments, the rejections are withdrawn. See notes above for additional reasoning and rationale for dropping prior-art rejection including Applicant’s amendments and arguments and unique combination of features and elements not taught by the prior-art without hindsight reasoning.
Applicant's arguments have been considered but are moot in view of the new ground(s) of rejection.
Applicants’ amendments have necessitated the new grounds of rejection noted above.
Regarding Claim X, on page(s) 8-9 of Applicant’s Remarks / After Final Amendments (dated 07/15/2011), Applicant(s) argues that the cited reference(s) (Ellis and Vandermolen) fails to teach, describe, or suggest the amended features. Specifically, Applicant(s) argues that cited reference(s) do not teach, describe, or suggest the following: . With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
With respect, Applicant’s arguments are deemed unpersuasive and the amended feature(s) remain rejected as follows.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
PERTINENT PRIOR ART – Patent Literature
The prior-art made of record and considered pertinent to applicant's disclosure.
Getsch 2007/0094608 [Figs. 1 & 3 - dynamically updating data items displayed in a GUI element][0007 - allowing one or more data item(s) presented in a GUI element to be dynamically updated during execution of an application program…; 0009; 0011][0033 - dialog box prompts the user for input regarding whether data presented in a GUI element should be modified]
Kim et al. 2015/0363810 - Abstract: Communication systems and methods to transmit data among a plurality of computing systems in processing benefit redemption, including a portal configured to communicate with transaction terminals, reward hosts and issues processors. In response to a reward balance inquiry from a transaction terminal, the portal communicates with a respective reward host to obtain the balance, communicates with an issuer processor to obtain a one-time use account number, and provides the transaction terminal with the balance and the account number. The transaction terminal an authorization request for a payment transaction made using the account number. In response to the authorization request being received in the issuer processor, the portal communicates with the issuer processor to identify the payment transaction and communicates with the reward host to perform a reward redemption to support the payment transaction.
Singh et al. 2012/0191525 – Abstract: A communications system for financial transactions, such as payment transactions made via credit accounts, debit accounts, prepaid accounts, bank accounts, stored value accounts and the like, is enhanced and/or used to support reward transactions. Thus, the reward communications can be processed as transactions over the communications system in a way similar to and/or together with credit/debit transactions.
Paintin et al. 2010/0042517 – Abstract: The invention provides various systems and methods for providing universal access to loyalty programs and/or financial accounts. The method includes initializing a universal loyalty program account and financial account device. The method further includes associating loyalty program accounts and/or financial accounts with the universal loyalty program and financial instrument device. The method then accesses at least one of the loyalty program accounts and/or the financial accounts at a customer facing device using the universal loyalty program account and financial account device.
White et al. 2008/0133351 – Abstract: Systems, methods, apparatus, means and computer program code are provided including receiving, from a point of interaction, an authorization request message identifying a requested purchase transaction, the authorization request message including data identifying a payment account identifier and a purchase amount; determining that the payment account identifier is eligible for a reward and selecting a reward message associated with the reward; and transmitting an authorization response message including the reward message to the point of interaction for display to an account holder.
Bies et al. 2008/0103968 – Abstract: Systems and methods are described for redeeming rewards at a merchant's point-of-sale. The reward redemption takes place in real time and can be accomplished without the active participation of the merchant. A single credit card with no additional information may be used with a single swipe from the consumer to access both credit and rewards accounts, such that a single authorization request is made to encompass both rewards and credit. Merchants can be fully compensated for transactions by the issuer despite the customer's choice to redeem rewards.
PERTINENT PRIOR ART – Non-Patent Literature (NPL)
The NPL prior-art made of record and considered pertinent to applicant's disclosure.
Lee, Zon-Yau, Hsiao-Cheng Yu and Pei-Jen Ku. “An analysis and comparison of different types of electronic payment systems.” PICMET '01. Portland International Conference on Management of Engineering and Technology. Proceedings Vol.1: Book of Summaries (IEEE Cat. No.01CH37199) Supplement (2001): 38-45 vol.2.
THIS ACTION IS MADE FINAL
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 extension fee 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.
THIS ACTION IS MADE FINAL
Applicant’s amendment necessitated new grounds of rejection and FINAL Rejection.
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 extension fee 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW T. SITTNER whose telephone number is (571) 270-7137 and email: matthew.sittner@uspto.gov. The examiner can normally be reached on Monday-Friday, 8:00am - 5:00pm (Mountain Time Zone). Please schedule interview requests via email: matthew.sittner@uspto.gov
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah M. Monfeldt can be reached on (571) 270-1833.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW T SITTNER/
Primary Examiner, Art Unit 3629b