WO2015000807A1

WO2015000807A1 - Method and system for carrying out electronic transactions

Info

Publication number: WO2015000807A1
Application number: PCT/EP2014/063707
Authority: WO
Inventors: Alfio PUGLISI
Original assignee: Gft Italia S.R.L.
Priority date: 2013-07-04
Filing date: 2014-06-27
Publication date: 2015-01-08
Also published as: ITMI20131126A1

Abstract

The present invention relates to a method and system for carrying out transactions (e.g. payments), even by means of mobile devices, more in particular, a method and system for creating a network of immediate payments, without requiring that each of the two parties (the one who issues the payment and the one who receives it) know the account or the financial instrument details of the other party.

Description

METHOD AND SYSTEM FOR CARRYING OUT ELECTRONIC

TRANSACTIONS

TECHNICAL FIELD

The present invention relates to a method and system for carrying out electronic transactions (e.g. payments), possibly by means of mobile devices, more in particular, a method and system for creating a network of immediate payments, without requiring that each of the two parties (the one who issues the payment and the one who receives it) know the account or the financial instrument details of the other party.

TECHNICAL BACKGROUND

We are experiencing an increasing success and spread of the so-called mobile payment, i.e. instantaneous payment methods that do not require the use of cash, in which two parties exchange a financial value of goods or services, by means of a mobile terminal. A further diffusion of such payment methods finds difficulties for payments of small amounts, due to the relatively high cost of a transaction with respect to its value and the complexity of payment mechanisms. The attempts to simplify such mechanisms must reckon with the safety and reliability requirements connected with the data transmission.

The attempts to implement and spread services for electronic transactions with authentication, access and data exchange are usually based on protocols universally accepted as safe (e.g. NFC forum, GSM association, SEPA). At the present state of the art, every service supplier must proceed with a project of a use specification and realize a specific client for the mobile terminals (application resident in the mobile terminal); moreover, a server (that is a counterpart application residing in the service distribution system) and an application communication protocol between the developed components must be prepared. This approach can be distractive in terms of resources and investments, because it is necessary to repeat common elements for every single application: on the contrary, it would be desirable to structure use processes beginning from a common base (proposed framework) which would reduce general costs and implementation times. Another problem of the present mobile payment methods derives from the fact that there is no way of exchanging money (or better, its corresponding value) or other financial values, between individual users, that is the so- called C2C ('consumer to consumer"), as set up against the more customary B2C ('business to consumer"). For these exchanges a financial intermediary intervention is needed, e.g. banks, credit cards, payment circuits. It is necessary to consider also regulatory restrictions imposed by the various national legislations and the difficulties deriving from the harmonization of such restrictions which allows the system to operate in more nations.

Document WO2013/028910 describes a system for transferring funds from the user of a mobile device to another one (including the possibility of C2C transfers). However, according to this system, the mobile devices (or at least one of the two, either the paying or the receiving one) are(is) connected to a mobile network operator which is likely to be a bank or telephone service provider, thus imposing restrictions and requirements that reduce the system flexibility.

The object of the present invention is to provide a technology that overcomes, at least partially, the disadvantages of the presently available systems.

SUMMARY OF THE INVENTION

This result has been obtained, according to the present invention, by means of a method for carrying out electronic transactions of financial values from an instructing user to a payee by means of a distributed system including a server, the server having access to a database containing information details on a plurality of registered users, each one of the registered user being associated to a user profile including at least one user ID and at least one financial instrument, the server being adapted to establish connections with registered users and with the financial instrument managers associated to the registered users, said method comprising the steps of: the server receiving a request to carry out a financial transaction from an instructing user, the request including the amount of the financial transaction and at least one identifying code of a payee; the server searching among the registered users for a registered user associated to the at least one payee's identifying code; responsive to a positive search result, the server transmitting to the manager of the at least one financial instrument associated to the instructing user the instruction of completing the requested financial transaction in favour of the at least one financial instrument associated to the payee; responsive to a negative search result, no registered user having the at least one identifying code associated, the server analysing the identifying code of the recipient user to determine at least one valid address for sending an automatic message; and responsive to the determination of at least one valid address, the server notifying to the payee the details of the request to carry out the financial transaction.

In a preferred embodiment, the server has the authorization of executing operations (e.g. payment order) on the financial instruments associated to the registered users, therefore the step of transmitting the instruction to the manager of the financial instruments, corresponds to a proper executive instruction with immediate effect.

Advantageously, the automatic message includes an email or an SMS or a vocal message and the step of determining a valid address includes analysing the at least one identifying code to check whether it contains a valid email address or a valid telephone number.

In an embodiment of the present invention, after the instruction to complete the requested financial transaction has been transmitted, the server notifies the registered payee about the transmission of the instruction.

The server communicates with the registered users by means of one of the following communication channels, or a combination thereof: mobile telephone network, Internet, Wi-Fi, BlueTooth, RFID, NFC.

Once the instruction of completing the requested financial transaction has been transmitted to the manager of the financial instrument of the instructing user, the server notifies the payee of the transmission of the instruction. This notification can be done immediately or only after the manager of the financial instrument has confirmed the transaction.

In an embodiment of the present invention, where the payee is not a registered user, the server, when transmitting the details of the requested transaction in favour of the payee, suggests that the payee registers himself as a registered user, in order to complete the transaction.

Advantageously, the profile associated with every registered user includes one or more of the following details: authorisation code the server has to ask the instructing user for authorizing the transaction, maximum allowable transaction value, specific time-related and/or payee-related provisions.

The transactions that can be realized by means of the method according to a preferred embodiment of the present invention can be "Consumer to Consumer" (C2C) or "Consumer to Business" (C2B), or "Business to Consumer" (B2C). When the electronic transaction is "Business to Consumer" (B2C), the subject of the financial transaction can include one or more of the following categories: discount coupon, commercial coupon, cash- back, e-coupon, charity cash-back.

Furthermore, advantageously, the instructing user is provided with a mobile terminal adapted to communicate with the server, directly or through intermediate devices, through a large capacity data exchange channel (e.g.

BlueTooth, RFID, Wi-Fi, GSM/GPRS/UMTS) and the connection takes place through one of these channels.

According to another advantageous embodiment of the present invention, the financial instruments include the reference to a credit card or other payment cards or a bank account. Other possible financial instruments include prepaid cards, telephone credit, coupon, cash-back, charity cash-back.

The present invention provides also a computer program, a software application or a program product that implement the foregoing method, when they are run on a computer, a telephone or any apparatus capable of data processing. In addition, a distributed system that implements the foregoing method has been provided.

The present invention provides a flexible and easy-to-use system, which enables the users to carry out rapid and safe financial transactions, without requiring the details of the transaction payee. In this way, it is possible to overcome some disadvantages of the state of the art systems available for mobile payment services (m-payment), domestic and international, which offer solutions without global breadth (in a similar manner to a real card Circuit), not pervasive (consequently, delimited to specific instruments, to a specific company context, or which force the choice of proprietary tools, such as virtual wallets or purses), not integrated (the whole Consumer-Merchant- Banks-Circuits chain) and partial (e.g. focusing on the payment and not on the whole life cycle of the commercial process). Typically, the transfers occur by means of not immediate «time» mechanisms (e.g. credit transfers t+1 ; credit card t+n; ...); at the same time, innovative tools, such as Paypal, makes it necessary to create virtual wallets as a payment mechanism. Another advantage deriving from the present invention is that it allows the use of the existing components and does not require a dedicated infrastructure. BRIEF DESCRIPTION OF THE DRAWINGS

These and other advantages, objects and characteristics of the present invention will be better understood by those skilled in the art from the following description and the enclosed drawings, related to the illustrative, exemplary, but not limiting, embodiments, in which:

- Figure 1 illustrates the general architecture of a system according to a preferred embodiment of the present invention;

- Figure 2 illustrates schematically a generic computer used in the system according to a preferred embodiment of the present invention;

- Figure 3 schematically illustrates the main module of the system according to a preferred embodiment of the present invention;

- Figure 4 illustrates the "virtual village" according to a preferred embodiment of the present invention;

- Figures 5-13 schematically illustrate 9 examples of possible uses and implementations of the system according to the present invention;

- Figure 14 schematically illustrates the steps of a method according to a preferred embodiment of the present invention;

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

According to a preferred embodiment of the present invention, the system includes a payment platform for handling payments and value added services; in way similar to a «hub», the platform integrates payments and value added services which are provided by the partner Banks, the Interbank Circuit, the credit and debit card Processors, the telephone companies, the Merchants and/or other «service providers», with the view of the provision of the new services in a simple and safe way, using e.g. PCs, smartphones and tablets or other devices, via e.g. web pages, «apps» or other interactions. In a preferred embodiment, the payment platform implements a «payment Super-Circuit» that joins and integrates the traditional payment systems, channelling the transactions by means of a single device and permitting the real-time management of the availability of the amounts being transferred. In a preferred embodiment, the main payment instrument is a Bank Account, for transactions with the same bank or to/from other banks; however, the platform includes and integrates other payment instruments, such as Credit/Debit Card, Pre-paid Credit Card, Mobile telephone credit, Coupons, Cash-back, Charity Cash-back, etc. Therefore, the users of this service can still use the payment instruments already in use, without the necessity to subscribe for new and/or specific instruments.

In a preferred embodiment, therefore, the technological platform consists of the following components:

· Data center technological facility

• Telematic connection networks that are safe for the subscribers

• Safety systems

• Software connectors that connect with Interbank Circuits, the credit card Processors and the Merchants

· Specific application components («apps», Portal, CRM, Gateway, ...)

For the system to function properly, an appropriate network of contractual frameworks and commercial agreements between the ecosystem members must be set up. The integration takes place through architectural models and standard technologies, in accordance with pre-coded protocols, which reduce the time and cost for activation at the partner counterparts (Banks, Processors, ...).

The platform has the advantage of allowing exchange of financial values (e.g. money) between two individuals, contrary to what usually happens with mobile payment models known in the art and currently implemented. Of course, the platform does not exclude the most classic use between consumer and operator.

According to a preferred embodiment, the platform provides for two main situation of use in the ecosystem:

• «C2C» (Consumer-to-Consumer), for the transfer of money between Consumers and the immediate availability of the transferred money to the payee

• «C2B» (Consumer-to-Business) designed to allow the purchase of products and services, without a physical POS, even through partial/total payment with electronic coupons; primarily referred to «Small Business» (e.g., small dealers, professionals, ...) and large «vertical» companies (e.g. Large/scale Organised Distribution (LOD), Oil Companies, ...).

As shown schematically in Figure 1 , according to a preferred embodiment of the present invention, the architecture comprises a main module for the management of financial transactions 101 , which allows setting in relation to each other a first member 103 (which we define as the instructing user) and a second member 105 (which we define as the payee) between which an exchange of financial values should take place (e.g. money, but it could also be, for example, a discount coupon, or a service coupon, a railway or subway ticket, the reservation of a theatre event, a healthcare ticket, the payment of a bill or a subscription/ticket for mobility services such as Restricted Traffic Zone (RTZ) or car parks, the payment of a periodic subscription (e.g. daily, weekly, yearly) or "pay per use" of a skiing resort with verification and contextual reservation of the amounts). Each user 103 and 105 is connected with a financial instrument (107 and 109 respectively), and this connection is known (or can be tracked anyway) by the main module 101. When the user 103 wants to make a financial transaction to the user 105, he can simply issue an order to the system (or rather to the main module 101 , the composition of which we will see later), without having to know the details of the financial instrument of user 105, that is the recipient of the financial transaction. The instructing user 103 simply has to know the ID with which the payee 105 is known to the system. Possibly, user 105 has more than one user-related identifier (e.g. phone number, email, or even a nickname), which enables the system to uniquely identify the user and to make the transaction to the financial instrument previously chosen by the payee 105 (e.g. a bank account, a credit card). In turn, the instructing user 103 must be known to the system by means of an ID (and possibly an proper identification means, e.g. a password) and must have a payment instrument (or an instrument that releases the value to be transmitted) associated with him, from which the system can draw the necessary funds to complete the transaction.

In a preferred implementation of the present invention, the user 103 may be associated with a client module that allows interaction with the system and with the main module 101 ; this client module may be, for example, an App installed on a mobile device (e.g. a mobile phone). However, other embodiments are possible: for example, the payment order may be entered by means of a message (e.g. an SMS) or an email; according to another possibility, the transaction triggering event is the occurrence of an expected situation, for example the the passage of an RFID transmitter in the vicinity of an enabled transceiver (see below for the example of the payment of a ski- pass or a car park). Also user 105 may be associated with a client module (e.g. a mobile phone) so that the transaction is properly notified to him: it must be remembered, however, that this step is not strictly necessary for the success of the operation, in other words, whether the recipient 105 is connected to the main module 101 in the moment in which the transfer takes place is not essential (in this case, however, he obviously cannot verify immediately the completion of the transaction). The main module 101 should include an appropriate communication network that enables interaction with the users (at least with the instructing user 103) and with the financial instruments 107 and 109; the system 101 will also include means for recognizing the instructing user and for identification of the payee (e.g. an online accessible database) so that the money can be withdrawn from the instrument associated with the instructing user 103 and transferred to the instrument associated with the payee 105. The system 101 shall be authorised to perform operations (e.g. making payments or ordering transfer of funds) on the financial instruments associated to registered users. In the situation as described above, both the instructing user 103 and the payee 105 are registered with the service and known to the system 101. More generally, while the instructing user 103 must compulsorily be registered with the service and known to the system 101 , the payee can even be unknown to the system 101 : as we shall see in more detail below, in this case (unknown payee), the system 101 will use the information provided by the instructing user to try to get in touch with the payee (e.g., determining a valid email address or a phone number) and to offer him the opportunity to complete the transaction and/or to register himself on the system.

Figure 2 depicts a generic computer used in the system, according to the preferred embodiment of the present invention. This general description includes any device with a processing capacity, albeit with different levels of sophistication and functionality (e.g., computers, mobile terminals, servers, network routers, proxy servers). The computer 250 is composed of several units, which are connected in parallel to a system bus 253. In greater detail one or more microprocessors 256 control the operation of the computer; a RAM 259 is used directly as the cache memory by microprocessor 256, while a ROM 262 contains the basic code for the initial booting of the system (bootstrap). Several peripheral units are connected to a local bus 265 by means of appropriate interfaces. In particular, these peripherals may include a mass storage unit consisting of a hard-disk drive 271 and a CD-ROM and/or optical disks (e.g. DVD or BlueRay) drive 274. In addition, the computer 250 may include input devices 277 (e.g., keyboard, mouse, track point) and output devices 280 (e.g., monitor, printer). A NIC (Network Interface Card) 283 connects the computer 250 to a network. A bridge unit 286 provides an interface between the system bus 253 and the local bus 265. Each microprocessor 256 and the bridge unit 256 may operate as a "master agent" and request exclusive access to the system bus 253 to transmit information. An arbiter 289 handles requests for access to the system bus 253, with the aim of avoiding conflicts between the instructing users. Similar considerations apply to slightly different systems or systems based on different network configurations. Other components, in addition to those described above, may be present in specific cases and for particular implementations (e.g., handheld computers, mobile phones etc.).

Figure 3 shows schematically the composition of the main module 101 in accordance with a preferred embodiment of the present invention. A server controls all operations, and includes a communication module that enables the connection through a network (e.g. GSM, Internet, LAN, or a combination thereof) with the users: in the case shown in Figure 1 , the connection is active with the instructing user 103 and with the payee 105. The server has access to a database containing all the information the server needs in order to associate the user IDs with their data, which may include for example: telephone number, email address, bank account IBAN code, credit card number, any conditions or limits of use, predefined instructions, emergency number, passwords. Those skilled in the art will easily appreciate that numerous precautions and security measures will be implemented to protect the data of individual users and to ensure that such data cannot be accessed by unauthorized third parties; in addition, the aim is to comply with existing rules on privacy and data security requirements. The server will also implement a procedure to connect with the financial instruments needed to complete the transaction, as described with reference to Figure 1.

This connection can be accomplished in many ways, available from the state of the art; for example, the connection can be made via the GSM, UMTS and HSDPA networks, Wi-Fi, Wi-Fi max, wired network, ADSL network; yet another possibility is the use of so-called "drop calls".

The users, in order to use the method in accordance with a preferred embodiment of the present invention, have to register and provide one or more of the above data. Individual users will be able to identify themselves with the system using a default name (nickname) which possibly correspond to the phone number of the mobile device from which the order is issued or to the email address from which the communication is sent. Upon completion of the identification procedures (which may include a request for a password or a PIN number to validate the identity of the user), the user who wishes to make a transaction (e.g. a transfer of money) to a another user, must provide details of the transaction (e.g. the amount of money) and an information detail enabling the system to identify the payee of the transaction. Input of data could be done through a terminal (e.g. a computer) possibly a portable one (e.g., a mobile phone or a handheld computer or a tablet) connected to the server through the above mentioned network. This identification may take place in various ways, and can also be assisted by a graphical user interface (GUI) on the terminal being used, which allows, for example, selection of a user among a number of possible users. To give one example among many possible ones, if the instructing user enters the name of the payee (assuming that the payee is an individual registered and known to the system with first name and family name), the GUI may provide a choice of possible solutions from which the user can select the desired payee. Possible combinations for the association between an ID and a user are quite numerous: the system administrator can modify the flexibility desired for the system itself based on which data are available for each user. In a possible embodiment of the present invention, the system may provide the possibility to carry out a transaction (e.g. send an amount of money) in favour of a payee that is not registered and is not known to the system: in this case, the instructing user will provide a contact detail (e.g., a phone number or an email address) by means of which the system notifies the payee about the instructing user's intention to effect such transaction (payment). The payee can decide whether to subscribe to the service or to accept a one-off operation, providing data for completing the transaction.

In any case, the details needed to perform the transaction, in favor of the payee, must include a financial instrument that can be, for example, a bank account identified by a unique identification code (e.g. IBAN code). Other possibilities include: credit and debit cards; rechargeable credit card, rechargeable SIM, electronic wallet, vouchers and coupons, credit deriving from "cash back" and a customer fidelity program ("loyalty program").

According to a preferred embodiment of the present invention, the system enables the creation of an extended "Virtual Village" within which the Consumer can experience an innovative payment in addition to special commercial conditions. Figure 4 shows a schematic representation of this "Virtual Village". With this solution, the limitations of current market solutions are overcome through:

- Aggregation and use, by a single «app», of the different service lines in a quick, transparent and safe way

- Immediate settlement of debit/credit amounts on accounts, credit cards, debit cards, prepaid cards

- Immediate availability of funds to the payee in respect of the transaction

- Use of pre-existing financial instruments (Bank current account, debit cards, prepaid debit cards, credit cards) owned by the Consumer and the Merchant without the need to introduce additional tools (e.g. virtual wallet)

- Transformation of the current account of the Merchant in a «virtual POS», with, in addition, the immediate availability of the amounts and the related reporting: hence, B2C transactions occur without the need for any physical POS (and related costs) Types of possible services

The platform in accordance with a preferred embodiment of the present invention can be adapted for countless uses.

As a pure example, we mention the following «lines» of services which can be put in place and offered in an integrated and transparent way:

• payments between individuals with transfer of money between individuals;

• payments and added value services with Merchants, for the payments of products/services to a Merchant

• payments for purchase of products/services on an e-commerce website of a subscribed Merchant

• managing and exploiting electronic discount vouchers (e-coupon) issued by the partner Merchant in the context of commercial promotions handled through the platform, usable by the Consumers in georeferencing mode, in the context of payment of products/services to the Merchant

· Consumer's cash payment at one of the partner Merchants, similar to a Bank counter, with the novel possibility of handling a possible refund

• Payments of tickets for ticket services (e.g. transportations, car parking, RTZ, amusement park)

• payment of ski pass in partner ski resorts in an innovative way («pay-per- use», season tickets, ...) and with added value for the user (e.g. without queuing up).

Main advantages of the system according to a preferred embodiment of the present invention from the «Consumer's» point of view:

· Subscription to the service by means of an «app» or the portal, which indicate and certify in a safe way the financial instruments for settling the payments (e.g. Bank accounts and cards)

• Safe operation through the «app», which allows to carry out the payment instructions identifying the payee through the telephone number, thus the sender is not requested to know and enter the details of the payee's payment instruments; consequently, this information does not travel on the web

• The payment simplicity with few essential data: in case of cash payment, it is enough to select the payee from the index of names, enter the amount (and a note, if necessary) and the device PIN. Other payment services (e.g. tickets and ski) need further data necessary for the specific usage field

• The processed amounts are limited and depend on the maximum number of daily operations, also based on the used service (e.g. cash vs. ski)

Main advantages of the system according to a preferred embodiment of the present invention in the «Merchant» field:

• For the Consumer:

• Automatic acquisition of the payee's data (e.g. by reading Bar Code, QR Code or Matrix Code, Tag NFC, ...) with the operation (e.g. taxi payment)

• For the Merchant:

• POS virtualization, caused by the transformation of the bank account into a virtual instrument

• Opening new services for customers

• Access for small business to commercial promotion instruments (CRM) with georeferencing logics (e.g. e-coupon, campaigns, ...) today not bearable due to their dimension, de facto opening a new Circuit of commercial opportunities; for the big vertical operators, the instruments are limited to the managing/fruition of the e-coupons (since, due to their dimension, they profit from their own CRM instruments)

• Adoption of social channels, offers the opportunity to increase the proper customer base according to the exponential word of mouth principle (e.g. a Consumer with 100 contacts in his index of names can, in turn, generate other 100 for each contact and so on; in a cascade passage over three contacts among Consumers, the potential is 100x100x100, consequently one million of potential clients)

Now we provide the details of a particular implementation of the system according to the present invention. We refer to this system as the Payment Platform (or even only Platform) and for convenience's sake, it will be referred to as such in the following description. It will be understood that the implementing details refer to one of the numerous embodiments of the method and system of the present invention.

Figures 5-13 illustrate the sequence of activities of a possible application of the method according to a preferred embodiment of the present invention. The examples given below represent some «cases of use», which are significant for the understanding of the Platform capacity and potentiality. In particular:

• Example 1 - Platform-cash illustrated in Figure 5: how a transfer of money between private persons occurs:

Step 1 : The instructing user selects the payee from his index of names; Step 2: The system automatically recovers the personal data corresponding to the selected payee's telephone number;

Step 3: The instructing user confirms the continuation of the operation and enters the amount, a note and the PIN;

Step 4: The system carries out the instruction and sends the result by means of notification message to both the instructing user and payee;

Step 5: The instructing user receives the confirmation of the successful transmission of the payment instruction; the payee is informed of being credited.

· Example 2 - Platform-cash illustrated in Figure 6: how a transfer of money between individuals occurs, where the payee has not subscribed to the service yet

Step 1 : The instructing user selects the payee from his index of names;

Step 2: The system checks the selected telephone number, but it indicates that the payee has not subscribed to the service;

Step 4: The system carries out the instruction transferring the amount on a temporary account (for a maximum period of e.g. 5 days). At the same time, it sends a message with the operation result to the instructing user and, after having credited his account, an SMS to the payee inviting him to subscribe to the service;

Step 5: The instructing user receives the confirmation of the successful transmission of the payment instruction; the payee is informed of being credited and invited to subscribe to the service within a prefixed period (e.g. 5 days). If the payee does not subscribe to the service, the amount is credited back to the instructing user's account, with the respective notification message for both.

• Example 3 - Platform-e-commerce illustrated in Figure 7: how a product bought on the internet from the e-commerce website of a partner Merchant is paid

Step 1 : The instructing user selects a product to buy from the partner Merchant's website and indicates the Platform as payment method, together with his telephone number;

Step 2: The Merchant's website sends to the Platform the transaction data (user's telephone number, Merchant's ID, transaction ID, amount, date, article). The Platform checks the data and sends a payment notification to the instructing user;

Step 3: The instructing user confirms the continuation and the system sends him the complete details of the transaction;

Step 4: The instructing user is shown a complete page of all the details of the transaction; the instructing user enters the PIN and confirms the operation;

Step 5: The system carries out the instruction and sends the result by means of notification message to both the instructing user and payee (the Merchant); Step 6: the website displays the transaction carried out successfully, enabling carrying out of the order; the instructing user receives the confirmation of the successful transmission of the payment instruction.

• Example 4 - Platform-coupon illustrated in Figure 8: how the discount vouchers are produced and distributed to two Consumers, who have subscribed to the e-coupon service in differentiated way Step 1 : The instructing user (in this case the Merchant) configures and asks the system to issue a set of e-coupons valid for all the points of sale of Milan and Cagliari;

Step 2: The system processes the e-coupon and confronts it with the rules of the Consumers who subscribed to the service to estimate its distribution; the service sends it to <Consumer 1 > (e.g. match on residence in Milan), but not to <Consumer 2> (no match);

Step 3: the Consumer 1 (payee) is notified that a discount coupon is available;

Step 4: In the meantime, the Consumer 2 (payee) goes from Verona to Milan and sends a request with his geographical coordinates to the system, so as to check which e-coupons are available in the specific Merchant typology within 10 km; the system sends the data and georeferencing information details; Step 5: the Consumer 2 displays the coordinates for the use of the discount coupon in "augmented reality" and then on the map.

• Example 5 - cash-me and Platform-coupon illustrated in Figure 9: how a product is paid with a combined use of cash and discount coupon

Step 1 : The instructing user selects from his index of names the payee who was also indicated for the presence of an soon expiring discount coupon; Step 2: The system automatically recovers the personal details corresponding to the selected payee's telephone number;

Step 3: The instructing user confirms the continuation of the operation and enters the amount of the purchase of 100€, selects the use of the coupon of 20€, enters the PIN and confirms the payment of 80€;

Step 4: The system cancels the discount coupon and carries out the payment instruction; then sends the result by means of notification message to both the instructing user and payee;

• Example 6 - Platform-ski illustrated in Figure 10: how a day on the ski slopes of one Ski Resort is paid;

Step 1 : The client (instructing user) accedes directly to the gates with his Ski pass card and passes for the first time;

Step 2: The gate calls the Platform-ski through the server of the facility administrator (payee) to ask the authorization to debit the card with the maximum contract amount of a daily ski pass;

Step 3: If the answer of the Platform-ski is OK, an obligation is created to lock the amount on the credit account. The facility gates are updated to allow the instructing user to pass;

Step 4: At the end of the day, the facility administrator's application calls the Platform-ski to communicate the real use of the ski pass (e.g. 3 hours);

Step 5: The Platform-ski cancels the obligation and debit the account with the amount due for the real use of the facilities; the system notify the instructing user about the debit;

Step 6: The instructing user receives the debit notification.

• Example 7 - Platform-ticket illustrated in Figure 1 1 : how a family pays a day in a Nature Park

Step 1 : The instructing user selects the entrance to the Nature Park (payee) from the index of Platform-ticket services; Step 2: the Platform-ticket communicates with the Park ticketing application and returns the details about the purchase of the entrance tickets;

Step 3: The instructing user selects the tickets and confirms the purchase; Step 4: the Platform-ticket settles the payment on the accounts and confirms the operation sending also a notification to the instructing user; the Park application sends the 3 entrance QR codes;

Step 5: The instructing user receives the message: "You have been charged 35€ for the Nature Park entrance";

Step 6: The instructing user accedes directly to the gates and displays the QR codes admitting the family to the Park.

• Example 8 - Platform-ticket illustrated in Figure 12: how the parking in a partner car park is paid

Step 1 : In order to use the service, the instructing user must have previously linked his Platform-ticket profile with one or more car number plates.

The instructing user enters the identifying code of the car park (payee) from the Platform-ticket services, or acquires it by reading a QR code or NFC, selects the car and the parking end time;

Step 2: The Platform-ticket asks the server of the Car Park administrator about the parking cost and then settles the payment on the accounts and confirms the operation notifying the instructing user;

Step 3: Ten minutes before the parking end time, the Platform-ticket sends an alert to the instructing user about the expiry proposing a possible renewal for the "Parkingl ".

• Example 9 - cash-me illustrated in Figure 8: how cash is paid at a partner Merchant Step 1 : The instructing user goes to a partner Merchant (payee) to pay cash; Step 2: The Merchant registers the instructing user in his index of names and asks his personal data to the Platform;

Step 3: The system automatically recovers the personal details corresponding to the selected payee's telephone number;

Step 4: The Merchant checks the correspondence of the personal details with the instructing user's identity document and enters the amount, a note and the PIN;

Step 5: The system carries out the operation, transferring the amount from the Merchant's account/card to the instructing user's account/card. Then it sends the result by means of a notification message to both the instructing user and Merchant;

Step 6: The Merchant receives the notification of the successful carrying out of the instruction; The instructing user receives the confirmation of the successful carrying out of the credit instruction.

The diagram of Figure 14 schematically illustrates the sequence of steps of the method according to a preferred embodiment of the present invention. The method addresses the carrying out of the electronic transactions of financial values (e.g. money, but not only, as already mentioned) from a instructing user to a payee (normally both have subscribed to a service, although this is not necessary for the payee); the method is implemented and works on a distributed system based on a server, which receives the requests and carries out the operations. The server must have access to a database in which the users are registered (at least the instructing ones): in the database, every registered user is associated with a profile, which must include an ID (there can be more identifiers for the same user, but not more users with the same ID) and a financial instrument, on which the financial values of the transaction are to be debited or credited. The server is designed to communicate with the registered users and with the financial instruments managers (e.g. banks, credit cards issuers). The method begins at step 1401 , in which the server receives a request from a registered user (if the user is not registered, the request cannot be satisfied) to carry out a financial transaction from the financial instrument associated to the instructing user (e.g. bank account) to a payee: the request must contain the amount of the financial transaction to be carried out, and a code which allows to identify the payee. In the most simple case, the payee will be a registered user of the payment method according to an embodiment of the present invention: then, the server carries out a check (choice 1403) and, in case of positive result (1405), it recovers the payee's details (e.g. IBAN code of his bank account) and sends (step 1407) to the instructing user's financial instrument manager (in the present example, a bank), the instruction to carry out a transfer to the payee's account. More in general, the manager of the financial instrument associated to the instructing user is instructed to carry out the requested financial transaction, to the financial instrument associated with the payee (who in this case is a registered user just like the instructing user). On the contrary, if the payee is not found among the registered users, the step 1409 is carried out, during which the server tries to retrieve, from the payee's identifier, the information necessary to send a communication which notifies to the payee the details of the financial transaction the instructing user requested in his favor. There can be various modes to make this notification, which depend on the system settings. The identifier can include an email address or a telephone number or both. In any case, the server checks (choice 141 1 ) if the address or telephone number (or another mode to send a message) is valid: if it is not able to send a communication to the payee, the transaction cannot be completed and a communication could be sent to the instructing user to inform him that it is not possible to complete the transaction and to contact the payee. On the contrary, if the payee can be reached, the message could contain an invitation to register to the system of the present invention, to complete the transaction and receive the subject financial values (step 1413). In any case, the method ends up with the communication of the transaction result to the instructing user and, if possible, to the payee (step 1415). In the following, some specific aspects related to one or more particular implementations are analyzed or some hypothetical solutions are given as a pure example.

Contract and compliance profiles of the Platform

• The user will subscribe to the Platform service which includes privacy terms of the acquisition of GPS coordinates, (Global Positioning System, necessary for the georeferencing operations);

• The proper rules relating to the use of the credit relations which take part in the transaction (credit cards, debit, bank account relation, ...), remain unchanged and are «transparent» to the Platform. In fact, the holder of the banking relationship (Bank or Circuit), who manages its ownership, is responsible for checking the compliance from the point of view of anti-money laundering regulations, with respect to proper verify of the counterpart and the mandatory reporting requirements. The Platform Security

^• Ensures the security of data relating to the payment instruments;

^• Allows secure execution of transactions with unique verification of the device and the payee, at the same time of the transaction;

• Continuous monitoring of 24x7 security through the Platform Operational Safety Unit and Alert mechanisms (e.g., with respect to payment events or when the threshold amount for a specific reference period is exceeded);

The «Platform-village» ecosystem is characterized by the presence of the following actors:

· Consumer and Merchant who make and receive payments through the

«app»;

^• The Service Provider, responsible for the service, technical, operational and commercial management and the security. Conveys payment transactions to the destination Circuit and/or to the partner Banks. This task can be performed by other subjects:

^• NewCo: was founded with the specific purpose of providing the Platform services;

^• Cards Processor: extends the scope of its intervention of the Platform services, benefiting from technological infrastructure, agreements and conventions already in place; ^• Telco Operators: extension of their business to innovative and pervasive services of Platform payment, benefiting from the infrastructure and technological skills already in place;

^• The Partners, that is, the financial counterparts (Banks, Circuits, ...) that join the Platform Cirtcuit agreement and that integrate their computer architectures for execution of payment transactions.

Payments with the Platform are greatly simplified and can be made by using a telephone index of names without having to know the Banking/PAN details of the payee.

Some of the benefits achievable with the Platform are as follows:

^• Transfer of a sum of money via "app" on a smartphone with immediate credit of the money;

^• Payment of a product/service at a store via "app" on a smartphone taking advantage of a discount as part of a virtual promotion of the operator;

· Availability of «smart» discount coupons, actually usable, which take into account the place where the Consumer is, the day, the type of purchase that the Consumer needs to do;

^• Creation of virtual promotions for merchants who do not have advanced information systems and CRM;

· Access to areas (e.g. parking, RTZ, ...) through recognition gates and automatic debit with "pay-per-use" logic;

• Instant access to the ski facilities without queing, and with payment of only actual use;

• Automatic restoration of availability (e.g. public transport tickets) upon achievement of a threshold (e.g., only 2 tickets remianing); Platform: Consumer Module

The Consumer user has access to the following functions, both «core» and « auxiliary»:

1 ) Through the "app":

2) Through Social Networks

3) Through the Platform Portal

Platform: Merchant Module

The user «Merchant», in addition to the functions available to the user Consumer (as he, in turn, can be also Consumer) has access to the following functions:

1 ) Social shopping function via e-coupons

2) E-commerce function

3) Advertising function

4) Trade statistics

5) Tariff profiles

6) Service statement consultation Platform: Service Provider Module

In addition to the typical tools for business management, the Service Provider can rely on all those necessary for the provision of the service, the operational management of the entire platform, security supervision and commercial development, according to the following main macro-modules: 1 ) Service Management 2) Safety Management

3) Commercial Management and Customer Care

4) Administrative Management

5) Monitoring and Service Supervision

Platform: Social Module

This is an additional and optional complementary application module for management of cash-back (also in the couponing form) and Charity Cash- Back through the movements made by the basic services Platform-cash and Platform-ecommerce, that is in a complementary manner through the movements of electronic money carried out on the issuer bank, acquiring or circuit, with the use of special "apps" connected to on one or more social networks Platform: availability management and accounting settlement

The settlement can be interchangeable when carried out between the following types of instruments:

• Current Account (ref. IBAN code);

• Credit/Pre-Paid/Debit Card on International Circuit (ref. PAN)

The Telephone Top-Up, to date, can only be the beneficiary of a transfer. The opportunity to use a phone card as the sender of a transfer is to be evaluated with the Telco Operators.

The «e-coupon wallet», powered by various partner Merchants, may be just a sender, that is total o partial payment of a product/service of a specific Merchant or groups of Merchants (e.g. complementary coalition) Availability management and accounting settlement always occurs in 4 major steps:

• Step 1 : Payment Order

• Step 2: Check of the Availability

· Step 3: Operation Status Report

• Step 4: Accounting Settlement (via SETIF flows)

Platform: platform safety

The overall safety of the platform is ensured according to the following key principles:

• In the context of subscription to the service:

1. Checking on the authenticity of payment instruments

• In the context of the payment instruction:

2. Checking the identity of the sender through the smartphones/legitimate owner combination: for example, the system generates a unique «client» key formed by the user ID and a token associated with the device. This enables the recognition of the user-device in the data exchange with the Platform platform. A given user can then operate only from a given device (unless he signs-up for a new subscription to the service). Similarly, the system generates a «server» token intended to be matched to the «device» token.

This enables unique recognition of the Platform server in the data exchange with the device.

3. Payment instructions with the payee's identification number through the telephone number, thus avoiding the sender having to know and enter the details to channel the payment. In addition, the account details of the sender and payee do not travel over the network.

4. Checking the correctness of the payee's phone number:

5. Entering a PIN stored in the «app» only locally on the smartphone:

6. Monitoring and superfision of the service.

In practice, the details of the execution may vary in any equivalent way as for what concerns the individual constructional elements herein described and illustrated and the nature of the materials herein shown, without departing from the adopted inventive idea, and therefore remaining within the limits of the protection conferred by the present patent. A technical person skilled in the art can make many changes to the solution described above in order to meet local or specific requirements. In particular, it should be appreciated that, while implementation details related to one or more preferred embodiments have been provided, omissions, substitutions or variations can be applied to some specific features or some steps of the above described method, following design or construction requirements.

As an example, the hardware components can take on a different appearance or include different modules; the term computer is intended to include any apparatus (e.g. telephones, handheld computers) having processing capacity for execution of software programs or portions thereof.

Software programs may be structured in a different manner or be implemented in any form. Similarly, memories can be implemented by using many embodiments or be replaced with equivalent devices (not necessarily consisting of tangible media). The programs can be in any form, suitable to perform their trasks, and can be written in any programming language or presented in the form of software, firmware or microcode, both in object code and in source code. The programs themselves may be stored on any kind of media provided that it is readable by a computer; as an example, the media can be: hard disks, removable disks (e.g. CD-ROMs, DVDs or Blue Ray Discs), tapes, cartridges, wireless connections, networks, telecommunications waves; the media can be, for example, electronic, magnetic, optical, electromagnetic, mechanical, infrared-operated or with semiconductors. In any case, the solution according to the present invention lends itself to be implemented by means of software, hardware (possibly integrated into chips or in semiconductor materials) or a combination of hardware and software.

Claims

1. A method for carrying out electronic transactions of financial values from an instructing user to a payee by means of a distributed data processing system including a server, the server having access to a data base containing information on a plurality of registered users, each one of the registered user being associated to a user profile including at least one identifier and at least one financial instrument, the server being adapted to establish connections with registered users and with the financial instrument managers, the method including the steps of:

- the server receiving from an instructing user a request to carry out a financial transaction, the request including the amount of the financial transaction and at least one identifying code of a payee;

- the server searching among the registered users the existence of a registered user associated to the at least one identifying code;

- responsive to a registered user having the at least one identifying code associated, the server transmitting to the manager of the at least one financial instrument associated to the instructing user the instruction of completing the requested financial transaction in favour of the at least one financial instrument associated to the payee;

- responsive to no registered user having the at least one identifying code associated, the server analysing the identifying code to determine at least one valid address for sending an automatic message; and responsive to the determination of at least one valid address, the server notifying to the payee the details of the request to carry out the financial transaction.

2. The method of claim 1 , wherein the automatic message includes an email and the step of determining a valid address includes analysing the at least one identifying code to determine a valid email address.

3. The method of any preceding claim, wherein the automatic message includes an SMS or a vocal message and the step of determining a valid address includes analysing the at least one identifying code to determine a valid telephone number.

4. The method of any preceding claim, further comprising:

- following the instruction of completing the requested financial transaction being transmitted, the server notifying to the instructing user the transmission of the instruction.

5. The method of any preceding claim, wherein the server communicates with the registered users by means of one or more of the following communication channels: mobile telephone network, Internet, Wi-Fi, BlueTooth, RFID, NFC.

6. The method of any preceding claim, further comprising:

- following the instruction of completing the requested financial transaction being transmitted, the server notifying to the payee the transmission of the instruction.

7. The method of claim 6 wherein the notification to the payee of the transmission of the instruction is done only after the manager of the financial instrument has confirmed the transaction.

8. The method of any claim 1 to 5, wherein the server, when transmitting to a non-registered user the details of the requested transaction, provides the option to the non-registered user to register in order to complete the transaction.

9. The method of any preceding claim, wherein the user profile includes one or more of the following information: authorisation code to be asked to the instructing user for authorising the transaction; maximum allowable value of the transaction; specific time-related and/or payee-related provisions.

10. The method of any preceding claim, wherein the transaction is

"Consumer to Consumer" (C2C) or "Consumer to Business" (C2B) or "Business to Consumer" (B2C).

1 1. The method of any claim 1 a 9, wherein the transaction is B2C and the subject of the financial transaction includes one or more of the following: discount coupon; commercial coupon; cash-back; e-coupon, charity cash- back.

12. The method of any preceding claim, wherein the financial instrument includes one or more of the following: bank account; credit/debit card; pre- paid credit card; mobile telephone credit; coupon; cash-back; charity cash- back.

13. A computer program which implements the method of any preceding claim when run on a data processing system.

14. A distributed system including one or more components adapted to perform the method of any claim 1 to 12.