US20160196591A1

US20160196591A1 - System and method for making and tracking charitable contributions

Info

Publication number: US20160196591A1
Application number: US14/992,352
Authority: US
Inventors: Ghislain Audemard d'Alancon
Original assignee: Heoh
Current assignee: Heoh
Priority date: 2015-01-05
Filing date: 2016-01-11
Publication date: 2016-07-07
Also published as: WO2016110635A1; FR3031410B1; US20180268492A1; US10755361B2; FR3031410A1; EP3243175A1

Abstract

A method and system of instructing an annex operation linked to the execution of a main transaction in a bank payment system comprising, for example, at least two distinct client devices and a third party device connected to an annex operation managing system, that is configured to carry out a main transaction between the two client devices. After having received from the third party device, in the annex operation managing system, information relative to the execution of the main transaction between the two client devices, at least one rule for executing the annex operation is identified according to at least one first information item of the received information. The annex operation is then executed according to said at least one identified rule and according to at least one second information item of the received information that is distinct from the first information item.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional application Ser. No. 62/101,675 filed on Jan. 9, 2015, which claims the benefit of French Patent application serial number 1550025 filed on Jan. 5, 2015, all incorporated herein by reference.

BACKGROUND

This disclosure concerns the management of financial transactions made by debtors with creditors via bank accounts of the latter. More precisely, the disclosure concerns methods and devices for instructing annex operations linked to the execution of main operations, for example management of donations further to payments by bank cards, carried out using devices connected by a communication network.
Whereas conventionally, donations were made autonomously, for example, by sending a check or a transfer to a general interest entity or by providing change to a representative of an association, there are now applications implemented by computer (that is to say, in practice, on computer, personal digital assistants, smartphones or the like).
An important feature of the computer-implemented mechanisms for collecting donations concerns the quality of the interfaces enabling donations to be made so that a user is not inclined to dismiss a donation offer due to complexity, excessive time, uncertainty as to the amount, beneficiary or the reliability of the procedure, etc.
While these mechanisms generally follow simple monetary rules by providing, for example, to round a sum to pay for a purchase to the integer above or to pay a predetermined sum for each purchase, the implementation is generally complex for meeting the needs of simplicity of the user and of security concerning the transactions. Furthermore, there is a high demand for traceability of the donations, in particular for tax purposes.
FIG. 1 diagrammatically illustrates an environment in which a mechanism for collecting donations can be implemented enabling a client to make a micro-donation at the time of a purchase, for example a donation of the difference between the price to pay and that price rounded to the integer above.
As illustrated, the environment 100 enables a client 105 having a payment card to make purchases from a merchant having a computer infrastructure 110. In addition to this infrastructure, the environment 100 here comprises a computer system 115 linked to a bank of the merchant, a computer system (not shown) linked to a bank of the client and a computer system 120 linked to a bank of an organization 125 of NGO type (NGO standing for Non-Governmental Organization).
The computer infrastructure 110 of the merchant here comprises, in particular, a computerized accounting system 130, a cash register software application 135 associated with a cash register operated by a checkout operator and a payment terminal 140. The computerized accounting system 130 and the cash register software application 135 are connected to each other by a communication network, for example a network of Ethernet type using IP protocol (IP standing for Internet Protocol).
The computer systems linked to the banks are connected together and to the computerized accounting system 130 as well as to the payment terminal 140 by a communication network of Internet type, the exchanges of data being made secure, for example by encryption.
The donation collection mechanism is generally for the most part implemented in the computerized accounting system 130 of the merchant as well as in its cash register software application.
When a client proceeds to checkout to make the payment for his purchasers (step {circle around (1)}), for an amount denoted M, the checkout operator asks him whether he wishes to make a donation for an amount denoted D (step {circle around (2)}). If the client declines, the payment procedure continues in a conventional manner (not shown).
By contrast, if the client agrees to make a donation (step {circle around (3)}), the checkout operator presses a specific button to calculate a donation value based on the rounding to the integer above of the amount of the purchasers, scans a specific barcode to obtain a similar result, or inputs the amount of the donation using the cash register software application (step {circle around (3)}′). This input is typically carried out by adding a particular reference to the list of the references for the products purchased by the client, this particular reference designating a donation and enabling, the case arising, the manual input of an amount by the checkout operator.
It may be noted that several particular references may each be used to designate an organization to which the donation must be made. The donation is thus integrated in the sales receipt of which the indicated total amount, denoted T, comprises the amount of the real purchases (M) and the donation amount (D). In other words, T=M+D.
In a following step (step {circle around (4)}), the total amount (T) indicated on the sales receipt, the amount of the real purchases (M) and the amount of the donation (D) are sent by the cash register software application 135 to the computerized accounting system 130 of the merchant.
If the payment for the purchases is made by bank card (and not in cash or by check), the cash register software application automatically sends the amount to pay (T) to the payment terminal 140. Alternatively, that amount is manually input by the checkout operator on the payment terminal 140. If it authorized, the client validates the payment using his secret code
The computer system of the merchant's bank tele collects the merchant's takings, typically periodically, and through bank intermediation presents the amount of the payments (T=M or T=M+D depending on whether the client has made a donation or not) to credit an account of the merchant with a corresponding amount (step {circle around (5)}).
In parallel, the merchant's computerized accounting system 130 updates account journals in which appear the amounts of the real purchases (M) and the amounts of the donations (D), typically by beneficiary organization. The separate management of the amounts of the real purchases (M) and of the amounts of the donations (D) is desired for accounting reasons (linked for example to VAT, standing for Value Added Tax) and tax reasons (in particular for calculating the turnover within which the amount of the donations must not be included).
The account journal for the donations is in particular used by the merchant to periodically transfer, for example every month, the total amount of the donations received on behalf of one or more organizations. Such payments are typically made by order of the merchant to his bank, the latter carrying out the transaction order (steps {circle around (6)} and {circle around (6)}′). The organization or organizations then have available the donations paid to carry out their missions (step {circle around (7)}).
It is observed here that implementation of the collection mechanisms for donations or micro-donations such as the one described with reference to FIG. 1 require substantial modifications to the devices used.
Thus, in particular, it is typical to modify the cash register software application and/or to add a software application cooperating therewith, to enable the input of at least one particular reference designating a donation and enabling the calculation of an associated amount or the manual input of an associated amount, in order for a particular article, not subject to VAT, to be added to a sales receipt.
It is also typical to modify the computerized accounting system of the merchant to enable separate management of the real purchase amounts and of the donation amounts, to enable the processing of references of products assimilated with donations and not subject to VAT (these amounts must not be included in the calculation of the turnover), to manage different account journals and to credit external accounts (accounts associated with organizations of NGO type) as well as to calculate the exact amount of the turnover.
Furthermore, it should be noted that the implementation of these donation collection mechanisms requires involvement of the checkout staff in relation to the clients. Thus, for example, the checkout operators must “petition” clients to make a donation then, where appropriate, handle the initiation of the donation management process. This excess work is generally considered to be unpleasant by checkout operators who feel they are begging for donations. Furthermore, this method may have an unpleasant psychological influence and be considered as intrusive by the client who feels trapped in that a refusal may be ill considered by a checkout operator or a client situated nearby when the question is asked.
Thus, the constraints imposed by these donation collection mechanisms have considerable consequences.
Furthermore, there is a risk of substantially slowing down the checkout due to the complexity of the procedure.
Lastly, the modifications to be made to the cash register software application in the merchant's computerized accounting system are very costly (typically of the order of several million euros (dollars) in the case of a retail chain operating nationwide). It is observed here that it is very difficult to export the modifications from one merchant to another, thereby involving repetition of the modification operations and therefore of the related costs.
Lastly, the transfer and the management of the funds are the merchant's responsibility, without real verifications being possible. The traceability of the donations is therefore not ensured, leading to problems such as tax exemption problems.

SUMMARY

At least some of the example embodiments enable at least one of the problems set forth above to be solved.
The examples relate to a method of instructing an annex operation linked to the execution of a main transaction, this method being implemented in an annex operation managing system that is connected to a third party device of a bank payment system further comprising at least two distinct client devices, the bank payment system being configured to carry out a main transaction between the two client devices, and comprising the following steps
receiving information relative to the execution of said main transaction between the two client devices, said information being received from said third party device;
identifying at least one execution rule for executing the annex operation according to at least one first information item of the received information; and
executing the annex operation according to said at least one identified rule and according to at least one second information item of said received information, that is distinct from said first information item.
The example methods described herein thus provides the possibility of making donations at the time of a payment on a payment terminal without modifying the cash register software applications and the computerized accounting systems with which merchants are equipped. In particular, the addition of a module for processing data arising from the payment chain may be used, without modifying the latter. This module is typically added to an item of equipment of the payment chain, for example an item of equipment of a bank providing a payment card used for the payment, without modifying the payment flows. The computerization costs for such a solution as well as the reliability of the solution are thus advantageous.
The collection of donations is particularly fast on account of the fact that it is entirely transparent, for the debtor and for the creditor, when executing the main transaction. The cash register operators are not called upon to collect the donations.
Furthermore, the installation of the method of managing donations according to the examples is particularly simple. Moreover, it enables real control and real traceability of the donations.
According to a particular embodiment, the method further comprises a step of configuring said at least one execution rule in said annex operation managing system.
According to a particular embodiment, the method further comprises a step of storing in memory at least one information item relative to the execution of said annex operation and a step of creating an execution history of annex operations.
According to a particular embodiment, said annex operation executing step comprises a step of sending data to at least one device that is distinct from said third party device.
According to a particular embodiment, said data sent to at least one device that is distinct from said third party device comprise a debit order and a credit order.
According to a particular embodiment, said steps of identifying at least one rule and of executing the annex operation are executed periodically according to the information received and stored beforehand.
At least some of the disclosed embodiments also relate to a computer program comprising instructions adapted for the implementation of each of the steps of the method described earlier when said program is executed on a computer. The advantages procured by that computer program are similar to those referred hereinabove.
At least some of the embodiments can also relate to a device for instructing annex operations linked to the execution of main transactions, said device comprising:
a database;
a module for acquiring and managing annex operations; and,
a calculating module,
the module for acquiring and managing annex operations and the calculating module being configured to
receive data from a third party device of a bank payment system further comprising at least two distinct client devices, the bank payment system being configured to carry out a main transaction between the two client devices; and
identify and execute at least partially a rule for executing an annex operation stored in the database according to the data received.
A device implementing one of the example embodiments can thus provide the possibility of making donations at the time of a payment on a payment terminal without modifying the cash register software applications and the computerized accounting systems with which merchants are equipped. The addition of a module for processing data arising from the payment chain is typically sufficient, without modifying the latter. This module is typically added to an item of equipment of the payment chain, for example an item of equipment of a bank providing a payment card used for the payment, without modifying the payment flows. The costs of computer setup for such a solution as well as the reliability of the solution are thus advantageous.
The collection of donations is particularly fast on account of the fact that it is entirely transparent, for the debtor and for the creditor, when executing the main transaction. The cash register operators are not called upon to collect the donations.
Furthermore, the installation of the device is particularly simple. Furthermore, it enables real control and real traceability of the donations.
According to a particular embodiment, the device further comprises a configuration module, the configuration module enabling the storage of data in said database and the parameterization of rules for executing annex operations.
According to a particular embodiment, the device further comprises a communication interface for acquiring data that is configured to receive data from said third party device.
According to a particular embodiment, said communication interface for acquiring data is unidirectional.
According to a particular embodiment, the device further comprises a configuration communication interface configured to enable a user to input, parameterize or modify a rule for executing annex operations.
According to a particular embodiment, said configuration communication interface gives Internet access to a remote device.
According to a particular embodiment, the device further comprises a communication interface configured to send data to said bank payment system on execution of an annex operation.

BRIEF DESCRIPTION OF THE DRAWINGS

Other advantages, objects and features of the example embodiments will emerge from the following detailed description, given by way of non-limiting example, relative to the accompanying drawings in which:

FIG. 1 diagrammatically illustrates an environment in which a mechanism for collecting donations can be implemented enabling a client to make a micro-donation at the time of a purchase, for example a donation of the difference between the price to pay and that price rounded to the integer above;

FIG. 2 diagrammatically illustrates a first example of an environment in which a particular example embodiment may be implemented;

FIG. 3 diagrammatically illustrates an annex operation managing system;

FIG. 4 diagrammatically illustrates a second example of an environment in which an example embodiment may be implemented; and

FIG. 5 illustrates an example of an information processing device adapted to implement, at least partially, an example embodiment;

FIG. 6 illustrates a network configuration of example devices that can be utilized for practicing the example environments; and

FIGS. 7A-7C show example screenshots of webpages used by users for configuring donation campaigns and obtaining related information in the example environment.

DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS

According to a particular example mode of implementing the example embodiments, a computer-implemented mechanism for instructing annex operations that are linked to the execution of main transactions, for example a donations collecting mechanism, makes use of a specific system connected to a system for executing main transactions to receive data therefrom, without interacting with that system for executing main transactions.
Thus, the system for executing main transactions is only slightly modified, solely to send information relative to the execution of main transactions.
A composite transaction here comprises a main transaction and at least one annex operation of which the execution automatically results in that of the main transaction. Such annex operations typically concern amounts and beneficiaries that are different from those of the main transaction. It may be recalled that a transaction is a commercial operation which, for the part to which a particular embodiment is directed, concerns a transfer of a monetary amount between a debtor and a creditor.
By way of illustration, a composite transaction may comprise the payment for a purchase (main transaction) combined with a donation (annex operation).
According to a particular embodiment, the management of the donations is confined for the most part to a particular computer system directed to the management of donations and the management of the donations themselves. This computer system for managing requests for donations and for managing the donations themselves is called annex operation managing system. It is, for example, a computer system implemented by a server connected to a bank server.
It is to be recalled here that the model which is known, in the field of computerized banking, by the name of four-corner model comprises a payment card of a holder, a payment terminal of a merchant, the merchant's bank and the holder's bank, the two banks being connected to each other via authorization networks also called bank intermediation networks.
According to this four-corner model, a client provided with a payment card, for example a card of Visa® type (Visa is a trademark), may make payment for a purchase to a merchant having a payment terminal. The payment card is associated with a bank account (client account) managed by a computer system of a bank (typically the bank that issued the bank card or on behalf of which the bank card was issued). Similarly, the payment terminal is associated with a bank account (merchant account) managed by a computer system of a bank.
To make a purchase transaction, a client presents his payment card to a payment terminal of a merchant to which the amount has been provided manually or automatically. After validation of the purchase by the client, for example by entering a confidential code or PIN (acronym for Personal Identification Number), the payment terminal generally makes a request for authorization which is sent to the computer system of the card holder's bank via the computer system of the merchant's bank and a bank intermediation network.
The message can be advantageously encrypted and comprises the identifiers of the client and of the merchant as well as the amount to be transferred.
After authentication and verification, in particular of the identity of the client and of that of the merchant as well as of the debtor's bank, a transfer acceptance message, preferably encrypted, is sent by the computer system of the client's bank to the computer system of the merchant′ bank.
After having received a transfer acceptance message, a credit message is sent by the computer system of the merchant's bank to the address of the computer system of the bank managing the bank account with which is associated the payment card used via the bank intermediation network. This message is preferably encrypted.
It is observed here that the requests for bank intermediations may be accumulated and made on a deferred basis. The bank intermediation network may for example be the bank intermediation network MasterCard®, Visa®, GIE Carte Bancaire®, SWIFT®, STET® or Target 2® (MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET and Target 2 are trademarks).
The merchant's account is then credited with the transferred sum whereas the client account is debited with the same amount, typically on a deferred basis.
The encryption used for the data exchanges is, for example, based on a standard encryption algorithm using a public key and a private key, for example encryption of RSA type (RSA standing for Ronald Rivest, Adi Shamir and Leonard Adleman).
According to their nature and/or according to the source and/or destination devices, it may be that only certain exchanges can be encrypted.
In such a standard four-corner model, a main transaction cannot instruct one or more independent annex operations, in particular donations, without substantial modifications to the computer systems of the merchant's bank and to those of the bank managing the bank account with which is associated the payment card used.
In accordance with a particular embodiment, a particular computer system is associated with a bank server to collect information relative to the execution of transactions made by a card holder and to instruct annex operations, in particular donation operations, without modifying the processing of the transactions.
FIG. 2 diagrammatically illustrates a first example of an environment 200 in which a particular embodiment may be implemented based on the four-corner model.
As illustrated, a holder of a payment card 205 of a particular payment account system (e.g., issuing bank) may make a payment at a payment terminal 210 itself connected to a bank computer system 215 of the bank of a merchant to comprise a merchant account system. This bank computer system 215 may in turn, via a bank intermediation network 220, enter into contact with a bank computer system 225 of the bank that issued the payment card used.
The bank computer system 225 is connected, via the bank intermediation network 220, to a bank computer system 230 of a bank managing an account of the holder of the payment card used, from which must be taken the amount of the purchases made. It is also connected to a server 235 implementing an annex operation managing system.
As illustrated, the server 235 implementing an annex operation managing system is itself connected, via the bank intermediation network 220, to the bank computer system 230 of a bank managing an account of the holder of the payment card used, from which will be taken the amount of the donations made and to a bank computer system 240 of a bank managing an account associated with one or more annex operations to be carried out (for example an account of an NGO to which donations are made).
It is observed here that if the bank computer system of the bank managing an account from which must be taken the amount of the purchases made is the same as the bank computer system of the bank managing an account from which must be taken the amount of the donations made, those systems and/or those accounts may be different.
The bank computer system 225 of the bank which issued the payment card used is preferably different from the bank computer system 230 of the bank managing an account of the holder of the payment card used, from which must be taken the amount of the donations made.
The protocols for communication between those different bank computer systems are preferably chosen from standard protocols, for example the IP protocols (IP standing for Internet Protocol) and X.25.
The bank intermediation network 220 is for example the bank intermediation network MasterCard®, Visa®, GIE Carte Bancaire®, SWIFT®, STET® or Target 2®.
The verification of annex operations is here carried out using an identifier associated with the payment card used and an annex operation managing system implemented in the computer system 235 connected to the bank computer system 225 of the bank that issued the payment card used.
The launching and the verification of annex operations may be broken down into two phases, a configuration phase and a utilization phase.
During the configuration phase (denoted {circle around (0)} in FIG. 2), the holder of the card 205 configures characteristics specific to him (which may be grouped together in the form of a profile) in the computer system 235 connected to the bank computer system 225 of the bank that issued the payment card used.
Such a configuration consists for example in determining rules to calculate the amounts of donations and indicate the recipients.
This configuration phase is described in more detail with reference to FIG. 3.
The utilization phase directly concerns the launching and the verification of annex operations further to the execution of a main transaction.
On executing a main transaction, for example to make a purchase for an amount M, a client presents his payment card 205 to a payment terminal 210 of a merchant to which the amount M has been provided manually or automatically. After validation of the purchase by the client (step {circle around (1)}), for example by entering a confidential code or PIN code (PIN being an acronym for Personal Identification Number), the payment terminal 210 here makes an authorization request (step {circle around (2)}) which is sent to the bank computer system 225 of the bank that issued the payment card used (step {circle around (3)}), with the amount M, via the computer system 215 of the merchant's bank and the bank intermediation network 220.
The message is advantageously encrypted and comprises the identifiers of the client and of the merchant as well as the amount to be transferred.
After authentication and verification, in particular of the identity of the client and of that of the merchant as well as of the limits for amounts authorized by the payment card used, a transfer acceptance message (denoted ack), preferably encrypted, is sent by the bank computer system 225 of the bank which sent the payment card used to the computer system 215 of the merchant's bank then to the payment terminal 210 (steps {circle around (2)} and {circle around (5)}).
After having received a transfer acceptance message, a debit message is sent by the computer system 215 of the merchant's bank to the address of the computer system 225 of the bank that issued the payment card used (step {circle around (6)}) via the bank intermediation network 220. This message is preferably encrypted.
A debit message is then sent by the bank computer system 225 of the bank that issued the payment card used to the address of the bank computer system 230 of a bank managing an account of the holder of the payment card used, from which must be taken the amount of the purchases made (step {circle around (7)}), via the bank intermediation 220. Again, this message is preferably encrypted.
It is observed here that the requests for bank intermediations may be accumulated and made on a deferred basis. Similarly, the credit and/or debit operations may be accumulated and made on a deferred basis.
The merchant's account is then credited with the transferred sum while the client's account is debited with the same sum, typically on a deferred basis, excluding commission (for example a merchant commission or an international payment commission).
The encryption used for the data exchanges is, for example, encryption using a public key and a private key, for example encryption of RSA type.
The bank computer system 225 of the bank that issued the payment card used here keeps an account journal comprising information relative to each main transaction made, for example the amount and an identifier associated with the payment card used (but preferably not enabling the number of the payment card used to be reconstituted (this card number enabling purchases to be made).
For each payment card managed by the corresponding bank computer system, account journal information is sent to the computer system 235 implementing the annex operation managing system (step {circle around (8)}), typically a software module. It may be sent for each main transaction or in batches, periodically.
This information is used to determine, on the basis of the configuration made by the holder of the card considered, the annex operations to be carried out, that is to say, for example, calculating a donation amount and identifying the recipient of the donations.
The annex operation managing system is described in more detail with reference to FIG. 3.
As illustrated diagrammatically in FIG. 2, a payment may be made in standard manner by the sending of a debit message from the computer system 235 implementing an annex operation managing system to the address of the bank computer system 230 of a bank managing an account of the holder of the payment card used, from which must be taken the amount of the purchases and/or of the donations made, and by the sending of a credit message from the computer system 235 implementing an annex operation managing system to the address of the bank computer system 240 of a bank managing an account of the recipient or recipients of the donation (steps {circle around (9)} and {circle around (9)}′), via the bank intermediation network 220.
According to a particular embodiment, the payment of donations (credit and debit) is carried out by batch for a set of donations (i.e. a sum of donations ΣD). The payment of accumulated donations is advantageously carried out using a particular account managed by a third party, for example by the entity in charge of the annex operation managing system, also called a clearing account.
FIG. 3 diagrammatically illustrates an annex operation managing system which may be implemented, for example, in a computer system connected to a bank computer system of a bank that issued a payment card enabling annex operations to be executed, for example the computer system 235 of FIG. 2.
As illustrated, the annex operation managing system 300 essentially comprises three modules 305, 310 and 315 as well as a database 320. The module 305 is a module configuration, the module 310 is a module for acquiring and managing annex operations for example for managing donations, and the module 315 is a calculating module, for example for calculating donations.
According to a particular embodiment, the modules 305, 310 and 315 are independent from each other.
As illustrated, the annex operation managing system 300 here comprises the communication interfaces 325, 330 and 335.
The communication interface 325 enables a user to interact with the configuration module 305. It is, for example, a local communication interface (for an access from an item of computer equipment implementing the annex operation managing system 300) or a remote communication interface (for access from a remote item of computer equipment via a communication network). The communication interface 325 preferably provides coding means enabling encryption of the exchanged data.
The configuration module 305 advantageously comprises a user interface operating with the communication interface 325 to enable a holder of a card managed by the manager of the annex operations managing system 300 to enter and parameterize the rules relative to annex operations. These rules may be stored in the form of tables in the database 320. Some of these user management functions are described below with respect to FIGS. 8 and 9.
The access to the module may, according to a particular embodiment, be carried out from a remote computer, using a connection such as the Internet. This access is, preferably, protected by an identifier and a password provided to the card holder in advance in conventional manner.
Table 1, presented in the appendix hereto, illustrates an example of rules relative to annex operations, here donations.

TABLE 1

ID rule	PC REF	RULE	Beneficiary ID

0	543291	Round up	1
1	1294G3	1 fixed amount	1 ( 0.40). 3 ( 0.60)
		per transaction
2	G53391	Lowest of 0.5% of the	1 (50%). 2 (50%)
		transaction and 5
. . .	. . .	. . .	. . .
n	491503	Round up	1

Each row of the table here corresponds to a rule. According to the illustrated example, each rule is defined by an identifier (column 1), an identifier associated with a payment card or a group of identifiers associated with payment cards (column 2), a mode of calculating donations (column 3) and an identifier of a beneficiary or a group of identifiers of beneficiaries (column 4).
Of course, other information may be used in the definition of the rules. Thus, for example, the identifier associated with a payment card may be replaced by or complemented by a client identifier and/or an agreement identifier.
As indicated earlier, an identifier associated with a payment card preferably does not match the payment card number. According to a particular embodiment, such an identifier does not enable the card to be used for making a payment.
When a group of beneficiaries has been designated, the sharing of a donation between them is, preferably, predetermined.
Thus, for example, the rule having the identifier 2 applies to the payment card or the group of payment cards having the reference G53391, the beneficiaries of a first half of a donation being a beneficiary having the identifier 1 and for the second half of the donation a beneficiary having the identifier 2. The amount of the donation is determined here on the basis of the amount of the purchases (0.5%) or as a fixed amount (e.g., 5
or $5), the smallest value being the one chosen.
As described above, the parameterization of these rules may be carried out by a protected access to the annex operation managing system 300. By way of illustration, a payment card holder may, using an identifier specific to him or a reference of his payment card and a password, access all the rules associated with that identifier or that reference, that is to say sub-set of the rules in memory. The access to the rules makes it possible to add, modify or delete rules. The access may be made from some computer or other, from a tablet, a smartphone or any other similar device connected to the annex operation managing system 300 via a communication network such as the Internet and via a portal of web type.
The module 310 for acquiring and managing annex operations, for example managing donations, receives data from the bank computer system of the bank that issued the payment card used (typically the computer system on which the annex operation managing system 300 is implemented) via the communication interface 330. These data, coming from an account journal, typically comprise an identifier associated with the payment card as well as one or more amounts. They may be received by the module 310 periodically, for example daily or weekly, or on request.
The data received may be stored in the database 320 to be processed by the calculating module 315 or be directly sent thereto.
It is, for example, a local communication interface (for an access from an item of computer equipment implementing the annex operation managing system 300) or a remote communication interface (for access from a remote item of computer equipment via a communication network). The communication interface 330 preferably provides coding means enabling encryption of the exchanged data. The communication interface 330 is advantageously unidirectional to enable the reception of data from a bank computer system without authorizing the sending of data to that system, thereby ensuring, in relation to the module 310 for acquiring and managing annex operations, the integrity of the data managed by the bank computer system to which it is connected.
The module 310 for acquiring and managing annex operations manages the results provided by the calculating module 315.
The calculating module 315 uses the rules associated with an identifier associated with the payment card considered, typically an identifier received by the module for acquiring and managing annex operations, stored here in the database 320, to determine the annex operations to perform.
According to a particular embodiment, the module 315 carries out some of the annex operations to carry out, such as the calculations concerned without the rules, for example the calculations of amounts of donations.
The results obtained by the module 315 are, preferably, stored in the database 320, for example in the form of journals of results, for example journals of donations.
Such a journal comprises, for example, for each transaction carried out, as illustrated in table 2 given in the appendix hereto, a transaction reference (column 1), a payment card identifier (column 2), a purchase amount (column 3), an amount of one or more donations made and the associated beneficiary or beneficiaries (column 4), it being observed that the amount of a donation may be shared between several beneficiaries.

TABLE 2

ID trans.	PC REF	M	D. b

0	543291	425.66	1: 0.34
1	543291	35.14	1: 0.86
2	G53391	87.45	1: 0.22. 2: 0.22
. . .	. . .	. . .	. . .
p	1294G3	118.00	1: 0.40. 3: 0.60

A journal of the donations may comprise other information such as an identifier of the merchant associated with the transaction having led to the donations considered. Furthermore, the journal of the donations may comprise the amount T of the payment, representing the sum of the amount M of purchases and of the amount of the corresponding donations.
By way of illustration, the row of the journal concerning the transaction identified by the reference 2 corresponds to a transaction made by a payment card referenced G53391, the amount of the purchases made being 87.45
and the amount of the donation of 0.44
being shared equally between the beneficiaries identified by the references 1 and 2.
The journals of results are accessed periodically, for example every month, by the module 310 for acquiring and managing annex operations.
In the context of donations, the module 310 determines, for example, the total of the donations associated with a payment card in order to debit an account of the holder of the card and credit the account or accounts designated as recipients.
These operations of debit and credit are carried out according to a standard scheme such as those described earlier, using the communication interface 335. By way of illustration, the communication interface 335 gives access to and from a bank intermediation network.
It is observed here that the debit and credit operations are particularly simple to perform for a bank sub-contractor. According to a particular embodiment, the results journals are kept, with an indication specifying that the corresponding operations of debit and credit have been performed, to make it possible, for example, to issue statements of donations which may in particular be used for tax purposes. Such statements are typically issued on request, for example using the configuration module 305 which may comprise consultation tools.
FIG. 4 diagrammatically illustrates a second example of an environment 400 in which a particular embodiment may be implemented based on the model known as the three-corner model.
It may be recalled here that, according to this model for payment by bank card, a single bank computer system is involved for the processing of a transaction. There is a separation between the management of the system for the payment cards and the holding of the debited and credited accounts The single bank computer system passes by systems for compensation and for payment to credit the merchant and debit the holders.
As illustrated in FIG. 4, a holder of a payment card 405 of a particular payment account system (e.g., issuing bank) may make a payment at a payment terminal 410 itself connected to a single bank computer system 415. This single bank computer system 415 may in turn, via a bank intermediation network 420, enter into contact with a bank computer system 425 of the merchant's bank (part of the merchant account system) and with a bank computer system 430 of the bank of the holder of the card used.
Lastly, the single bank computer system 415 is connected to a computer system 435 implementing an annex operation managing system.
As illustrated, the computer system 435 is itself connected, via the bank intermediation network 420, to the bank computer system 430 of a bank managing an account of the holder of the payment card used, from which must be taken the amount of the donations made, as well as to a bank computer system 440 of a bank managing an account associated with one or more annex operations to be made, for example an account of an NGO.
The protocols for communication between these different bank computer systems are, preferably, chosen from among standard protocols, for example the IP and X.25 protocols.
The bank intermediation network 420 is for example the bank intermediation network MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET or Target 2.
The single bank computer system 415 is, for example, a computer system of Amex type (Amex is a trademark).
The verification of the annex operations is here made using an identifier associated with the payment card used and using an annex operation managing system implemented in a computer system connected to the single bank computer system.
According to the example illustrated in FIG. 4, the single bank computer system 415 is that of the bank that issued the payment card used.
As described above with reference to FIG. 2, the launching and the verification of annex operations may be broken down into two phases, a configuration phase and a utilization phase.
The configuration phase (denoted {circle around (0)} in FIG. 4) is similar to that described above with reference to FIG. 3. Again, this configuration consists for example in determining rules to calculate the amounts of donations and indicate the recipients.
The phase of utilization directly concerns the launching and the verification of annex operations when a main transaction is made.
On executing a main transaction, for example to make a purchase for an amount M, a client presents his payment card 405 to a payment terminal 410 of a merchant to which the amount M has been provided manually or automatically. After validation of the purchase by the client (step {circle around (1)}), for example by entering a confidential code or PIN code (PIN being an acronym for Personal Identification Number), the payment terminal 410 here makes a request for authorization of the single bank computer system 415 (step {circle around (2)}).
The message is advantageously encrypted and comprises the identifiers of the client and of the merchant as well as the amount to be transferred.
After authentication and verification, in particular of the identity of the client and of that of the merchant as well as of the limits for the amounts authorized by the payment card used, a transfer acceptance message (denoted ack), preferably encrypted, is sent by the single bank computer system 415 to the payment terminal (step {circle around (3)}).
A credit message is then sent by the single bank computer system 415, via the bank intermediation network 420, to the computer system 425 of the merchant's bank (step {circle around (4)}).
In the same way, a debit message is sent by the single bank computer system 415, via the bank intermediation network 420, to the computer system 430 of a bank managing an account of the holder of the payment card used (step {circle around (5)}).
These debit and credit messages, concerning an amount M, are preferably encrypted.
It is observed here that the requests for debit and/or credit may be accumulated and carried out on a deferred basis.
The merchant's account is then credited with the transferred sum while the client's account is debited with the same sum, typically on a deferred basis, excluding commission (for example a merchant commission or an international payment commission).
The encryption used for the data exchanges is, for example, encryption using a public key and a private key, for example encryption of RSA type.
The single bank computer system linked to the bank that issued the payment card used here keeps an account journal comprising information relative to each main transaction made, for example the amount and an identifier associated with the payment card used (but preferably not enabling the number of the payment card used to be reconstituted (this card number enabling purchases to be made).
For each payment card managed by the single bank computer system 415, account journal information is sent to an annex operation managing system, typically a software module, of the computer system 435 (step {circle around (6)}). It may be sent for each main transaction or in batches, periodically.
It is typically used to determine, on the basis of the configuration made by the holder of the card considered, the annex operations to be carried out, that is to say, for example, calculating a donation amount and identifying the recipient of the donations.
This annex operation managing system may be similar to that described above with reference to FIG. 3.
As illustrated diagrammatically in FIG. 4, a payment of donations may be carried out by the annex operation managing system of the computer system 435, in standard manner, by the sending of a debit message to the address of the bank computer system 430 of the bank managing an account of the holder of the payment card used, from which must be taken the amount of the donations made, and by the sending of a credit message to the address of the bank computer system 440 of a bank managing an account of the recipient of the donations (steps {circle around (7)} and {circle around (7)}′). The operations of debit and of credit are carried out here via the bank intermediation network 420.
When there are several recipients for the donations, several credit messages are sent.
According to a particular embodiment, the payment of donations (credit and debit) is carried out by batches for a set of donations (i.e. a sum of donations ΣD). Again, the payment of accumulated donations is advantageously made using a clearing account.
FIG. 5 illustrates an example of a device able to be used to at least partially implement an embodiment, in particular of the steps described with reference to FIGS. 2, 3 and 4. The device 500 is for example a server, a computer or a personal digital assistant.
The device 500 preferably comprises a communication bus 502 to which are connected:
a central processing unit (CPU) or microprocessor 504;
A read only memory 506 (ROM) able to include the operating system and programs such as “Prog”;
a Random Access Memory (RAM) or cache memory 508, comprising registers adapted to record variables and parameters created and modified during the execution of the aforementioned programs;
a reader 510 of a removable storage medium 512 such as a memory card or a disc, for example a DVD disc; and
a graphics card 514 linked to a screen 516.
Optionally, the device 500 may also have the following items:
a hard disk 520 able to contain the aforesaid programs “Prog” and data processed or to be processed according to the embodiments;
a keyboard 522 and a mouse 524 or any other pointing device such as an optical stylus, a touch screen or a remote control enabling the user to interact with the programs according to the embodiments, in particular to initiate a transfer of money, to configure rules for requests for donations, follow one or more lists of donations and to obtain a tax receipt; and
a communication interface 526 connected to a distributed communication network 528, for example the Internet network, the interface being able to transmit and receive data.
The communication bus allows communication and interoperability between the different elements included in the device 500 or connected to it. The representation of the bus is non-limiting and, in particular, the central processing unit may communicate instructions to any element of the device 500 directly or by means of another element of the device 500.
The executable code of each program enabling the programmable apparatus to implement the processes according to the embodiments may be stored, for example, on the hard disk 520 or in read only memory 506.
According to a variant, the executable code of the programs can be received by the intermediary of the communication network 528, via the interface 526, in order to be stored in an identical fashion to that described previously.
More generally, the program or programs may be loaded into one of the storage means of the device 500 before being executed.
The central processing unit 504 will control and direct the execution of the instructions or portions of software code of the program or programs according to the embodiments, these instructions being stored on the hard disk 520 or in the read-only memory 506 or in the other aforementioned storage elements. On powering up, the program or programs which are stored in a non-volatile memory, for example the hard disk 520 or the read only memory 506, are transferred into the random-access memory 508, which then contains the executable code of the program or programs according to the embodiments, as well as registers for storing the variables and parameters desirable for implementation of the embodiments.
A consumer who desires to use the methodology to make donations to chosen charities or other organizations, for example the holder of a credit card who desires to make donations upon use of that credit card, can access the annex operation managing system using a user computer device to remotely configure an account on the system, such as by using a configuration webpage or other user interface provided on the user computer device.
The consumer user can use the configuration website to choose which credit cards or other payment systems to utilize for the donation method, choose which charities to donate to (such as by choosing from a list of participating charities or suggesting one), and which bank accounts to utilize. The user can choose rules to apply, such as for donating a percentage of the transaction, or a fixed amount per transaction, or to round up transaction values for donating the rounding portion, for example. And the user can use the interface to change settings when desired. The merchants that will be used to participate in the method may also be chosen in some embodiments, so that only purchases at certain merchants are utilized for donations.
The website can also provide the user with up-to-date donation information, tax impacts, terms and conditions, donation and settings reports, and other information and settings.
FIG. 7A shows an example screenshot of a summary webpage that displays to the user total donation amount information, tax savings information, user personal information, some current settings, and specific donation activities. Links to other pages such as setting change pages, information pages, social media pages, and personal settings and information are also provided.
FIG. 7B shows an example screenshot of a webpage that provides the user's particular donation campaigns for showing which charities the user has chosen to donate to, and allowing the user to add or modify such charities. A list of available charities is also available.
FIG. 7C shows an example screenshot of a webpage that provides the user the ability to configure a new campaign.
By using this web interface, the user can customize a donation campaign in many different ways, so that donations are automatically made when the user uses the configured credit cards or other payment systems at participating (or at all) merchants).
Naturally, to satisfy specific needs, a person skilled in the art will be able to apply modifications in the preceding description. The present example embodiments are not limited to the described embodiments, other variants and combinations of features are possible.
In particular, it is observed here that although, for the purposes of illustration, the embodiments have been described according to particular embodiments, there are other variants.
Thus, for example, the embodiments may be implemented in a context of payment via network; in particular payments by Internet such as payments of secure on-line shopping type or of m-POS type (m-POS standing for mobile Point of Sale).
Similarly, still by way of illustration, the embodiments may be implemented at the time of operations of withdrawal type (a donation being made for each withdrawal, which may or may not be based on certain limits).
As will be appreciated by one of skill in the art, the example embodiments described herein, among others, may be actualized as, or may generally utilize, a method, system, computer program product, or a combination of the foregoing. Accordingly, any of the computer devices of the example embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) for execution on hardware, or an embodiment combining software and hardware aspects that may generally be referred to as a “system.” Generally, the “system” will comprise a server with storage capability such as one or more databases that interact with a plurality of remote devices via a communication network such as the Internet, an intranet, or another communication network such as a cellular network, for example. Such networks may utilize Ethernet, WiFi. Bluetooth, POTS, cellular, combinations thereof, or other network hardware. Remote devices may include any of a plurality of computing devices, such as smart phones, phablets, tablets, computerized registers, card readers, or personal computers, for example. The remote devices will typically execute software, and in the example embodiments this may include specialized software and/or plug ins to perform the functions described herein.
Furthermore, any of the embodiments may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium, in particular the functions executing on the server system which may include one or more computer servers and one or more databases, such as, for example, described herein below.
Any suitable computer usable (computer readable) medium may be utilized for storing the software to be executed for implementing the method. The computer usable or computer readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer readable medium would include the following: an electrical connection having one or more wires; a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CDROM), cloud storage (remote storage, perhaps as a service), or other tangible optical or magnetic storage device; or transmission media such as those supporting the Internet or an intranet.
Computer program code for carrying out operations of the example embodiments (e.g., for the aps or server software) may be written by conventional means using any computer language, including but not limited to, an interpreted or event driven language such as BASIC, Lisp, VBA, or VBScript, or a GUI embodiment such as visual basic, a compiled programming language such as FORTRAN, COBOL, or Pascal, an object oriented, scripted or unscripted programming language such as Java, JavaScript, Perl, Smalltalk, C++, Object Pascal, or the like, artificial intelligence languages such as Prolog, a real-time embedded language such as Ada, or even more direct or simplified programming using ladder logic, an Assembler language, or directly programming using an appropriate machine language. Web-based languages such as HTML or any of its many variants may be utilized. Graphical objects may be stored using any graphical storage or compression format, such as bitmap, vector, metafile, scene, animation, multimedia, hypertext and hypermedia, VRML, and other formats could be used. Editing and development tools for any of these languages and/or formats can be used to create the software.
The computer program data and instructions of the software and/or scripts may be provided to a remote computing device (e.g., a smartphone, tablet, phablet, PC, card readers, cash registers, or other device) which includes one or more programmable processors or controllers, or other programmable data processing apparatus, which executes the instructions via the processor of the computer or other programmable data processing apparatus for implementing the functions/acts specified in this document. It should also be noted that, in some alternative implementations, the functions may occur out of the order noted herein. In particular, the disclosed embodiments may utilize installed operating systems running specialized software for providing the desired user interfaces for interacting with the users using the remote devices.
FIG. 6 shows an example of various hardware networked together that could be used for implementing an example environment 200 (FIG. 2) to practice one or more of the example embodiments described herein. A server 610 connected to one or more databases 612 for storing the various software applications and data used by the system, such as one that might be utilized for implementing a computer management system for donations (e.g., device 500 as shown in FIG. 5). The server 610, which may comprise one or more computer servers and/or other computing devices, can be connected to a communication network 600 (such as the Internet), possibly via an internal network (e.g., an intranet) for generating the data for transmittal to various external devices 621, 622, 626 as desired. Additional external systems (such as payment processors, among others) may user a server 650 with database 652, also connected to the communication network 600. Any of the servers may include an a web server located in the “cloud”, and it will likely be accessible to the remote computing devices via the communication network 600, which may include the Internet, cellular networks, WiFi networks, and Bluetooth networks, among others. The external devices may include, among others, tablets, smartphones, cell phones, laptops, and personal computers, among others, any of which may connect to the server 610 via the communication network 600 (e.g., the Internet) via various means described herein.
Various vendor/retailers can have various external equipment, such as computer terminals 633, cash registers 632, and/or credit card readers 631 connected to a local communication network 630 that communicates with the server 610 via the communication network 600, for implementing any of the disclosed embodiments, as desired.
The present example embodiments has been described and illustrated in the present detailed description with reference to the appended Figures. However, the embodiments are not limited to the examples presented. Other variants and embodiments may be deduced and implemented by the person competent in the art on reading the present description and appended Figures.
In the claims, the term “comprise” does not exclude other elements or other steps. The indefinite article “a” does not exclude the plural. A single processor or several other units may be used to implement the embodiments. The different features presented and/or claimed may advantageously be combined. Their presence in the description or in different dependent claims does not indeed exclude the possibility of combining them. The reference signs are not to be understood as limiting the scope of the embodiments.

Claims

1. A method for executing an annex operation using an annex operation management system, said annex operation being based on a main transaction between a merchant account system and a customer account system using a payment account system selected by the customer, said annex operation for providing donations to any of a plurality of different organizations, said method comprising the steps of:

providing the customer with an interface for selecting one or more of the different organizations for receiving donation contributions;

the merchant account system sending information about the main transaction to the payment account system over a communication network, said information about the main transaction including a first information item and a second information item distinct from said first information item;

the payment account system sending, over the communication network to the annex operation management system, the first information item and the second information item;

the annex operation management system identifying at least one execution rule for executing the annex operation according to the first information item; and

the annex operation management system executing the annex operation according to said at least one identified rule and according to said second information item, wherein

said annex operation includes automatically supporting a donation from the customer account system to the chosen one or more of said plurality of different organizations.

2. A method according to claim 1, further comprising a step of configuring said at least one execution rule in said annex operation managing system.

3. A method according to claim 1, further comprising a step of storing in memory at least one information item relative to the execution of said annex operation and a step of creating an execution history of annex operations.

4. A method according to claim 1, wherein said step of executing the annex operation comprises a step of annex operation management system sending data to at least one device that is distinct from said payment account system.

5. A method according to claim 4, wherein said data sent to at least one device that is distinct from said payment account system comprise a debit order and a credit order.

6. A method according to claim 1, wherein said steps of identifying at least one execution rule and of executing the annex operation are performed periodically according to information received and stored by the annex operation management system in advance of the main transaction.

7. The annex operation management system for performing the method of claim 1, wherein said annex operation management system comprises:

a database;

a computer for executing a module for acquiring and managing annex operations; and,

the computer also for executing a calculating module, wherein

the module for acquiring and managing annex operations and the calculating module are configured to:

receive data from the payment account system interacting with merchant account system and a customer account system to carry out the main transaction between the merchant account system and a customer account system, and

identify and execute at least partially the at least one identified rule for executing an annex operation which is stored in the database.

8. A system comprising the annex operation management system for performing the method of claim 1.

9. The system according to claim 8, further comprising a configuration module configured to enable the storage of data in the database and the parameterization of rules for executing the annex operations.

10. The system according to claim 9, further comprising a communication interface for acquiring data via the communication network.

11. The system according to claim 10, wherein said communication interface for acquiring data is unidirectional.

12. The system according to claim 11, further comprising a configuration communication interface configured to enable the user to input, parameterize or modify a rule for executing annex operations.

13. The system according to claim 12, wherein said configuration communication interface gives Internet access to a remote device.

14. The system according to claim 13, further comprising a communication interface configured to send data to a bank payment system supporting the chosen one or more of said plurality of different organizations upon execution of the annex operation.

15. The method according to claim 1, wherein said transaction between the merchant account system and the customer account system is initiated using a credit card associated with the payment account system.

16. The method according to claim 1, wherein said annex operation management system provides data to a customer device over a communication network to provide a user interface to the customer for performing the step of selecting one or more of the different organizations for receiving donation contributions.

17. The method according to claim 1, wherein said first information item includes an identification of a payment device of the payment account system used by the customer for said main transaction, and wherein said second information item includes a cost of the main transaction.

18. A method for executing an annex operation using an annex operation management system, said annex operation being based on a main transaction between a merchant account system and a customer account system using a payment account system selected by the customer, said annex operation for providing donations to any of a plurality of different organizations, said method comprising the steps of:

The annex operation management system sending interface data to a customer computer device using a communication network, said interface data configured for creating a customer interface on the user device for providing a list of the plurality of different organizations for allowing selection of one or more of the different organizations for receiving donation contributions;

the annex operation management system identifying at least one execution rule for executing the annex operation according to the first information item;

said annex operation includes automatically supporting a donation from the customer account system to the chosen one or more of said plurality of different organizations; and

sending data to a bank payment system for providing donations to the chosen one or more of said plurality of different organizations upon execution of the annex operation.

19. A method for executing an annex operation using an annex operation management system, said annex operation being based on a main transaction between a merchant account system and a customer account system using a payment account system selected by the customer, said annex operation for providing donations to any of a plurality of different organizations, said method comprising the steps of:

said annex operation includes automatically supporting a donation from the customer account system to the chosen one or more of said plurality of different organizations;

sending data to a bank payment system for providing donations to the chosen one or more of said plurality of different organizations on behalf of the customer upon execution of the annex operation;

said annex operation management system tracking donations made to the chosen one or more of said plurality of different organizations on behalf of the customer; and

said annex operation management system sending status data to the customer computer device over the communication network, said status data configured to generate a user interface on the customer computer device for displaying information about the tracked donations.