EP3195224A1 - Procédés et dispositifs de gestion de transactions composites - Google Patents

Procédés et dispositifs de gestion de transactions composites

Info

Publication number
EP3195224A1
EP3195224A1 EP15771997.2A EP15771997A EP3195224A1 EP 3195224 A1 EP3195224 A1 EP 3195224A1 EP 15771997 A EP15771997 A EP 15771997A EP 3195224 A1 EP3195224 A1 EP 3195224A1
Authority
EP
European Patent Office
Prior art keywords
transaction
ancillary
donation
initiating
parameter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP15771997.2A
Other languages
German (de)
English (en)
Inventor
Ghislain D'ALANÇON
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Heoh
Original Assignee
Heoh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Heoh filed Critical Heoh
Publication of EP3195224A1 publication Critical patent/EP3195224A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/209—Specified transaction journal output feature, e.g. printed receipt or voice output
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0279—Fundraising management

Definitions

  • the present invention relates to the management of financial transactions made by debtors to creditors via bank accounts of the latter. More specifically, the invention relates to methods and devices for managing composite transactions, for example transactions involving payment and donation to a particular organization, performed using devices connected by a communication network.
  • An essential feature of computer-implemented donation collection mechanisms is the quality of the interfaces for making donations so that a user is not inclined to discard an offer of donations for reasons of complexity, excessive time, uncertainty as to the amount, the beneficiary or the reliability of the procedure, etc.
  • Figure 1 schematically illustrates an environment in which a donation collection mechanism can be implemented whereby a customer can make a micro-donation during a purchase, for example a donation of the difference between the price to be paid and this price rounded up to the next integer.
  • the environment 100 allows a client 105 having a payment card to make purchases from a merchant with a computer infrastructure 1 10.
  • the environment 100 includes here a system computer 1 15 linked to a merchant's bank, a computer system (not shown) linked to a customer's bank and a computer system 120 linked to a bank an organization 125 of the NGO type (acronym of Non-Governmental Organization).
  • the merchant's IT infrastructure 1 10 here comprises, in particular, an accounting computer system 130, cash register software 135 associated with a cash register operated by a cashier and a payment terminal 140.
  • the accounting computer system 130 and the software cash register 135 are connected to each other by a communication network, for example a network of Ethernet type implementing the IP protocol (abbreviation of Internet Protocol in English terminology).
  • the computer systems linked to the banks are interconnected with the accounting computer system 130 and the payment terminal 140 by an Internet type communication network, the data exchanges being secured, for example by encryption.
  • the donation collection mechanism is generally implemented primarily in the accounting computer system 130 of the merchant as well as in his cash register software.
  • step ⁇ When a customer goes to the cash register to pay for his purchases (step ⁇ ), with an amount marked M, the cashier asks him if he wishes to donate an amount marked D (step ⁇ ) . If the customer refuses, the payment process continues in a conventional manner (not shown).
  • step ® if the customer agrees to make a donation (step ®), the cashier presses a specific button to calculate a donation value based on the rounding up of purchases, passes a specific barcode to obtain a similar result or enter the donation amount using the cash register software (step ® ').
  • This input is typically done by adding a particular reference to the list of product references purchased by the client, this particular reference designating a donation and allowing, if necessary, the seizure of a free amount by the cashier.
  • T M + D.
  • step (step)) the total amount (7) indicated on the receipt, the amount of the actual purchases (M) and the donation amount (D) are transmitted by the cash register software 1 35 to the computer system. Accountant 1 30 of the merchant.
  • the cash register software automatically transmits the amount to pay (7) to the payment terminal 140. Alternatively, this amount is entered by the hostess. cash box on the payment terminal 140. If it is authorized, the customer validates the payment using his secret code.
  • the merchant's accounting computer system 130 updates account journals in which the actual purchase amounts (M) and the donation amounts (D) are shown, typically by beneficiary organization.
  • the separate management of the amounts of the actual purchases ⁇ M) and the amounts of the donations (D) is necessary for accounting reasons (for example related to VAT, acronym for Value Added Tax) and fiscal (especially for the calculation of the figure). in which donations must not be returned).
  • the donations account log is used by the merchant to periodically pay, for example every month, the total amount of donations received on behalf of one or more organizations. Such payments are typically made by order of the merchant to his bank, the latter executing the transaction order (steps ⁇ and ⁇ '). The organization or organizations then have donations paid to perform their missions (step ®).
  • the invention solves at least one of the problems discussed above.
  • the subject of the invention is thus a method for managing a composite transaction comprising a main transaction and at least one ancillary operation, this method being implemented in a set comprising a device for initiating a transaction, a device for proposing at least one transaction. an annex operation according to characteristics of a main transaction and an ancillary operations management device, said device for proposing at least one ancillary operation being accessible by a plurality of devices for initiating a distinct transaction and by a plurality of management devices separate operations, this method comprising the following steps,
  • step estimation of at least one parameter of said at least one annex operation, based on at least one predetermined rule, according to at least one piece of information received relating to said main transaction, said step estimation being implemented in said device to propose at least one additional operation;
  • the method according to the invention thus offers the possibility of making donations during payment on a payment terminal without substantially modifying cash register software and accounting computer systems equipping merchants. Costs of computer implementation at merchants are therefore not significant (the same device for proposing at least one ancillary operation or the same system of management of request for donations can be used by systems of different merchants, systems of different banks and / or systems of different recipients of donations).
  • the collection of donations is particularly rapid because of a number of operations that can be limited to a single entry type acceptance. In addition, cashiers are not asked to collect donations.
  • the donation management method according to the invention allows the simplified installation in a large number of merchants as well as the control and traceability of donations.
  • the method further comprises a step of selecting said at least one rule to estimate said at least one parameter of said at least one ancillary operation.
  • the method further comprises a step of receiving an identifier of said device for initiating a transaction, said at least one rule for estimating said at least one parameter of said at least one subsidiary operation being selected according to said identifier of said device for initiating a transaction.
  • the method further comprises an initial step of configuring at least one rule to estimate at least one parameter of at least one ancillary operation.
  • said data transmitted to said ancillary operations management device in response to an indication of acceptance of said at least one annex operation further comprises said information relating to said main transaction.
  • the method further comprises a step of transmitting a print command to said device for initiating a transaction, said print command for printing a receipt comprising said at least one parameter of said at least one ancillary operation and said at least one received information.
  • a customer can keep a proof of a donation made through the printing of a ticket by a payment terminal that includes a reference.
  • the latter allows the identification of the user on a computer system donation management allowing including access to a set of donations already made and download tax receipts.
  • said print command also aims to print a reference to an identifier of a personal entity on said receipt.
  • said data comprising at least said at least one parameter of said at least one annex operation further comprises said reference.
  • the method further comprises a step of storing said at least one parameter of said at least one ancillary operation.
  • the method further comprises a step for generating a transaction based on at least one previously stored parameter of at least one ancillary operation.
  • the method further comprises a step for generating a summary of ancillary operations, said summary comprising at least one previously stored parameter of at least one ancillary operation.
  • the method further comprises a step of encrypting at least one piece of data transmitted between said device for initiating a transaction and said device for proposing at least one ancillary operation or between said device for proposing at least one operation annex and said ancillary operations management device.
  • the communication protocol between said device for initiating a transaction and said device for proposing at least one ancillary operation or between said device for proposing at least one ancillary operation and said ancillary operations management device complies with to an IP type standard.
  • the invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer and a system comprising means adapted to the implementation of each of the steps of the method described above.
  • a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer
  • a system comprising means adapted to the implementation of each of the steps of the method described above.
  • FIG. 1 schematically illustrates an environment in which can be implemented a mechanism for collecting donations allowing a customer to make a micro-donation during a purchase, for example a gift of the difference between the price to pay and this price rounded up to the next integer;
  • FIG. 2 diagrammatically illustrates an environment in which a particular embodiment of the invention can be implemented as well as certain steps of an exemplary method according to the invention
  • FIG. 3 diagrammatically represents a payment terminal element comprising a screen on which several choices of donations are offered to a user
  • FIG. 4 schematically illustrates a standard example of payment by payment card in an infrastructure comprising a payment card, a payment terminal as well as banking computer systems related to the debtor and the creditor;
  • FIG. 5 illustrates an exemplary information processing device adapted to implement, at least partially, an embodiment of the invention.
  • a mechanism for managing computer-implemented composite transactions uses several devices including a set of third-party devices to isolate at least partially specific elements of the management of composite transactions.
  • a composite transaction here includes a main transaction and at least one side operation.
  • the latter or the latter typically involve amounts and beneficiaries different from those of the main transaction.
  • a transaction is a commercial transaction for the part that is the subject of a particular embodiment of the invention, a transfer of a monetary sum between a debtor and a creditor.
  • a composite transaction may include the settlement of a purchase (main transaction) combined with a donation (ancillary transaction).
  • the management of donations is essentially entrusted to two separate servers, one for the purpose of managing requests for donations, called computer system for managing requests for donations or more generally device for proposing at least one ancillary operation, and the other the management of the donations themselves, called the donation management computer system or more generally the ancillary operations management device.
  • FIG. 2 schematically illustrates an environment in which a particular embodiment of the invention can be implemented as well as certain steps of an exemplary method according to the invention.
  • the environment 200 here comprises an assembly including a cash register software 202, a payment terminal 205 (more generally called a device for initiating a transaction), an accounting computer system 210, a computer system for managing requests for donations 215 and a system 220.
  • the cash register software 202, the payment terminal 205 and the accounting computer system 210 belong to the merchant 225.
  • the cash register software 202 and the payment terminal 205 as well as the cash register software 202 and the accounting computer system 210 are connected by a private or public communication network, for example an Ethernet network or the Internet network.
  • the payment terminal 205 is here also connected to the computer system for managing requests for donations 215, for example an Ethernet network or the Internet network, enabling real-time data exchange.
  • the computer system for managing requests for donations 215 and the donation management computer system 220 are here accessible via a public communication network, for example the Internet, to be accessible by computer systems of different merchants and different users ( ie customers).
  • a public communication network for example the Internet
  • the communication protocols between these different devices are preferably chosen from standard protocols, for example the IP and X.25 protocols.
  • the environment 200 further comprises a bank intermediation network 230, for example the banking intermediation network MasterCard, Visa, GIE Bank Card, SWIFT, STET or Target 2 (MasterCard, Visa, GIE Bank Card, SWIFT, STET and Target 2 are trademarks), as well as computer systems for managing bank accounts 235 to 250 respectively associated with a customer, the merchant having the cash register software 202, the payment terminal 205 and the computer accounting system 210, with a third party in charge of the management of donations and to an organization receiving donations.
  • a bank intermediation network 230 for example the banking intermediation network MasterCard, Visa, GIE Bank Card, SWIFT, STET or Target 2 (MasterCard, Visa, GIE Bank Card, SWIFT, STET and Target 2 are trademarks), as well as computer systems for managing bank accounts 235 to 250 respectively associated with a customer, the merchant having the cash register software 202, the payment terminal 205 and the computer accounting system 210, with a third party in charge of the management of donations and to an organization receiving donations.
  • the data exchanged between the cash register software 202, the payment terminal 205, the computer accounting system 210, the computer system for managing donation requests 215, the computer system for managing donations 220, the banking intermediation network 230 and the bank account and transaction management computer systems 235 to 250 are transmitted in the form of encrypted messages using standard algorithms, for example algorithms based on the use of private keys and public keys, including RSA type algorithms (Ronald Rivest, Adi Shamir and Leonard Adleman), in packets. Alternatively, only certain exchanges are encrypted according to their nature and / or according to the source and / or destination devices.
  • an initial step is intended to configure the donation request management computer system 215.
  • Such a configuration notably comprises the definition of one or more rules associated with one or more payment terminals.
  • payment typically all payment terminals of the same merchant, defining a method of calculating the amount of gifts and associating a gift to a recipient, for example an NGO-type organization.
  • These rules are typically applied according to parameters received, for example according to a value received (e.g., transaction amount), and / or an identifier of the device from which these data (i.e. issuer of the message comprising these data) are received.
  • a value received e.g., transaction amount
  • an identifier of the device from which these data i.e. issuer of the message comprising these data
  • Each rule is here defined by an identifier (column 1), an identifier of a payment terminal or a group of payment terminals (column 2), a donation calculation mode (column 3) and an identifier of beneficiary or group of beneficiaries (column 4).
  • the distribution of a donation between them can be predetermined or left to the discretion of a user (including selecting a single beneficiary in the group).
  • the rule having the identifier 2 applies to the payment terminal or the group of payment terminals having the identifier G53391, the beneficiaries being for a first half of a donation a beneficiary having the identifier 1 and for the second half of the donation a beneficiary with the identifier 2.
  • the amount of the donation is here determined according to the amount of purchases (0.5%) or in a lump sum ( € 5), the smallest value being retained.
  • the setting up of these rules can be done by a protected access to the computer system for managing requests for donations 215.
  • a merchant can access, using an identifier of a payment terminal or a payment terminal. a group of payment terminals and a password, to all the rules associated with this identifier, that is to say a subset of the stored rules.
  • Rule access allows you to add, edit, or delete rules. Access can be done from any computer (or equivalent) connected to the computer system for managing requests for donations 215 via a communication network such as the Internet and via a web-like portal.
  • a communication link or a communication session is established between the payment terminal 205 and the computer system for managing requests for donations 215.
  • the communication link is established automatically after entering, obtaining or validating the amount M purchases.
  • the payment terminal comprises an address of the computer system for managing requests for donations 215, for example a URL link (abbreviation 'Uniform Resource Locator in English terminology) associated with an access command called as soon as an amount is entered, obtained or validated.
  • the computer system for managing donation requests 215 can be accessed from different payment terminals managed by different merchants, that is to say by different payment terminals having no links between them.
  • the amount M of the purchases as well as an identifier of the payment terminal and the transaction are transmitted by the payment terminal. 205 to the grant request computer system 215 (step ⁇ ).
  • the amount M of the purchases as well as the identifier of the payment terminal are transmitted in the form of a message to a predetermined address or to a dynamically determined address, for example using a DNS type mechanism (acronym Domain Name System in English terminology).
  • the donation request management computer system 215 determines the applicable donation calculation rule or rules, in particular according to the identifier received from the payment terminal, and calculates one or more donation values. This or these values are then transmitted to the payment terminal, each value being associated with a beneficiary denoted b (step ⁇ ').
  • the donation value (s) and the corresponding beneficiaries are then preferably displayed on a screen of the payment terminal to enable the client to validate a donation proposal, to select and validate a donation proposal from among several, to freely enter an amount. donate or pay for purchases without making a donation.
  • the selection or refusal of a donation is made by a single touch of a key of the payment terminal (or a device connected thereto).
  • a payment terminal can be deported, for example on a smartphone device or a website, to allow a user to view and / or validate choices on his own device.
  • FIG. 3 schematically represents a payment terminal element comprising a screen on which several choices of donations are offered to a user.
  • the payment terminal element 300 here comprises a set 305 of keys and a screen 31 0.
  • the screen displays a message offering the possibility to a user to make a donation of € 0.54 to the Red Cross or the Restos du C ⁇ urs (the Red Cross and the Restos du C ⁇ urs are trademarks) or to pay for purchases without making a donation.
  • a pressure on the key 1, referenced 330 has the effect of the payment of a donation of 0.54 € to the Red Cross
  • a pressure on the key 2 , referenced 335 has the effect of paying a donation of € 0.54 to Restos du C ⁇ urs
  • pressing the A key, referenced 340 has the effect of paying for its purchases without making a donation.
  • the validation of purchases is made by entering a PIN associated with the card used or by any other means biotechnology (eg fingerprints).
  • biotechnology eg fingerprints
  • the PIN can be a code associated with an identifier previously obtained from the user.
  • the withdrawal of the amount T from the user's bank account and the credit of an equivalent amount from the merchant's bank account is advantageously effected in a conventional manner as described with reference to FIG. 4 (step)).
  • the payment terminal 205 addresses, if necessary, an indication of acceptance of donation to the computer system for managing requests for donations 21 5, typically in the form of a message including the value (s) of the gift and the selected beneficiary (step)).
  • the computer system for managing requests for donations 21 5 preferably returns a command for printing a ticket containing the details of the operation, that is to say the total payment made and its distribution. between the payment of purchases and the donation made (step '). On receipt of this order, the payment terminal prints this ticket which is given to the user.
  • the print order of a ticket is transmitted with a card reference (Rc) associated with the payment card used, this card reference being preferably determined by the payment terminal from an identifier or a card number (for example by applying a hash function on the card number).
  • Rc card reference
  • a person identifier (I Dp) is given to each user when he / she is registered on the donation management computer system 220 (the entry typically comprising the creation of a user profile).
  • the card reference provided on the ticket can be used for this registration which can be performed, for example, via a web interface.
  • the creation of a profile may be subject to the provision of additional information, for example, in addition to providing the card reference, the user may be asked to give the last six digits of the number. the payment card (from which a card reference can be generated that will be compared to that received to validate it).
  • a password is advantageously associated with the person identifier to secure access to data relating to this donor.
  • a profile is created. It includes the card reference, other credit card references that can be associated with this profile.
  • the person identifier enables a donor to connect to the donation management system 220, for example via a web page, and to obtain information relating to the history of donations made, download the tax receipts for the amounts of the donations accumulated on all of his cards or receive information from the beneficiary associations of his enjoyment.
  • the person identifier and the associated profile are preferably known only from the donation management computer system 220 (Le., They are not known to the payment terminal 205 or the computer system for managing requests for donations 215 ).
  • the payment terminal sends the donation request processing computer system 215 a reference of the payment card used with the donation acceptance indication.
  • the donation management computer system 220 can retrieve a previously created person identifier (the donation management computer system 220 stores the links between a person identifier and one or more card references, for example in a table). If no person ID is found, the donation data is stored for later processing after the creation of a user profile associated with the corresponding card reference.
  • the computer system for managing requests for donations 215 stores the amount of the purchases M and the amount of the donation D made in a donation journal.
  • the latter comprises, for each transaction carried out, a transaction reference, an identifier of a payment terminal or a group of payment terminals, a reference Rc of payment card, an amount M of purchases, an amount of donation (s) made and the associated beneficiary (s) (it being observed that the amount of a donation may be divided among several beneficiaries).
  • FIG. 2 An example donation log from a donation request management computer system is shown in the Appendix (Table 2).
  • the log line for the transaction identified by reference 2 corresponds to a transaction made from a payment terminal or a group of payment terminals identified by reference G53391 for the donor who used the transaction. a card with the reference 023, the amount of purchases made being € 87.45 and the amount of the gift of € 0.44 divided equally between the beneficiaries identified by references 1 and 2.
  • an identifier of a payment terminal or a group of payment terminals, a reference Rc to a payment card, an amount M of purchases, a donation amount (s) made and the associated beneficiary (s), the donation journal may, optionally (not shown), include the amount T of the payment, representing the amount of M purchases and the amount of the donation (s) made.
  • the donation journal is transmitted periodically, for example every hour or night, to the donation management computer system 220 (step)) where it is stored. After transmission to the donation management computer system, the donation journal stored in the donation management computer system 220 is reset (however, a copy is preferably kept).
  • the donation management computer system 220 then analyzes the donation journal to extract the parts relating to a particular computerized accounting system, for example the computer accounting system 210, that is to say the computerized accounting system associated with a terminal. payment or to a group of payment terminals.
  • the extracted parts relating to a particular accounting computer system are here transmitted to the latter to allow him to perform an accounting reconciliation (step ®).
  • the donation management computer system 220 calculates, for a particular accounting computer system, the sum of the donations made by customers to payment terminals associated with it, dénoté ⁇ D. This calculation is made from the purchase journal, by cumulating donations associated with the same payment terminal or the same group of payment terminals. A request for collection or payment of this amount is then sent to this accounting computer system to credit this amount a bank account associated with the computer system donation management (step ®).
  • the donation management computer system 220 calculates, for each beneficiary, the sum of the donations to be returned to him. Again, this calculation is done from the donation journal, accumulating donations associated with the same beneficiary.
  • the donation journal stored in the donation management computer system 220 is preferably updated following the transfer of donations. However, a history is kept to allow the traceability of donations and establishment, if necessary, of tax records.
  • the computer system donation management 220 calculates, for a particular user, for some or for all users, the sum of donations paid during a given period, typically a fiscal year. Again, this calculation is done from the donation journal, accumulating donations associated with the same user.
  • the implementation of the solution described with reference to FIG. 2 requires the creation of a computer system for managing requests for donations and a computer system for managing donations as well as the creation of interfaces. .
  • the following interfaces are created:
  • the data exchange interfaces are based on usual communication protocols and use standard encryption algorithms.
  • these exchanges can use the IP protocol combined with an encryption of data by private keys and public keys of the RSA type.
  • Figure 4 schematically illustrates a standard example of payment by payment card in an infrastructure including a card payment terminal, payment terminal and bank computer systems related to the debtor and the creditor.
  • a payment scheme is also known as a four-corner credit card payment model.
  • This payment scheme or a similar scheme can in particular be used for transfers of money between a cardholder's account and a merchant's account as referred to with reference to FIG. 2.
  • This payment scheme can be used, like the traditional schemes used for checks, transfers and withdrawals, for money transfers between the accounts of a merchant (referenced 240 in Figure 2), a donation manager (referenced 245 in Figure 2) and a beneficiary association (referenced 250 in Figure 2).
  • a customer provided with a payment card 400 for example a Visa-type card (Visa is a brand), here settles a purchase from a merchant with a payment terminal 405.
  • the payment card is associated with a bank account 410 (customer account) managed by a computer system 415 of a bank (typically the bank having issued the bank card or on behalf of which the bank card has been issued).
  • the payment terminal 405 is associated with a bank account 420 (merchant account) managed by a computer system 425 of a bank.
  • a customer presents his credit card to a payment terminal of a merchant to which the amount has been transmitted manually or automatically (step ⁇ ).
  • the payment terminal After validation of the purchase by the customer, for example by entering a PIN or PIN (acronym for Personal Identification Number in English terminology), the payment terminal typically makes a request for authorization that is transmitted to the computer system 41 5 of the bank of the cardholder via the computer system 425 of the merchant bank and a banking intermediation network 435 (step ⁇ and ®).
  • the message is advantageously encrypted and includes the identifiers of the customer and the merchant as well as the amount to be transferred.
  • a transfer acceptance message is sent by the computer system 415 of the customer's bank to the customer. 425 computer system of the merchant's bank (step ⁇ ).
  • a credit message is transmitted 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 the payment card used is associated (step ⁇ ), i.e. here to the computer system 415, via the bank intermediation network 435.
  • This message is preferably encrypted.
  • the banking intermediation network 435 may be, for example, the banking intermediation network MasterCard, Visa, GIE Bank Card , SWIFT, STET or Target 2).
  • the merchant's account 420 is then credited with the transferred amount (step)) while the customer's account 410 is debited by the same amount (step)), typically in a deferred manner.
  • the encryption used for data exchange is, for example, encryption using a public key and a private key, for example an RSA type encryption.
  • FIG. 5 illustrates an exemplary device that can be used to implement, at least partially, one embodiment, in particular the steps described with reference to FIGS. 2 and 4.
  • the device 500 is for example a server, a computer or a device. personal assistant.
  • the device 500 preferably comprises a communication bus 502 to which are connected:
  • CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • 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 removable storage medium 512 such as a memory card or a disc, for example a DVD disc;
  • a graphic card 514 connected to a screen 516.
  • the device 500 may also have the following elements:
  • a hard disk 520 which may comprise the aforementioned "Prog" programs and data processed or to be processed according to the invention
  • 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 various elements included in the device 500 or connected to it.
  • the representation of the bus is not limiting and, in particular, the central unit is able to communicate instructions to any element of the device 500 directly or via another element of the device 500.
  • the executable code of each program enabling the programmable device to implement the processes according to the invention can be stored, for example, in the hard disk 520 or in the read-only memory 506.
  • the executable code of the programs can be received via the communication network 528, via the interface 526, to be stored in the same manner as that described previously.
  • program or programs may be loaded into one of the storage means of the device 500 before being executed.
  • the central unit 504 will control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, instructions which are stored in the hard disk 520 or in the read-only memory 506 or else in the other elements of aforementioned storage.
  • the program or programs that 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 invention, as well as registers for storing the variables and parameters necessary for the implementation of the invention.
  • the invention also relates to a method for managing a composite transaction relating to a single transaction, the amount of which is the sum of an amount of a main transaction and an amount of at least one ancillary transaction, this method being characterized in that it is implemented in a set comprising a device (205) for initiating a transaction, a device (215) for proposing at least one ancillary operation according to characteristics of a main transaction and a device (220) of ancillary operations management, said device for proposing at least one ancillary operation being accessible by a plurality of devices for initiating a distinct transaction and by a plurality of separate subsidiary operation management devices, and in that it comprises the following steps,
  • receiving information relating to said main transaction including an indication of the amount of the main transaction, said information being received from said device for initiating a transaction by said device to provide at least one side operation;
  • step estimation of at least one parameter of said at least one annex operation whose amount of said at least one annex operation, from at least one predetermined rule, according to at least one information received relating to said main transaction, said step estimation being implemented in said device to propose at least one additional operation;
  • said at least one annex operation comprises a plurality of ancillary operations, said method further comprising a step of calculation, by the ancillary operations management device, of the sum of the amounts of the subsidiary operations of said plurality and a step of initiating a transaction whose amount is equal to the calculated amount, to debit the amount of said transaction of said second account.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention a notamment pour objet la gestion de transactions composites comprenant une transaction principale et au moins une opération annexe dans un ensemble comprenant un dispositif (205) pour initier une transaction, un dispositif (215) pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif (220) de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts.

Description

Procédés et dispositifs de gestion de transactions composites
La présente invention concerne la gestion de transactions financières effectuées par des débiteurs auprès de créditeurs via des comptes bancaires de ces derniers. Plus précisément, l'invention concerne des procédés et des dispositifs de gestion de transactions composites, par exemple de transactions comprenant un paiement et un don à un organisme particulier, effectuées à l'aide de dispositifs reliés par un réseau de communication.
Alors que traditionnellement les dons étaient effectués de façon autonome, par exemple en adressant un chèque ou un virement à un organisme d'intérêt général ou en donnant de la monnaie à un représentant d'une association, il existe aujourd'hui des applications mises en œuvre sur ordinateur (c'est-à-dire, en pratique, sur ordinateurs, assistants personnels, smartphones ou similaires).
Une caractéristique essentielle des mécanismes de collecte de dons mis en œuvre par ordinateur concerne la qualité des interfaces permettant d'effectuer des dons afin qu'un utilisateur ne soit pas enclin à écarter une offre de dons pour des raisons de complexité, de temps excessif, d'incertitude quant au montant, au bénéficiaire ou à la fiabilité de la procédure, etc..
Alors que ces mécanismes obéissent généralement à des règles monétaires simples en proposant, par exemple, d'arrondir une somme à payer pour un achat à l'entier supérieur ou de verser une somme prédéterminée pour chaque achat, la mise en œuvre est généralement complexe pour répondre aux besoins de simplicité de l'utilisateur et de sécurité concernant les transactions. En outre, il existe une demande importante de traçabilité des dons, notamment à des fins fiscales.
La figure 1 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mécanisme de collecte de dons permettant à un client d'effectuer un micro-don lors d'un achat, par exemple un don de la différence entre le prix à payer et ce prix arrondi à l'entier supérieur. Comme illustré, l'environnement 100 permet à un client 105 disposant d'une carte de paiement d'effectuer des achats auprès d'un commerçant disposant d'une infrastructure informatique 1 10. Outre cette infrastructure, l'environnement 100 comprend ici un système informatique 1 15 lié à une banque du commerçant, un système informatique (non représenté) lié à une banque du client et un système informatique 120 lié à une banque une organisation 125 de type ONG (sigle d'Organisation Non-Gouvernementale).
L'infrastructure informatique 1 10 du commerçant comprend ici, en particulier, un système informatique comptable 130, un logiciel de caisse 135 associé à une caisse opérée par une hôtesse de caisse et un terminal de paiement 140. Le système informatique comptable 130 et le logiciel de caisse 135 sont connectés l'un à l'autre par un réseau de communication, par exemple un réseau de type Ethernet mettant en œuvre le protocole IP (sigle d'Internet Protocol en terminologie anglo-saxonne).
Les systèmes informatiques liés aux banques sont reliés entre eux et au système informatique comptable 130 ainsi qu'au terminal de paiement 140 par un réseau de communication de type Internet, les échanges de données étant sécurisés, par exemple par cryptage.
Le mécanisme de collecte de dons est généralement essentiellement mis en œuvre dans le système informatique comptable 130 du commerçant ainsi que dans son logiciel de caisse.
Lorsqu'un client passe en caisse pour effectuer le règlement de ses achats (étape ©), d'un montant noté M, l'hôtesse de caisse lui demande s'il souhaite effectuer un don d'un montant noté D (étape ©). Si le client refuse, le processus de paiement se poursuit de façon classique (non représenté).
Au contraire, si le client accepte d'effectuer un don (étape ®), l'hôtesse de caisse appuie sur un bouton spécifique pour calculer une valeur de don basée sur l'arrondi supérieur du montant des achats, passe un code-barres spécifique pour obtenir un résultat similaire ou saisi le montant du don à l'aide du logiciel de caisse (étape ®'). Cette saisie est typiquement effectuée en ajoutant une référence particulière à la liste des références des produits achetés par le client, cette référence particulière désignant un don et permettant, le cas échéant, la saisie d'un montant libre par l'hôtesse de caisse.
Il est observé que plusieurs références particulières peuvent être utilisées pour désigner chacune un organisme à qui le don doit être effectué. Le don est ainsi intégré au ticket de caisse dont le montant total indiqué, noté T, comprend le montant des achats réels (M) et le montant du don (D). En d'autres termes, T= M + D.
Dans une étape suivante (étape ©), le montant total ( 7) indiqué sur le ticket de caisse, le montant des achats réels (M) et le montant du don (D) sont transmis par le logiciel de caisse 1 35 au système informatique comptable 1 30 du commerçant.
Si le paiement des achats est effectué par carte bancaire (et non en espèce ou par chèque), le logiciel de caisse transmet automatiquement le montant à payer ( 7) au terminal de paiement 140. Alternativement, ce montant est saisi par l'hôtesse de caisse sur le terminal de paiement 140. S'il est autorisé, le client valide le paiement à l'aide de son code secret.
Le système informatique de la banque du commerçant télécollecte les encaissements du commerçant, typiquement de façon périodique, et présente en intermédiation bancaire le montant des paiements ( 7 = M ou T = M + D selon que le client ait effectué un don ou non) pour créditer un compte du commerçant d'un montant correspondant (étape (D).
Parallèlement, le système informatique comptable 130 du commerçant met à jour des journaux de compte dans lesquels figurent les montants des achats réels (M) et les montants des dons (D), typiquement par organisation bénéficiaire. La gestion distincte des montants des achats réels {M) et des montants des dons (D) est nécessaire pour des raisons comptables (liées par exemple à la TVA, sigle de Taxe sur la Valeur Ajoutée) et fiscales (notamment pour le calcul du chiffre d'affaire dans lequel le montant des dons ne doit pas rentrer).
Le journal de compte des dons est notamment utilisé par le commerçant pour reverser périodiquement, par exemple tous les mois, le montant total des dons reçus pour le compte d'une ou plusieurs organisations. De tels versements sont typiquement effectués sur ordre du commerçant à sa banque, cette dernière exécutant l'ordre de transaction (étapes © et ©'). La ou les organisations disposent alors des dons versés pour effectuer leurs missions (étape ®).
II est observé ici que les mécanismes de collecte de dons ou de micro-dons tels que celui décrit en référence à la figure 1 nécessitent, pour leur mise en œuvre, des modifications substantielles des dispositifs utilisés.
Ainsi, en particulier, il est nécessaire de modifier le logiciel de caisse et/ou d'ajouter un logiciel coopérant avec ce dernier, afin de permettre la saisie d'au moins une référence particulière désignant un don et permettant le calcul d'un montant associé ou la saisie d'un montant libre associé, pour qu'un article particulier, non soumis à la TVA, soit ajouté à un ticket de caisse.
Il est également nécessaire de modifier le système informatique comptable du commerçant pour permettre une gestion distincte des montants d'achats réels et des montants de dons, pour permettre le traitement de références de produits assimilés à des dons et non soumis à la TVA (ces montants ne doivent pas entrer dans le calcul du chiffre d'affaire), pour gérer différents journaux de comptes et pour créditer des comptes extérieurs (comptes associés à des organisations de type ONG) ainsi que pour calculer le montant exact du chiffre d'affaire.
Par ailleurs, il convient de noter que la mise en œuvre de ces mécanismes de collecte de dons nécessite une implication du personnel de caisse auprès des clients. Ainsi, par exemple, les hôtesses de caisse doivent faire la « quête » auprès des clients en les priant de réaliser un don puis, le cas échéant, gérer l'initiation du processus de gestion de dons. Ce surplus de travail est généralement considéré comme désagréable par les hôtesses de caisse qui ont la sensation de quémander des dons. En outre, cette façon de procéder peut avoir une influence psychologique désagréable et être considérée comme intrusive par le client qui se sent piégé dans la mesure où un refus peut être mal considéré par une hôtesse de caisse ou un client situé à proximité lorsque la question est posée. Ainsi, les contraintes imposées par ces mécanismes de collecte de dons ont des conséquences importantes.
En outre, il existe des risques de ralentissement important du passage en caisse à cause de la complexité de la procédure.
Enfin, les modifications devant être apportées au logiciel de caisse et dans le système informatique comptable du commerçant sont très coûteuses (typiquement de l'ordre de plusieurs millions d'euros dans le cadre d'une chaîne opérant à l'échelle nationale). Il est observé ici que les modifications sont très difficilement exportables d'un commerçant à un autre, ce qui implique une répétition des opérations de modifications et donc des coûts afférents.
Enfin, le transfert et la gestion des fonds sont de la responsabilité du commerçant, sans réels contrôles possibles. La traçabilité des dons n'est ainsi pas assurée, conduisant à des problèmes tels que des problèmes de défiscalisation.
L'invention permet de résoudre au moins un des problèmes exposés précédemment.
L'invention a ainsi pour objet un procédé de gestion d'une transaction composite comprenant une transaction principale et au moins une opération annexe, ce procédé étant mis en œuvre dans un ensemble comprenant un dispositif pour initier une transaction, un dispositif pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts, ce procédé comprenant les étapes suivantes,
- réception d'informations relatives à ladite transaction principale, lesdites informations étant reçues dudit dispositif pour initier une transaction par ledit dispositif pour proposer au moins une opération annexe ;
- estimation d'au moins un paramètre de ladite au moins une opération annexe, à partir d'au moins une règle prédéterminée, selon au moins une information reçue relative à ladite transaction principale, ladite étape d'estimation étant mise en œuvre dans ledit dispositif pour proposer au moins une opération annexe ;
- en réponse à une indication d'acceptation de ladite au moins une opération annexe reçue dudit dispositif pour initier une transaction, transmission audit dispositif de gestion d'opérations annexes de données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe, ladite transaction principale étant gérée indépendamment desdites étapes de réception, estimation et transmission.
Le procédé selon l'invention offre ainsi la possibilité d'effectuer des dons lors d'un paiement sur terminal de paiement sans modification substantielle des logiciels de caisse et des systèmes informatiques comptables équipant des commerçants. Les coûts d'implantation informatique chez des commerçants ne sont donc pas significatifs (un même dispositif pour proposer au moins une opération annexe ou un même système de gestion de demande de dons peut être utilisé par des systèmes de différents commerçants, des systèmes de différentes banques et/ou des systèmes de différents bénéficiaires de dons).
La collecte de dons est particulièrement rapide du fait d'un nombre d'opérations pouvant se limiter à une seule saisie de type acceptation. En outre, les hôtesses de caisse ne sont pas sollicitées pour collecter des dons.
Le procédé de gestion de dons selon l'invention permet l'installation simplifiée chez un grand nombre de commerçants ainsi que le contrôle et la traçabilité des dons.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de sélection de ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de réception d'un identifiant dudit dispositif pour initier une transaction, ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe étant sélectionnée selon ledit identifiant dudit dispositif pour initier une transaction. Selon un mode de réalisation particulier, le procédé comprend en outre une étape initiale de configuration d'au moins une règle pour estimer au moins un paramètre d'au moins une opération annexe.
Selon un mode de réalisation particulier, lesdites données transmises audit dispositif de gestion d'opérations annexes en réponse à une indication d'acceptation de ladite au moins une opération annexe comprennent en outre lesdites informations relatives à ladite transaction principale.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de transmission d'une commande d'impression audit dispositif pour initier une transaction, ladite commande d'impression visant l'impression d'un reçu comprenant ledit au moins un paramètre de ladite au moins une opération annexe et ladite au moins une information reçue.
Un client peut ainsi garder une preuve d'un don réalisé grâce à l'impression d'un ticket par un terminal de paiement qui comporte une référence. Cette dernière permet l'identification de l'utilisateur sur un système informatique de gestion des dons permettant notamment d'accéder à un ensemble des dons déjà effectués et télécharger des reçus fiscaux.
Selon un mode de réalisation particulier, ladite commande d'impression vise en outre l'impression d'une référence à un identifiant d'une entité personnelle sur ledit reçu.
Selon un mode de réalisation particulier, lesdites données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe comprennent en outre ladite référence.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de mémorisation dudit au moins un paramètre de ladite au moins une opération annexe.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape pour générer une transaction basée sur au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape pour générer un récapitulatif d'opérations annexes, ledit récapitulatif comprenant au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
Selon un mode de réalisation particulier, le procédé comprend en outre une étape de cryptage d'au moins une donnée transmise entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes.
Selon un mode de réalisation particulier, le protocole de communication entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes est conforme à un standard de type IP.
L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un système comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce système sont similaires à ceux évoqués ci-avant.
D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels :
- la figure 1 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mécanisme de collecte de dons permettant à un client d'effectuer un micro-don lors d'un achat, par exemple un don de la différence entre le prix à payer et ce prix arrondi à l'entier supérieur ;
- la figure 2 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention ainsi que certaines étapes d'un exemple de procédé selon l'invention ;
- la figure 3 représente schématiquement un élément de terminal de paiement comprenant un écran sur lequel plusieurs choix de dons sont proposés à un utilisateur ; - la figure 4 illustre schématiquement un exemple standard de paiement par carte de paiement dans une infrastructure comprenant une carte de paiement, un terminal de paiement ainsi que des systèmes informatiques bancaires liés au débiteur et au créditeur ; et
- la figure 5 illustre un exemple de dispositif de traitement d'informations adapté à mettre en œuvre, au moins partiellement, un mode de réalisation de l'invention.
Selon un mode particulier de mise en œuvre de l'invention, un mécanisme de gestion de transactions composites mis en œuvre par ordinateur, par exemple un mécanisme de collecte de dons, fait appel à plusieurs dispositifs dont un ensemble de dispositifs tiers afin d'isoler au moins partiellement des éléments spécifiques de la gestion de transactions composites.
Une transaction composite comprend ici une transaction principale et au moins une opération annexe. Cette dernière ou ces dernières visent typiquement des montants et des bénéficiaires différents de ceux de la transaction principale. Il est rappelé qu'une transaction est une opération commerciale visant, pour la partie faisant l'objet d'un mode de réalisation particulier de l'invention, un transfert d'une somme monétaire entre un débiteur et un créditeur.
A titre d'illustration, une transaction composite peut comprendre le règlement d'un achat (transaction principale) combiné à un don (opération annexe).
Selon un mode de réalisation particulier, la gestion des dons est essentiellement confiée à deux serveurs distincts, l'un ayant pour objet la gestion de demandes de dons, appelé système informatique de gestion de demandes de dons ou plus généralement dispositif pour proposer au moins une opération annexe, et l'autre la gestion des dons eux-mêmes, appelé système informatique de gestion des dons ou plus généralement dispositif de gestion d'opérations annexes. La figure 2 illustre schématiquement un environnement dans lequel peut être mis en œuvre un mode de réalisation particulier de l'invention ainsi que certaines étapes d'un exemple de procédé selon l'invention.
L'environnement 200 comprend ici un ensemble incluant un logiciel de caisse 202, un terminal de paiement 205 (plus généralement appelé dispositif pour initier une transaction), un système informatique comptable 210, un système informatique de gestion de demandes de dons 215 et un système informatique de gestion des dons 220. Comme illustré, le logiciel de caisse 202, le terminal de paiement 205 et le système informatique comptable 210 appartiennent au commerçant 225.
Le logiciel de caisse 202 et le terminal de paiement 205 ainsi que le logiciel de caisse 202 et le système informatique comptable 210 sont reliés par un réseau de communication privé ou public, par exemple un réseau Ethernet ou le réseau Internet.
Le terminal de paiement 205 est ici également relié au système informatique de gestion de demandes de dons 215, par exemple un réseau Ethernet ou le réseau Internet, permettant un échange de données en temps réel.
Le système informatique de gestion de demandes de dons 215 et le système informatique de gestion des dons 220 sont ici accessibles via un réseau de communication public, par exemple le réseau Internet, pour être accessibles par des systèmes informatiques de différents commerçants et de différents utilisateurs (i.e. clients).
Les protocoles de communication entre ces différents dispositifs sont, de préférence, choisis parmi des protocoles standard, par exemple les protocoles IP et X.25.
Il est observé que si le système informatique de gestion de demandes de dons 215 et le système informatique de gestion des dons 220 sont typiquement des serveurs distincts, la gestion de demandes de dons et la gestion des dons peuvent être effectuées par deux applications mises en œuvre sur un même serveur, voire par une même application. L'environnement 200 comprend en outre un réseau d'intermédiation bancaire 230, par exemple le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2 (MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET et Target 2 sont des marques), ainsi que des systèmes informatiques de gestion de comptes bancaires 235 à 250 associés respectivement à un client, au commerçant ayant le logiciel de caisse 202, le terminal de paiement 205 et le système informatique comptable 210, à un tiers en charge de la gestion de dons et à une organisation bénéficiaire de dons.
Selon un mode de réalisation particulier, les données échangées entre le logiciel de caisse 202, le terminal de paiement 205, le système informatique comptable 210, le système informatique de gestion de demandes de dons 215, le système informatique de gestion des dons 220, le réseau d'intermédiation bancaire 230 et les systèmes informatiques de gestion de comptes bancaires et de transactions 235 à 250 sont transmises sous forme de messages cryptés à l'aide d'algorithmes standard, par exemple d'algorithmes basés sur l'utilisation de clés privées et de clés publiques, notamment d'algorithmes de type RSA (Ronald Rivest, Adi Shamir et Léonard Adleman), par paquets. Alternativement, seuls certains échanges sont cryptés selon leur nature et/ou selon les dispositifs sources et/ou destinataires.
Comme représentée sur la figure 2, une étape initiale (étape ®) a pour objet de configurer le système informatique de gestion de demandes de dons 215. Une telle configuration comprend notamment la définition d'une ou plusieurs règles associées à un ou plusieurs terminaux de paiement, typiquement tous les terminaux de paiement d'un même commerçant, définissant une modalité de calcul de montant de dons et associant un don à un destinataire, par exemple une organisation de type ONG.
Ces règles sont typiquement appliquées selon des paramètres reçus, par exemple selon une valeur reçue (e.g. montant d'une transaction), et/ou un identifiant du dispositif duquel sont reçues ces données (i.e. émetteur du message comprenant ces données).
Un exemple de telles règles est illustré en annexe sous forme de table (table 1 ). Comme illustré, chaque ligne de la table correspond à une règle. Chaque règle est ici définie par un identifiant (colonne 1 ), un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement (colonne 2), un mode de calcul de dons (colonne 3) et un identifiant d'un bénéficiaire ou d'un groupe de bénéficiaires (colonne 4).
Bien entendu, d'autres informations peuvent être utilisées dans la définition des règles.
Lorsqu'un groupe de bénéficiaires est désigné, la répartition d'un don entre ces derniers peut être prédéterminée ou laissée à l'appréciation d'un utilisateur (pouvant notamment sélectionner un seul bénéficiaire dans le groupe).
Ainsi, par exemple, la règle ayant l'identifiant 2 s'applique au terminal de paiement ou au groupe de terminaux de paiement ayant l'identifiant G53391 , les bénéficiaires étant pour une première moitié d'un don un bénéficiaire ayant l'identifiant 1 et pour la seconde moitié du don un bénéficiaire ayant l'identifiant 2. Le montant du don est ici déterminé en fonction du montant des achats (0,5%) ou de façon forfaitaire (5€), la plus petite valeur étant retenue.
Le paramétrage de ces règles peut se faire par un accès protégé au système informatique de gestion de demandes de dons 215. A titre d'illustration, un commerçant peut accéder, à l'aide d'un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement et d'un mot de passe, à l'ensemble des règles associées à cet identifiant, c'est-à-dire à un sous- ensemble des règles mémorisées. L'accès aux règles permet d'ajouter, modifier ou supprimer des règles. L'accès peut se faire depuis un ordinateur quelconque (ou équivalent) connecté au système informatique de gestion de demandes de dons 215 via un réseau de communication tel qu'Internet et via un portail de type web.
Lorsqu'un client se présente devant un terminal de paiement pour régler des achats et après que le montant M des achats ait été déterminé, par exemple par une hôtesse de caisse ou de façon automatique, et obtenu par le terminal de paiement (étape ©), de façon manuelle ou automatique, un lien de communication ou une session de communication est établi entre le terminal de paiement 205 et le système informatique de gestion de demandes de dons 215. Selon un mode de réalisation particulier, le lien de communication est établi automatiquement après saisi, obtention ou validation du montant M des achats. A ces fins, le terminal de paiement comprend une adresse du système informatique de gestion de demandes de dons 215, par exemple un lien URL (sigle ô' Uniform Resource Locator en terminologie anglo-saxonne) associé à une commande d'accès appelée dès qu'un montant est saisi, obtenu ou validé.
Comme décrit précédemment, le système informatique de gestion de demandes de dons 215 peut être accédé de différents terminaux de paiement gérés par différents commerçant, c'est-à-dire par différents terminaux de paiement n'ayant pas de liens entre eux.
Suite à établissement du lien de communication entre le terminal de paiement 205 et le système informatique de gestion de demandes de dons 215, le montant M des achats ainsi qu'un identifiant du terminal de paiement et de la transaction sont transmis par le terminal de paiement 205 au système informatique de gestion de demandes de dons 215 (étape ©).
Alternativement, le montant M des achats ainsi que l'identifiant du terminal de paiement sont transmis sous forme d'un message à une adresse prédéterminée ou à une adresse déterminée dynamiquement, par exemple à l'aide d'un mécanisme de type DNS (sigle de Domain Name System en terminologie anglo-saxonne).
En réponse, le système informatique de gestion de demandes de dons 215 détermine la ou les règles de calcul de dons applicables, notamment en fonction de l'identifiant reçu du terminal de paiement, et calcule une ou plusieurs valeurs de don. Cette ou ces valeurs sont alors transmises au terminal de paiement, chaque valeur étant associée à un bénéficiaire dénoté b (étape ©').
La ou les valeurs de dons ainsi que les bénéficiaires correspondants sont alors de préférence affichés sur un écran du terminal de paiement pour permettre au client de valider une proposition de don, de sélectionner et valider une proposition de don parmi plusieurs, de saisir librement un montant de don ou de payer ses achats sans effectuer de don. De façon avantageuse, la sélection ou le refus d'un don se fait par une seule pression sur une touche du terminal de paiement (ou d'un dispositif relié à ce dernier).
Il est observé ici qu'au moins une partie des actions effectuées par un terminal de paiement peuvent être déportées, par exemple sur un dispositif de type smartphone ou un site web, pour permettre à un utilisateur de visualiser et/ou valider des choix sur son propre dispositif.
La figure 3 représente schématiquement un élément de terminal de paiement comprenant un écran sur lequel plusieurs choix de dons sont proposés à un utilisateur. L'élément 300 de terminal de paiement comprend ici un ensemble 305 de touches et un écran 31 0.
Comme représenté, l'écran affiche un message offrant la possibilité à un utilisateur d'effectuer un don de 0,54€ à la Croix-Rouge ou aux Restos du Cœurs (la Croix-Rouge et les Restos du Cœurs sont des marques) ou de régler ses achats sans effectuer de don. Comme indiqué avec les références 31 5, 320 et 325, respectivement, une pression sur la touche 1 , référencée 330, a pour effet le versement d'un don de 0,54€ à la Croix-Rouge, une pression sur la touche 2, référencée 335, a pour effet de verser un don de 0,54€ aux Restos du Cœurs et pression sur la touche A, référencée 340, a pour effet de régler ses achats sans effectuer de don.
Après avoir validé ou refusé un don, l'utilisateur valide ses achats (étape ®) pour un montant total T correspondant au montant de ses achats auquel est ajouté le montant du don ( T = M + D) ou correspondant uniquement au montant des achats ( T = M). Typiquement, lorsque le paiement des achats est effectué à l'aide d'une entité électronique portable telle qu'une carte bancaire, la validation des achats est effectuée par la saisie d'un code confidentiel associé à la carte utilisée ou par tout autre moyen biotechnique (e.g. empreintes digitales). Alternativement, par exemple si le paiement est effectué par virement ou à l'aide d'un porte-monnaie électronique, la code confidentiel peut être un code associé à un identifiant préalablement obtenue de l'utilisateur. Le prélèvement du montant T sur le compte bancaire de l'utilisateur et le crédit d'un montant équivalent du compte bancaire du commerçant est avantageusement effectué de façon classique comme décrit en référence à la figure 4 (étape ©).
Parallèlement au paiement ou, de préférence, suite à la réception d'une autorisation de paiement, le terminal de paiement 205 adresse, le cas échéant, une indication d'acceptation de don au système informatique de gestion de demandes de dons 21 5, typiquement sous forme d'un message comprenant la ou les valeurs du don et le ou les bénéficiaires sélectionnés (étape ©).
En réponse, le système informatique de gestion de demandes de dons 21 5 retourne, de préférence, une commande d'impression d'un ticket contenant le détail de l'opération, c'est-à-dire le versement total effectué et sa répartition entre le paiement des achats et le don effectué (étape ©'). A la réception de cette commande, le terminal de paiement imprime ce ticket qui est remis à l'utilisateur.
Selon un mode de réalisation particulier, la commande d'impression d'un ticket est transmise avec une référence de carte (Rc) associé à la carte de paiement utilisée, cette référence de carte étant de préférence déterminée par le terminal de paiement à partir d'un identifiant ou d'un numéro de carte (par exemple en appliquant une fonction de hachage sur le numéro de carte).
Il est observé ici que, selon un mode de réalisation particulier, un identifiant de personne (I Dp) est donnée à chaque utilisateur lors de son inscription sur le système informatique de gestion des dons 220 (l'inscription comprenant typiquement la création d'un profil utilisateur). La référence de carte fournie sur le ticket peut être utilisée pour cette inscription qui peut être réalisée, par exemple, via une interface web. Pour éviter toute fraude, la création d'un profil peut être soumise à la fourniture d'informations supplémentaires, par exemple, outre la fourniture de la référence de carte, il peut être demandé à l'utilisateur de donner les six derniers chiffres du numéro de la carte de paiement (à partir desquels pourra être générée une référence de carte qui sera comparée à celle reçue afin de la valider). Un mot de passe est avantageusement associé à l'identifiant de personne pour sécuriser l'accès à des données relatives à ce donneur.
Lorsqu'un donneur s'est inscrit sur le système informatique de gestion des dons 220, un profil est créé. Il comprend notamment la référence de carte, d'autres références de cartes de paiement pouvant être associées à ce profil.
Outre l'accès à son profil, l'identifiant de personne permet à un donneur de se connecter au système de gestion des dons 220, par exemple via une page web, et d'obtenir des informations relatives à l'historique des dons effectués, télécharger les reçus fiscaux des montants des dons cumulés sur l'ensemble de ses cartes ou recevoir des informations émanant des associations bénéficiaires de sa générosité.
L'identifiant de personnes et le profil associé ne sont connus, de préférence, que du système informatique de gestion des dons 220 (Le., ils ne sont pas connus du terminal de paiement 205 ni du système informatique de gestion de demandes de dons 215).
Pour permettre au système informatique de gestion des dons 220 de gérer des dons, le terminal de paiement adresse, au système informatique de gestion de demandes de dons 215, une référence de la carte de paiement utilisée avec l'indication d'acceptation de don. Avec cette référence de la carte, le système informatique de gestion des dons 220 peut retrouver un identifiant de personne préalablement créé (le système informatique de gestion des dons 220 mémorise les liens entre un identifiant de personne et une ou plusieurs références de carte, par exemple dans une table). Si aucun identifiant de personne n'est trouvé, les données relatives au don sont mémorisées pour être traitées ultérieurement, après la création d'un profil d'utilisateur associé à la référence de carte correspondante.
Suite à l'acceptation d'un don, le système informatique de gestion de demandes de dons 215 mémorise le montant des achats M ainsi que le montant du don D effectués dans un journal de dons. Ce dernier comprend, pour chaque transaction effectuée, une référence de transaction, un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement, une référence Rc de carte de paiement, un montant M d'achats, un montant de don(s) effectué(s) et le ou les bénéficiaires associés (étant observé que le montant d'un don peut être réparti entre plusieurs bénéficiaires).
Un exemple de journal de dons d'un système informatique de gestion de demandes de dons est illustré en annexe (table 2). A titre d'illustration, la ligne du journal visant la transaction identifiée par la référence 2 correspond à une transaction effectuée à partir d'un terminal de paiement ou d'un groupe de terminaux de paiement identifiés par la référence G53391 pour le donneur ayant utilisé une carte ayant la référence 023, le montant des achats effectués étant de 87,45€ et le montant du don de 0,44€ se répartissant à parts égales entre les bénéficiaires identifiés par les références 1 et 2.
Outre un identifiant de transaction, un identifiant d'un terminal de paiement ou d'un groupe de terminaux de paiement, une référence Rc àe carte de paiement, un montant M d'achats, un montant de don(s) effectué(s) et le ou les bénéficiaires associés, le journal de dons peut, de façon optionnelle (non représentée), comprendre le montant T du paiement, représentant du somme montant M d'achats et du montant de don(s) effectué(s) réglés.
Le journal de dons est transmis de façon périodique, par exemple toutes les heures ou toutes les nuits, au système informatique de gestion des dons 220 (étape ©) où il est mémorisé. Après transmission au système informatique de gestion des dons, le journal de dons mémorisé dans le système informatique de gestion des dons 220 est réinitialisé (cependant une copie est, de préférence, conservée).
Le système informatique de gestion des dons 220 analyse alors le journal de dons pour en extraire les parties concernant un système informatique comptable particulier, par exemple le système informatique comptable 210, c'est-à-dire le système informatique comptable associé à un terminal de paiement ou à un groupe de terminaux de paiement. Les parties extraites concernant un système informatique comptable particulier sont ici transmises à ce dernier pour lui permettre d'effectuer un rapprochement comptable (étape ®). De façon périodique, par exemple toutes les semaines ou tous les mois, le système informatique de gestion des dons 220 calcule, pour un système informatique comptable particulier, la somme des dons effectués par des clients auprès de terminaux de paiement associés à celui-ci, dénoté∑D. Ce calcul est effectué à partir du journal d'achat, en cumulant les dons associés à un même terminal de paiement ou à un même groupe de terminaux de paiement. Une demande de prélèvement ou de règlement de ce montant est alors adressée à ce système informatique comptable pour créditer de ce montant un compte bancaire associé au système informatique de gestion des dons (étape ®).
Le prélèvement ou le règlement de cette somme de dons sur un compte bancaire associé à un système informatique comptable et le crédit d'un montant équivalent du compte bancaire associé au système informatique de gestion des dons est avantageusement effectué de façon classique de façon similaire à un processus de paiement d'un fournisseur.
Dans une étape suivante, le système informatique de gestion des dons 220 calcule, pour chaque bénéficiaire, la somme des dons à lui reverser. A nouveau, ce calcul est effectué à partir du journal de dons, en cumulant les dons associés à un même bénéficiaire.
Le journal de dons mémorisé dans le système informatique de gestion des dons 220 est de préférence mis à jour suite au transfert de dons. Cependant, un historique est conservé pour permettre la traçabilité des dons et établissement, le cas échéant, de relevés fiscaux.
Ainsi, par exemple, le système informatique de gestion des dons 220 calcule, pour un utilisateur particulier, pour certains ou pour tous les utilisateurs, la somme des dons versés durant une période donnée, typiquement une année fiscale. A nouveau, ce calcul est effectué à partir du journal de dons, en cumulant les dons associés à un même utilisateur.
La gestion de transactions composites et, en particulier, de dons adossés à des achats, nécessite la création de systèmes informatiques tiers auxquels peuvent faire appel des commerçants et des clients ainsi que le développement d'interfaces particulières permettant l'accès à ces systèmes informatiques.
Ainsi, par exemple, la mise en œuvre de la solution décrite en référence à la figure 2 nécessite la création d'un système informatique de gestion de demandes de dons et d'un système informatique de gestion de dons ainsi que la création d'interfaces. Parmi ces dernières et pour permettre la mise en œuvre de la solution décrite en référence à la figure 2, les interfaces suivantes sont créées :
- interface d'échange sécurisé de données, en temps réel, entre un logiciel d'un terminal de paiement et un logiciel du système informatique de gestion de demandes de dons ;
- interface d'échange sécurisé de données entre un logiciel du système informatique de gestion de demandes de dons et un logiciel du système informatique de gestion de dons,
- interface de paramétrage du système informatique de gestion de demandes de dons (typiquement à l'aide d'un système informatique d'un commerçant pour configurer des règles de demandes de dons via une page web) ;
- interface d'interrogation du système informatique de gestion de dons (typiquement à l'aide d'un système informatique d'un utilisateur pour paramétrer son identité, inscrire ses cartes, modifier son profil et/ou accéder à des relevés de dons via une page web) ; et
- une interface d'échange standard entre le système de gestion des dons et le système informatique comptable du commerçant.
Selon un mode de réalisation particulier, les interfaces d'échange de données sont basées sur des protocoles de communication usuels et utilisent des algorithmes de cryptage standard. Ainsi, à titre d'illustration, lorsque les systèmes informatiques sont reliés les uns aux autres via un réseau de type Internet, ces échanges peuvent utiliser le protocole IP combiné avec un cryptage de données par clés privées et clés publiques de type RSA.
La figure 4 illustre schématiquement un exemple standard de paiement par carte de paiement dans une infrastructure comprenant une carte de paiement, un terminal de paiement ainsi que des systèmes informatiques bancaires liés au débiteur et au créditeur. Un tel schéma de paiement est aussi connu sous le nom de modèle de paiement par carte bancaire en quatre coins.
Ce schéma de paiement ou un schéma similaire peut notamment être utilisé pour des transferts d'argent entre un compte d'un porteur de carte et un compte d'un commerçant comme visé en référence à la figure 2.
Ce schéma de paiement peut être utilisé, tout comme les schémas classiques utilisés pour les chèques, virements et prélèvements, pour des transferts d'argent entre les comptes d'un commerçant (référencé 240 sur la figure 2), d'un gestionnaire de dons (référencé 245 sur la figure 2) et d'une association bénéficiaire (référencée 250 sur la figure 2).
Comme illustré, un client pourvu d'une carte de paiement 400, par exemple une carte de type Visa (Visa est une marque), règle ici un achat auprès d'un commerçant disposant d'un terminal de paiement 405. La carte de paiement est associée à un compte bancaire 410 (compte client) géré par un système informatique 415 d'une banque (typiquement la banque ayant émis la carte bancaire ou pour le compte de laquelle la carte bancaire a été émise). De même, le terminal de paiement 405 est associé à un compte bancaire 420 (compte commerçant) géré par un système informatique 425 d'une banque.
Pour effectuer une transaction d'achat, un client présente sa carte de paiement à un terminal de paiement d'un commerçant auquel le montant a été transmis de façon manuelle ou automatique (étape ©). Après validation de l'achat par le client, par exemple en saisissant un code confidentiel ou code PIN (acronyme de Personal Identification Number en terminologie anglo-saxonne), le terminal de paiement effectue typiquement une demande d'autorisation qui est transmise au système informatique 41 5 de la banque du porteur de carte via le système informatique 425 de la banque du commerçant et un réseau d'intermédiation bancaire 435 (étape © et ®).
Le message est avantageusement crypté et comprend les identifiants du client et du commerçant ainsi que le montant devant être transféré. Après authentification et vérification, notamment de l'identité du client et de celle du commerçant ainsi que du solde du compte débiteur, un message d'acceptation de transfert, de préférence crypté, est adressé par le système informatique 415 de la banque du client au système informatique 425 de la banque du commerçant (étape ©).
Après avoir reçu un message d'acceptation de transfert, un message de crédit est transmis par le système informatique de la banque du commerçant à l'adresse du système informatique de la banque gérant le compte bancaire auquel est associée la carte de paiement utilisée (étape ©), c'est-à-dire ici au système informatique 415, via le réseau d'intermédiation bancaire 435. Ce message est de préférence crypté.
Il est observé ici que les demandes d'intermédiations bancaires peuvent être accumulées et effectuées de façon différées (comme précisé précédemment, le réseau d'intermédiation bancaire 435 peut être, par exemple, le réseau d'intermédiation bancaire MasterCard, Visa, GIE Carte Bancaire, SWIFT, STET ou Target 2).
Le compte 420 du commerçant est alors crédité de la somme transférée (étape ©) tandis que le compte 410 du client est débité de la même somme (étape ®), typiquement de façon différée.
Le cryptage utilisé pour les échanges de données est, par exemple, un cryptage utilisant une clé publique et une clé privée, par exemple un cryptage de type RSA.
La figure 5 illustre un exemple de dispositif pouvant être utilisé pour mettre en œuvre, au moins partiellement, un mode de réalisation, notamment des étapes décrites en référence aux figures 2 et 4. Le dispositif 500 est par exemple un serveur, un ordinateur ou un assistant personnel.
Le dispositif 500 comporte de préférence un bus de communication 502 auquel sont reliés :
- une unité centrale de traitement ou microprocesseur 504 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 506 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter le système d'exploitation et des programmes tels que "Prog" ;
- une mémoire vive ou mémoire cache 508 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ;
- un lecteur 510 de support amovible de stockage 512 tel qu'une carte mémoire ou un disque, par exemple un disque DVD ; et
- une carte graphique 514 reliée à un écran 516.
Optionnellement, le dispositif 500 peut également disposer des éléments suivants :
- un disque dur 520 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l'invention ;
- un clavier 522 et une souris 524 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l'utilisateur d'interagir avec les programmes selon l'invention, en particulier pour initier un transfert d'argent, configurer des règles de demandes de dons, suivre une ou plusieurs listes de dons et obtenir un reçu fiscal ; et
- une interface de communication 526 reliée à un réseau de communication distribué 528, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément du dispositif 500.
Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en œuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 520 ou en mémoire morte 506. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 528, via l'interface 526, pour être stocké de façon identique à celle décrite précédemment.
De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés.
L'unité centrale 504 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 520 ou dans la mémoire morte 506 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 520 ou la mémoire morte 506, sont transférés dans la mémoire vive 508 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention.
Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. La présente invention ne se limite pas aux formes de réalisation décrites, d'autres variantes et combinaisons de caractéristiques sont possibles.
La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois, la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en œuvre par la personne compétente dans le domaine de l'invention à la lecture de la présente description et des figures annexées.
Dans les revendications, le terme « comporter » n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en œuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes n'exclut pas, en effet, la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.
L'invention concerne aussi un procédé de gestion d'une transaction composite relative à une opération unique dont le montant est la somme d'un montant d'une transaction principale et d'un montant d'au moins une opération annexe, ce procédé étant caractérisé en ce qu'il est mis en œuvre dans un ensemble comprenant un dispositif (205) pour initier une transaction, un dispositif (215) pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif (220) de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts, et en ce qu'il comprend les étapes suivantes,
- réception d'informations relatives à ladite transaction principale comprenant une indication du montant de la transaction principale, lesdites informations étant reçues dudit dispositif pour initier une transaction par ledit dispositif pour proposer au moins une opération annexe ;
- estimation d'au moins un paramètre de ladite au moins une opération annexe dont le montant de ladite au moins une opération annexe, à partir d'au moins une règle prédéterminée, selon au moins une information reçue relative à ladite transaction principale, ladite étape d'estimation étant mise en œuvre dans ledit dispositif pour proposer au moins une opération annexe ;
- en réponse à une indication d'acceptation de ladite au moins une opération annexe reçue dudit dispositif pour initier une transaction, transmission audit dispositif de gestion d'opérations annexes de données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe, et initiation, par le dispositif pour initier une transaction, de ladite transaction composite pour débiter le montant de ladite transaction composite d'un premier compte et créditer ledit montant débité sur un second compte; - ladite transaction principale étant gérée indépendamment desdites étapes de réception, estimation et transmission et ladite au moins une opération annexe étant gérée par ledit dispositif de gestion d'opérations annexes.
Selon un mode de réalisation particulier, ladite au moins une opération annexe comprend une pluralité d'opérations annexes, ledit procédé comprenant en outre une étape de calcul, par le dispositif de gestion des opérations annexes, de la somme des montants des opérations annexes de ladite pluralité et une étape d'initiation d'une transaction dont le montant est égal à la somme calculée, pour débiter le montant de ladite transaction dudit deuxième compte.
ANNEXE
Table 1
Table 2

Claims

REVENDICATIONS
1 . Procédé de gestion d'une transaction composite comprenant une transaction principale et au moins une opération annexe, ce procédé étant caractérisé en ce qu'il est mis en œuvre dans un ensemble comprenant un dispositif (205) pour initier une transaction, un dispositif (215) pour proposer au moins une opération annexe selon des caractéristiques d'une transaction principale et un dispositif (220) de gestion d'opérations annexes, ledit dispositif pour proposer au moins une opération annexe étant accessible par une pluralité de dispositifs pour initier une transaction distincts et par une pluralité de dispositifs de gestion d'opérations annexes distincts, et en ce qu'il comprend les étapes suivantes,
- réception d'informations relatives à ladite transaction principale, lesdites informations étant reçues dudit dispositif pour initier une transaction par ledit dispositif pour proposer au moins une opération annexe ;
- estimation d'au moins un paramètre de ladite au moins une opération annexe, à partir d'au moins une règle prédéterminée, selon au moins une information reçue relative à ladite transaction principale, ladite étape d'estimation étant mise en œuvre dans ledit dispositif pour proposer au moins une opération annexe ;
- en réponse à une indication d'acceptation de ladite au moins une opération annexe reçue dudit dispositif pour initier une transaction, transmission audit dispositif de gestion d'opérations annexes de données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe, ladite transaction principale étant gérée indépendamment desdites étapes de réception, estimation et transmission.
2. Procédé selon la revendication 1 comprenant en outre une étape de sélection de ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe.
3. Procédé selon la revendication 2 comprenant en outre une étape de réception d'un identifiant dudit dispositif pour initier une transaction, ladite au moins une règle pour estimer ledit au moins un paramètre de ladite au moins une opération annexe étant sélectionnée selon ledit identifiant dudit dispositif pour initier une transaction.
4. Procédé selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape initiale de configuration d'au moins une règle pour estimer au moins un paramètre d'au moins une opération annexe.
5. Procédé selon l'une quelconque des revendications 1 à 4 selon lequel lesdites données transmises audit dispositif de gestion d'opérations annexes en réponse à une indication d'acceptation de ladite au moins une opération annexe comprennent en outre lesdites informations relatives à ladite transaction principale.
6. Procédé selon l'une quelconque des revendications 1 à 5 comprenant en outre une étape de transmission d'une commande d'impression audit dispositif pour initier une transaction, ladite commande d'impression visant l'impression d'un reçu comprenant ledit au moins un paramètre de ladite au moins une opération annexe et ladite au moins une information reçue.
7. Procédé selon la revendication 6 dans lequel ladite commande d'impression vise en outre l'impression d'une référence à un identifiant d'une entité personnelle sur ledit reçu.
8. Procédé selon la revendication 7 selon lequel lesdites données comprenant au moins ledit au moins un paramètre de ladite au moins une opération annexe comprennent en outre ladite référence.
9. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de mémorisation dudit au moins un paramètre de ladite au moins une opération annexe.
10. Procédé selon la revendication 9 comprenant en outre une étape pour générer une transaction basée sur au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
1 1 . Procédé selon la revendication 9 comprenant en outre une étape pour générer un récapitulatif d'opérations annexes, ledit récapitulatif comprenant au moins un paramètre préalablement mémorisé d'au moins une opération annexe.
12. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de cryptage d'au moins une donnée transmise entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes.
13. Procédé selon l'une quelconque des revendications précédentes selon lequel le protocole de communication entre ledit dispositif pour initier une transaction et ledit dispositif pour proposer au moins une opération annexe ou entre ledit dispositif pour proposer au moins une opération annexe et ledit dispositif de gestion d'opérations annexes est conforme à un standard de type IP.
14. Programme d'ordinateur comprenant des instructions adaptées à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.
15. Système comprenant des moyens adaptés à la mise en œuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 13.
EP15771997.2A 2014-09-15 2015-09-15 Procédés et dispositifs de gestion de transactions composites Ceased EP3195224A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1458676A FR3025915B1 (fr) 2014-09-15 2014-09-15 Procedes et dispositifs de gestion de transactions composites
PCT/FR2015/052472 WO2016042258A1 (fr) 2014-09-15 2015-09-15 Procédés et dispositifs de gestion de transactions composites

Publications (1)

Publication Number Publication Date
EP3195224A1 true EP3195224A1 (fr) 2017-07-26

Family

ID=51842610

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15771997.2A Ceased EP3195224A1 (fr) 2014-09-15 2015-09-15 Procédés et dispositifs de gestion de transactions composites

Country Status (8)

Country Link
US (2) US20180225663A1 (fr)
EP (1) EP3195224A1 (fr)
CN (1) CN107209887A (fr)
AU (1) AU2015316635A1 (fr)
BR (1) BR112017004962A2 (fr)
FR (1) FR3025915B1 (fr)
MX (1) MX2017003424A (fr)
WO (1) WO2016042258A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108985741B (zh) * 2018-07-19 2021-06-01 南京市公安局建邺分局 一种警务平台资金流水自动查询追踪方法
JP2020034864A (ja) * 2018-08-31 2020-03-05 京セラドキュメントソリューションズ株式会社 画像形成装置
US11721156B2 (en) * 2020-06-12 2023-08-08 Juan Carlos Vera System and method of setting and charging a fixed donation amount
US20220301039A1 (en) * 2021-03-16 2022-09-22 ELP Global LLC Location-based system for charitable donation

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003052709A1 (fr) * 2001-12-14 2003-06-26 Pohl Angus Procede informatique automatise de collecte de petite monnaie

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6876971B1 (en) * 2000-07-05 2005-04-05 Every Penny Counts, Inc. Funds distribution system connected with point of sale transaction
US6112191A (en) * 1993-02-18 2000-08-29 Every Penny Counts, Inc. Method and system to create and distribute excess funds from consumer spending transactions
US6088682A (en) * 1993-02-18 2000-07-11 Every Penny Counts, Inc. Funds distribution system connected with point of sale transactions
US5466919A (en) * 1993-04-02 1995-11-14 Hovakimian; Henry Credit/charge card system enabling purchasers to contribute to selected charities
US7542919B1 (en) * 1997-03-21 2009-06-02 Walker Digital, Llc Method and apparatus for selecting a supplemental product to offer for sale during a transaction
US20040034563A1 (en) * 1998-11-18 2004-02-19 Brissette Edward C. System and method for making charitable donations
MXPA01013136A (es) * 1999-06-23 2004-06-03 Postrel Richard Sistema para permuta electronica para negociar y recuperar puntos acumulados en programas de recompensa por uso frecuente.
US8160922B2 (en) * 1999-06-23 2012-04-17 Signature Systems, LLC. Method and system for making donations to charitable entities
EP1136931A1 (fr) * 2000-03-20 2001-09-26 Roundit Inc. Système d'incitation au patronage, et méthode de commerce au détail basée sur internet
US6307812B1 (en) * 2000-03-27 2001-10-23 Michael S. Gzybowski Security system using modular timers
US20020120539A1 (en) * 2000-11-20 2002-08-29 Price Cynthia L. Method and system for distributing charitable donations at a point of sale to qualified donees
US20020116214A1 (en) * 2001-02-16 2002-08-22 Horn James Van Automated fundraising accounting system
US20020196204A1 (en) * 2001-06-26 2002-12-26 Matthew Senn Steven Michael Retail customer and product purchase divider with interactive retail transaction functions
US20030065572A1 (en) * 2001-09-28 2003-04-03 Mcnee Carolyn Charity donation method
US20060122856A1 (en) * 2002-06-06 2006-06-08 Benevolink Corporation System and method for enabling consumers to add personal charitable contributions and transfer the right to designate a beneficiary to other consumers
US20040182922A1 (en) * 2003-03-21 2004-09-23 Frank Talarico Systems and methods for a loadable stored-value card with a contribution to a specified beneficiary
US7080775B2 (en) * 2003-09-05 2006-07-25 American Cancer Society Methods and systems for automatically determining and collecting a monetary contribution from an instrument
US20050125342A1 (en) * 2003-10-01 2005-06-09 Steven Schiff System and method for interactive electronic fund raising and electronic transaction processing
AU2007202567B2 (en) * 2004-07-23 2011-12-15 Jord Williams Poster Charitable giving
US20050251485A1 (en) * 2005-04-18 2005-11-10 Quigley Daniel H Systems for soliciting donations
US8214287B1 (en) * 2007-12-12 2012-07-03 Ernest Garfield System for collecting and distributing charitable contributions
US20090171835A1 (en) * 2007-12-26 2009-07-02 Mastercard International, Inc. Multiple Payment Transaction Systems
US8336762B1 (en) * 2008-11-17 2012-12-25 Greenwise Bankcard LLC Payment transaction processing
US20120084162A1 (en) * 2010-10-05 2012-04-05 Merrill Brooks Smith Systems and methods for conducting a composite bill payment transaction
US9105054B2 (en) * 2013-06-27 2015-08-11 Sparo Corporation Method and system for automated online calendar-based donations

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003052709A1 (fr) * 2001-12-14 2003-06-26 Pohl Angus Procede informatique automatise de collecte de petite monnaie

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2016042258A1 *

Also Published As

Publication number Publication date
FR3025915B1 (fr) 2018-04-20
FR3025915A1 (fr) 2016-03-18
US10776782B2 (en) 2020-09-15
BR112017004962A2 (pt) 2018-04-10
MX2017003424A (es) 2018-08-01
CN107209887A (zh) 2017-09-26
US20160125482A1 (en) 2016-05-05
WO2016042258A1 (fr) 2016-03-24
US20180225663A1 (en) 2018-08-09
AU2015316635A1 (en) 2017-05-04

Similar Documents

Publication Publication Date Title
US10810557B2 (en) Financial services ecosystem
Bollen The Legal Status of Online Currencies–Are Bitcoins the Future?
US20170323298A1 (en) System and method for securely transferring funds between persons
Ivashchenko Using cryptocurrency in the activities of Ukrainian small and medium enterprises in order to improve their investment attractiveness
US20160284022A1 (en) System and method for automated digital currency savings platform
WO2018154082A1 (fr) Système et procédé de traitement d'une transaction bancaire
WO2016042258A1 (fr) Procédés et dispositifs de gestion de transactions composites
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
WO2016110635A1 (fr) Procédés et dispositifs de commande d'opérations annexes liées a l'exécution de transactions principales
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP1983480A1 (fr) Terminal de paiement, procédé et programme associés
EP2724305A1 (fr) Procede de transaction dematerialisee
EP3050034A1 (fr) Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants
EP3300012A1 (fr) Procede et systeme pour gerer des autorisations d'achat
WO2005013163A2 (fr) Systeme et procede de paiement electronique
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
FR2808144A1 (fr) Procede et systeme de paiement electronique

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170410

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180409

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20210930