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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/28/2025 was filed prior to examination. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Application Status
This Office Action is in response to Applicant’s filing.
Claims 1-20 are pending and have been examined.
This action is non-final.
Claim Rejections
Claims 1-201 are rejected under 35 U.S.C. § 101 for being directed to an abstract idea without significantly more.
Claims 1-20 are rejected under 35 U.S.C. § 103 in view of the following prior art of record2:
US 20170148003 A1 (Lopez)
US 20160292753 A1 (Fuller)
US 20180276658 A1 (Liscia)
US 20050251485 A1 (Quigley)
US 20140229397 A1 (Fink)
US 20210326831 A1 (Al-Bedaiwi)
Examiner additionally notes the following prior art used as evidentiary support for examiner’s position of what one of ordinary skill in the art understands of round-up donations, specifically for claims 7, 14, and 19:
US 20140229397 A1 (Fink)
US 20170330300 A1 (Nelson)
US 20240257189 A1 (Morgan)
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier provisional application filing date as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994)
The disclosure of the prior-filed application, Application No. 63/640,417, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. For example, 63/640,417 does not include disclosure pertaining to a “gateway computer”, as disclosed throughout the instant application (19/191,992). The instant application appears to provide adequate support to the currently filed claims. Accordingly, the effective filing date for claims reciting a gateway computer is determined to be 04/28/2025.
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 because the claimed invention is directed to an abstract idea without significantly more.
As an initial matter, the relevant test is the Alice/Mayo test3. The following analysis provided in this section results from the instant application’s claims being examined within the scope of the Alice/Mayo test framework.
With respect Step 1 of Alice/Mayo analysis, the claims are either directed to a system, product of manufacture, or method. Therefore, each of the claims are directed to one of the four statutory categories of invention (Step 1 of Alice/Mayo Test: YES).
Based upon consideration of all relevant factors with respect to the claims as a whole, claims 1-20 are determined to be directed to an abstract idea of transferring aggregated round-up amounts. The rationales for the aforementioned determination are explained further below.
With respect Step 2A Prong I of Alice/Mayo analysis, claims 1-20 recite as a whole a method of organizing human activity because independent claims 1, 11, and 16 recite:
“1. A method comprising:
receiving… an enrollment message from … a user via an authorizing entity …, the enrollment message specifying one or more preferences associated with value portions associated with interactions4 conducted by the user;
receiving… authorization request messages associated with a plurality of interactions conducted by the user;
aggregating… value portions associated with the authorization request messages to form an aggregate value; and
processing… a transfer of the aggregate value to one or more records associated with one or more receiving entities.”
“11. … performing a method comprising:
receiving an enrollment message from … a user via an authorizing entity …, the enrollment message specifying one or more preferences associated with value portions associated with interactions conducted by the user;
receiving authorization request messages associated with a plurality of interactions;
aggregating value portions associated with the authorization request messages to form an aggregate value; and
processing a transfer of the aggregate value to one or more receiving entities.”
“16. A method comprising:
receiving, by an authorizing entity … from … a user, an enrollment message;
transmitting, by the authorizing entity …, the enrollment message;
receiving, by the authorizing entity ..., a plurality of authorization request messages associated with a plurality of interactions conducted by the user;
receiving, by the authorizing entity …, a pull interaction message comprising an aggregate value derived from aggregating value portions associated with the authorization request messages; and
facilitating, by the authorizing entity …, a transfer of the aggregate value to one or more records associated with one or more receiving entities.”
Under broadest reasonable interpretation consistent with the specification, these are recitations of commercial interactions of transferring aggregated round-up amounts (e.g., for aggregated donations). Thus, the claims recite an abstract idea (Step 2A Prong I: Yes, the claims recite an abstract idea).
This judicial exception recited in independent claims 1, 11, and 16 is not integrated into a practical application because, when analyzed under prong II of revised step 2A of the Alice/Mayo test:
The additional elements “, by a processing system,”, “a user device operated by”, “[authorizing entity] computer”, and “, by the processing system,” of claim 1, the additional elements “A processing system comprising: a processor; and a non-transitory computer readable medium comprising code, executable by the processor, for ”, “a user device operated by”, and “[authorizing entity] computer” of claim 11, and the additional elements “[authorizing entity] computer”, “a user device operated by”, “transmitting, by the authorizing entity computer to a processing system via an API,”, and “[authorizing entity] computer” of claim 16 amount to no more than mere instructions to implement the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05 (f), (h)), even when considering each claim’s additional elements both separately and as an ordered combination. See Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014): "… Stating an abstract idea "while adding the words ‘apply it’ " is not enough for patent eligibility. … Nor is limiting the use of an abstract idea " ‘to a particular technological environment.’ … Stating an abstract idea while adding the words "apply it with a computer" simply combines those two steps, with the same deficient result”.
The claims merely invoke computers as tools to perform an abstract business process (e.g., the recited transferring aggregated round-up amounts – see MPEP §2106.05(f)(2)).
The Applicant’s claims fail to provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to any other technology or technical field (MPEP §§2106.04(d)(1) & 2106.05(a)).
An improvement in the abstract idea itself is not a technological solution to a technological problem (MPEP §§ 2106.05 (a), (a) II). See the following:
MPEP 2106.05(a) II: “… it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology … Merely adding generic computer components to perform the method is not sufficient.”
Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370 (Fed. Cir. 2015): “... our precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea.”
Customedia Techs. V. Dish Network Corp., 951 F.3d 1359, (Fed. Cir. 2020): “We have held that ‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ was insufficient to render the claims patent eligible as an improvement to computer functionality”.
In light of the above rationales provided for step 2A Prong II analysis, the Examiner respectfully submits the focus of the claims is not on an improvement in computers as tools, but rather on an abstract idea that uses computers as tools. Considered both separately and as an ordered combination, the additional elements of the independent claims do not integrate the abstract idea into a practical application, as they do no more than represent computers performing functions that correspond to (,i.e., implement,) the acts of the abstract transferring of aggregated round-up amounts, and do not provide details such that one of ordinary skill in the art would recognize the claims as reflecting an improvement to the functioning of a computer or any other technology or technical field. (Step 2A Prong II of Alice/Mayo Test: NO, the additional elements do not integrate the judicial exception into a practical application). Accordingly, claims 1, 11, and 16 are determined to be directed to an abstract idea (Step 2A of the Alice/Mayo Test: The claims are directed to an abstract idea).
When analyzed under step 2B, claims 1, 11, and 16 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims 1, 11, and 16, each when viewed as a whole, do not include additional elements amounting to significantly more, as their elements, each viewed both individually and as an ordered combination, amount to no more than mere instructions to implement the abstract transferring aggregated round-up amounts concept within a particular technological environment, absent of any particular technological details that one of ordinary skill in the art would recognize the claimed invention as providing an improvement to the functioning of a computer or to any other technology or technical field – see MPEP §§ 2106.05 (a), (f), (h) and Alice Corp. v. CLS Bank International, 573 U.S. 208, 223-24 (2014). Accordingly, the Examiner respectfully maintains the focus of the claims is not on such an improvement in computers as tools, but rather on abstract ideas that use computers as tools. Hence, none of the elements of the independent claims add significantly more to the abstract idea itself (i.e., an inventive concept), as merely employing computers as tools to automate and/or implement the abstract idea cannot provide significantly more than the judicial exception itself – see BSG Tech LLC vs. BuySeasons, Inc., 899 F.3d 1281, 1290 (Fed. Cir. 2018): “It has been clear since Alice that a Claimed invention’s use of the ineligible concept to which it is directed cannot supply the inventive concept that renders the invention ‘significantly more’ than that ineligible concept”.
Accordingly, independent claims 1, 11, and 16 are not patent eligible.
With respect to the dependent claims, the dependent claims have been given the full analysis, including analyzing the additional limitations both individually and as an ordered combination (if any). The dependent claims, when analyzed both individually and in combination, are also held to be patent ineligible under 35 U.S.C. 101 because of the same reasoning as above, and because the claim limitations of the dependent claims fail to establish that the claims are integrated into a practical application or amount to significantly more. The rationales for the aforementioned determinations are explained further below.
With respect to dependent claims 2, 4, 7, 8, 10, 13-15, and 17-19, the additional limitations of the dependent claims, when considered individually and as an ordered combination, do not recite additional elements outside of the abstract idea that integrate the judicial exception into a practical application or amount to significantly more than the abstract idea, as the claims do not recite any further additional elements outside of the abstract idea and also do not indicate that the previously mentioned additional elements are successfully integrated / amounting to significantly more, either individually or as an ordered combination. For these reasons the dependent claims 2, 4, 7, 8, 10, 13-15, and 17-19 are also not patent eligible.
With respect to dependent claim 3, it recites further details of the abstract transferring of aggregated round-up amounts concept, per reciting limitations “…wherein the processing of the transfer of the aggregate value comprises transmitting a pull interaction message comprising the aggregate value to the authorizing entity … and transmitting a push interaction message comprising the aggregate value …”. The additional elements, “…computer…” and “…to a gateway computer…” do no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, this claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 3 is also not patent eligible.
With respect to dependent claim 5, it recites further details of the abstract transferring of aggregated round-up amounts concept, per reciting limitations “…wherein the authorizing entity … is … an issuer”. The additional element, “…computer…operated by…” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, this claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 5 is also not patent eligible.
With respect to dependent claim 6, it does not include further recitation of the abstract idea under step 2A Prong I. However, the additional element “…wherein the processing system and the authorizing entity computer communicate via one or more APIs.…” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, this claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 6 is also not patent eligible.
With respect to dependent claims 9 and 12, they recite further details of the abstract transferring of aggregated round-up amounts concept, per reciting limitations “…wherein the processing the transfer of the aggregate value comprises transmitting a pull interaction message comprising the aggregate value to the authorizing entity … and transmitting a push interaction message comprising the aggregate value … transfer… the aggregate value or a portion of the aggregate value to the one or more records associated with the one or more receiving entities”. The additional element, “…computer…”, and “…to a switch, wherein the switch…” do no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, these claims do not improve the functioning of a computer, or to any other technology or technical field, do not integrate the judicial exception into a practical application, and do not amount to significantly more. Therefore, dependent claims 9 and 12 are also not patent eligible.
With respect to dependent claim 20, it does not include further recitation of the abstract idea under step 2A Prong I. However, the additional element “…wherein the user device is a mobile phone.…” does no more than represent the use of computers as tools to perform the abstract idea and/or merely limit the use of the abstract idea to a particular technological environment (MPEP §§ 2106.05(f) & 2106.05(h)). Accordingly, when considered as a whole, this claim does not improve the functioning of a computer, or to any other technology or technical field, does not integrate the judicial exception into a practical application, and does not amount to significantly more. Therefore, dependent claim 20 is also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims rejected in view of Lopez in Further View of Fuller
Claims 1, 2, 4-6, 11, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over United States Patent Publication No. US 20170148003 A1 (Lopez), in further view of United States Patent Application Publication No. US 20160292753 A1 (Fuller).
Claim 1
With respect to claim 1, Lopez discloses: A method comprising:
receiving, by a processing system (payment network 106), an enrollment message (transmitted registration) from a user device (smartphone; see refs 116, 118) operated by a user (consumer 114) via an authorizing entity computer (computing device 200 of issuer 108; see Fig. 1), See at least ¶28 in further view of ¶¶19,21 and Fig. 1:
¶28: “…the consumer 114 may initially register to the donation engine 122, whereby the consumer 114 creates a profile (e.g., a user profile, etc.) linked to the consumer's payment account (and, thus, to the consumer's payment device 116). The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100). … if the donation engine 122 is associated with and/or incorporated in the payment network 106, the profile may be created by the consumer 114 through interaction with one or more web-based interfaces associated with the issuer 108, which calls an API associated with the payment network 106.”
¶¶19,21: “[0019] The computing device 200 further includes an input device 208 that receives input from the user. … in some exemplary embodiments, a touch screen, such as that included in … a smartphone, … behaves as both presentation unit 206 and input device 208. … [0021] Referring again to FIG. 1, the consumer 114 in the system 100 is associated with payment device 116. The payment device 116 may include any suitable payment device such as, … another device used to provide an account number (e.g., a mobile phone, a tablet, etc.), etc. The payment device 116 is associated with a payment account, which is specific to the consumer 114, and by which the consumer 114 may fund purchase transactions for products such as goods and/or services, for example, at merchant 102. …. In addition in FIG. 1, the consumer 114 is associated with the communication device 118, which is illustrated as a smartphone or tablet and which may be used, in some embodiments, to provide the consumer's account number to the merchant 102.”
PNG
media_image1.png
459
756
media_image1.png
Greyscale
Examiner’s Note: Examiner interprets the above limitation as describing the following transmission sequence/path for the enrollment message:
User device -> authorizing entity computer -> processing system.
the enrollment message specifying one or more preferences associated with value portions associated with interactions conducted by the user;
See ¶29:
¶29: “The profile created during the registration (and, more broadly, generated by the donation engine 122 in response to the inputs provided by the consumer 114) is stored, for example, in memory 204 of the computing device 200 (associated with the donation engine 122). As part of creating the profile, the consumer 114 provides one or more preferences (i.e., user preferences) relating to the donations to be made as part of purchase transactions to the consumer's payment account and, from which, the donation engine 122 is then able to cause donations to charities, for example, charity 110, consistent with the consumer's preferences. ….”
receiving, by the processing system, authorization request messages associated with a plurality of interactions conducted by the user;
See ¶34, and ¶¶28, 35, in further view of examiner’s note and ¶¶35, 21, 38, and 34:
¶34: “In operation in the system 100, when the donation engine 122 detects an authorization request for a purchase transaction to the payment account associated with the consumer 114, the donation engine 122 determines, based on the consumer's preferences (and any other imposed limitations), if a donation transaction should be made, for example, to charity 110 (when set as a designated charity preference by the consumer 114)”.
¶28: “… the donation engine 122 is associated with and/or incorporated in the payment network 106 …”
¶35: “…After the donation transaction is … appended to the consumer's purchase transaction as part of the detected authorization request, the donation engine 122 causes the clearing and settlement processes for the purchase transaction to also include funding the charity account associated with the charity 110, for example, in the amount of the specified donation, or in the amount(s) of multiple donations. This may be done on a per transaction basis, or it may be done on a batch basis (e.g., once a particular number of donation transactions have been generated for the consumer 114 or in general for a group of consumers, etc.).”
Examiner’s Note: While Lopez does not verbatim state “authorization request messages” (i.e., a plurality of authorization request messages) being received, examiner notes one of ordinary skill in the art reading Lopez understands Lopez implicitly teaches “authorization request messages” being received, as Lopez discloses a plurality of aggregated donation transactions (¶35 “…batch basis (e.g., once a particular number of donation transactions…”), where preferences can dictates donation transactions occurring only on a per purchase transaction basis (¶31: “…the preferences provided by the consumer 114 in the profile, during registration, may include any suitable preferences. In addition, any number of preferences may be provided by, or be made available to, the consumer 114 through the donation engine 122 to define donations and/or to alter donations based on, for example, … donation amounts per transaction”), where multiple purchase transactions are contemplated (¶38: “…donations to be made as part of purchase transactions to the consumer's payment account….”), and where each of those purchase transactions are realized by a purchase transaction authorization request (¶34: “In operation in the system 100, when the donation engine 122 detects an authorization request for a purchase transaction to the payment account associated with the consumer 114, the donation engine 122 determines, based on the consumer's preferences (and any other imposed limitations), if a donation transaction should be made…”).
aggregating, by the processing system (payment network 106 comprising donation engine 122; see ¶28), value portions (donations amounts on a per transaction basis – see ¶31: “… donation amounts per transaction”) associated with the authorization request messages to form an aggregate value; (¶35) and
See ¶35 in further view of at least ¶28; see also examiner’s notes:
¶35: “… the donation engine 122 causes the clearing and settlement processes for the purchase transaction to also include funding the charity account associated with the charity 110, for example, in the amount of the specified donation, or in the amount(s) of multiple donations. This … may be done on a batch basis (e.g., once a particular number of donation transactions have been generated …”
¶28: “… the donation engine 122 is associated with and/or incorporated in the payment network 106 …”
Examiner’s Note: Examiner takes the position that “…to form an aggregate value…” is recitation of intended use and has limited patentable weight.
Examiner’s Note (2): Examiner takes the position that ¶35 of Lopez disclosing: “…the amount of the specified donation, or in the amount(s) of multiple donations…”is disclosure of formation of an aggregate value, as it contemplates an alternative where a singular donation amount corresponding multiple donations.
processing, by the processing system, a transfer of the aggregate value to one or more records associated with one or more receiving entities.
Again, see ¶35 in further view of at least ¶28 (above,) and prior examiner’s notes.
While the examiner respectfully maintains Lopez implicitly teaches, “…authorization request messages…” (i.e., a plurality of authorization request messages) being received, as Lopez discloses a plurality of aggregated donation transactions (¶35 “…batch basis (e.g., once a particular number of donation transactions…”), where preferences can dictates donation transactions occurring only on a per purchase transaction basis (¶31: “…the preferences provided by the consumer 114 in the profile, during registration, may include any suitable preferences. In addition, any number of preferences may be provided by, or be made available to, the consumer 114 through the donation engine 122 to define donations and/or to alter donations based on, for example, … donation amounts per transaction”), where multiple purchase transactions are contemplated (¶38: “…donations to be made as part of purchase transactions to the consumer's payment account….”), and where each of those purchase transactions are realized by a purchase transaction authorization request (¶34: “In operation in the system 100, when the donation engine 122 detects an authorization request for a purchase transaction to the payment account associated with the consumer 114, the donation engine 122 determines, based on the consumer's preferences (and any other imposed limitations), if a donation transaction should be made…”), examiner notes that, Arguendo, even if not implicitly taught, the above disclosure of Lopez renders obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention, that a consumer of Lopez could configure their donation preferences to a per-transaction amount (¶¶31, 34), perform multiple purchase transactions (¶38) and associated authorization requests (¶¶38, 34), and aggregate them on a batch basis (¶35), in order to advantageously utilize network resources more efficiently, and simplify record keeping of the donations.
Additionally, while the examiner respectfully maintains Lopez implicitly teaches aggregating, … value portions … to form an aggregate value…, examiner understands Applicant may have a narrower reading of Lopez and may disagree.
Arguendo, Fuller, of the same Applicant as Lopez, discloses:
aggregating, … value portions … to form an aggregate value…,
See at least ¶35; At least ¶¶48, 49, and 52 are also relevant:
¶35: “… the donation engine 120 aggregates the donation indicators, for a predefined interval (e.g., for a third-interval, for a one-month interval, for a two-week interval, etc.). The donation engine 120 then generates a transaction to the consumer's payment account in the form of a donation (broadly, a payment) to the charity 110, based on the aggregated donation indicators, …. Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104”.
¶¶48, 49: “[0048] In some embodiments, the charity 110, the consumer 114, the donation engine 120, or another entity may specify a minimum transaction threshold (e.g., a[n] … aggregated donation value, etc. …) [0049] … the donation engine 120 submits a donation transaction to … for payment of the aggregated donation value to the charity 110. …”
¶52: “…It should be appreciated that a donation transaction may be submitted by the donation engine 120 alone, or as part of a batch file with other donation transactions to be processed…”
Accordingly, given the same Applicant disclosing the same donation engine technology performing a batching process, Lopez’s implicit disclosure, and Fuller’s explicit disclosure, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention that the batching of Lopez would form an aggregate value for transfer, as made more explicit by Fuller. This advantageously utilizes network resources more efficiently, and simplifies record keeping of the donations.
Claim 2
With respect to claim 2, Lopez in view of Fuller renders obvious the method of parent claim 1. Lopez does not teach, but Fuller implicitly discloses or otherwise renders obvious:
wherein the plurality of interactions occur within a predetermined time window.
See at least ¶29 in further view of ¶35; at least ¶¶36, 46 are also relevant (not shown):
¶29: “…The consumer 114 may then set, through the interface, one or more of an amount to donate, a donation … per transaction …”
¶35: “…the donation engine 120 identifies transactions to the consumer's payment account and generates donation indicators for the transactions based on one or more predefined conditions (e.g., based on one or more user preferences …Next, the donation engine 120 aggregates the donation indicators, for a predefined interval (e.g., for a third-interval, for a one-month interval, for a two-week interval, etc.). The donation engine 120 then generates a transaction to the consumer's payment account in the form of a donation (broadly, a payment) to the charity 110, based on the aggregated donation indicators, and submits the transaction …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the method/system of Lopez in view of Fuller to be able to process aggregated donations of Lopez in view of Fuller within a predetermined interval, resulting in the batching to be based both on timeframe and threshold amount logic, in order to advantageously provide batched funds within a predetermined timeframe regardless of passing a threshold or not – this advantageously allows under-funded charities of Lopez to still receive donations, even if not exceeding a particular threshold, such as the threshold of Lopez.
Claim 4
With respect to claim 4, Lopez in view of Fuller renders obvious the method of parent claim 1. Additionally, Lopez discloses:
wherein the one or more receiving entities includes a beneficiary (e.g., a charity / associated beneficiary or beneficiaries)
See abstract and at least ¶¶13, 44.
Claim 5
With respect to claim 5, Lopez in view of Fuller renders obvious the method of parent claim 1. Additionally, Lopez discloses:
wherein the authorizing entity computer is operated by an issuer.
See at least ¶28 and mapping of parent claim 1’s authorizing entity computer, further above, mutatis mutandis.
¶28: “…the consumer 114 may initially register to the donation engine 122, whereby the consumer 114 creates a profile (e.g., a user profile, etc.) linked to the consumer's payment account (and, thus, to the consumer's payment device 116). The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100). … if the donation engine 122 is associated with and/or incorporated in the payment network 106, the profile may be created by the consumer 114 through interaction with one or more web-based interfaces associated with the issuer 108, which calls an API associated with the payment network 106.”
Claim 6
With respect to claim 6, Lopez in view of Fuller renders obvious the method of parent claim 1. Additionally, Lopez discloses:
wherein the processing system and the authorizing entity computer communicate via one or more APIs.
See at least ¶28, ¶22 (not shown), and mapping of parent claim 1’s authorizing entity computer further above, mutatis mutandis.)
¶28: “…The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100). Alternatively, when or if the donation engine 122 is associated with and/or incorporated in the payment network 106, the profile may be created by the consumer 114 through interaction with one or more web-based interfaces associated with the issuer 108, which calls an API associated with the payment network 106. …”
Claim 11
With respect to claim 11, the following claim limitations are mapped under the same mapping as claim 1 (above), mutatis mutandis:
receiving an enrollment message from a user device operated by a user via an authorizing entity computer, the enrollment message specifying one or more preferences associated with value portions associated with interactions conducted by the user;
receiving authorization request messages associated with a plurality of interactions; aggregating value portions associated with the authorization request messages to form an aggregate value; and
processing a transfer of the aggregate value to one or more receiving entities.
With respect to the remaining limitations. Lopez additionally discloses:
A processing system comprising: a processor; and a non-transitory computer readable medium comprising code, executable by the processor, for performing a method comprising: (Fig. 1; ¶¶14,15,16 of Lopez)
Claim 13
With respect to claim 13, it is rejected under the same rationale as claim 2 (above), mutatis mutandis.
Claims rejected in view of Lopez and Fuller, in Further View of Liscia
Claims 3, 9, 12, 16, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lopez and Fuller, in further view of United States Patent Application Publication No. US 20180276658 A1 (Liscia).
Claim 3
With respect to claim 3, Lopez in view of Fuller renders obvious the method of parent claim 1. Additionally, Lopez in view of Fuller generally discloses:
…wherein the processing of the transfer of the aggregate value comprises transmitting a … message comprising the aggregate value (See at least ¶35 of Lopez and ¶35 of Fuller; Examiner notes the same obviousness rationale drawn to the aggregation limitations applies herein, mutatis mutandis)
Lopez in view of Fuller fails to disclose the ordered combination of:
wherein the processing of the transfer of the aggregate value comprises transmitting a pull interaction message comprising the aggregate value to the authorizing entity computer and transmitting a push interaction message comprising the aggregate value to a gateway computer.
However, Liscia, also disclosing batch settlement processes as Lopez and Fuller (e.g., ¶35), of the same Applicant as Lopez and Fuller, discloses:
wherein the processing of the transfer of … value comprises transmitting a pull interaction message comprising the … value to the authorizing entity computer (sponsor system – see ¶16) and
PNG
media_image2.png
720
550
media_image2.png
Greyscale
See ¶¶16, 30, 46 of Liscia, in further view of at least Fig. 6:
¶16: “…a sponsor system such as an acquiring bank, an issuing bank, a payment processor, an application programming interface (API), or the like, can communicate with a digital wallet operated by the cardholder and can act on behalf of a cardholder to transfer payment from the cardholder's account to a … [payee] account through a pull and a push process.”
¶17: “…During the pull process, the sponsor system may pull a payment requested by the cardholder from an issuer of the cardholder account to the sponsor system based on the cardholder PAN received from the digital wallet…”
¶30: “…The sponsor system 120 may perform the pull operation by transmitting an authorization request message (e.g., ISO 8583) to the sending issuer 130 via the payment network 150, and receive an authorization response message from the sending issuer 130 via the payment network 150.”
¶¶49, 52: “[0049] FIG. 6 illustrates a method 600 of pulling and pushing a payment, according to an example embodiment. For example, the method 600 may be performed by a sponsor system … a payment processing device executing a send API, and the like. … [0052] 630, the method includes pulling the requested payment from the issuer of the sending account to the sponsor system via a payment network based on issuer information of the sending account included in the send request, and in 640, pushing the requested payment from the sponsor system to an issuer of the receiving account via the payment network based on issuer information of the receiving account included in the request. …”
transmitting a push interaction message comprising the … value to a gateway computer. (payment network)
See ¶18 in further view of at least ¶32 of Liscia; with respect to the value aspect, see ¶28 disclosing the push/pull processes involving a “…transaction amount…” (not shown below):
¶18: “…a payment network … may include payment network devices and other systems such as payment gateways…”
¶32 “Once the payment has been pulled from the sending account issued by the sending issuer 130 and transferred to the sponsor system 120, the sponsor system 120 may push the pulled payment to the receiving issuer 140 via the payment network 150. …”
¶¶49, 52: “[0049] FIG. 6 illustrates a method 600 of pulling and pushing a payment, according to an example embodiment. For example, the method 600 may be performed by a sponsor system … a payment processing device executing a send API, and the like. … [0052] 630, the method includes pulling the requested payment from the issuer of the sending account to the sponsor system via a payment network based on issuer information of the sending account included in the send request, and in 640, pushing the requested payment from the sponsor system to an issuer of the receiving account via the payment network based on issuer information of the receiving account included in the request. …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the system/ method of Lopez in view of Fuller to incorporate the push/pull technique of Liscia, e.g., (via a payment send API (e.g., MasterCard Send API; ¶18), resulting in the processing of the transfer of the aggregate of value of Lopez in view of Fuller to comprise ‘transmitting a pull interaction message comprising the aggregate value to the authorizing entity computer and transmitting a push interaction message comprising the aggregate value to a gateway computer’, in order to advantageously obviate traditional payment clearing and settlement (which is much slower), with the much faster and nearly-instantaneous transaction method disclosed in Liscia (¶15 of Liscia).
Claim 9
With respect to claim 9, it is rejected under the same rationale as claim 3, mutatis mutandis. (Examiner’s Note: Liscia does not verbatim state “switch”; however, the payment network of Liscia is understood to constitute a switch, to one of ordinary skill in the art, as a switch routes messages between banking institutions, and that is what the payment network of Liscia is doing, as noted in claim 3 mapping.)
Claim 12
With respect to claim 12, it is rejected under the same rationale as claims 3 and 9 (above), mutatis mutandis.
Claim 16
With respect to claim 16, Lopez discloses a method comprising:
receiving, by an authorizing entity computer from a user device operated by a user, an enrollment message;
See at least ¶28 in further view of ¶¶19, 21, and Fig. 1:
¶28: “…the consumer 114 may initially register to the donation engine 122, whereby the consumer 114 creates a profile (e.g., a user profile, etc.) linked to the consumer's payment account (and, thus, to the consumer's payment device 116). The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100). … if the donation engine 122 is associated with and/or incorporated in the payment network 106, the profile may be created by the consumer 114 through interaction with one or more web-based interfaces associated with the issuer 108, which calls an API associated with the payment network 106.”
¶¶19,21: “[0019] The computing device 200 further includes an input device 208 that receives input from the user. … in some exemplary embodiments, a touch screen, such as that included in … a smartphone, … behaves as both presentation unit 206 and input device 208. … [0021] Referring again to FIG. 1, the consumer 114 in the system 100 is associated with payment device 116. The payment device 116 may include any suitable payment device such as, … another device used to provide an account number (e.g., a mobile phone, a tablet, etc.), etc. The payment device 116 is associated with a payment account, which is specific to the consumer 114, and by which the consumer 114 may fund purchase transactions for products such as goods and/or services, for example, at merchant 102. …. In addition in FIG. 1, the consumer 114 is associated with the communication device 118, which is illustrated as a smartphone or tablet and which may be used, in some embodiments, to provide the consumer's account number to the merchant 102.”
PNG
media_image1.png
459
756
media_image1.png
Greyscale
Examiner’s Note: Examiner interprets the above limitation as describing the following transmission sequence/path for the enrollment message:
User device -> authorizing entity computer -> processing system.
transmitting, by the authorizing entity computer to a processing system via an API, the enrollment message;
See at least ¶28 in further view of ¶¶19, 21, and Fig. 1:
¶28: “…the consumer 114 may initially register to the donation engine 122, whereby the consumer 114 creates a profile (e.g., a user profile, etc.) linked to the consumer's payment account (and, thus, to the consumer's payment device 116). The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100). … if the donation engine 122 is associated with and/or incorporated in the payment network 106, the profile may be created by the consumer 114 through interaction with one or more web-based interfaces associated with the issuer 108, which calls an API associated with the payment network 106.”
receiving, by the authorizing entity computer, a plurality of authorization request messages associated with a plurality of interactions conducted by the user;
See At least ¶34:
¶34: “…the authorization request transmitted … to the issuer 108.”
Examiner’s Note: While Lopez does not verbatim state “authorization request messages” (i.e., a plurality of authorization request messages) being received, examiner notes one of ordinary skill in the art reading Lopez understands Lopez implicitly teaches “authorization request messages” being received, as Lopez discloses a plurality of aggregated donation transactions (¶35 “…batch basis (e.g., once a particular number of donation transactions…”), where preferences can dictates donation transactions occurring only on a per purchase transaction basis (¶31: “…the preferences provided by the consumer 114 in the profile, during registration, may include any suitable preferences. In addition, any number of preferences may be provided by, or be made available to, the consumer 114 through the donation engine 122 to define donations and/or to alter donations based on, for example, … donation amounts per transaction”), where multiple purchase transactions are contemplated (¶38: “…donations to be made as part of purchase transactions to the consumer's payment account….”), and where each of those purchase transactions are realized by a purchase transaction authorization request, of which are sent to the issuer (¶34: “[34] In operation in the system 100, when the donation engine 122 detects an authorization request for a purchase transaction to the payment account associated with the consumer 114, the donation engine 122 determines, based on the consumer's preferences (and any other imposed limitations), if a donation transaction should be made … the authorization request transmitted … to the issuer 108.”).
… aggregating value portions associated with the authorization request messages;
See ¶35 in further view of at least ¶28; see also examiner’s notes:
¶35: “… the donation engine 122 causes the clearing and settlement processes for the purchase transaction to also include funding the charity account associated with the charity 110, for example, in the amount of the specified donation, or in the amount(s) of multiple donations. This … may be done on a batch basis (e.g., once a particular number of donation transactions have been generated …”
¶28: “… the donation engine 122 is associated with and/or incorporated in the payment network 106 …”
Examiner’s Note: Examiner takes the position that “…to form an aggregate value…” is recitation of intended use and has limited patentable weight.
Examiner’s Note (2): Examiner takes the position that ¶35 of Lopez disclosing: “…the amount of the specified donation, or in the amount(s) of multiple donations…”is disclosure of formation of an aggregate value, as it contemplates an alternative where a singular donation amount corresponding multiple donations.
Lopez fails to expressly teach, but Fuller discloses:
… aggregating value portions associated with the authorization request messages;
See at least ¶35; At least ¶¶48, 49, and 52 are also relevant:
¶35: “… the donation engine 120 aggregates the donation indicators, for a predefined interval (e.g., for a third-interval, for a one-month interval, for a two-week interval, etc.). The donation engine 120 then generates a transaction to the consumer's payment account in the form of a donation (broadly, a payment) to the charity 110, based on the aggregated donation indicators, …. Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104”.
¶¶48, 49: “[0048] In some embodiments, the charity 110, the consumer 114, the donation engine 120, or another entity may specify a minimum transaction threshold (e.g., a[n] … aggregated donation value, etc. …) [0049] … the donation engine 120 submits a donation transaction to … for payment of the aggregated donation value to the charity 110. …”
¶52: “…It should be appreciated that a donation transaction may be submitted by the donation engine 120 alone, or as part of a batch file with other donation transactions to be processed…”
receiving, by the authorizing entity computer, a … interaction message comprising an aggregate value derived from aggregating value portions associated with the authorization request messages; and (¶35 in further view of ¶¶22,23)
¶35: the donation engine 120 aggregates the donation indicators, for a predefined interval (e.g., for a third-interval, for a one-month interval, for a two-week interval, etc.). The donation engine 120 then generates a transaction to the consumer's payment account in the form of a donation (broadly, a payment) to the charity 110, based on the aggregated donation indicators, …. Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104”.
Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104. Once received, the transaction (or the multiple transactions in the batch file) is handled substantially consistent to the payment transaction described above between the consumer 114 and the merchant 102”.
¶22: “…typically in the illustrated system 100, the merchant 102, the acquirer 104, the payment network 106, and the issuer 108 cooperate, in response to a request from a consumer 114, to complete a payment transaction for a product and/or service using a payment account. As part of the payment transaction, the consumer 114 initially provides information about the payment account to the merchant 102 (e.g., a payment account number, etc. via a payment card, other payment device (e.g., a fob, a smartphone, etc.), or via login credentials for a previously established purchase account (e.g., an electronic wallet such as MasterPass™, Google Wallet, PayPass, Softcard®, etc.), etc.). The merchant 102 reads the payment account information and communicates, via the network 112, an authorization request to the payment network 106, via the acquirer 104 (associated with the merchant 102), to process the transaction (e.g., using the MasterCard® interchange, etc.). The authorization request includes various details of the transaction (e.g., transaction data, etc.) to help facilitate processing the authorization request. The payment network 106, in turn, communicates the authorization request to the issuer 108 (associated with the consumer's payment account). The issuer 108 then provides an authorization response (e.g., authorizing or declining the request) to the payment network 106, which is provided back through the acquirer 104 to the merchant 102. The transaction with the consumer 114 is then completed by the merchant 102. Depending on the authorization response, the transaction is approved or denied.”
¶23: “…Transaction data is generated as part of the above interactions among the merchant 102, the acquirer 104, the payment network 106, the issuer 108, and the consumer 114. Depending on the transaction, the transaction data is transmitted from the merchant 102 to the issuer 108 through the payment network 106 (e.g., as part of the authentication request, as part of a separate request, etc.). The transaction data may include, without limitation, a payment account number for the consumer's payment account, a payment amount for the transaction, …”
facilitating, by the authorizing entity computer, a transfer of the aggregate value to one or more records associated with one or more receiving entities.
(¶35 in further view of ¶¶22,23)
¶35: the donation engine 120 aggregates the donation indicators, for a predefined interval (e.g., for a third-interval, for a one-month interval, for a two-week interval, etc.). The donation engine 120 then generates a transaction to the consumer's payment account in the form of a donation (broadly, a payment) to the charity 110, based on the aggregated donation indicators, …. Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104”.
Generally, the donation engine 120 creates a batch file, which includes multiple donation-based transactions to the charity 110 for the predefined interval (e.g., from the multiple consumers 114, etc.), and submits the batch file to the acquirer 104. Once received, the transaction (or the multiple transactions in the batch file) is handled substantially consistent to the payment transaction described above between the consumer 114 and the merchant 102”.
¶22: “…typically in the illustrated system 100, the merchant 102, the acquirer 104, the payment network 106, and the issuer 108 cooperate, in response to a request from a consumer 114, to complete a payment transaction for a product and/or service using a payment account. As part of the payment transaction, the consumer 114 initially provides information about the payment account to the merchant 102 (e.g., a payment account number, etc. via a payment card, other payment device (e.g., a fob, a smartphone, etc.), or via login credentials for a previously established purchase account (e.g., an electronic wallet such as MasterPass™, Google Wallet, PayPass, Softcard®, etc.), etc.). The merchant 102 reads the payment account information and communicates, via the network 112, an authorization request to the payment network 106, via the acquirer 104 (associated with the merchant 102), to process the transaction (e.g., using the MasterCard® interchange, etc.). The authorization request includes various details of the transaction (e.g., transaction data, etc.) to help facilitate processing the authorization request. The payment network 106, in turn, communicates the authorization request to the issuer 108 (associated with the consumer's payment account). The issuer 108 then provides an authorization response (e.g., authorizing or declining the request) to the payment network 106, which is provided back through the acquirer 104 to the merchant 102. The transaction with the consumer 114 is then completed by the merchant 102. Depending on the authorization response, the transaction is approved or denied.”
¶23: “…Transaction data is generated as part of the above interactions among the merchant 102, the acquirer 104, the payment network 106, the issuer 108, and the consumer 114. Depending on the transaction, the transaction data is transmitted from the merchant 102 to the issuer 108 through the payment network 106 (e.g., as part of the authentication request, as part of a separate request, etc.). The transaction data may include, without limitation, a payment account number for the consumer's payment account, a payment amount for the transaction, …”
Lopez in view of Fuller fails to expressly characterize the interaction message as a pull interaction message.
However, Liscia, also disclosing batch settlement processes as Lopez and Fuller (e.g., ¶3), of the same Applicant as Lopez and Fuller, discloses:
a pull interaction message comprising the … value to the authorizing entity computer (sponsor system – see ¶16) and
See ¶¶16, 30, 46 of Liscia, in further view of at least Fig. 6:
PNG
media_image2.png
720
550
media_image2.png
Greyscale
¶16: “…a sponsor system such as an acquiring bank, an issuing bank, a payment processor, an application programming interface (API), or the like, can communicate with a digital wallet operated by the cardholder and can act on behalf of a cardholder to transfer payment from the cardholder's account to a … [payee] account through a pull and a push process.”
¶17: “…During the pull process, the sponsor system may pull a payment requested by the cardholder from an issuer of the cardholder account to the sponsor system based on the cardholder PAN received from the digital wallet…”
¶30: “…The sponsor system 120 may perform the pull operation by transmitting an authorization request message (e.g., ISO 8583) to the sending issuer 130 via the payment network 150, and receive an authorization response message from the sending issuer 130 via the payment network 150.”
¶¶49, 52: “[0049] FIG. 6 illustrates a method 600 of pulling and pushing a payment, according to an example embodiment. For example, the method 600 may be performed by a sponsor system … a payment processing device executing a send API, and the like. … [0052] 630, the method includes pulling the requested payment from the issuer of the sending account to the sponsor system via a payment network based on issuer information of the sending account included in the send request, and in 640, pushing the requested payment from the sponsor system to an issuer of the receiving account via the payment network based on issuer information of the receiving account included in the request. …”
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the system/ method of Lopez in view of Fuller to incorporate the push/pull technique of Liscia, e.g., (via a payment send API (e.g., MasterCard Send API; ¶18), resulting in the processing of the transfer of the aggregate of value of Lopez in view of Fuller to comprise ‘receiving, by the authorizing entity computer, a pull interaction message comprising an aggregate value derived from aggregating value portions associated with the authorization request messages’, in order to advantageously obviate traditional payment clearing and settlement (which is much slower), with the much faster and nearly-instantaneous transaction method disclosed in Liscia (¶15 of Liscia).
Claim 18
With respect to claim 18, it is rejected under the same rationale as claim 2 (above), mutatis mutandis.
Claim 20
With respect to claim 20, Lopez in view of Fuller and Liscia renders obvious the method of parent claim 16. Additionally, Lopez discloses:
wherein the user device is a mobile phone. (¶28: “The registration is provided through one or more web-based interfaces (e.g., websites, applications, etc.), which are accessible to the consumer 114 (via the communication device 118, for example) either directly or, in some embodiments, via an application programming interface (API) or other link from one or more web-based interfaces associated with the issuer 108 (or other part of the system 100)”, in further view of ¶¶15, 19: “[15]… the communication device 118 … [is] consistent with computing device 200. … [19] Further, in some exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, behaves as both presentation unit 206 and input device 208…”, and ¶21: “…the communication device 118, which is illustrated as a smartphone…”)
Claims rejected in view of Lopez and Fuller, in Further View of Quigley
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Lopez and Fuller, as applied in parent claims 1 and 11, in further view of United States Patent Application Publication No. US 20050251485 A1 (Quigley). Examiner notes United States Patent Application Publication No. US 20140229397 A1 (Fink), United States Patent Application Publication No. US 20170330300 A1 (Nelson), and United States Patent Application Publication No. US 20240257189 A1 (Morgan) as further evidentiary support for rejection of Lopez in view of Fuller and Quigley.
Claim 7
With respect to claim 7, Lopez in view of Fuller renders obvious the method of parent claim 1. Additionally, Lopez discloses:
wherein the authorization request messages have interaction values … (¶23)
¶23: “…the amount of the purchase (broadly, transaction data) to the acquirer 104 (as part of an authorization request) …”
Lopez in view of Fuller fails to disclose, but Quigley discloses:
and the value portions (e.g., donation amounts) are determined using [by?] subtracting the interactions values from target values (e.g., transaction amount rounded up to next whole dollar amount).
See ¶27 in further view of Fig. 2:
¶27: “FIG. 2 illustrates one embodiment of a screen display 100 for display on terminals 30 (FIG. 1) for soliciting a donation … An inquiry may require the online shopper to simply authorize the making of a donation or decline from making a donation. For example, an online shopper may be required to click on one of the two options. A suggested amount of a donation is provided in a data entry field 130. For example, during checkout, a rounded-up amount, the difference between the amount of the total purchase and the next whole dollar amount may be calculated, and displayed in data entry field 130”.
PNG
media_image3.png
564
791
media_image3.png
Greyscale
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to include more preferences in the method/system of Lopez in view of Fuller, resulting in the set of possible preferences to include a rounding-up to the next dollar amount (per transaction), as disclosed in Quigley, as the rounding-up transactions is a common method of calculating donation amounts triggered by transactions, as they are known to be relatively low-commitment donations to one of ordinary skill in the art – see the following prior art serving as evidentiary support of Examiner’s position of the prevalence of such a method of determining value portions:
¶¶6,7 of United States Patent Application Publication No. US 20140229397 A1 (Fink): “[¶6] People inherently want to help others, and charitable activity can come in many forms. … [¶7] Research indicates that people have a psychological barrier to giving a dollar (US) or more at retail locations. A `round up` feature may promote more charitable giving by limiting user donations to under a dollar US. It is commonplace to be bombarded with requests for donations,…”.
¶8 of United States Patent Application Publication No. US 20170330300 A1 (Nelson): “It is also known to ask a customer to provide a charity donation by rounding the amount of their bill up to the nearest whole unit of currency….”
¶1 of United States Patent Application Publication No. US 20240257189 A1 (Morgan): “Events such as war and natural disaster can affect millions of people's lives instantaneously; people watching the news want a fast, direct way to help. Collecting donations at self-checkouts and other point-of-sale (POS) systems is not uncommon. Typically, when ordering, a cashier asks a customer if the customer wants to donate or round up to the nearest dollar of their bill to donate to a … charity.”
Claim 14
With respect to claim 14, it is rejected under the same rationale as claim 7 (above), mutatis mutandis.
Claims rejected in view of Lopez, Fuller, and Quigley, in Further View of Fink
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lopez, Fuller, and Quigley, in further view of United States Patent Application Publication No. US 20140229397 A1 (Fink).
Claim 8
With respect to claim 8, it is rejected under the same rationale as claim 7 (further above), mutatis mutandis.
While the examiner respectfully maintains Lopez in view of Fuller and Quigley renders obvious wherein the target values are determined using the one or more preferences, as the preferences of Lopez and Fuller dictate the target value’s calculation (e.g., donation amounts) and Quigley discloses a calculation pertaining to target values within the same context as Lopez (see claim 7), Examiner notes, Arguendo, that Fink discloses: target values are determined using … one or more preferences (¶¶2, 7, 8, 112; see also Fig. 3, ref 217: “Round Up”, in further view of ¶46: “…User customizable preferences include transaction category 213, assigned charity 215, donation amount 217,…”)
Accordingly, it is obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention that the preferences of Lopez could be modified to have a transaction amount dependent donation amount as a user preferences, as indicated by Fink (above). This advantageously provides a preference that matches most consumer’s psychology (¶7 of Fink).
Claim 15
With respect to claim 15, it is rejected under the same rationale as claim 8 (above), mutatis mutandis.
Claims rejected in view of Lopez, Fuller, and Liscia, in Further View of Al-Bedaiwi
Claims 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lopez, Fuller, and Liscia, in further view of United States Patent Application Publication No. US 20210326831 A1 (Al-Bedaiwi).
Claim 10
With respect to claim 10, Lopez in view of Fuller and Liscia renders obvious the method of parent claim 9. Lopez in view of Fuller and Liscia fails to disclose, but Al-Bedaiwi discloses:
wherein the push interaction message is an OCT message. (¶¶17, 21, 38, 42, 71, 75, 79)
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have the method / system of Lopez in view of Fuller and Liscia utilize an OCT message technique, as disclosed in Al-Bedaiwi, in order to advantageously have associated systems minimize the amount of payment kernel software required to reside on point-of-sale terminals, and consequently, minimize or reduce the number of certifications required (¶3) and not requiring selections prior to or contemporaneous with the completion of the transaction, allowing for selections long after the transaction is authorized, cleared, and settled (¶68).
Claim 17
With respect to claim 17, Lopez in view of Fuller and Liscia renders obvious parent claim 16. Lopez in view of Fuller and Liscia fails to disclose, but Al-Bedaiwi discloses:
wherein the push interaction message is an AFT message. (¶¶17, 21, 38, 42, 71, 72, 75, 79)
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have the method / system of Lopez in view of Fuller and Liscia utilize an OCT message technique, as disclosed in Al-Bedaiwi, in order to advantageously have associated systems minimize the amount of payment kernel software required to reside on point-of-sale terminals, and consequently, minimize or reduce the number of certifications required (¶3) and not requiring selections prior to or contemporaneous with the completion of the transaction, allowing for selections long after the transaction is authorized, cleared, and settled (¶68).
Claims rejected in view of Lopez, Fuller, and Liscia, in Further View of Quigley
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Lopez, Fuller, and Liscia, in further view of United States Patent Application Publication No. US 20050251485 A1 (Quigley). Examiner notes United States Patent Application Publication No. US 20140229397 A1 (Fink), United States Patent Application Publication No. US 20170330300 A1 (Nelson), and United States Patent Application Publication No. US 20240257189 A1 (Morgan) as further evidentiary support for rejection of Lopez in view of Fuller, Liscia, and Quigley.
Claim 19
With respect to claim 19, Lopez in view of Fuller and Liscia renders obvious the method of parent claim 16. Additionally, Lopez discloses:
wherein the authorization request messages have interaction values … (¶23)
¶23: “…the amount of the purchase (broadly, transaction data) to the acquirer 104 (as part of an authorization request) …”
Lopez in view of Fuller fails to disclose, but Quigley discloses:
and the value portions (e.g., donation amounts) are determined using [by?] subtracting the interactions values from target values (e.g., transaction amount rounded up to next whole dollar amount).
See ¶27 in further view of Fig. 2:
¶27: “FIG. 2 illustrates one embodiment of a screen display 100 for display on terminals 30 (FIG. 1) for soliciting a donation … An inquiry may require the online shopper to simply authorize the making of a donation or decline from making a donation. For example, an online shopper may be required to click on one of the two options. A suggested amount of a donation is provided in a data entry field 130. For example, during checkout, a rounded-up amount, the difference between the amount of the total purchase and the next whole dollar amount may be calculated, and displayed in data entry field 130”.
PNG
media_image3.png
564
791
media_image3.png
Greyscale
Accordingly, it would have been rendered obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to include more preferences in the method/system of Lopez in view of Fuller, resulting in the set of possible preferences to include a rounding-up to the next dollar amount (per transaction), as disclosed in Quigley, as the rounding-up transactions is a common method of calculating donation amounts triggered by transactions, as they are known to be relatively low-commitment donations to one of ordinary skill in the art – see the following prior art serving as evidentiary support of Examiner’s position of the prevalence of such a method of determining value portions:
¶¶6,7 of United States Patent Application Publication No. US 20140229397 A1 (Fink): “[¶6] People inherently want to help others, and charitable activity can come in many forms. … [¶7] Research indicates that people have a psychological barrier to giving a dollar (US) or more at retail locations. A `round up` feature may promote more charitable giving by limiting user donations to under a dollar US. It is commonplace to be bombarded with requests for donations,…”.
¶8 of United States Patent Application Publication No. US 20170330300 A1 (Nelson): “It is also known to ask a customer to provide a charity donation by rounding the amount of their bill up to the nearest whole unit of currency….”
¶1 of United States Patent Application Publication No. US 20240257189 A1 (Morgan): “Events such as war and natural disaster can affect millions of people's lives instantaneously; people watching the news want a fast, direct way to help. Collecting donations at self-checkouts and other point-of-sale (POS) systems is not uncommon. Typically, when ordering, a cashier asks a customer if the customer wants to donate or round up to the nearest dollar of their bill to donate to a … charity.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Non-Patent Literature, “The Round Up App for Nonprofits” (RoundUp). RoundUp discloses a fundraising solution where a user’s credit or debit card automatically performs round-up donations for each transaction (see 0:00-0:04, and 0:27-0:53), where end-of-month totals are provided to organization receiving donations (0:53 – 1:08).
Non-Patent Literature, “Terms of Service” (4fund.com). 4fund.com is relevant for disclosing a donation/fundraising solution that requires MasterCard Send and Visa Direct cards (page 14 of PDF supplied).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A MALKOWSKI whose telephone number is (313)446-6624. The examiner can normally be reached Monday - Friday, 9:00AM - 5:00PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Matthew Gart can be reached on (571) 272-3955. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.A.M./Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
1 I.e., the subject matter claimed.
2 See detailed 103 rejections further within office action for each claim’s specific combination of prior art.
3 See MPEP § 2106 I.
4 Per ¶21 of Applicant Specification (underline emphasis added): “An "interaction" may include a reciprocal action or influence…Example interactions include a transaction between two parties … an interaction can include a payment transaction … An interaction can include a transaction interaction,”
5 ¶3 of Liscia, underline emphasis added: “…transaction[s] may be approved … However, the actual exchange of funds from the cardholder's account to the …[payee] is not performed immediately. Rather, … approved authorizations [are sent] in a batch …”
Prosecution Insights