FIELD OF THE INVENTION

The present invention relates to the technical field of computer systems and of communications between computer systems. More in particular, the present invention relates to the technical field of computer systems and of communications between computer systems adapted to transfer money and titles in electronic form between users.

PRIOR ART

The present invention relates to the fields of computer and communication systems. More in particular, a system and methods are provided to facilitate the exchange of electronic money between users by means of computer devices.

Electronic money has become a major part of modern economic and financial systems. It is estimated that only about 5% of the world’s currency exists on media such as coins, banknotes, securities, while about 95% is managed only in electronic form and allocated on storage devices associated with data processing systems. Electronic money solves a number of problems associated with the use of banknotes and other physical media, such as banker’s drafts and bank checks.

The use of cash requires regular replenishment of damaged banknotes, is subject to forgery, theft and loss, and requires significant accounting management efforts. Electronic money and the introduction of payment instruments, such as credit and debit cards, have solved or at least alleviated some of the aforesaid problems. However, credit cards cannot meet all the requirements of electronic money management and, in particular, they cannot be used to transfer money directly between two electronic money users.

The use of banker’s checks or bank checks is still very frequent despite the many drawbacks related thereto, some of the main ones of which are: the check, either a bank check or a cashier’s check, is, to date, issued only in paper form and has remained on paper despite the innovations introduced in the banking sector in recent years; it must be produced by the issuing bank and physically delivered to the customer; the customer, in turn, must physically carry the check with him or her in order to be able to issue it to someone. The bank check can be issued post-dated although this is not allowed by law; the cashier’s check is used mainly for notarial transactions because the bank wire is not concurrent with respect to the stipulation of the contract to which it refers. Moreover, the management of the entire check issuing/paying process is particularly burdensome and risky for the banking system itself.

However, today’s electronic money management and transfer systems are also not free of defects and drawbacks to be eliminated; they are subject to complex formalities and procedures, which make use of the user’s personal and confidential data and are therefore inefficient, lengthy, difficult to complete and inconvenient for the user who may, for example, be reluctant to disclose confidential information required to complete the required electronic currency transfer.

All of the electronic payment systems available to date have drawbacks which limit their use. For example, wire transfers (generally referred to as bank transfers in Europe) have the advantage of having no amount limits, allowing international transactions and transactions to anyone with a current account, but have major disadvantages; they are revocable until shortly before being cleared by bank (which may even occur a few days after having ordered the payment), they do not provide an instantaneous outcome (1 -2 working days elapse after they have been cleared by the bank for the recipient to be certain of the transaction) and require the exchange of bank details between recipient and payer. Therefore, a bankwire is not a suitable instrument for transactions in which payment must be certain at the same time as the exchange of an asset (e.g. as is the case of the sale of a used car or a notarial instrument).

Instant bank transfers provide an instantaneous outcome once they have been ordered but have amount limits (e.g. €15,000 for SEPA SCT Instant, € 100,000 since July 2020), require the exchange of bank details and both banks involved in the transaction must be members of the banking circuit within which the transfer takes place. Therefore, an instant bank transfer is not suitable for payments over a given threshold and has an inconvenient user experience mainly because of the necessary exchange of bank details and because the recipient is not notified of the performed transaction but must verify it by accessing their account. The ever-increasing number of P2P electronic money transfers allow users to exchange money easily and instantly, but they have two major drawbacks; the first is linked to the amount limit which is kept very low (generally between € 200 and € 300), due to the fact that the amount transferred is credited to the recipient before it is debited to the payer and there is always the risk - assumed by the bank - that the account is not sufficient due to concurrent transactions; the second drawback is related to the need for these transfers to be referred to a closed circuit, both the payer and the recipient must have accounts with the banks which subscribe to the service or must download third-party applications and register for new services in order to complete the transaction.

Credit or debit cards, whether physical or virtual (such as Google Pay, Apple Pay, Samsung Pay, etc.) are always subject to monthly spending limits (generally between € 1 ,300 and € 1 ,500) which make them unusable for high amount payments, also need a POS device to be able to collect a payment effectively reducing the beneficiaries to business users.

All the available electronic payment systems lack very important features.

The first is the possibility to set payment at a future date which is irrevocable. To date, only the bank transfer - or bank wire - allows users to set a payment at a future date but this can be canceled until shortly before the transfer is actually effected, making it, in fact, a useful tool only for the payer as it does not offer any kind of guarantee or certainty to the recipient.

The second is that the electronic payment system can be used immediately without needing the users to be provided with dedicated software programs or mobile apps in advance, without the need for the recipient to register to currency transfer services or hold a bank account with the same financial institution where the payer user has an account, and without the need for the payer user to know the recipient user’s bank details.

Another feature missing from the electronic payment systems currently available is the possibility to associate customization of the payment itself with the collection step of the payment. The aforesaid customization, e.g. through images or videos, may be related to the object of the payment itself, to the paying company or to a particular chosen event. Today’s electronic payment tools allow only a limited object to be associated with the payment but they do not allow the payment to be characterized by the addition of content which can personalize it. This feature could be useful for companies which reimburse their customers (e.g. by sending cash backs as part of marketing campaigns) or for sending gifts related to special occasions and should be available without needing to know the recipient’s bank details.

It is, therefore, an object of the present invention to introduce a new method and system for transferring electronic money between users which is immune from the aforesaid drawbacks and which is safe and easy to use, thereby contributing to facilitating the progressive replacement of the cash, checks and electronic money payment methods currently in use.

BRIEF DESCRIPTION OF THE FIGURES

Further objects, features and advantages of the present invention will be more apparent from the following detailed description provided by way of non-limiting example and illustrated in the accompanying figures, in which:

Fig. 1 shows a block chart of a preferred implementation of the distributed electronic payment system according to the present description;

Fig. 2 shows a first diagrammatic flow chart of a preferred embodiment of the method according to the present description, in which the interactions between the described system and the users of the described system are highlighted; and Fig. 3 shows a second diagrammatic flow chart of a preferred embodiment of the method according to the present description, in which the interactions between the described system and the users of the described system are highlighted.

The component parts of the method and system according to the present description are shown in the drawings, where appropriate, with conventional symbols, showing only the specific details which are relevant to the understanding of the embodiments of the present invention, so as not to highlight details which will be immediately apparent, to those skilled in the art with reference to the description given herein. DETAILED DESCRIPTION OF THE INVENTION

The method and system to support the electronic payment described below is structured in a sequence of steps which provide an initial collection of the information related to the payment; the successive sending of the payment by the payer user; the receipt by the recipient user of the payment made by the payer user; the acceptance by the recipient user of the payment received and finally the transfer of the amount which is the object of the transfer from the payer user to the recipient user.

The initial payment information can be collected through different channels which must have access to the payer’s current account from which the payment will withdraw the sums to be transferred. The aforesaid channels may be traditional banking channels (home banking, mobile banking, credit or debit cards, either virtualized or not, etc.) or other channels such as fintech platforms which, by taking advantage of the new European open banking regulations dictated by the PSD2 (Payment Service Directive), have access to the current account.

The steps by means of which the distributed electronic payment method and system are structured are briefly described below in the following paragraphs.

(Collection of required information from the payer user)

The information to be collected through one of the aforesaid channels relates to the following data:

The recipient’s name and surname;

A unique identifier of the recipient. The identifier may be a telephone number, an email address, an account number, the tax code or any code which uniquely identifies the recipient within the distributed payment system according to the invention;

The payment date, which may be the same as or later than the date of creation of the payment itself;

The amount of the payment;

A description of the payment, which may consist of a free text or a text chosen from a predetermined list;

The payment method, which may require the immediate blocking of funds to be transferred or not.

(Sending the payment request)

The data collected through one of the above channels are sent to the system which is the subject of this description. Upon receipt of the information relating to the payment request, the system may request the blocking of the amounts relating to the payment on the payer’s current account, or this blocking may be done by the recipient at the time of acceptance or on the payment date, if future. At this point, the system sends the payment notification - which is irrevocable - to the recipient through the digital channel related to the unique identifier of the recipient. For example, if the unique identifier of the recipient is the email address, the payment will be sent via an email message; if the identifier is the phone number, the payment will be sent via an SMS text message or via instant messages (Whatsapp, Telegram, in-app notification, etc.); if the identifier is a code which identifies a device of another nature (e.g. a POS), the message will travel on the network to which that device is connected. The recipient will then receive a message containing the details of the payment and instructions to cash it on a device consistent with the transmission channel used (PC, smartphone, POS, etc.).

Once the payment has been sent, the payer will not be able to cancel it.

(Receipt of payment by the recipient)

The payment may be received by the recipient in different ways. If the channel receiving the payment can connect directly to the system according to the present invention, the payment can be accepted directly from the channel interface (e.g. through POS, through the bank channel etc.). If the channel cannot connect directly to the system (e.g. as in the case of emails or SMS text messages), the message will contain a link to a web page or an application for portable devices, made available by the system according to the invention, which will allow access to the payment received.

The recipient will have a period of a given number of days configurable by the system which is the object of the invention to be able to accept payment from the set payment date. During such a period of time, the payer may neither cancel nor change the payment. After such a period of time, the payment will be canceled and it will no longer be possible for the recipient to collect it.

(Acceptance of payment by the recipient)

The payment may be accepted by the recipient in different ways. If the recipient’s unique identifier is already linked to the coordinates of the recipient’s current account within the system according to the invention, then the recipient will only have to accept or refuse the payment. If, on the other hand, the recipient’s unique identifier is not linked to the recipient’s bank details, the recipient must enter these before accepting the payment. The recipient will not have to download any new apps or register for any new services in order to collect the payment received.

The recipient may, at any time, associate his or her bank details with his or her unique identifier within the system which is the subject of the invention. In this manner, for subsequent received payments, the bank details will be automatically suggested by the system according to the present description. The entered bank details can still be changed at any time.

The portal (web or mobile application) where it is possible to accept the payment, can be customized both in terms of graphics and content to associate the payment with the event related to the payment itself. For example, if the payment is related to a cashback campaign, the system according to the present description may display the logo of the campaign and the text which reminds the association of the payment made with the campaign.

(Transfer of money to the recipient)

The money transfer relating to the transfer is made as follows: When the payment is accepted by the recipient and the date of collection is either equal to or later than the payment date set by the payer, the system according to the invention communicates with the payer’s current account, checks availability and, if the account is sufficient, blocks the funds (if not already done so during the step of creating of the payment if the payer chose guaranteed payment) and queues the payment on the chosen system in irreversible manner, so as to protect the recipient. The system will settle the payment according to the methods and timing typical of the underlying payment system (e.g.: one working day in the case of an SCT transfer (SEPA Credit Transfer), within 20 seconds in the case of SCT Instant).

If the payment is accepted by the recipient before the payment date specified by the payer (future payment date), the payment is held in standby until that date. (Notifications produced)

All the steps of the payment and the changes to the status of the payment itself are notified in real-time to both the payer and to the recipient through the most appropriate channels with respect to the channel chosen by the payer and used for payment. The last notification sent to the recipient is the one confirming the availability of the sums and the irreversible start of the credit made.

(Unlock code)

The payment transaction can be associated with an unlock code to increase security. Such a code may be generated by the system which is the object of the present description and communicated by the payer to the recipient on a channel other than the one used for the transmission of the payment, or it may be a code already in the possession of the recipient (customer number, tax code, etc.) and previously shared with the user payer. Such a code, if set by the payer, must be entered by the recipient in order to unlock the payment.

The code can also be provided to an independent third party to act as an escrow agent by unlocking the transaction at the appropriate time.

(Irrevocability)

The payment at a future date is irrevocable, therefore, after the payment has been sent by the payer to the recipient, the payer is no longer entitled to cancel or modify it. This applies both to payments with immediate payment dates and to payments with future dates. It is the system according to the present invention which guarantees irrevocability, regardless of the chosen payment regulation system (e.g., SEPA SCT, SEPA SCTinst, Wire Transfer), of which the system according to the present description becomes a value-added service. Indeed, the chosen payment regulation system does not see the payment request until it must be effected because the system which is the object of the present invention keeps the payment and communicates it to the regulation system only when the money transfer must be actually effected.

(Instant outcome)

The system according to the present invention also allows scheduling irrevocable and recurring future payments at regular intervals within a given time interval and allows providing an instantaneous outcome of the transaction, both to the payer and to the recipient, even when the chosen payment system does not provide such a possibility. This is made possible by the fact that the sums are blocked on the payer’s account when the payment is accepted (either on the payment date if it is accepted earlier, or at the creation of the payment if the guaranteed method is chosen). Even if the payment is settled at a later time (e.g. as with weekend bank transfers), the amount has already been blocked and thus removed from the payer’s availability.

(Collection customization)

The system also allows customizing the recipient’s user experience. The customization can be done in two ways, i.e. by choosing from a predefined, preset list or by implementing it ad hoc.

The customization by choosing one of the available pre-prepared models (e.g. birthday wishes) provides a fixed structure of the payment acceptance page and the possibility of modifying some of its contents. The customization may be chosen by the payer directly from the channel with which the payer accesses the system functionality. The customization, on the other hand, may also be defined by the payer on payment collection page structure level. In this case, the structure is defined and implemented by means of an ad hoc project aimed at modifying the collection section accessed by the payer, modifying its graphics and contents also by means of multimedia elements, such as images or videos.

DETAILED DESCRIPTION OF THE INVENTION

All electronic payment systems available to date have drawbacks which limit their use. In particular, they lack two important features, i.e. the possibility of setting a future payment date which is irrevocable and the possibility of immediately using the electronic payment system without having to obtain dedicated software programs or apps for mobile devices in advance and without having to make registrations to currency transfer services.

The present description illustrates an electronic payment service from current account to current account free of the limitations of current systems.

The method and the system according to the present description can, therefore, be used by any user in possession of a bank account and are adapted to settle payments from current account to current account. The recipient user of the electronic payment made through the system according to the present description is put in a position to collect payment without having to register to any new service or download new applications (e.g. as is the case of all P2P payment services). This feature is also useful for the payer user who will not have to worry about whether the recipient is a subscriber to some particular service but will only have the service according to the invention integrated in one of the channels which has access to his or her current account.

With reference to the attached Fig. 1 , the distributed electronic payment system 103 according to the present description is configured to communicate, by means of an interconnection network 8, e.g. the Internet, with a payer user 100 provided with a communication device 9, with a recipient user 101 provided with a communication device 10, and with a financial institution 102 which has access to the current account of the payer user 100. The financial institution 102 may be a bank, an electronic money institution, a payment institution, a fintech and, in general, any organization which has access to the current account of the payer user 100. The distributed electronic payment system 103 according to the present description will be integrated into the channels of the financial institution 102 so as to make it available to the payer users 100 who hold a current account with said financial institution 102.

The payer user, by means of a first communication device 9, accesses his or her current account through the channels provided by the financial institution 102 connected to the current account. These channels may be home banking, mobile banking, corporate banking, or even apps for smartphones or smartwatches, or any other channel on which the financial institution 102 has integrated its services and made them available to users. Correspondingly, the communication device 9 of the payer user 100 may be a personal computer, a smartwatch, a smartphone or any other device configured to reach the aforementioned channels provided by the financial institution 102 with access to the current account of the payer user 100. The recipient user 101 will be put in a position to collect the payment sent by the payer user 100 by means of a second communication device 10 configured to communicate, by means of said interconnection network 8, with the distributed electronic payment system 103 according to the present description. The communication device 10 of the recipient user 101 may be a personal computer, a smartwatch, a smartphone and also a POS payment terminal, a cash register, etc. In further detail, a preferred implementation of the system 103 comprises a remote server 3 configured to communicate with at least one server 102a of at least one bank or financial institution 102. Said remote server 3 is connected to a first database 1 containing the general transaction information which must be shared between the financial institutions which manage the current accounts of payer and recipient and is configured to manage payment transactions centrally and to communicate and exchange data with recipient users 101 by means of said interconnection network 8. Advantageously, the remote server 3 may be associated with cryptographic communication protocols or security layers 6 which allow secure communication over said interconnection network 8, e.g. a TCP/IP type network, such as the Internet, providing authentication, data integrity and encryption. Furthermore, said remote server 3 is further connected to a second database 2 containing confidential information for the financial institution, i.e. information which must not be shared between financial institutions which manage the current accounts of payer and recipient users.

With reference to the attached figure 2, according to another preferred embodiment of the invention, said remote server 3 comprises a first server 4 and a second server 5. The remote server 4 is connected to a first database 1 containing the general transaction information which must be shared between the financial institutions which manage the current accounts of payer and recipient and is configured to manage payment transactions centrally and to communicate and exchange data with the recipient users 101 by means of said interconnection network 8. The second server 5 is connected to the second database 2 containing confidential information for the financial institution, i.e. information which must not be shared between financial institutions which manage the current accounts of payer and recipient users. Advantageously, the second server 5 may preferably be associated with cryptographic communication protocols or security layers 6 which allow secure communication over said interconnection network 8, e.g. a TCP/IP type network, such as the Internet, providing authentication, data integrity and encryption. Said security layers 6 may be built using state-of-the-art techniques and comprise, for example, at least one firewall and one network balancer associated with said firewall.

The electronic currency according to the present invention is transferred in three steps: generating and sending the payment request by the payer user 100 of a sum drawn from his or her bank account, receiving and accepting the payment by the recipient user 101 , transferring money by the bank of the payer user 100. (Generating and sending the request).

In further detail, and with reference to attached Fig. 3 and 4, the payment method according to the present description provides a payer user 100 to access, from his or her personal computer, tablet, smartwatch or smartphone, the Internet Banking (IB) or Mobile Banking (MB) application of his or her bank and choose a section relating to the new method of payment according to the present invention. In more general terms, the payer user 100 accesses 201 , through his or her communication device 9, the server 102a on which the channel of the financial institution 102 which has access to the current account from which the payer 100 wants to send money is hosted. This access is performed according to the usual procedures of the concerned financial institution, using the requirements and user experience (UX) typical of the chosen channel (e.g., the IB or MB application used can now ask the payer user 100, at this point, for the OTP or PWD required for the ordering operations and a confirmation to make the transfer).

The payer user 100 enters 202 the information relating to a promise of payment (e.g. the recipient user’s details 101 , the amount to be transferred, the date of the transfer, a possible security PIN, the description and payment method, which may be standard, instant, repeated, or otherwise, etc.) which are sent to the financial institution 102.

At this point, the server 102a of the financial institution 102 sends 203 the aforesaid payment information to the server 3 (or the second server 5) of the system 103. The server 3 (or the second server 5) of the system 103 creates 204 payment (e.g. by creating an identifier within the system by entering the payment record with all the information in said database 2) and sends 205 a payment notification prepared to the recipient user 101 , through a channel consistent with the unique ID of the recipient used by the payer user 100 (e.g. email in the case of email address, SMS or instant message in the case of phone number, etc.). Said notification preferably comprises the information needed to proceed with the collection of the payment (a web link in the case of email or SMS, or the possibility of accepting directly the payment for cash or POS devices of the recipient user 101 ). If the payment method chosen by the payer user 100 provides the immediate blocking of funds relating to the payment to be made, the server 3 (or the second server 5) of the system 103 sends 206 the respective request to financial institution 102, which will block 207 the money for the transaction, as requested. In this case, the notification to the recipient user 101 is sent only after confirmation of the blocking of funds by the bank. (Reception and acceptance of payment).

The recipient user 101 receives 208 the payment notification. If the notification contains the link, the recipient user 101 must follow the link which will direct him to a web page for the collection contained on said a first server 3 of the system 103 according to the present invention. If, on the other hand, the recipient receives the notification on a channel which is directly integrated in the system in accordance with the present description, he or she may continue the collection operations directly from that channel (e.g., in the case of POS, the payment can be accepted by the device by pressing a button on the user interface of the POS). Again, in this case, the interaction takes place with said first server 3 but the user interface to perform the collection is hosted elsewhere.

At this point, the recipient user 101 can confirm 209 his or her bank details if they have already been saved (e.g., the IBAN code for the transfer credit) or can enter new ones. If required by the payment method chosen by the payer, the recipient must also enter 210 an unlock code for the transaction (e.g., the PIN set during the creation of the payment which can be associated with the transaction and which can be represented by the tax code, the customer code, the contract code or any other code associated with the transaction). At this point, the recipient user 101 may either accept or refuse the payment 211 . The refused payment will cease to be available. (Making the payment).

The system 103 collects the data entered from the recipient user 101 to complete the requested payment. If the date when the payment is accepted by the recipient user 101 is the same as or later than the date set by the payer user for payment, the request to send the money to the financial institution 102 hosting the current account of the payer user 100 is sent 212; otherwise, if the date on which the requested payment is accepted is earlier than the payment date, the system 103 keeps 213 the requested payment pending until the payment date indicated by the payer user 100. Finally, on the payment date, the request to send the money is sent 212 to the financial institution 102 hosting the current account of the payer user 100. The financial institution 102 checks 214 the balance of the current account of the payer user 100 from which to charge and, if it is sufficient, blocks 215 the funds necessary for the transfer (if it did not already do so) and irreversibly queues 216 to the payment by sending 217 notification to the system 103. If the current account is not sufficient, the financial institution 102 sends 217 a notification of a negative outcome of the transaction to the system 103.

Once the outcome of the transaction has been received, in the event of a positive outcome, the system 103 sends 218 a notification to the payer user 100 and to the recipient user 101 notifying them that the irreversible payment is in progress. In the event of a negative outcome, the system 103 will instead notify 218 the failed payment to the payer user 100 and the recipient user 101 . The payment notification - which is irrevocable - is sent to the recipient through the digital channel related to the unique identifier of the recipient him or herself. For example, if the unique identifier of the recipient is the email address, the payment will be sent via an email message; if the identifier is the phone number, the payment will be sent via an SMS text message or via instant messages (Whatsapp, Telegram, in-app notification, etc.); if the identifier is a code which identifies a device of another nature (e.g. a POS), the message will travel on the network to which that device is connected. The recipient will then receive a message containing the details of the payment and instructions to cash it on a device consistent with the transmission channel used (PC, smartphone, POS, etc.).

Finally, if the transaction is successful, the financial institution 102 transfers 219 the money to the recipient user’s current account 101 using the chosen payment control system.

The payment shall be made for a defined period of time from the payment date specified by the payer. If the recipient user 101 does not accept or refuses the payment by that date, the payment will expire and it will no longer be possible to complete it. The previous description of exemplifying embodiments makes reference to the attached drawings. The detailed description above does not limit the invention. Conversely, the scope of the invention is defined by the appended claims.

The reference in the description to “an embodiment” or “a preferred embodiment” means that a particular structure or feature or a characteristic element described in relation to an embodiment is comprised in at least one embodiment of the described object. Therefore, the presence of the expression “in an embodiment” or “in a preferred embodiment” or “in the embodiment” or “in the preferred embodiment” in various points of the description does not necessarily refer to the same embodiment. Furthermore, the characteristic elements, structures of particular features may be combined in any manner suited to one more or embodiments.