WO2015023172A2 - Systemes et procedes de paiement mobile interpersonnel instantane (p2p) - Google Patents

Systemes et procedes de paiement mobile interpersonnel instantane (p2p) Download PDF

Info

Publication number
WO2015023172A2
WO2015023172A2 PCT/MA2014/000017 MA2014000017W WO2015023172A2 WO 2015023172 A2 WO2015023172 A2 WO 2015023172A2 MA 2014000017 W MA2014000017 W MA 2014000017W WO 2015023172 A2 WO2015023172 A2 WO 2015023172A2
Authority
WO
WIPO (PCT)
Prior art keywords
bank
account
mobile
server
transfer
Prior art date
Application number
PCT/MA2014/000017
Other languages
English (en)
Other versions
WO2015023172A3 (fr
Inventor
Jawad SAADI
Original Assignee
Saadi Jawad
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 Saadi Jawad filed Critical Saadi Jawad
Publication of WO2015023172A2 publication Critical patent/WO2015023172A2/fr
Publication of WO2015023172A3 publication Critical patent/WO2015023172A3/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/305Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108Remote banking, e.g. home banking
    • G06Q20/1085Remote banking, e.g. home banking involving automatic teller machines [ATMs]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223Realising banking transactions through M-devices

Definitions

  • the invention proposes a new instant interpersonal mobile payment (P2P) service based on new systems and processes for electronic money transfers.
  • P2P instant interpersonal mobile payment
  • M-Banking solutions are being tested in 2013 in France.
  • One of the most prominent solutions is a mobile money transfer account-to-account application offered by a bank of the place to its customers. This solution is downloadable on smartphone phones from known download platforms but it only provides one type of transfer.
  • NFC Near Field Communication
  • Japan it is the NFC technology that has mainly been used for some years in the mobile payment of purchases made in stores and more particularly transport services.
  • the consumer shakes his mobile phone equipped with a smart card in front of a NFC reader installed at the point of sale. Most of these transactions do not require authentication, but some require it via a PIN.
  • the payment is then deducted directly from a prepaid account or debited from a mobile account hosted in a bank.
  • M-Payment solutions are the direct billing solutions offered by telephone operators to their customers.
  • the customer pays his purchases at a point of sale by waving his mobile phone in front of a reader using Bluetooth or NFC technology.
  • the amount of the transaction is billed directly to the customer through his telephone company.
  • Other types of mobile payments in these countries use mini terminals or mobile (wireless) card readers installed at the points of sale.
  • the merchant slides the customer's credit card into this mobile reader and the transaction is concluded.
  • instant money transfer solutions are not widespread in these Nordic countries.
  • M-Pesa mobile money transfer service
  • This service allows users to deposit money into a registered account on their cell phones, send money to other users using SMS technology and redeem their registered or received deposits for free. money to agents including the resellers of airtime and outlets who act as banking agents.
  • the M-Pesa service has spread rapidly in this country and has become the most successful mobile payment service in developing countries. In 2012, this service had about 17 million registered accounts in Kenya.
  • Kenya launched in 2009 a mobile payment service whose underlying platform is based on the M-Pesa model created in Kenya.
  • the only difference between the two services lies in the technology used in the transmission of mobile money transfer data: in Kenya it is based on the SMS whereas in Africa it is mainly based on the USSD (Unstructured Supplementary Service). Data) to provide users with more user-friendly menus.
  • USSD Unstructured Supplementary Service
  • the new template instead of storing the credentials in the secure element of a mobile device, stores the personal account numbers in the cloud, and stores a prepaid account on the phone.
  • This prepaid account is linked to accounts stored in the cloud and is processed at the point of sale for financing the purchase.
  • the solution solved a problem of getting card issuers to participate in the transactions generated by this mobile wallet model.
  • another invention beyond the cloud-based approach proposes a dual map of payment that will give users the ability to pay with mobile wallets at locations that do not accept NFC payments. This is to couple the mobile wallet with a dual payment card. Technically, this update should be launched during this year 2013.
  • a mobile application was launched by another bank of the place in 2012 and allows its user to perform a set of M-Banking operations and which are:
  • TR receiver's mobile phone R for instant interpersonal mobile money transfer (P2P)
  • CRU virtual account system assimilated to a single reserve account of the same name of the bank B of the receiver R (general case)
  • CRUR virtual account system assimilated to a single reserve account of the same name of the B2 bank of the receiver R
  • CR bank account of receiver R domiciled in bank B or B2 (general case)
  • CRI bank account of the receiver R if domiciled at the same bank B as that of the issuer E
  • CVE or CVE / CRU virtual account of the issuer E backed by the CRU domiciled in the bank B or Bl (general case)
  • CVR or CVR / CRU virtual account of the receiver R backed by the CRU domiciled in the bank B or B2 (case general)
  • CVRI or CVR1 / CRU virtual account of the receiver R backed by the CRU if domiciled at the same bank B than that of the issuer E
  • CVR2 or CVR2 / CRUR virtual account of the receiver R backed by the CRUR if domiciled in a bank B2 different from that Bl of the issuer E
  • Ci or C traditional payment and withdrawal card (GAB) respectively of a recipient Ri or R associated with his current account respectively (CRi or CR) or virtual respectively (CVRi or CVR)
  • CDi or CD dual payment and withdrawal card (GAB) of a receiver respectively Ri or R associated with his current account respectively (CRi or CR) and virtual respectively (CVRi or CVR)
  • GAB payment and withdrawal card
  • CRi or CR receiver respectively Ri or R associated with his current account respectively
  • CVRi or CVR virtual respectively
  • GLOBAL LEGEND (more)
  • SD internal dedicated server of bank B (general case)
  • SD1 internal dedicated server of the bank Bl
  • SD2 internal dedicated server of bank B2
  • SIB Internal Information Server of Bank B (general case)
  • SIB1 Internal information server of Bank Bl
  • SIB2 Internal B2 Bank Information Server
  • BSD Database within the SD dedicated server dedicated exclusively to the management of the dynamic Pt ceilings of all the dual CD and classic C cards associated with the CRU
  • BSIB Central database within the SIB internal banking server managing the St balances of all the current accounts and the dynamic Pt ceilings of all the dual CD and classic C cards associated with the CRU
  • Bcc Number of the classic card Ci of a transmitter Ei or a receiver Ri respectively associated with the virtual account CVEi or CVRi with a ceiling in t of Pit
  • Ccj Number of the classic card Cj of any customer of bank B or Bl associated with his checking account with a balance in t of Sjt
  • CDk Number of the dual card CDk of a receiver Rk associated with his virtual account CVRk and current CRk with a ceiling t of PDkt with respect to CVRk and a balance SDkt with respect to CRk
  • NCj Number of current account of any customer of bank B with a balance in t of Sjt
  • NCDK Number of the current account CRk of a receiver Rk having a dual card CDk of withdrawal and payment
  • NCRU Number of the Single Reserve Account domiciled in a bank B (general case)
  • NCVE Number of the virtual account of an issuer E domiciled in a bank B (general case)
  • NCVR Number of the virtual account of a receiver R domiciled in a bank B (general case)
  • the invention proposes a new instant interpersonal mobile payment (P2P) service based on new systems and processes for electronic money transfers.
  • This service allows people to send or transfer money instantly and at any time to other people by using their mobile phones.
  • the underlying processes in question provide for and imply the use by the beneficiaries of said so-called “dual CD” or “classic” C card transfers for the payment and withdrawal of cash at ATMs (rechargeable ATMs). These beneficiaries can then withdraw the money received directly from the first (ATM) met or pay a given service through their payment cards and reloaded.
  • the invention targets all users of mobile phones type Smartphone or basic (entry-level phones) whether banked or unbanked.
  • a transfer between two bank accounts is an operation that consists of debiting a sender account for the benefit of another account called receiver or beneficiary. The latter is then credited with the amount of the transfer.
  • This transfer is considered a classic transfer.
  • the processing of a classic transfer differs depending on whether it is carried out between two EC and CR current accounts domiciled at the same bank B or in two separate banks B1 and B2.
  • a bank information system SB collects, consolidates, classifies, processes and disseminates intra-bank transfers within the same bank B.
  • An intra bank transfer is a movement of funds from one account of bank B to another account domiciled in the same bank and this by the combined use of computer, electronic and telecommunications processes.
  • the processing of the transfer operation in question puts a certain delay ⁇ ranging from 12 to 24 hours to be effective. This delay is primarily due to the time taken by the collection operation at the end of the day of all orders for daily transfers from all bank branches belonging to the same bank. Once collected, the transfer orders are processed electronically (sometimes manually) and successively the same evening by a computer processing center CTR (regional processing centers). The treatments in question then become effective only the next day. This is one of the problems that the intragrange system object of the invention attempts to solve by allowing instant interpersonal mobile banking (P2P) banking transfers.
  • P2P instant interpersonal mobile banking
  • An SB1 banking information system makes it possible to collect, group, classify and process interbank transfers within the same bank Bl before distributing them to the SIT (Interbanking Telebanking System).
  • An interbank transfer is a movement of funds from one Bl bank account to another account domiciled in a separate B2 bank through the combined use of computer, electronic and telecommunications processes.
  • the processing of the transfer operation in question puts a certain delay ⁇ ranging from 24 to 72 hours to be effective. This delay is primarily due to the time taken by the SBl during the collection operation at the end of the day of all orders for daily transfers from all bank branches of Bank Bl.
  • the Transfer orders are processed electronically (sometimes manually) and successively the same evening for processing by the SIT. The latter then takes charge of the interbank transfer and clearing operations, so that the executions of the transfers become effective one to three days later.
  • P2P interpersonal interpersonal mobile
  • an emitter E can thus pay by mutual agreement via its mobile phone a beneficiary or receiver R by transferring money from its bank account EC to the bank current account CR of the latter: it this is the model or type of interpersonal mobile money transfer (PC2PC).
  • PC2PC model or type of interpersonal mobile money transfer
  • Three other models are then identified according to the type of interpersonal mobile money transfer made by the issuer E: the model (PC2PNC) of transfer from an EC bank current account to a virtual bank account CVR, the model (PNC2PC) transfer credit a CVE virtual bank account to a bank current account CR and finally the model (PNC2PNC) transfer from a CVE virtual bank account to another CVR virtual bank account.
  • PNC2PNC transfer it simply means that it is a mobile money transfer from a "Person with No Current Account” to a "Person with No Current Account” which is equivalent to speaking in the latter case a mobile money transfer from an unbanked person to another unbanked person either: it is neither more nor less than a mobile money transfer from a virtual bank account rated CVE d an emitter E to the CVR virtual bank account of a receiver R.
  • CVE d virtual bank account rated CVE d
  • the beneficiary or receiver R (banked or not) of the transfer receives the money transferred instantly and at any time to his virtual bank account. If the latter is banked, it can use this money in real time and in whole or in part from its virtual reception account to pay directly a given service through a so-called dual dual payment and withdrawal card CD to his current account and virtual. It may also withdraw all or part of it from the virtual receipt account at the first ATM.
  • a non-banked R receiver uses a normal C normal payment and withdrawal card associated exclusively with his virtual account.
  • a bankarized or unbanked beneficiary or receiver R has the choice to go to the first (ATM) met to withdraw money that is sent to him instantly via a mobile phone or if he wants to spend this money by paying a fee. service directly with his card and reloaded by a transmitter E.
  • the invention thus allows a beneficiary R already banked to keep and use the same and only card already associated with his current account and his virtual account in order to benefit from the interpersonal mobile payment service (P2P).
  • P2P interpersonal mobile payment service
  • the embodiment of the invention then assumes and necessarily implies the use by a banked beneficiary R of a dual card CD payment and withdrawal (ATM). This card allows him to access his two bank accounts: a current bank account and a virtual account. Hence the name of this card in this memo "remotely rechargeable dual payment and withdrawal card".
  • virtual accounts are not conventional current accounts since they only allow to put money transferred instantly by.
  • a mobile phone at the disposal of banked or unbanked receivers. The latter can then proceed to its withdrawal to (ATM) or spend it by paying a service of any kind through their classic cards C or dual CD.
  • the invention further proposes that all virtual accounts domiciled in the same bank B form a system called CRU can be likened to a single reserve account.
  • This relay account also called for convenience CRU, belongs exclusively to the bank B offering the service object of the invention. It is pre-funded amounts that can be withdrawn from (ATM) or spent for service payments given.
  • ATM withdrawn from
  • This single relay account is in fact shared, thanks to the virtual accounts which are backed by it, by all the beneficiaries or receivers R of mobile money transfers.
  • the key principle of the invention is to advance if necessary and instantly to a beneficiary R the amount of money that is transferred to him on the occasion of a mobile money transfer made by an issuer E.
  • another conventional transfer order (underlying) of the same amount is automatically issued from the issuing account to the CRU account and this parallel to said mobile transfer.
  • This new order is sent to the internal banking system SB Bank B for execution to repay or compensate the CRU. The latter is then credited after the amount transferred.
  • Consequence of the role of the CRU the normal delay ⁇ processing and execution of the conventional transfer underlying the transfer intra-bank or interbank mobile is avoided and bypassed.
  • the CRU system is similar to a shared single reserve account with the same name and accessible through a multitude of dual cards or conventional users registered in the object of the invention.
  • the Pit limits of these cards relative to the CRU are specific to each card. They are continuously updated and recalculated for each card according to the amounts of money transferred via mobile phones, withdrawals made at (GAB), payments made through a (TPE) and finally maximum allowable limits for each card.
  • the overall balance of the CRU reserve account is estimated by calculating the product of the expected and estimated expected number of potential users of the service in question by the expected total expected amount of payments and withdrawals made by an average user of the service all weighted by a reducing factor equal to the Cooke ratio (8%).
  • the invention is a process innovation within the meaning of the Oslo definition since it can be interpreted as the implementation of a substantially improved instantaneous interpersonal mobile payment (P2P) method (because available at any time). and offering real-time transfers) involving significant changes in traditional mobile money transfer processes such as the introduction of the CRU Relay Account and the introduction of new processes in association with cards. dual or classic remote remotely charged payment and withdrawal.
  • P2P instantaneous interpersonal mobile payment
  • the APP version is a mobile application hosted on Smartphone-type mobile phones and designed to support the four PC2PC, PC2PNC, PNC2PC and PNC2PNC interpersonal mobile money transfer models.
  • the version based on the USSD standard allows the transmission of a client menu on GSM signal channels (for Global System for Mobile Communications) adapted to all types of mobile phones but more specifically to basic type phones.
  • GSM signal channels for Global System for Mobile Communications
  • This version is also designed to support the four PC2PC, PC2PIMC, PNC2PC and PIMC2PNC interpersonal mobile money transfer models.
  • the latter then proceeds to the instantaneous incrementation (29, 291) (in the dedicated database BSD managed by the SD) of the dynamic ceiling Pt of the card of conventional type C or dual CD of the receiver R the amount of money transferred.
  • the server SD then transmits an update order 25 of said ceiling Pt to an internal banking server SIB.
  • the latter executes this order by incrementing 22 in turn said ceiling of the same amount in its own database BSIB.
  • the dynamic ceiling Pt is thus updated at the instant t following the mobile money transfer received by the receiver R.
  • This server decrements (28, 281) in turn said ceiling of the same amount in its own dedicated database BSD.
  • the dynamic ceiling Pt is thus updated instantaneously following the consumption by the receiver R of part or all of the amount that has been transferred to him by means of the mobile phone of the transmitter E.
  • the dynamic ceiling of the conventional card C associated with the virtual CVE account of the issuer E is also decremented (20, 24, 28) in turn and instantly but the information afferente emanates first from the SD via the BSD and is then processed at the SIB via the BSIB according to a reverse decrementation process.
  • the issuer E in this case has the choice to make the bank transfer classic type PC2PC from its bank bank account CE to the current bank account CR or instantaneously to the virtual account CVR / CRU receiver R. These two accounts are domiciled in the same bank as that of the issuer E or in another separate bank receiving B.
  • the method CRU / PC2PC-CVR thus allows the issuer E to make a non-instantaneous mobile money order transfer from its current account CE to the current account CR of the receiver R: it is just a transfer order conventional 32 addressed to the internal banking server SIB of the issuing bank for processing (via a remote server SIT if the transfer is interbank). It then becomes effective only after a delay ⁇ 'ranging from 12H to 72H.
  • the beneficiary R can therefore pay in real time a given service with his card or withdraw his money at the (GAB) closest if necessary (if the withdrawal is interbank) to a remote server SRI.
  • an underlying standard transfer order (31) is sent to the SIB with an amount Mi from the CE to the CRU (via the remote server SIT if the transfer is interbank): it is simply a question of an operation of compensation of the amount Mi at the CRU. The latter is then credited only after a certain time ⁇ .
  • the latter account is domiciled in the same bank as that of the issuer E or in another separate bank receiving B.
  • the dynamic ceiling of the conventional card R receiver vis-à-vis the CVR / CRU varies and changes continuously according to incoming instantaneous mobile money orders transfers (29, 25, 22), card payments as well as withdrawals (20, 24, 28) to (ATMs) from the CRU.
  • the issuer E in this case has the choice to make the bank transfer in CVE virtual bank account to CRI bank current account or CVR1 / CRU virtual bank account of beneficiary R. These two accounts are domiciled in the same bank B as that of issuer E.
  • Beneficiary R can therefore pay a given service with his card at this moment or withdraw his money at the nearest (GAB) thanks to the SRI if necessary.
  • the ceiling of the dual card CD of the receiver R vis-à-vis the CVR1 / CRU varies and changes continuously according to the new instantaneous mobile money orders received (291, 25, 22), card payments as well as withdrawals (20, 24, 281) to (ATMs) from the CRU.
  • the beneficiary R can therefore pay a given service with his card at this moment or withdraw his money at the nearest (GAB) thanks to the role, if any, of the SRI.
  • the emitter E in this case has the choice to perform the bank transfer in question from his virtual bank account CVE domiciled in a bank B1 to the current bank account CR2 or to the virtual account CVR2 of the receiver R both domiciled in a separate bank B2.
  • the beneficiary R can therefore pay a given service with his dual card at that moment or withdraw his money at the nearest (GAB) thanks, if necessary, to the SRI.
  • the dynamic ceiling of the conventional card issuer E is automatically decreased (28, 25, 21) T of the amount Mi compared to CVE / CRU (domiciled in the bank Bl).
  • a conventional transfer order (underlying 71) from the CRU to the CRUR of an amount Mi is sent to the SIB1 (with the subsequent participation of the remote server SIT) for reimbursement.
  • the dynamic ceiling of the dual receiver card R vis-à-vis the CVR2 / CRUR varies and changes continuously according to incoming instantaneous mobile money orders received (291, 25, 22), payments by card as well as withdrawals (20, 24, 281) to (ATMs) from the CRUR.
  • an underlying standard transfer order 81 is sent to SIB1 (with the assistance of the remote SIT) for the reimbursement of the amount Mi of the CRU (domiciled in the bank Bl) to the CRUR (domiciled in the bank B2).
  • the dynamic ceiling of the conventional card of the receiver R is increased (29, 25, 22) by the transferred amount Mi and this with respect to the CVR2 / CRUR.
  • the beneficiary R can therefore from his CVR2 account pay a given service with his conventional card at this moment or withdraw his money at the nearest (GAB) thanks to the SRI if necessary.
  • This method enables a banked R receiver banked instantaneous interpersonal mobile money transfer (P2P) having a current account CR and virtual CVR in a bank B to have a single card CD dual dual payment and withdrawal to (GAB) associated with said current and virtual accounts, the latter being backed by the CRU.
  • P2P banked R receiver banked instantaneous interpersonal mobile money transfer
  • the receiver R uses the unique password associated with his dual CD card to one (GAB) or on one (TPE) to access the choice to one of his two accounts.
  • the request for an interbank withdrawal 90 of an amount of money by the receiver R to a (ABM) or his request for payment of a given service by means of a (TPE) 91 is always transmitted in both cases directly to an external server SRI which transmits VPN 93 (Virtual Private Network) for verification to an internal banking server SIB belonging to the bank B.
  • Said request is directly transmitted to the server internal bank SIB belonging to the bank B if the withdrawal of an amount of money to a (GAB) by the receiver R from one of its two accounts CR or CVR is intra-bank 92.
  • the internal banking server SIB receives said request once transmitted and accepted after an identity check, then returns a single interface to (GAB) or on (TPE) via the external server SRI (93, 94) or directly 95 if the order emanates from a request for withdrawal intra-bank thus allowing the receiver R to access the choice to one of his accounts current CR or virtual CVR domiciled at the same bank B.
  • the receiver R From this interface unique to (GAB) or on a (TPE), the receiver R then has the choice to withdraw an amount of money or pay a service by debiting his current account CR or withdrawing the amount M which it is instantly transferred or to spend it by paying a service but by this time directly debiting the CVR / CRU account (debit transaction of the CRU account).
  • the order relating to this choice is then transmitted either to the external server SRI which in turn sends it back to the internal banking server SIB (94, 93) for processing in the case of an interbank withdrawal or a payment by (TPE) in a given point of sale is directly 95 to the internal banking server SIB in the case of an intra-bank withdrawal.
  • the internal banking server SIB debits the account chosen (CR or CRU) by the user R, if applicable, of the amount M (transferred instantly) if the latter chooses to use his CVR virtual account.
  • the internal banking server SIB updates the dynamic ceiling Put of the dual card CD of the receiver R (in the central database BSIB) by decreasing it 23 of the amount M and sends an update order (24, 96 ) by VPN connection to the dedicated server SD which in turn proceeds to the decrementation 281 (in its dedicated database BSD) of the dynamic ceiling level Pot of said dual card of the same amount and this compared to the single reserve account CRU domiciled at bank B.
  • the receiver R chooses to use his current account CR, it is debited by the internal banking server SIB the amount of money spent without reporting to the dedicated server SD.
  • the latter is dedicated (among other functions) to the management of Pit dynamic ceilings of CVRi or CVEi accounts (contained in its BSD database) and not to the management of CRi current account balances. .
  • the internal server SIB transmits an order (93, 94, 95) for the delivery of cash tickets to the (GAB) quencher equivalent to the amount M fired instantly. It also transmits a standard transfer order from the CVR to the point-of-sale credit account if the R-payee pays for a given service by means of his dual-card and one (TPE) card.
  • a classic intra-bank transfer from one bank account to another bank account opened with the same bank B is managed by the bank's bank.
  • intermediate clearing transactions are first carried out: these transactions are managed by means of a SIT (Interbanking system of Tele-compensation). .
  • PC2PC-type mobile transfers do not have a CVR component and are therefore not instantaneous since they are only simple orders for mobile phone transfers that these banks execute with a ⁇ delay.
  • PC2PNC mobile transfers are virtually instantaneous. The fact remains, however, that their beneficiaries do not have withdrawal cards and can only withdraw money sent to them via a mobile phone or by moving to specific withdrawal points at a specific (ATM) location. by addressing an agent with all the related disadvantages. They can not pay a service instantly using a payment card and a (TPE) in a point of sale with the money sent to them via the mobile of an emitter E.
  • TPE payment card and a
  • the invention proposes to create, as has been described above, a system noted CRU of virtual accounts assimilated to a single special bank account named CRU single reserve account within a given bank B and offering the service underlying the invention.
  • this relay account instantly makes available to a receiver R the money that is transferred to him by a transmitter E via a mobile phone. The latter can then withdraw the money from (GAB) or spend it directly by paying a given service through its dual card CD or classic C and a (TPE).
  • All beneficiaries Ri instantaneous mobile money transfers (P2P) domiciled in the same bank B have virtual accounts (CVRi, Pit) forming a CRU noted system that can be likened to a single relay account called CRU single reserve account. This account can be accessed by a multitude of dual CDi cards or classic payment and withdrawal cards belonging to the beneficiaries Ri.
  • the CRU system is thus treated as a multicard account allowing each beneficiary Ri to withdraw money that is transferred to him in real time or to pay (on receiving his money in real time) a given service by means of his card.
  • dual or classic associated with his virtual account (CVRi, Pit) The Pit dynamic cap of the latter changes instantly based on mobile money transfers, withdrawals made at (GAB) and finally payments made by means of a (TPE) but never exceed its maximum authorized ceiling.
  • the management of the dynamic ceilings Pt (compared to the single reserve account RAW) of conventional cards C or dual CD withdrawal and payment users of the service object of the invention is provided largely by management programs bases of BSD and BSIB data hosted respectively in the SD and SIB servers. These two databases interact with each other (24, 25) by managing the real-time variations of so-called dynamic ceilings of said cards during each mobile money transfer operation for the benefit of their owners or on the occasion of withdrawal or withdrawal. payment made by them.
  • the dynamic ceiling of the conventional card C associated with the virtual account CVE of the emitter E is decremented (28, 25, 21) in turn in real time but this time the order in question first passes through the BSD of the SD before being processed by the BSIB of the SIB.
  • Figure 3A (Sheet 3/15): Method CRU / PC2PC-CVR
  • the banked issuer E issues at time T an intra-bank or interbank mobile transfer of an amount Mi to the banked receiver R via a USSD service or the mobile application installed on its smartphone-type mobile phone.
  • the issuer E has the choice of making the bank transfer in question from its bank bank account CE to the bank current account CR or to the virtual account CVR / CRU of the receiver R, the latter two being domiciled in the same bank or that of the issuer or another separate receiving bank B.
  • the issuer E of the transfer order in question chooses to make a transfer to the CVR virtual account of the receiver R (on the latter's request, for example) then the dynamic ceiling Pt of the dual card CD of the latter is increased instantaneously (291, 25, 22) in T of the amount Mi transferred relative to the CVR / CRU virtual account.
  • the beneficiary R can therefore from this account pay a given service with his card at this moment or withdraw his money at the nearest (GAB) (thanks to the external server SRI if the withdrawal is interbank).
  • an underlying conventional transfer order 31 is sent to the SIB of the amount Mi from the CE to the CRU (by means of the external server SIT there also if the transfer is interbank): it is simply a matter of an operation of compensation of the amount Mi at the CRU. The latter is then credited with this amount only after a certain delay ⁇ .
  • the issuer E discloses at time T an intra bank or interbank mobile transfer of an amount Mi to the receiver R via a USSD service or the mobile application installed on his mobile phone.
  • the issuer E makes the bank transfer in question from its EC bank current account to the CVR / CRU virtual account of the unbuffered receiver R.
  • the latter account is domiciled in the same bank as that of the issuer E or in another separate bank receiving B.
  • the dynamic ceiling Pt with respect to the virtual CVR / CRU account of the conventional card C of the receiver R is increased instantaneously (29, 25, 22) in T of the amount Mi transferred.
  • the beneficiary R can therefore from this account pay a given service with his card at this moment or withdraw his money at the nearest (GAB) (thanks to the external server SRI if the withdrawal is interbank).
  • GAB nearest
  • an underlying conventional transfer order 41 is sent to the SIB of the bank issuing the amount Mi from the CE to the CRU (via the external server SIT also if the transfer is interbank).
  • there simply an operation of compensation of the amount Mi at the CRU is then credited with this amount only after a certain delay ⁇ .
  • the ceiling of the conventional card of the receiver R vis-à-vis the CVR / CRU varies and changes continuously according to the new instantaneous transfers received Mj (29, 25, 22), card payments as well as withdrawals (20, 24, 28) by the receiver R to (GAB) from the CRU but without ever exceeding its maximum authorized limit for mobile money transfers.
  • Figure 5A (Sheet 5/15): CRU / PNC2PC-CVR Method
  • the non-banked issuer E emits at time T an intra-bank mobile transfer of an amount Mi to the banked receiver R via a USSD service or the mobile application installed on his mobile phone.
  • the issuer E has the choice of making the bank transfer in question from its virtual bank account CVE to the bank current account CRI or to the virtual account CVR1 / CRU of the receiver R, the latter two being domiciled in the same bank B than that of the issuer E.
  • the emitter E of the transfer order in question chooses to transfer to the current account CRI of the receiver R then the dynamic ceiling of the conventional card C of the transmitter E is automatically decreased (28, 25, 21) by T of the amount Mi compared to the virtual account CVE / CRU in this case. It then follows a conventional transfer 52 not instantaneous directly from the CRU account to the CRI account addressed to the SIB Bank B for processing. It then becomes effective only after a delay ⁇ 'ranging from 12H to 48H.
  • the issuer E of the transfer order in question chooses to make a transfer to the virtual account CVR1 of the receiver R (on the latter's request, for example) then the ceiling Pt dynamic of the dual card CD of the latter is increased instantly (291, 25, 22) T of the amount Mi transferred compared to the virtual account CVRl / CRU in this case.
  • the beneficiary R can therefore from this account pay a given service with his card at this moment or withdraw his money at the nearest (GAB) (thanks to the external server SRI if the withdrawal is interbank).
  • the dynamic ceiling of the conventional card of the issuer E is automatically decreased in T of the amount Mi compared to the CVE / CRU: it is simply a game of compensation of the amount Mi between the accounts CVE / CRU and CVRl / CRU, both backed by CRU.
  • the dynamic ceiling Pt of the dual card of the receiver R vis-à-vis the CVRl / CRU varies and changes continuously (without ever exceeding the maximum amount allowed) according to the new instant transfers received Mj (291, 25, 22), card payments as well as withdrawals (20, 24, 281) by the receiver R to (ABMs) from the CRU.
  • Figure 6A (Sheet 6/15): Process CRU / PNC2PNC
  • the unbanked transmitter E emits at time T an intra-bank mobile transfer of an amount Mi to the unbuffered receiver R via a USSD service or the mobile application installed on his mobile phone.
  • the issuer E makes the bank transfer in question from its virtual bank account CVE to the virtual account CVR1 of the receiver R domiciled in the same bank as that of the issuer E.
  • the dynamic ceiling of the conventional card C of the transmitter E is automatically decreased (28, 25, 21) T of the amount Mi compared to the virtual account CVE / CRU. It then follows a game of compensation of the amount Mi within the CRU since at the same time the dynamic ceiling Pt of the conventional card R receiver is increased (29, 25, 22) amount Mi transferred and compared at CVRl / CRU.
  • the beneficiary R can therefore from this account pay a given service with his card at this moment or withdraw his money to the nearest (GAB) thanks if necessary to external server SRI.
  • the ceiling Pt of the conventional card of the receiver R vis-à-vis the CVRl / CRU varies and changes continuously without ever exceeding the maximum authorized amount of mobile money transfers and this according to the new instantaneous transfers received Mj (29, 25, 22), card payments and withdrawals (20, 24, 28) to (ATMs) from the CRU.
  • Figure 7A (Sheet 7/15): Method CRU / PNC2PC-CVR / BD
  • the unbanked transmitter E emits at time T an interbank mobile transfer of an amount Mi to the banked receiver R via a USSD service or the mobile application installed on its mobile phone.
  • the issuer E has the choice of making the bank transfer in question from its virtual bank account CVE domiciled in a bank B1 to the current bank account CR2 or to the virtual account CVR2 of the receiver R both domiciled in another B2 bank separate from Bl.
  • the emitter E of the transfer order in question chooses to transfer to the current account CR2 of the receiver R then the dynamic ceiling of the conventional card of the issuer E is automatically decreased (28, 25, 21) by T of the amount Mi compared to the CVE / CRU virtual account. It then follows a non-instantaneous classic transfer order 72 directly from the CRU account domiciled at the bank B1 to the account CR2 addressed to the SIB1 of the bank B1 for processing. The order in question then becomes effective only after a delay ⁇ 'ranging from 12H to 72H.
  • the issuer E of the transfer order in question chooses to make a transfer to the CVR2 virtual account of the receiver R (on the latter's request, for example) then the dynamic ceiling Pt of the dual card CD of the latter with respect to the CVR2 / CRUR (domiciled in bank B2) is increased instantaneously (291, 25, 22) in T of the amount Mi transferred.
  • the beneficiary R can therefore from his CVR2 / CRUR account pay a given service with his card at this moment or withdraw his money at the nearest ATM and thanks to the external SRI server if necessary.
  • the dynamic ceiling of the conventional card E is automatically decreased in T of the amount Mi compared to the CVE / CRU (domiciled in the bank Bl).
  • an order for the underlying conventional transfer payment 71 is finally sent to the SIBI with the assistance of the external server SIT of an amount Mi to be made from the CRU to the CRUR, the latter being domiciled at the bank B2.
  • the dynamic ceiling Pt of the dual card of the receiver R vis-à-vis the CVR2 / CRUR varies and changes continuously without ever exceeding the maximum ceiling authorized mobile money transfers and this according to the new instantaneous transfers received Mj (291, 25, 22), card payments as well as withdrawals (20, 24, 281) to (ATMs) from the CRUR.
  • Figure 8A (Sheet 8/15): Method CRU / PNC2PIMC / BD
  • the unbanked transmitter E emits at time T an interbank mobile transfer of an amount Mi to the unranked receiver R via a USSD service or the mobile application installed on his mobile phone.
  • the issuer E in this case makes the bank transfer in question from his CVE virtual bank account domiciled in a bank Bl to the CVR2 virtual account of the receiver R domiciled in a different bank B2.
  • the dynamic ceiling of the conventional card of the transmitter E is automatically decremented (28, 25, 21) in T of the amount Mi compared to the virtual account CVE / CRU. It then follows an order of transfer classic underlying 81 sent to the SIBl with the assistance of the external server SIT of an amount Mi from the CRU to the CRUR domiciled respectively to the bank Bl and B2.
  • the dynamic ceiling Pt of the conventional card C of the receiver R is incremented (29, 25, 22) by the amount Mi transferred relative to the virtual account CVR2 / CRUR.
  • the beneficiary R can therefore from this latter account pay a given service with his classic card at this moment or withdraw his money to the nearest (GAB) and this thanks to the external server SRI if necessary.
  • the dynamic ceiling Pt of the conventional card R receiver vis-à-vis the CVR2 / CRUR varies and changes continuously according to the new instantaneous transfers received Mj (29, 25, 22) , card payments as well as withdrawals (20, 24, 28) to (ATMs) from the CRUR but without ever exceeding the maximum authorized amount of mobile money transfers.
  • FIG. 9A (Sheet 9/15): CD DUAL CARD Process
  • GAB dual CD payment and withdrawal
  • FIG. 1B Intra banking system: Case (PC2PC-CVR)
  • the bank bank B client E issuer can transmit at any time an intra-bank mobile transfer of an amount M to the banked payee R via a USSD service (via an SU server via channels GSM signals 102) or an application installed on its mobile phone TE via a secure web connection VPN 101 to a central server SC.
  • the mobile transfer order in question is then recorded by the external server SC.
  • the latter transmits the information via a VPN connection 113 to an internal SD dedicated server integrated in the SB of the bank B.
  • the SD server then orders the internal server of the bank SIB 105 to proceed with the mobile transfer (optionally receiver R) of the E bank bank account of the issuer E to the bank CRI or virtual bank account CVR1 (backed by the CRU) of the receiver R.
  • the mobile transfer 32 is processed by the SIB and executed at the end a normal delay ⁇ .
  • said mobile transfer is instantaneous since it is the simultaneous result of the instantaneous increase of an amount M made (in its own database BSD 291) by the dedicated server SD on the dynamic ceiling Pt of the CVR1 associated dual CD card and underlying conventional transfer order 31 executed by the CE SIB to the CRU.
  • the central database BSIB managed by the SIB is then notified by the SD (25, 107) of the new amount of the ceiling 27 of the dual card CD associated with the CVR1 account of the receiver R.
  • the (GAB) and the (TPE) are then notified by the SIB (109, 110) of this new amount when they are used by the receiver R.
  • an expense order (109, 110) is received (via the SRI if applicable) in the first place and instantly by the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrement 23 (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the dual card CD of the receiver R of the amount of money transferred.
  • the SIB transmits to the server SD an update order (24, 107) of said ceiling Pt that in turn decrements 281 of the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantly following the consumption by the receiver R of part or all of the amount transferred by means of the mobile phone TE of the transmitter E.
  • the server SIB transmits a confirmation of the execution of said transfer (via the server SD 106) to the server SC 103 which transmits it to a server SM by means of a signaling channel 104 (GSM standard).
  • GSM signaling channel 104
  • the emitter E and the beneficiary R then receive in a few seconds a SMS (Short Message Service) confirmation (made through the SM mail server) on their mobile phones (TE and TR) the success of the transfer in question.
  • SMS Short Message Service
  • the receiver R finally has the choice to pay 108 directly from the CVR1 backed up to the CRU a given service by using its dual card CD by means of a (TPE) (with the help of the external server SRI) or to remove 108 the sum M or a portion dm of this sum to the first ATM (ATM) met and this thanks to the role of the external server SRI where appropriate.
  • FIG. 2B Intra banking system: Case (PC2PNC)
  • Bank B customer banked E issuer issues an intra-bank mobile transfer of M amount to unranked R receiver via a USSD service (via the SU server and via GSM signal channels 112) or an application installed on its mobile phone TE via a secure web connection (VPN) 111 to the central server SC at first.
  • a USSD service via the SU server and via GSM signal channels 112
  • an application installed on its mobile phone TE via a secure web connection (VPN) 111 to the central server SC at first.
  • VPN secure web connection
  • the order of instantaneous mobile transfer in question is recorded by the external server SC.
  • the latter transmits the information via a VPN connection 113 to an internal SD dedicated server integrated in the SB of the bank B.
  • the SD server then orders the SIB 115 to make a conventional transfer underlying 41 of the current account.
  • EC bank of the issuer E to the virtual account CVR1 (backed by the CRU) of the receiver R.
  • said mobile transfer is instantaneous since it is the simultaneous result of the instantaneous incrementation of an amount M made by the dedicated server SD (in its own BSD database 29) on the dynamic ceiling Pt of the conventional card C associated with the CVR1 and the underlying conventional transfer order executed by the SIB from the CE to the CRU.
  • the central database BSIB managed by the SIB is then notified by the SD (25, 117) of the new amount of the ceiling of the conventional card C associated with the CVR1 account of the receiver R.
  • the (GAB) and the (TPE) are then notified in their turn by the SIB (119, 120) of this new amount when they are used by the recipient R.
  • an expense order (119, 120) is received (via the SRI if applicable) in the first place and instantly by the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrementation 20 (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the conventional card C of the receiver R of the amount of money transferred.
  • the SIB then transmits to the server SD an update order (24, 117) of said ceiling Pt that it decrements in turn 28 of the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantly following the consumption by the receiver R of part or all of the amount transferred by means of the mobile phone TE of the transmitter E.
  • the server SIB transmits a confirmation of the execution of said transfer (via the server SD 116) to the server SC 113 which transmits it to a server SM by means of a signaling channel 114 (GSM standard).
  • the emitter E and the beneficiary R then receive in a few seconds a confirmation SMS (made via the mail server SM) on their mobile phones (TE and TR) of the success of the transfer in question.
  • the receiver R can therefore by using his conventional card C associated with his CVR1 virtual account backed by the CRU pay 118 directly a given service by means of a (TPE) (thanks to the intervention at this level of the external server SRI ) or withdraw 118 the sum M transferred instantaneously or a part dm of this sum (thanks to the role possibly of the external server SRI) to the first ATM (ATM) met.
  • TPE transport-layer
  • ATM first ATM
  • FIG. 3B Intra banking system: Case (PNC2PC-CVR)
  • the unbanked transmitter E in a bank B initially transmits an intra-bank mobile transfer of an amount M to the banked receiver R via a USSD service (via the server SU and via signal channels GSM 122) or an application installed on its mobile phone TE via a secure web connection (VPN) 121 to the central server SC.
  • a USSD service via the server SU and via signal channels GSM 122
  • GSM 122 signal channels
  • GSM 122 secure web connection
  • the mobile transfer order in question is recorded by the external server SC.
  • the latter transmits the information via a VPN connection 123 to an internal SD dedicated server integrated in the SB of the bank B.
  • the SD server instructs the SIB 126 to make the conventional transfer underlying the CVE virtual bank account of the issuer E to the current bank account CRI of the receiver R.
  • the transfer order is equivalent to a conventional transfer 52 between the CRU and the CRI: it is then processed by the SIB and executed after a normal delay ⁇ .
  • the issuer E opts for a transfer in real time to the virtual account of the receiver R on request thereof for example, said transfer is then instantaneous since it is the simultaneous result of the instantaneous increase of an amount M performed by the dedicated server SD (via the BSD database 291) on the dynamic ceiling Pt of the dual card CD associated with the CVR1 and the decrementation 28 of the dynamic ceiling of the conventional card associated with the CVE of the same amount.
  • the central BSIB database managed by the SIB is then notified by the SD (25, 27, 21, 125, 127) of the new amounts of the ceilings of said cards associated with the CVE and CVR1 accounts respectively of the issuer E and the receiver R.
  • the (GAB) and the (TPE) are then notified to their by the SIB (129, 130) of these new amounts at the time of their use by the issuer E or the receiver R.
  • an expense order (129, 130) is received (via the SRI if applicable) in the first place and instantly by the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrement 23 (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the dual card CD of the receiver R of the amount of money transferred.
  • the SIB transmits to the server SD an update order (24, 127) of said ceiling Pt that it in turn decrements 281 of the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantly following the consumption by the receiver R of part or all of the amount transferred by means of the mobile phone TE of the transmitter E.
  • the dynamic ceiling of the conventional card C associated with the virtual account CVE of the emitter E is decremented in turn 28 instantaneously but the information related thereto emanates first the SD via the BSD (25, 125) to be processed at the SIB via the BSIB following a reverse decrement process.
  • the server SIB transmits a confirmation of the execution of the transfer (via the server SD 126) to the server SC 123 which transmits it to a server SM by means of a signaling channel 124 (GSM standard).
  • the emitter E and the beneficiary R then receive in a few seconds a confirmation SMS (made via the mail server SM) on their mobile phones (TE and TR) of the success of the transfer in question.
  • the receiver R has the choice to pay 128 directly from the CVRl backed up to the CRU a given service by means of a (TPE) (thanks to the intervention at this level of the external server SRI) using its dual card CD of payment and withdrawal or to withdraw 128 the transfer sum M or a part dm of this sum (thanks to the role, if applicable, of the external server SRI) to the first automatic teller machine (ATM) encountered.
  • TPE automatic teller machine
  • FIG. 4B Intra banking system: Case (PNC2PNC)
  • the unbanked issuer E of a bank B issues an intra-bank mobile transfer of an amount M to the unbilled bank receiver R via a USSD service (via the SU and via GSM signal channels 132). or an application installed on his mobile phone TE of the Smartphone type via a secure web connection (VPN) 131 to the central server SC at first.
  • the bank transfer order in question is recorded by the external server SC.
  • the latter transmits the information via a VPN connection 133 to an internal SD dedicated server integrated in the SB of the bank B.
  • the transfer is instantaneous since it is the simultaneous result of the instantaneous incrementation.
  • the SIB server is then notified by the SD (25, 135, 137) of the new amounts of the ceilings of said cards associated with the CVE and CVR1 accounts respectively of the issuer E and the receiver R.
  • the (GAB) and the (TPE) are then notified in their turn by the SIB (139, 140) of these new amounts at the time of their use by the issuer E or the receiver R.
  • an expense order (139, 140) is received (via the SRI if applicable) in the first place and instantly by the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrementation (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the conventional card C of the receiver R of the amount of money transferred.
  • the SIB transmits to the server SD an update order (24, 137) of said ceiling Pt that it decrements in turn 28 of the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantly following the consumption by the receiver R of part or all of the amount transferred by means of the mobile phone TE of the transmitter E.
  • the server SIB transmits a confirmation of the execution of said transfer (via the server SD 136) to the server SC 133 which transmits it to a server SM by means of a signaling channel 134 (GSM standard).
  • GSM standard a signaling channel 134
  • the emitter E and the beneficiary R then receive in a few seconds a confirmation SMS (made via the mail server SM) on their mobile phones (TE and TR) of the success of the transfer in question.
  • the receiver R can use his conventional card C associated with his CVR1 virtual account backed by the CRU to pay directly 138 a given service by means of a (TPE) (thanks to the intervention at this level of the external server SRI) or withdraw 138 the amount transferred M or a part dm of this sum to the first ATM (met) (thanks to the role, if any, of the external server SRI).
  • TPE transport-layer transfer protocol
  • metal thanks to the role, if any, of the external server SRI
  • Figure 5B (Sheet 14/15): Integrated intra-bank system
  • the issuer E domiciled in a bank B issues an intra-bank mobile transfer of an amount M to the receiver or beneficiary R domiciled in the same bank via a USSD service (thanks to the role of the SU via GSM signals 142) or an application installed on its mobile phone TE via a secure internet network (VPN) 141 to the central server SC.
  • a USSD service thanks to the role of the SU via GSM signals 142
  • an application installed on its mobile phone TE via a secure internet network (VPN) 141 to the central server SC.
  • VPN secure internet network
  • the internal dedicated SD server in the internal system SB of the bank B transmits the mobile transfer order issued for execution (144, 145) to the internal banking server SIB according to the models of interpersonal mobile money transfers (PC2PC), (PC2PNC), ( PNC2PC) or (PNC2PNC).
  • the SIB then proceeds to the traditional intra-bank transfer (31, 32, 41, 52, 71, 72, 81, 145) between the accounts object of said transfer (except for the case of a transfer type (PNC2PNC)). This transfer is then executed after a certain time noted ⁇ .
  • the integrated intra-bank system will allow in all cases transfers already mentioned (except for the case of a non-instant transfer type (PC2PC)), the internal server SD domiciled in the bank B to proceed in real time the increase in its own database BSD (29, 291) of the dynamic ceiling Pt of the classic card C or dual CD beneficiary R compared to the single reserve account CRU (domiciled in the bank B). It then follows from the server SD an update command (25, 146) of said ceiling Pt addressed to the server SIB. The latter executes this order by incrementing (22, 27) said ceiling of the same amount in its own central database BSIB. The dynamic ceiling Pt is thus updated following the mobile money transfer received by the receiver R. It follows that the amount M transferred is thus made instantly available to the receiver R for withdrawal to (ATM) or for payment of a service given through a (TPE).
  • PC2PC non-instant transfer type
  • an expense order (148, 149) is received (via the SRI if applicable) in the first place and instantly by the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrementation (20, 23) (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the card of conventional type C or dual CD of the receiver R of the amount of money transferred.
  • the SIB transmits to the server SD an update order (24, 146) of said ceiling Pt that it decrements in turn the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantaneously following the consumption by the receiver R of part or all of the amount that was transferred to him by means of the mobile phone TE of the transmitter E.
  • the dynamic ceiling of the conventional card C associated with the virtual account CVE of the emitter E is decremented in turn 28 instantaneously but the information therefrom emanates from First, the SD via the BSD 144 is then processed at the SIB via the BSIB (25, 21) following an inverse decrementation process.
  • the server SIB transmits a confirmation of the execution of said transfer to the server SD 145 which transmits it to a server SM by means of a signaling channel 143 (GSM standard).
  • the emitter E and the beneficiary R then receive in a few seconds a confirmation SMS. (done through the SM mail server) on their mobile phones (TE and TR) the success of the transfer in question.
  • the beneficiary R has the choice of immediately withdrawing the amount M or part dm from this amount at any time at the nearest (GAB) (with the assistance of the external server SRI if the withdrawal is interbank) or pay 147 through a (TPE) (with the help of the SRI external server) a given service with its dual card CD or classic C associated as appropriate to its current account CRI and / or virtual CVR1 backed by made to the CRU.
  • GAB nearest
  • TPE with the help of the SRI external server
  • FIG. 6B (Sheet 15/15): Global Interbank System
  • the issuer E domiciled in a bank B1 issues an inter-bank mobile transfer of an amount M to the receiver or beneficiary R domiciled in another B2 bank via a USSD service (thanks to the role of the SU via GSM signals 152) or an application installed on its mobile phone TE via a secure web connection (VPN) 151 to the central server SC.
  • a USSD service thanks to the role of the SU via GSM signals 152
  • an application installed on its mobile phone TE via a secure web connection (VPN) 151 to the central server SC.
  • VPN secure web connection
  • the issuer E with its own CE bank account or a virtual bank-based CVE account domiciled in the Bl bank transfers money via its mobile phone TE to the beneficiary R with a current account own CR2 or a CVR2 virtual account backed by the CRUR and domiciled in B2 bank.
  • the central server SC external to the internal systems SB1 and SB2 (respectively of the issuing bank B1 and the receiving bank B2) transmits via VPN connection 153 the mobile transfer order issued to a dedicated server SD1 integrated internally to the SB1.
  • the server SD1 transmits an order 157 of the underlying conventional transfer (31, 41, 71, 81) for execution at SIB1 according to the interpersonal mobile money transfer (PC2PC), (PC2PNC), (PNC2PC) or (PNC2PNC) models.
  • the SIB1 then proceeds to the conventional interbank transfer between the two separate banks B1 and B2 and more precisely between the accounts object of said transfer. This transfer is then executed by the SIT (Interbanking System Tele-compensation) after a certain period noted ⁇ .
  • SIT Interbanking System Tele-compensation
  • the global interbank system will allow in all cases of transfers already mentioned (except for the case of a non-instantaneous transfer of type (PC2PC)), that the information is transmitted directly 154 and instantly by VPN connection of the server external central SC to the dedicated server SD2 domiciled in the bank B2.
  • the latter then proceeds in real time in his own BSD2 database to the incrementation (29, 291) of an amount M of the dynamic limits Pt of the classic cards C or dual CDs of the beneficiary R with respect to the single reserve account CRUR (domiciled in B2 bank).
  • the internal server SIB2 domiciled in the bank B2 is then notified by the SD2 (25, 159) of the new amount of the ceiling of the CVR2 account of the receiver R.
  • the SIB2 increments (22, 27) in turn said ceiling of the same amount in its own central database BSIB2.
  • the amount M transferred is thus instantly put at the disposal of the receiver R for withdrawal (ATM) or for payment of a given service by means of a (TPE).
  • (GAB) and (TPE) are in turn notified by SIB2 (162, 163) of this new amount at the time of their use by recipient R.
  • an order of expenditure (162, 163) is received (via the SRI if necessary) in the first place and instantly by the internal banking server SIB2.
  • the latter then proceeds to the instantaneous decrementation (20, 23) (in the central database BSIB2 managed by the SIB2) of the dynamic ceiling Pt of the card of the conventional type C or dual CD of the receiver R of the amount of money transferred.
  • the SIB2 transmits to the server SD2 an update order (24, 159) of said ceiling Pt which in turn decrements (28, 281) by the same amount in its own database BSD2.
  • the dynamic ceiling Pt is thus updated instantaneously following the consumption by the receiver R of part or all of the amount that was transferred to him by means of the mobile phone TE of the transmitter E.
  • the dynamic ceiling of the conventional card C associated with the virtual account CVE of the emitter E is decremented 28 in turn instantaneously but the information related thereto emanates from First, SD1 via BSD1 (25, 156) to be processed at SIB1 via BSIB1 following a reverse decrement process.
  • the server SIB2 transmits a confirmation of the execution of said transfer (via the SD2 server 158) to the SC server 154 which transmits it to a server SM by means of a signaling channel 155 (GSM standard).
  • the emitter E and the beneficiary R then receive in a few seconds a confirmation SMS (made via the mail server SM) on their mobile phones (TE and TR) of the success of the transfer in question.
  • the beneficiary R has the choice of immediately withdrawing the amount M or part dM of this amount at any time at the nearest (GAB) (with the assistance of the external server SRI if the withdrawal is interbank) or to pay 160 via a (TPE) (with the help of the external SRI server) a given service with its dual card CD or classic C associated as the case with its current account CR2 and / or virtual CVR2 backed by made to the CRUR.
  • GAB nearest
  • TPE with the help of the external SRI server
  • an external remote interactive server SU intended for users of basic telephones and providing a USSD service for transmitting data via GSM signal channels and offering a client interface dedicated to transactional exchanges induced by mobile money transfers
  • a central server SC conductor of all the data exchanges between servers and systems by VPN or GSM links mainly and especially between the servers SU, SM, SD and the internal banking system SB
  • An SM server which provides the messaging and notification service of the users of the service object of the invention
  • ATM automated teller machine
  • each bank has its own dedicated SD and internal SIB server as well as its own unique CRU reserve account.
  • Bl and B2 the two separate banks are denoted by Bl and B2 and their dedicated and internal servers and their reserve accounts are respectively (SD1, SIB1, CRU) and (SD2, SIB2, CRUR).
  • the instant interpersonal mobile payment service (P2P) object of the invention relies on the use by the transmitter E and the receiver R of mobile phones of all types (smartphones or basic).
  • the interactive remote server SU The interactive remote server SU:
  • the remote server SU makes it possible to cover in the USSD version all of the user's interactions of a basic type of mobile telephone with the instantaneous interpersonal mobile payment service (P2P) which is the subject of the invention.
  • P2P instantaneous interpersonal mobile payment service
  • This external server at the B Bank SIB is managed by an external service provider. Thanks to this version, this last one has the possibility to:
  • the mobile application for Smartphone makes it possible to cover all of the user's interactions with the service object of the invention by enabling the following functionalities:
  • the mobile application can exist on different platforms. Most of the application is developed on a multiplatform generation tool such as Phone Gap which greatly facilitates an extension of the business logic of the application without redeveloping it on other platforms. Nevertheless, it is the technical process of the invention that makes it possible to know whether to develop everything natively or not. It is nevertheless necessary to create plugins to develop in native code for security aspects, such as certificate management.
  • the central server SC The central server SC:
  • the central server SD is the conductor of all the exchanges between servers and systems among others the servers SU, S, SD1, SD2 and the internal banking systems SIB1 and SIB2 in the case of two partner banks of the service object of the invention. More specifically, it makes it possible to cover all the interactions initiated by the users of said service by offering the possibility of:
  • the internal banking server SIB The internal banking server SIB
  • This server is an internal element of the information system SB which is the organized set of resources (hardware, software, personnel, data and procedures) that allow to collect, group, classify, process and disseminate information within a given bank B offering the service underlying the invention.
  • the invention necessarily entails, first and foremost, interfacing and integration of the systems and elements of the instantaneous interpersonal mobile payment (P2P) service, in particular the SD server with a server of the information system SIB of a bank B offering this service.
  • P2P instantaneous interpersonal mobile payment
  • the mobile money transfers induced by the invention are executed last and largely by the SIB server of said bank B.
  • the payments by means of (TPE) and the withdrawals to (GAB) card dual CD or classic C are also managed largely by the SIB but with the assistance, if necessary, of a dedicated external SRI server.
  • the SIB server is the downstream executor of a large part of the tasks related to mobile money transfers. It allows:
  • PC2PC PC2PNC
  • PNC2PC PNC2PNC
  • This server is the pivotal element between the external systems that are the subject of the invention (SU, SC) and the system / internal information server SB / SIB of a given bank B. It makes it possible in particular to:
  • PC2PC mobile transfers
  • PC2PNC PC2PNC
  • PNC2PC PNC2PNC
  • set the maximum amounts to be withdrawn or spent in payment per day
  • set the floor or threshold level for the single CRU reserve account below which ATM withdrawals and (TPE) payments are strictly prohibited.
  • the role of the internal server SD is increased because it also performs the role exercised by the central server SC in the case of a global intra-bank or interbank system. Indeed, in an integrated system, there is no external server such as the SC and therefore the role of the latter is confused with that of the SD.
  • the CRU system
  • All CVR-valued virtual accounts involved by the instant interpersonal mobile payment service (P2P) object of the invention and domiciled in the same bank B form a system similar to a single relay account called CRU single reserve account.
  • This account can be accessed by a multitude of dual CD cards or classic C withdrawal and payment belonging to beneficiaries R mobile money transfers: it is therefore a multicard account where each withdrawal card or payment backed him is actually associated with a current account and / or virtual and has its own dynamic ceiling in a time t rated Pt.
  • CRU system forming the single reserve account CRU which ensures the instantaneousness sought of the interpersonal mobile money transfers of type PC2PNC, PNC2PC and PNC2PNC. Indeed, the latter is ensured by the instant availability of the amounts transferred by an issuer E to a beneficiary R and this through a set of variations in the ceilings of said cards (dual or classic) payment or withdrawal. Beneficiary R therefore has the choice to withdraw from the Relay Account the money that is instantly transferred to the first (GAB) met or to spend it through his dual card or classic payment and withdrawal associated with his current account. CR and / or virtual CVR / CRU.
  • This reserve account is so named because it is pre-funded by bank B where it is domiciled amounts likely to be withdrawn from (GAB) or spent by means of a (TPE) by receivers R registered service offered by said bank.
  • the reserve to be allocated to this reserve account depends on the product of the expected and estimated expected number of potential users of the service in question by the expected total expected amount of payments and withdrawals made by an average user of the service all weighted by a similar reduction factor to the Cooke ratio (8%).
  • the SM mail server :
  • the external mail server SM is connected via a signaling channel (GSM standard) to the central server SC and allows the latter to make notifications (to the users of the service object of the invention) via SMS messages confirming the success of instant interpersonal mobile money transfer (P2P) transactions and their receipt in the beneficiaries' current or virtual accounts.
  • SMS are sent to the mobile phone numbers respectively of the issuer E and the beneficiary R.
  • Each recipient or receiver R user of the instant interpersonal mobile payment service (P2P) object of the invention has a CVR virtual account for receiving instant electronic money transfers. He is therefore given a classic card payment and withdrawal (ATM) directly associated with his virtual account itself backed to the CRU owned and domiciled at the same bank B that the user.
  • ATM classic card payment and withdrawal
  • the invention proposes and allows them to use a single card called dual CD payment and withdrawal (ATM).
  • this card is associated with the two accounts of the banked beneficiary namely its current account CR and its virtual account CVE: its owner can therefore through this dual card access a unique interface to (GAB) and (TPE) giving it the choice to pay for a particular service or withdraw the funds transferred to it or other funds from the chosen CR or CVR account.
  • the banked user of the service in question will have to use one and only dual card payment and withdrawal associated with his current account and his virtual account backed up to the CRU single reserve account.
  • the interbank remote server SRI The interbank remote server SRI:
  • the external external SRI server provides the national interoperability service for withdrawals made at automated teller machines (ATMs). It is managed by an external service provider and allows a client of the service object of the invention to withdraw the money that is transferred instantly to him by mobile phone and in any (ATM) of any bank. It is securely connected to the SIBs of all banks.
  • ATMs automated teller machines
  • the interbank remote server SIT The interbank remote server SIT:
  • the remote external server SIT Interbanking Teletransaction Server
  • SIT Interbanking Teletransaction Server
  • the remote external server SIT provides the electronic service for managing and clearing conventional interbank transfers. It is managed by an external service provider and therefore allows a given issuing bank B to make interbank funds transfers to another receiving B2 bank.
  • the processing of these traditional inter-bank transfers generally take a certain delay ⁇ to be executed.
  • This server is securely connected to the SIBs of all banks.
  • the user will have the choice between two client interfaces to use the service object of the invention:
  • Any natural person not subject to a banking prohibition is allowed to register with the service in question and this by creating a user account (or customer account) that allows him to have a current account CR or virtual CVR. It is sufficient for the future user of the service to go to a customer service representative at one of the branches of the bank B of his choice, provided with:
  • the account manager gives the future user a document explaining how to activate and use the service and deactivate it if necessary. It is then delivered to the registered customer a temporary PIN code with a lifespan of 30 minutes. With the latter, the user can activate the service on the spot a first time via his mobile phone after downloading the mobile application related thereto or by calling the special access number to the corresponding USSD service.
  • the user opts for the USSD service then he must, to activate his user account, first call the special telephone number of the remote interactive server SU which requests him to enter the temporary PIN code. After verifying that the temporary PIN is the one associated with the calling number, the SU server then asks the user to enter a new permanent PIN of his choice that he must re-enter a second time for verification.
  • the emitter E can therefore access said service after activation of the latter by two means:
  • Smartphone mobile phone users registered to the service use the mobile application associated with it after downloading and installing it from the appropriate platform.
  • the user E In order to access the said service, the user E must re-activate the mobile application on his Smartphone by following the same steps as for access to the USSD service described above.
  • the technical kinematics of the mobile electronic banking transfers from the account of an issuer E to the account of a beneficiary R is processed first by the central server SC which transmits via VPN connection the information to the SD installed within the internal system. SB from bank B.
  • the CRU account domiciled at the same bank B comes into action: the transferred money is then advanced and made available to the beneficiary R instantly (except the type of transfer PC2PC and PNC2PC ) thanks to variations (executed in the BSD database managed by the SD) instantaneous dynamic ceilings of the dual card CD or classic C payment and withdrawal associated with current accounts CR and / or CVR of the receiver R.
  • the CRU account is thus debited with the amount transferred and withdrawn by the receiver R from any automatic teller machine (ATM) or spent by the latter when paying for a given service by means of its dual or classic card.
  • ATM automatic teller machine
  • the mobile money transfer is done simply by a set of compensation between the dynamic ceilings of a virtual CVE issuer account and that of a CVR receiver virtual account since the latter two are domiciled in France. the same bank B and backed by the same CRU single reserve account. Finally, the CRU account is refunded afterwards (except for the transfer type PC2PC and PNC2PC) by being credited with the amount transferred following the traditional transfer transaction already initiated from the EC or CVE issuer account to the CRU.
  • the technical kinematics of interbank mobile money transfers from the account of an issuer E to the account of a beneficiary R is processed in the first place by the central server SC which transmits the information via VPN connection to the SIB1 and SIB2 internal servers respectively banks partners Bl and B2 respectively SD1 and SD2 installed respectively in the two banks Bl and B2.
  • the interbank mobile transfer order that can be of the PC2PC, PC2PNC, PNC2PC and PNC2PNC type is first executed in a conventional manner by the SIB1 of the bank B1 and by the SIT (server interbanking of remote compensation) by putting a delay ⁇ of several hours before being effective.
  • the CRUR account domiciled in the bank B2 comes into action: the money transferred is thus advanced and made available to the beneficiary R instantly (except the type of transfer PC2PC and PNC2PC) and this thanks to modifications in the dedicated database BSD2 managed by the SD2 dynamic ceilings of the card dual CD or classic C payment and withdrawal associated with current accounts CR2 and / or CVR2 receiver R.
  • the account CRUR is thus debited from the amount transferred and withdrawn by the receiver R from any automatic teller machine (ATM) or spent by the latter when paying for a given service by means of its dual or conventional card.
  • ATM automatic teller machine
  • the CRUR account is reimbursed a posteriori (except the type of transfer PC2PC and PNC2PC) being credited with the amount transferred following the traditional transfer transaction already initiated from the issuer account EC or CVE to the CRUR.
  • the user of the service in question can at any time temporarily disable the service from his mobile application or the USSD service. This deactivation protects all the sensitive data created during the initial activation of the two applications and in particular the electronic certificate relating to the identity of the user. Nevertheless, it can always reactivate the service via its application if it wishes using its PIN.
  • Any user of the service in question can definitively close his customer account by going to a customer service representative of the bank B offering said service. In order to reuse the latter, the user is obliged to follow the same procedure as when he first registered for said service.
  • the service advocated by the invention must allow its users to make mobile money transfers in a very safe and secure way. Therefore, this requires securing the connections and communications initiated between the central server SC and:
  • the central server SC can be reached by registered users of the service in question by means of two types of mobile phones:
  • the electronic certificates managed by the central server SC are provided to the mobile applications as well as to the dedicated secondary servers SD by a certification authority.
  • the service is accessible by making a telephone call to the interactive remote server SU.
  • the PIN code sent by the user transits over a secure network in this case a GSM type channel de facto considered safe (that of the telephone operator and provider concerned).
  • a GSM type channel de facto considered safe that of the telephone operator and provider concerned.
  • the caller's telephone number provided by the operator in question and combined with the PIN code makes it possible to authenticate the user of the service without the possibility of intrusions or fraud.
  • this channel is supposed already encrypted by the telephone operator already mentioned.
  • the mobile application generates a unique identifier for all the initial activation operations of the service for each SIM card whose holder is registered in the service object of the invention.
  • This activation identifier is encrypted and sent to the central server SC via SMS: it ensures that the activation has been made by the owner of the SIM card registered service.
  • the application asks the user to enter the following information:
  • This information is accompanied by the unique activation identifier and is then encrypted to the central server SC via an SSL channel for final activation of the mobile application.
  • the mobile application as well as the dedicated secondary servers SD must have electronic certificates from the central server SC in order to be authenticated.
  • the information to be exchanged between these systems over a VPN connection is encrypted.
  • the central server SC Once the above information is validated (after a first activation) by the central server SC then the latter sends electronic certificates to be used for all future authentications between the mobile application and the dedicated servers SD on one side and the SC central server on the other.
  • Any electronic security certificate for a connection must have a renewable validity period. Indeed, the mobile application as well as the SD dedicated servers must make sure automatically (before opening any secure channels with the central SC server) that their electronic certificates have not expired and / or have not been revoked by the CA. In case of revocation of a given electronic certificate or expiry of its validity period, then the corresponding connection is automatically refused by the central server SC.
  • Each bank B must necessarily install an SD server dedicated to the management of the virtual accounts object of the invention. Since the central server SC is not always on the same infrastructure as the dedicated secondary servers SD, the links between the central server SC and the secondary servers SD are therefore via a secure VPN.
  • the system of the invention must be able to handle responsibilities in the event of proven internal or external fraud.
  • the transaction history must therefore be allowed and stored by this system for a predefined limitation period.
  • These operations can range from interpersonal mobile money transfer (P2P) transactions and their amounts, changes in IN code, memorization of activation dates of the service in question and identities of users (issuers and beneficiaries of transfers) to exchanges to through the different elements of the system as a whole (internal systems of the SIB partner banks, SC central server, dedicated secondary SD servers, mobile phones used, remote interactive server records SU and SM ..).
  • P2P interpersonal mobile money transfer
  • the intra-bank system comprising the elements forming the instant interpersonal mobile payment system (P2P) allows an emitter E via a USSD service (via the SU) or a mobile application installed on its mobile phone in the case a Smartphone (via the internet network and a secure VPN connection) to perform within the same bank B and at any time an interpersonal mobile money transfer intra-banking order type (PC2PC), (PC2PNC), ( PNC2PC) or (PNC2PNC) in other words from its current account CE and / or virtual CVE to the current account CRI and / or virtual CVR1 of a beneficiary R. Said order is transmitted to an external central server SC.
  • the latter after performing the authentication of the transmitter E transmits the transfer order in question directly to a dedicated internal SD server integrated into the internal system SB of the bank B and this through a VPN connection.
  • the SD orders an internal server SIB to launch a conventional order of transfer (non-instantaneous) respectively between the accounts (CE and CRI), (CE and CVR1 / CRU) or (CVE / CRU and CRI).
  • the SD sends the SIB another order enabling the latter to instantly make available to the beneficiary R money (advanced) to a single CRU reserve account domiciled in the same bank B.
  • This translates into transfer cases (PC2PNC) or (PNC2PNC) by an incrementation of the dynamic ceiling Pt of the virtual account of the receiver R in this case the CVR1 / CRU account backed by a single reserve account CRU.
  • the single reserve account CRU is debited with said amount and a debit order is transmitted (via the SRI if necessary) instantaneously to the internal banking server SIB.
  • the latter then proceeds to the instantaneous decrementation (in the central database BSIB managed by the SIB) of the dynamic ceiling Pt of the conventional card C or dual CD of the receiver R of the amount of money debited.
  • the SIB transmits to the server SD an update order of said ceiling Pt that it decrements in turn the same amount in its own database BSD.
  • the dynamic ceiling Pt is thus updated instantly following the expenditure by the receiver R of part or all of the amount transferred by means of the mobile phone TE of the transmitter E.
  • the dynamic ceiling of the conventional card C or dual CD associated with the virtual account CVE of the emitter E is decremented in turn instantly following a reverse decrement process since the related information comes first from the SD and its BSD database before being processed at the SIB via BSIB.
  • the emitter E and the beneficiary R then receive a confirmation SMS from a mail server SM on their mobile phones (TE and TR) for the success of the mobile transaction in question.
  • the interbank system comprising the elements forming the instant interpersonal mobile payment system (P2P) allows an issuer E having a current account CE or virtual CVE domiciled at the bank Bl to transfer money instantaneously and instantly to a beneficiary R whose current or virtual account respectively CR2 or CVR2 are domiciled in another separate bank B2.
  • the transfer is made via a USSD service (through an external server SU) or a mobile application installed on the mobile phone transmitter TE in the case of a smartphone.
  • the interbank transfer order is initially sent to an external SC server via secure web connections.
  • the type of mobile money transfer in question may be one or the other of the types of interpersonal mobile money transfers (PC2PC), (PC2PIMC), (PNC2PC) or (PNC2PNC).
  • the central server SC external to the internal systems SB1 and SB2, respectively of the sending bank B1 and the receiver B2, transmits firstly via a VPN connection the order transfer in question issued to a dedicated server SD1 interfaced internally with the server SIB1.
  • the server SD1 thus transmits first and foremost a conventional inter-bank mobile transfer order of type (PC2PC), (PC2PNC), (PNC2PC) or (PNC2PNC) between the accounts domiciled in the two separate banks concerned.
  • the transfer is then processed by the external server SIT (Telebanking Interbanking System).
  • the SC transmits directly to the SD2 via a VPN connection another order allowing it to transmit in turn the information to the internal server SIB2 belonging to the SB2 of the receiving bank B2.
  • the latter instantly makes available to the beneficiary R the amount of money transferred to a single CRUR reserve account domiciled in the same B2 bank.
  • transfers PC2PIMC
  • PNC2PNC PNC2PNC
  • the dynamic ceiling of the conventional card C associated with the virtual account CVE / CRU of the emitter E is decremented in turn instantly following a reverse decrementation process since the related information comes first from SD1 and its BSD1 database within the B1 receiving bank before being processed at SIB1 via BSIB1.
  • the emitter E and the beneficiary R then receive a confirmation SMS (made via an external mail server SM) on their mobile phones of the success of the transfer in question.
  • the invention provides new instant interpersonal mobile payment (P2P) systems and methods with specific utility as well as substantial and credible potential public interest.
  • the invention can be directly used by the banking industry thus constituting an undeniable economic contribution to this sector in terms of added value.
  • the instant interpersonal mobile payment solution (P2P) underlying the invention will allow the emergence of a new service and hence the emergence of new economic opportunities for the banking industry, in particular by making it gain new customers until now. there unbanked and out of reach.
  • the socio-economic impact of the invention can not be limited to the banking sector alone.
  • the invention may also have indirect socio-economic effects on the trade in goods and services sector.
  • P2P interpersonal money transfers
  • the invention will contribute indirectly to the increase of a national economic indicator, namely the consumption of households in goods and services.
  • National economic actors in general will therefore only be able to feel the impact on their business, thus contributing to the creation of jobs and the sustainable socio-economic development of our country. Therefore, the invention could be recognized as being susceptible of industrial application.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention propose un nouveau service de paiement mobile interpersonnel instantané (P2P) basé sur de nouveaux systèmes et procédés utilisant et associant des cartes dites duales (CD) ou classiques (C) de paiement et de retrait aux guichets automatiques bancaires (GAB) rechargeables. L'invention doit permettre de façon générale à un utilisateur de téléphone mobile de transférer de l'argent en toute heure et instantanément à un autre utilisateur de téléphone mobile. Ce dernier peut alors retirer cet argent au premier guichet automatique rencontré (GAB) ou le dépenser en payant un service donné par le biais de sa carte de retrait et de paiement. L'invention apporte dès lors une réponse technique au problème majeur de l'instantanéité des virements monétiques mobiles. Sur le plan économique, le service objet de l'invention est de par sa nature un service orienté marché destiné au secteur bancaire. Ce service est susceptible d'application industrielle en plus d'être accessible au plus grand nombre possible d'utilisateurs de téléphones portables et ce qu'ils aient un compte courant bancaire ou non. Enfin, les nouveaux procédés sous-jacents au service en question relèvent aussi bien du domaine du M-Payment que du domaine du M-Banking.

Description

SYSTEMES ET PROCEDES DE PAIEMENT MOBILE INTERPERSONNEL INSTANTANE (P2P)
I. Description
1.1 Domaine de l'invention
L'invention propose un nouveau service de paiement mobile interpersonnel instantané (P2P) basé sur des systèmes et procédés nouveaux de virements monétiques. Ce service relève à la fois des domaines du M-Payment et du M-Banking.
1.2 Etat de la technique antérieure
Afin de mieux cerner l'état de la technique èn général du M-Payment et du M-Banking, nous proposons en premier lieu à notre lecteur un tour d'horizon de l'état de la technique à l'échelle internationale pour ensuite en faire une analyse à l'échelle nationale en décrivant notamment et brièvement les solutions locales de paiement mobile interpersonnel.
Enfin nous éhumérons succinctement quelques brevets existants se rapportant aux méthodes de paiement mobile interpersonnel de par le monde en laissant le soin à notre lecteur de noter les différences de procédés de l'invention objet du présent mémoire par rapport à ceux déjà existants.
L'état de la technique du M-Payment et du M-Banking dans quelques principaux marchés internationaux :
France:
Plusieurs solutions de M-Banking sont en cours d'essai en 2013 en France. L'une des solutions les plus en vue est une application mobile de virement d'argent de compte à compte proposée par une banque de la place à ses clients. Cette solution est téléchargeable sur les téléphones de type Smartphone à partir des plates-formes de téléchargement connues mais elle ne prévoit qu'un seul type de virement.
Royaume-Uni:
Au Royaume-Uni, une solution de paiement mobile a été mise en place par un ensemble d'opérateurs téléphoniques locaux dans le but de développer un cadre commun permettant une facturation directe des achats des clients sur leurs factures de téléphone. Cette solution permet au client utilisateur d'un téléphone mobile de s'assurer de son achat et de son prix avant de lancer son paiement mobile dans un point de vente affilié au service en question. Ce service de M-Payment est géré par une compagnie de monétique intermédiaire. Espagne:
En Espagne une solution globale intégrée de M-Payment a vu le jour en 2012. Elle est le fruit d'une joint-venture formée de tous les opérateurs de téléphonie mobile actuels en Espagne et de 80% des toutes les institutions financières. Cette solution encore en phase d'essai a pour but de lancer des services de commerce mobile en Espagne, en transformant le téléphone portable en un moyen convivial, souple et sûr de paiement.
Grâce à ce service, des transactions de paiements de factures d'achats utilisant la technologie NFC (Near Field Communication) sont exécutés en temps réel chez les commerçants affiliés. Le système est également conçu pour traiter, valider et procéder à des demandes d'autorisation pour les opérations de cartes de débits et crédits lors des paiements dans les points de ventes affiliés. Ce modèle ne prévoit pas de virements d'argent interpersonnels instantanés.
Japon:
Au Japon, c'est la technologie NFC qui est principalement utilisée depuis quelques années dans le paiement mobile des achats effectués dans les magasins et plus particulièrement des services de transport. Pour effectuer son M-Payment, le consommateur agite son téléphone mobile équipé d'une carte à puce devant un terminal de lecture NFC installé au point de vente. La plupart de ces transactions ne nécessite pas d'authentification, mais certaines la nécessitent via un code PIN. Le paiement est ensuite déduit directement d'un compte prépayé ou débité d'un compte mobile hébergé dans une banque.
Néanmoins, le mode de paiement mobile via NFC fait face à des défis importants en vue de son adoption à grande échelle et ce en raison essentiellement d'un investissement lourd en infrastructures de soutien et d'un écosystème complexe des parties prenantes. Il n'empêche que ce type de paiement mobile est finalement devenu de facto la méthode standard au Japon pour les paiements dans les réseaux de transport en commun et les réseaux ferroviaires.
Corée du sud:
A l'instar du Japon, la Corée du Sud a vu depuis 2011 l'installation de terminaux mobiles de M- Payment et leur mise à niveau dans plus de 300.000 points de ventes notamment chez les détaillants et dans les lieux de transport publics en commun. Pratiquement tous les Smartphones sont équipés dans ce pays de la technologie NFC permettant à leurs utilisateurs de payer leurs achats dans les magasins et autres endroits équipés de terminaux mobiles compatibles avec cette dernière.
Scandinavie:
Dans les pays Scandinaves (Norvège, Suède, Finlande et Danemark) les solutions de M-Payment les plus répandues sont les solutions de facturation directe proposées par les opérateurs téléphoniques à leurs clients. Autrement dit, le client paye ses achats dans un point de vente en agitant son téléphone mobile devant un lecteur utilisant la technologie du Bluetooth ou NFC. Le montant de la transaction est directement facturé au client par le biais de son opérateur téléphonique. D'autres types de paiements mobiles dans ces pays emploient des mini terminaux ou lecteurs mobiles de cartes bancaires (sans fil) installées dans les points de ventes. Le commerçant fait glisser la carte bancaire du client dans ce lecteur mobile et la transaction est conclue. Là encore, les solutions de virements d'argent instantanés ne sont pas répandues dans ces pays nordiques.
Kenya:
En Avril 2007, le premier opérateur téléphonique du Kenya a lancé un nouveau service de transfert mobile d'argent connu sous le nom de M-Pesa. Ce service permet aux utilisateurs de déposer de l'argent dans un compte enregistré sur leurs téléphones cellulaires, d'envoyer des montants d'argent à d'autres utilisateurs en utilisant la technologie SMS et de racheter leurs dépôts enregistrés ou reçus contre de l'argent chez des agents incluant les revendeurs des temps d'antenne et les points de vente qui agissent comme agents bancaires. Le service M-Pesa s'est propagé rapidement dans ce pays et est devenu le service le plus réussi de paiement mobile dans les pays en voie en développement. En 2012, ce service comptait environ 17 millions de comptes enregistrés au Kenya.
Tanzanie:
La Tanzanie a lancé en 2009 un service de paiement mobile dont la plateforme sous-jacente repose sur le modèle M-Pesa crée au kenya. La seule différence entre les deux services réside dans la technologie utilisée dans la transmission des données de transferts mobiles d'argent : au Kenya celle-ci repose sur le SMS alors qu'en Tanzanie, elle repose principalement sur l'USSD (Unstructured Supplementary Service Data) pour fournir aux utilisateurs des menus clients plus conviviales.
Namibie:
Une solution de M-Payment a été développée en Namibie à partir de 2004 et a eu depuis lors un grand succès dans ce pays d'Afrique. Cette solution permet de transférer de l'argent mais avec un léger différé, d'acheter du temps d'antenne à la télévision locale, de payer des factures d'électricité et enfin d'acheter des produits aux points de ventes que sont les supermarchés et les détaillants. Cette solution fonctionne avec tous les modèles de téléphones mobiles.
Afrique du Sud:
En Septembre 2010 ce pays a lancé un service de M-Payment basé sur le modèle Kenyan M-Pesa. Mais ce service a été lent à prendre pied dans le marché Sud-Africain. En mai 2011, seulement 100.000 clients s'étaient enregistrés à ce service. L'écart entre les performances prévues et réalisées de M-Pesa peut être attribué en partie aux différences significatives entre le Kenya et le marché Sud- Africain, notamment au niveau de la réglementation bancaire. D'autres raisons tel que le manque d'une politique de communication efficace du service en question ont entravé les efforts de déploiement initial du service en question dans ce pays. Enfin, pour pallier à cet échec relatif, un autre modèle de transfert mobile d'argent était en cours de développement en Afrique du Sud durant l'année (2013).
Marché US: les grandes tendances du marché du M-Payment en 2012:
L'année 2012 a été présentée aux Etats-Unis comme l'année du M-Payment. C'était la troisième année de suite à être présentée de la sorte dans ce pays. En fin de compte l'année 2012 n'est pas devenue l'année de rupture technologique tant attendue entre les moyens de paiements classiques et le recours aux applications de paiements mobiles et leurs adoptions. Néanmoins et avec un peu de recul, l'année 2012 a connu certains développements importants dans l'espace du paiement mobile. Parmi ceux jugés les plus importants on peut citer l'émergence aux Etats-Unis d'une start- up chouchou des médias et des analystes financiers et technologiques depuis son lancement depuis un peu plus de deux ans et qui a continué à susciter le même intérêt en 2012. Son fondateur a réussi à soulever d'énormes sommes d'argent (près de 350 millions d'euros) auprès d'investisseurs privés. Mais des questions se sont posées depuis lors sur la viabilité du modèle économique de cette startup. Y a-t-il assez de bénéfices générés par les paiements mobiles faits en contrepartie de produits achetés aux détaillants pour justifier l'évaluation de plusieurs milliards de dollars de cette startup ? La société a fait signer plus de deux millions de marchands détaillants afin d'utiliser sa solution de paiement mobile. Mais ce modèle est-il rentable ? En Août 2012, il semblerait que ce modèle ait quand même séduit les consommateurs de produits d'entretien de pelouses et de gazons. Cette startup a signé notamment un accord avec une autre société (célèbre détaillant de café avec 7000 cafés en Amérique du nord) pour permettre les achats de cafés en utilisant la solution de paiement mobile de la startup en question. Mais il est encore trop tôt pour dire à quel point ce deal sera bénéfique. Cette entente a été probablement le premier signe que la société est bien consciente que son avenir se trouve au-delà de la distribution de sa solution de paiement mobile auprès des petits commerçants.
De nouveaux concurrents de la startup en question copiant son modèle mPOS (Mobile Point of Sales) sont apparus durant l'année 2012. Mais selon un spécialiste du domaine du paiement mobile, seules les entreprises qui peuvent offrir un modèle de paiement mobile mPOS comme service supplémentaire interfacé avec les systèmes d'entreprise peuvent survivre à long terme dans ce marché. Quant au modèle de portefeuille mobile utilisant la technologie NFC sur le marché US et malgré le secret bien gardé entourant les chiffres de sa rentabilité, il n'a apparemment pas été au rendez-vous des attentes des analystes financiers et technologiques de la place. Néanmoins, ses inventeurs sont en train de le revoir en permettant à ses utilisateurs grâce à un réseau de type Cloud de charger n'importe quelle carte duale de crédit ou de débit. Autrement dit au lieu de stocker les informations d'identification dans l'élément sécurisé d'un appareil mobile, le nouveau modèle stocke les numéros de comptes personnels dans le nuage, et stocke un compte prépayé sur le téléphone. Ce compte prépayé est lié aux comptes stockés dans le nuage et est traité au point de vente pour le financement de l'achat. La solution a résolu un problème à savoir obtenir des émetteurs de cartes de participer aux transactions générées par ce modèle de portefeuille mobile. De plus, une autre invention au-delà de l'approche basée sur le Cloud propose une carte duale de paiement qui donnera aux utilisateurs la possibilité de payer avec des portefeuilles mobiles à des endroits qui n'acceptent pas les paiements NFC. Il s'agit là de coupler le porte-monnaie mobile avec une carte duale de paiement. Techniquement, cette mise à jour devrait être lancée au courant de cette année 2013.
Un autre type de paiement mobile a été élaboré cette année. Ce modèle va permettre aux utilisateurs d'accéder à leurs comptes à travers un réseau de points de ventes de détaillants. Les millions de titulaires de comptes américains pourront saisir leurs numéros de téléphones associés à leurs comptes puis entrer un code PIN en tout point de ventes avec une carte associée et acceptée, l'achat étant financé par le compte en question. Quant aux marchands affiliés à ce réseau, ils seront en mesure de recevoir les paiements sans changer leurs terminaux de paiements. Ce modèle signifie que la carte en question aura accès à un tout nouveau groupe de clients.
Enfin n'oublions pas l'annonce faite aux Etats-Unis en 2012 du lancement prochain du plus grand réseau de paiements mobiles dans le monde et le lancement d'un programme pilote (toujours dans le domaine du paiement mobile) basé sur la technologie NFC à Sait Lake City et Austin. Par ailleurs, les géants des cartes de crédit essaient eux aussi timidement en ce moment (en 2013) de mettre le pied dans ce marché en tissant des partenariats avec des opérateurs téléphoniques de renom ou en lançant des portefeuilles mobiles (mobile wallet).
En conclusion, une chose est certaine: 2012 a été pour beaucoup de joueurs du marché du M- Payment l'année où l'idée de payer ou faire du shopping par le biais de son téléphone mobile a été prise très au sérieux. On pourrait affirmer sans ombages que l'année 2012 n'a pas été « l'année du M-Payment » mais que viendrait un jour où on pourrait regarder en arrière et dire que c'était l'année qui a peut-être précédé l'année du M-Payment proprement dit.
L'état de la technique du M-Payment et du M-Banking au Maroc :
Depuis l'année 2010, quelques solutions de M-Banking ont vu le jour au Maroc. Ces solutions ont été développées aussi bien par des opérateurs téléphoniques que par des banques de la place. Ces solutions sont décrites ci-après.
Survol des solutions de virements monétiques mobiles déjà en service au Maroc:
L'opérateur historique marocain a lancé en 2010 un service de virement mobile d'argent, premier service de virement d'argent par téléphone mobile au Maroc. Ce service a été lancé en partenariat avec deux groupes financiers de la place. Ce service mobile permet de :
• déposer de l'argent sur un compte dans toutes les agences de l'opérateur et dans certains distributeurs agréés
• retirer de l'argent de ce compte aux agences de l'opérateur et chez les distributeurs agréés
• transférer de l'argent partout au Maroc à récupérer dans les agences et distributeurs agrées Une autre application mobile via Smartphone est proposée par une banque de la place et est téléchargée gratuitement à partir des AppStores spécialisés connus. Elle se décline également en version vocale. Cette solution intègre un volet transactionnel qui permet à son utilisateur d'effectuer l'essentiel des opérations de M-Banking y compris des virements de compte à compte, des virements nationaux et internationaux différés etc.. Mais ces virements ne sont pas instantanés et ne sont en fait que des ordres de virements transmis par le biais du mobile à la banque qui les traite un peu plus tard.
Une application mobile a été lancée par une autre banque de la place en 2012 et permet à son utilisateur d'effectuer un ensemble d'opérations de M-Banking et qui sont :
• consulter le solde d'un compte ;
• afficher l'historique des dernières opérations effectuées sur un compte
• procéder au paiement des factures d'eau et d'électricité;
• effectuer des virements d'argent au Maroc 24h/24 et 7j/7 : le titulaire d'un compte peut transférer de l'argent par le biais de son téléphone mobile et le mettre à la disposition d'un bénéficiaire qui pourra le retirer dans un des guichets de la banque sans avoir nécessairement besoin d'une carte duale de paiement et de retrait.
Un autre opérateur téléphonique local a dévoilé en février de l'année 2013 un nouveau service de paiement mobile interpersonnel. Pour bénéficier de ce service, les utilisateurs doivent obligatoirement ouvrir un compte dans une agence de l'opérateur en question. Ce service est destiné uniquement aux clients enregistrés de l'opérateur en question et le bénéficiaire d'un virement d'argent doit se déplacer et s'adresser à un agent dans une agence du réseau de cet opérateur pour récupérer son argent.
Existence de brevets pertinents de paiement mobile interpersonnel :
Au niveau national et après des recherches dans la base de données de l'OMPIC (Office Marocain de la Propriété Industrielle et Commerciale), il n'existe aucun brevet reproduisant de près ou de loin les systèmes et procédés innovants de l'invention objet du présent mémoire descriptif.
Au niveau international et après des recherches dans l'espace de recherche de l'Office Européen des brevets (Espacenet Patent search), il s'avère qu'il n'existe à ce jour (16 Août 2013) dans cet espace aucun brevet offrant l'instantanéité des virements monétiques mobiles requise par l'invention et reproduisant ses systèmes et procédés innovants avec l'utilisation de cartes de retraits rechargeables.
Néanmoins, il existe des brevets (datant de moins de trois ans) exposant d'autres méthodes particulières de virements monétiques mobiles interpersonnels et qui méritent d'être cités vu leurs pertinences par rapport à l'invention. Le tableau de la page suivante énumère les principaux brevets en question avec leurs numéros de publication : Brevets internationaux des principales méthodes de virements monétiques mobiles interpersonnels :
Figure imgf000008_0001
LEGENDE GLOBALE :
Utilisateurs de l'invention
E : émetteur d'un virement monétique mobile interpersonnel instantané (P2P)
TE : téléphone mobile de l'émetteur E d'un virement monétique mobile interpersonnel instantané (P2P)
Ei : émetteur i d'un virement monétique mobile interpersonnel instantané (P2P)
R : receveur ou bénéficiaire d'un virement monétique mobile interpersonnel instantané (P2P)
TR : téléphone mobile du receveur R d'un virement monétique mobile interpersonnel instantané (P2P)
Ri : receveur ou bénéficiaire i d'un virement monétique mobile interpersonnel instantané (P2P)
B : banque donnée de l'émetteur E et du bénéficiaire R (cas général), offrant le service objet de l'invention
Bl : banque donnée de l'émetteur E et offrant le service objet de l'invention
B2 : banque donnée du bénéficiaire R distincte de Bl et offrant le service objet de l'invention
Système CRU :
CRU: système de comptes virtuels assimilé à un Compte de Réserve Unique de même nom de la banque B du receveur R (cas général)
CRUR : système de comptes virtuels assimilé à un compte de Réserve Unique de même nom de la banque B2 du receveur R
NCRU : numéro du Compte de Réserve Unique CRU
Comptes courants :
CE : compte courant bancaire de l'émetteur E domicilié à la banque B ou Bl (cas général)
CR : compte courant bancaire du receveur R domicilié à la banque B ou B2 (cas général)
CRI : compte courant bancaire du receveur R si domicilié à la même banque B que celle de l'émetteur E
CR2 : compte courant bancaire du receveur R si domicilié dans une banque B2 différente de celle Bl de l'émetteur E
Sjt : Solde du compte courant CEj ou CRj au temps t respectivement d'un émetteur Ej ou d'un receveur Rj
Comptes virtuels et cartes duales :
CVE ou CVE/CRU : compte virtuel de l'émetteur E adossé au CRU domicilié à la banque B ou Bl (cas général) CVR ou CVR/CRU : compte virtuel du receveur R adossé au CRU domicilié à la banque B ou B2 (cas général)
CVRI ou CVR1/CRU : compte virtuel du receveur R adossé au CRU si domicilié à la même banque B que de celle de l'émetteur E
CVR2 ou CVR2/CRUR: compte virtuel du receveur R adossé au CRUR si domicilié dans une banque B2 différente de celle Bl de l'émetteur E
(CVE, Pt) : compte virtuel d'un émetteur E adossé au CRU et dont le plafond dynamique de la carte C ou CD associée est de Pt au temps t
(CVEi, Pit) : compte virtuel d'un émetteur Ei adossé au CRU et dont le plafond dynamique de la carte C ou CD associée est de Pit au temps t
(CVR, Pt) : compte virtuel d'un receveur R adossé au CRU et dont le plafond dynamique de la carte C ou CD associée est de Pt au temps t
(CVRi, Pit) : compte virtuel d'un receveur Ri adossé au CRU et dont le plafond dynamique de la carte C ou CD associée est de Pit au temps t
Ci ou C : carte classique de paiement et de retrait aux (GAB) respectivement d'un receveur Ri ou R associée à son compte courant respectivement (CRi ou CR) ou virtuel respectivement (CVRi ou CVR)
CDi ou CD: carte duale de paiement et de retrait aux (GAB) d'un receveur respectivement Ri ou R associée à son compte courant respectivement (CRi ou CR) et virtuel respectivement (CVRi ou CVR) LEGENDE GLOBALE : (suite)
Serveurs :
SU : serveur externe USSD interactif
SC : serveur central
SD : serveur dédié interne de la banque B (cas général)
SD1 : serveur dédié interne de la banque Bl
SD2 : serveur dédié interne de la banque B2
SM : serveur de messagerie
SRI : serveur gérant les retraits interbancaires aux (GAB)
Intermédiaires :
SB : Système d'information de la banque B (cas général)
SB1 : Système d'information de la banque Bl
SB2 : Système d'information de la banque B2
SIB : Serveur interne d'information de la banque B (cas général)
SIB1 : Serveur interne d'information de la banque Bl
SIB2 : Serveur interne d'information de la banque B2
SIT : Serveur Interbancaire de Télé-compensation
GAB : Guichet Automatique Bancaire
TPE : Terminal de paiement électronique
Gestion des plafonds dynamiques :
BSD : Base de données au sein du serveur dédié SD dédiée exclusivement à la gestion des plafonds dynamiques Pt de toutes les cartes duales CD et classiques C associées au CRU
BSIB : Base centrale de données au sein du serveur interne bancaire SIB gérant les soldes St de tous les comptes courants et les plafonds dynamiques Pt de toutes les cartes duales CD et classiques C associées au CRU
Cci : Numéro de la carte classique Ci d'un émetteur Ei ou d'un receveur Ri associée respectivement au compte virtuel CVEi ou CVRi avec un plafond en t de Pit
Ccj : Numéro de la carte classique Cj d'un client quelconque de la banque B ou Bl associée à son compte courant avec un solde en t de Sjt
CDk : Numéro de la carte duale CDk d'un receveur Rk associé à son compte virtuel CVRk et courant CRk avec un plafond en t de PDkt par rapport à CVRk et un solde SDkt par rapport à CRk
NCj : Numéro du compte courant d'un client quelconque de la banque B avec un solde en t de Sjt
NCDK : Numéro du compte courant CRk d'un receveur Rk disposant d'une carte duale CDk de retrait et de paiement
NCRU : Numéro du Compte de Réserve Unique domicilié dans une banque B (cas général)
NCVE : Numéro du compte virtuel d'un émetteur E domicilié dans une banque B (cas général)
NCVR : Numéro du compte virtuel d'un receveur R domicilié dans une banque B (cas général)
(CVRk, PDkt) : compte virtuel d'un receveur Rk bancarisé ayant une carte duale CDk associée au CRU et dont le plafond dynamique au temps t est de PDkt
Autres :
ΔΤ : délai normal de traitement d'un virement classique interbancaire ou intra bancaire pouvant aller de 12h à 72h M-Payment : paiement par le biais de téléphones mobiles
M-Banking : opérations bancaires par le biais de téléphones mobiles 1.3 Exposé de l'invention
L'invention propose un nouveau service de paiement mobile interpersonnel instantané (P2P) basé sur des systèmes et procédés nouveaux de virements monétiques. Ce service permet à des personnes d'envoyer ou de virer de l'argent instantanément et en toute heure à d'autres personnes et ce en utilisant leurs téléphones mobiles. Les procédés sous-jacents en question prévoient et impliquent l'utilisation par les bénéficiaires desdits virements de cartes dites duales CD ou classiques C de paiement et de retrait d'argent aux guichets automatiques bancaires (GAB) rechargeables. Ces bénéficiaires peuvent alors retirer l'argent reçu directement au premier (GAB) rencontré ou payer un service donné par l'intermédiaire de leurs cartes de paiements ainsi rechargées.
Il est à noter que la propriété d'instantanéité des virements monétiques mobiles en question est d'une importance capitale. En effet, nul ne saurait imaginer une solution de paiement mobile interpersonnel (P2P) digne de ce nom sans ladite propriété : c'est là un des défis techniques majeurs que la présente invention tente de résoudre en y apportant la réponse technique idoine.
Enfin l'invention cible tous les utilisateurs de téléphones mobiles de type Smartphone ou basiques (téléphones d'entrée de gamme) qu'ils soient bancarisés ou non bancarisés.
1.3.1 Caractéristiques techniques connues
Un virement entre deux comptes bancaires est une opération qui consiste à débiter un compte émetteur au profit d'un autre compte dit récepteur ou bénéficiaire. Ce dernier est alors crédité du montant dudit virement. Ce virement est considéré comme un virement classique. Le traitement d'un virement de type classique diffère selon qu'il soit effectué entre deux comptes courants CE et CR domiciliés à la même banque B ou dans deux banques distinctes Bl et B2.
Cas des virements intra bancaires :
Un système d'information bancaire SB permet de collecter, regrouper, classifier, traiter et diffuser des virements intra bancaires au sein d'une même banque B.
Un virement intra bancaire est un mouvement de fonds d'un compte de la banque B vers un autre compte domicilié dans la même banque et ce par l'utilisation combinée de moyens informatiques, électroniques et de procédés de télécommunications.
Selon que les deux comptes soient domiciliés à la même agence ou dans des agences distinctes de la même banque B, le traitement de l'opération de virement en question met un certain délai ΔΤ allant de 12 à 24 heures pour être effectif. Ce délai s'explique en premier lieu par le temps mis par l'opération de collecte en fin de journée de tous les ordres de virements quotidiens en provenance de toutes les agences bancaires appartenant à la même banque. Une fois collectés, les ordres de virement sont traités électroniquement (parfois manuellement) et successivement le soir même par un centre de traitement informatique CTR (centres de traitement régionaux). Les traitements en question ne deviennent alors effectifs que le lendemain. C'est l'une des problématiques qu'essaie de résoudre le système intra bancaire objet de l'invention en permettant des virements monétiques intra bancaires mobiles interpersonnels (P2P) instantanés.
Cas des virements interbancaires :
Un système d'information bancaire SB1 permet de collecter, regrouper, classifier et traiter des virements interbancaires au sein d'une même banque Bl avant de les diffuser vers le SIT (Système Interbancaire de Télé-compensation).
Un virement interbancaire est un mouvement de fonds d'un compte de la banque Bl vers un autre compte domicilié dans une banque distincte B2 et ce par l'utilisation combinée de moyens informatiques, électroniques et de procédés de télécommunications. Le traitement de l'opération de virement en question met un certain délai ΔΤ allant de 24 à 72 heures pour être effectif. Ce délai s'explique en premier lieu par le temps mis par le SBl lors de l'opération de collecte en fin de journée de tous les ordres de virements quotidiens en provenance de toutes les agences bancaires de la banque Bl. Une fois collectés, les ordres de virement sont traités électroniquement (parfois manuellement) et successivement le soir même en vue de les faire traiter par le SIT. Ce dernier se charge alors des opérations de virements et de compensation interbancaires faisant que les exécutions desdits virements ne deviennent alors effectifs qu'un à trois jours plus tard. C'est l'une des problématiques qu'essaie de résoudre également le système interbancaire objet de l'invention en permettant des virements monétiques interbancaires mobiles interpersonnels (P2P) instantanés.
1.3.2 Caractéristiques techniques propres à l'invention
Grâce à l'invention, un émetteur E peut donc payer de gré à gré par le biais de son téléphone mobile un bénéficiaire ou receveur R en virant de l'argent de son compte courant bancaire CE au compte courant bancaire CR de ce dernier: il s'agit là du modèle ou type de virement monétique mobile interpersonnel (PC2PC). Trois autres modèles sont alors identifiés selon le type de virement monétique mobile interpersonnel effectué par l'émetteur E : le modèle (PC2PNC) de virement d'un compte courant bancaire CE vers un compte bancaire virtuel CVR, le modèle (PNC2PC) de virement d'un compte bancaire virtuel CVE vers un compte courant bancaire CR et enfin le modèle (PNC2PNC) de virement d'un compte bancaire virtuel CVE vers un autre compte bancaire virtuel CVR.
Autrement dit, et afin d'aider notre lecteur à comprendre et à mieux appréhender les acronymes utilisés par nos soins pour décrire les différents modèles de virements monétiques mobiles interpersonnels (P2P) déjà cités, il suffit de remarquer que quand on dit "virement de type PC2PNC" cela veut dire tout simplement qu'il s'agit là d'un virement monétique mobile d'une" Personne avec Compte courant" vers une "Personne avec Non Compte courant" c.-à-d. vers une personne non bancarisé. De la même façon, quand on dit "virement de type PNC2PNC" cela veut dire tout simplement qu'il s'agit d'un virement monétique mobile d'une "Personne avec Non Compte courant" ers une" Personne avec Non Compte courant' ce qui équivaut à parler dans ce dernier cas d'un virement mobile d'argent d'une personne non bancarisée vers une autre personne non bancarisée elle non plus : il ne s'agit là ni plus ni moins que d'un virement monétique mobile d'un compte bancaire virtuel noté CVE d'un émetteur E vers le compte bancaire virtuel CVR d'un receveur R. Le même raisonnement s'applique aux autres acronymes utilisés.
Par ailleurs, dans tous les cas de modèles de virements monétiques mobiles interpersonnels identifiés, le bénéficiaire ou receveur R (bancarisé ou non) du virement reçoit l'argent viré instantanément et en toute heure sur son compte bancaire virtuel. Si ce dernier est bancarisé, il peut utiliser cet argent en temps réel et en totalité ou en partie à partir de son compte de réception virtuel pour payer directement un service donné par le biais d'une carte de paiement et de retrait dite duale CD associée à son compte courant et virtuel. Il peut également le retirer en totalité ou en partie à partir du compte de réception virtuel au premier guichet automatique bancaire (GAB) rencontré. Par contre, un receveur R non bancarisé utilise une carte de paiement et de retrait classique C normale associée exclusivement à son compte virtuel.
Par conséquent un bénéficiaire ou receveur R bancarisé ou non bancarisé a le choix d'aller au premier (GAB) rencontré pour retirer l'argent qui lui est envoyé instantanément via un téléphone mobile ou s'il le désire de dépenser cet argent en payant un service directement avec sa carte rechargée ainsi par un émetteur E. L'invention permet donc à un bénéficiaire R déjà bancarisé de garder et d'utiliser une même et seule carte déjà associée à son compte courant et à son compte virtuel en vue de bénéficier du service de paiement mobile interpersonnel (P2P). Le mode de réalisation de l'invention suppose alors et implique nécessairement l'utilisation par un bénéficiaire R bancarisé d'une carte duale CD de paiement et de retrait aux (GAB). Cette carte permet donc à ce dernier d'accéder à ses deux comptes bancaires : un compte bancaire courant et un compte virtuel. D'où l'appellation de cette carte dans le présent mémoire "carte de paiement et de retrait duale rechargeable à distance" .
Par ailleurs les comptes dits virtuels prévus par l'invention ne sont pas des comptes courants classiques puisqu'ils permettent seulement de mettre de l'argent viré instantanément par. un téléphone mobile à la disposition des receveurs bancarisés ou non bancarisés. Ces derniers peuvent alors procéder à son retrait aux (GAB) ou le dépenser en payant un service quelconque par le biais de leurs cartes classiques C ou duales CD.
L'invention propose en outre que tous les comptes virtuels domiciliés dans une même banque B forment un système appelé CRU pouvant être assimilé à un compte de réserve unique. Ce compte relais appelé également pour commodité CRU, appartient exclusivement à la banque B proposant le service objet de l'invention. Il est pré-provisionné des montants susceptibles d'être retirés aux (GAB) ou dépensés pour paiements de services donnés. Ce compte relais unique est en fait partagé, grâce aux comptes virtuels qui lui sont adossés, par tous les bénéficiaires ou receveurs R de virements monétiques mobiles. En effet, c'est le CRU qui permet l'instantanéité recherchée des virements monétiques mobiles interpersonnels en mettant instantanément à la disposition d'un receveur R aux (GAB) les sommes virées par un émetteur E et en permettant au premier s'il le désire de les dépenser en payant directement un service par l'intermédiaire de sa carte duale CD ou classique C et d'un terminal de paiement électronique (TPE).
Par conséquent, le principe clé de l'invention est le fait d'avancer au besoin et instantanément à un bénéficiaire R le montant d'argent qui lui est transféré à l'occasion d'un virement monétique mobile effectué par un émetteur E. Il n'empêche qu'au même moment, un autre ordre de virement classique (sous-jacent) du même montant est émis automatiquement du compte émetteur au compte CRU et ce parallèlement audit virement mobile. Ce nouvel ordre est envoyé au système interne bancaire SB de la banque B pour exécution afin de rembourser ou de compenser le CRU. Ce dernier est alors crédité à postériori du montant viré. Conséquence du rôle du CRU : le délai normal ΔΤ de traitement et d'exécution du virement classique sous-jacent audit virement intra bancaire ou interbancaire mobile est ainsi évité et contourné.
Mais en retirant ou en dépensant le montant d'argent qui lui est viré instantanément à partir du CRU en utilisant sa carte C ou CD le receveur R débite en fait son compte virtuel propre CVR adossé au compte de réserve unique. Cette opération de débit implique automatiquement alors une diminution ou une décrémentation du même montant du plafond dit dynamique Pit de ladite carte associée au compte virtuel CVR, ce dernier étant adossé au compte de réserve unique CRU.
Le système CRU est assimilé à un compte de réserve unique partagé portant le même nom et accessible par l'intermédiaire d'une multitude de cartes duales ou classiques d'utilisateurs enregistrés au service objet de l'invention. Les plafonds Pit de ces cartes par rapport au CRU sont propres à chaque carte. Ils sont continuellement mis à jour et recalculés pour chaque carte en fonction des montants d'argent virés via des téléphones mobiles, des retraits effectués aux (GAB), des paiements effectués par le biais d'un (TPE) et enfin des plafonds maximaux autorisés pour chaque carte.
Le solde global du compte de réserve CRU est estimé quant à lui en calculant le produit du nombre espéré prévu et estimé des utilisateurs potentiels du service en question par le montant espéré total estimé des paiements et retraits effectués par un utilisateur moyen dudit service le tout pondéré par un facteur réducteur égal au ratio Cooke (8%).
In fine toutes les caractéristiques techniques propres à l'invention et décrites ci-dessus impliquent nécessairement de nouveaux systèmes et procédés de virements monétiques mobiles interpersonnels instantanés P2P). Ces derniers sont justement en relation directe avec le système CRU mais diffèrent selon que les virements monétiques mobiles sous-jacents soient de type PC2PC, PC2PNC, PIMC2PC ou PNC2PNC et que les systèmes y afférents soient de type intra ou interbancaires. Ces procédés techniques sont au nombre de sept et sont nommés CRU/PC2PC-CVR, CRU/PC2PNC, CRU/PNC2PC-CVR, CRU/PNC2PNC, CRU/PNC2PC-CVR/BD, CRU/PNC2PNC/BD et le procédé de carte duale. Par conséquent, l'invention est une innovation de procédé au sens de la définition d'Oslo puisqu'elle peut être interprétée comme la mise en œuvre d'une méthode de paiement mobile interpersonnel instantané (P2P) sensiblement améliorée (car disponible à chaque instant et proposant des virements en temps réel) impliquant des changements significatifs dans les procédés classiques de virements d'argent par téléphone mobile à l'instar de l'instauration du compte relais nommé CRU et de l'introduction de nouveaux procédés en association avec des cartes duales ou classiques de paiement et de retrait rechargeables à distance.
Enfin, l'invention suppose le développement d'une solution sous-jacente de paiement mobile interpersonnel instantané (P2P). Cette solution est proposée en deux (2) versions APP et USSD :
- la version APP est une application mobile hébergée sur des téléphones mobiles de type Smartphone et conçue pour supporter les quatre modèles de virements monétiques mobiles interpersonnels PC2PC, PC2PNC, PNC2PC et PNC2PNC.
- la version basée sur la norme USSD permet la transmission d'un menu client sur des canaux de signaux GSM (pour Global System for Mobile Communications) adaptés à tous les types de téléphones mobiles mais plus spécifiquement aux téléphones de type basique. Cette version est également conçue pour supporter les quatre modèles de virements monétiques mobiles interpersonnels PC2PC, PC2PIMC, PNC2PC et PIMC2PNC.
L'intérêt d'une telle approche à savoir le développement de la solution sous-jacente à l'invention en deux versions associant des cartes duales CD ou classiques C (rechargeables à distance) et prévoyant tous les cas de virements monétiques mobiles est motivé par le fait que la dite solution se veut être une solution globale et accessible à «Monsieur tout le monde» tout en étant simple d'utilisation et d'emploi. Ainsi, tous les profils d'utilisateurs de téléphones mobiles sont ciblés par cette solution et ce qu'ils disposent de téléphones de type Smartphone ou de type basique et qu'ils aient un compte courant bancaire ou non. l.3.2.1.Système CRU et gestion des plafonds dynamiques
La gestion des plafonds dynamiques notés Pt des cartes duales CD ou classiques C de retrait et de paiement des utilisateurs du service objet de l'invention est au cœur de l'ensemble des nouveaux systèmes et procédés proposés de paiement mobile interpersonnel instantané (P2P). En effet, l'instantanéité des virements monétiques mobiles citée est assurée en grande partie par des variations en temps réel des plafonds dits dynamiques desdites cartes par rapport au compte de réserve unique CRU constitué par le système de même nom CRU et ce lors de chaque opération de virement d'argent mobile à destination de leurs détenteurs ou de retrait ou de paiement effectués par ces derniers. Autrement dit, lorsqu'un émetteur E choisit d'envoyer à un instant t de l'argent instantanément via son mobile à un bénéficiaire R, son ordre de virement est reçu par un serveur externe SC central qui le transmet instantanément à un serveur SD dédié au service en question. Ce dernier procède alors à l'incrémentation (29, 291) instantanée (dans la base de données dédiée BSD gérée par le SD) du plafond dynamique Pt de la carte de type classique C ou duale CD du receveur R du montant d'argent viré. Le serveur SD transmet ensuite un ordre de mise à jour 25 dudit plafond Pt à un serveur interne bancaire SIB. Ce dernier exécute cet ordre en incrémentant 22 à son tour ledit plafond du même montant dans sa propre base de données BSIB. Le plafond dynamique Pt est ainsi mis à jour à l'instant t suite au virement monétique mobile reçu par le receveur R.
Inversement, lorsque le bénéficiaire R décide à partir de l'instant t de dépenser en partie ou en totalité (à partir de son compte virtuel CVR adossé au CRU) le montant qui lui a été viré (en payant un service donné avec sa carte classique C ou duale CD au moyen d'un (TPE) dans un point de vente ou en le retirant au premier (GAB) rencontré), son ordre de dépense est reçu en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation instantanée 20 du montant de l'argent viré (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte de type classique C ou duale CD du receveur R. Le SIB transmet ensuite au serveur dédié SD un ordre de mise à jour 24 dudit plafond Pt. Ce serveur décrémente (28, 281) à son tour ledit plafond du même montant dans sa propre base de données dédiée BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou d'une totalité du montant qui lui a été viré au moyen du téléphone mobile de l'émetteur E. Par ailleurs, dans le cas de virement monétiques mobiles interpersonnels de type PNC2PC ou PNC2PNC, le plafond dynamique de la carte classique C associée au compte virtuel CVE de l'émetteur E est également décrémenté (20, 24, 28) à son tour et instantanément mais l'information y afférente émane d'abord du SD via la BSD pour être ensuite traitée au niveau du SIB via la BSIB suivant un processus de décrémentation inverse.
La description ci-dessus du mode de fonctionnement des plafonds dynamiques des cartes classiques ou duales va nous permettre de décrire ci-après les procédés de l'invention de façon plus fluide. En effet, étant donné que ces derniers reposent en grande partie sur la dynamique de ces plafonds, nous ne décrivons pas de nouveau le fonctionnement de cette dynamique ce qui nous permet de nous concentrer uniquement sur la description des algorithmes proprement dits de tels procédés.
1.3.2.2. Procédé CRU/PC2PC-CVR de paiement mobile interpersonnel instantané :
L'émetteur bancarisé E émet à un instant T=0 donné un virement monétique mobile intra bancaire ou interbancaire d'un montant Mi à un receveur bancarisé R. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire classique de type PC2PC de son compte courant bancaire CE vers le compte courant bancaire CR ou de façon instantané vers le compte virtuel CVR/CRU du receveur R. Ces deux derniers comptes sont domiciliés dans la même banque que celle de l'émetteur E ou dans une autre banque distincte réceptrice B.
Le procédé CRU/PC2PC-CVR permet donc à l'émetteur E d'effectuer un virement monétique mobile classique non instantané de son compte courant CE vers le compte courant CR du receveur R : il s'agit là juste d'un ordre de virement classique 32 adressé au serveur interne bancaire SIB de la banque émettrice pour traitement (via un serveur distant SIT si le virement est interbancaire). Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H. Si par contre l'émetteur E choisit d'effectuer un virement monétique mobile instantané vers le compte virtuel CVR du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique par rapport au CVR/CRU de la carte duale CD de ce dernier est augmenté instantanément (291, 25, 22) en T=0 du montant Mi transféré. Le bénéficiaire R peut donc payer en temps réel un service donné avec sa carte ou retirer son argent au (GAB) le plus proche grâce le cas échéant (si le retrait est interbancaire) à un serveur distant SRI. Dans le même temps, un ordre de virement classique sous-jacent (31) est envoyé au SIB d'un montant Mi du CE vers le CRU (via le serveur distant SIT si le virement est interbancaire) : il s'agit là simplement d'une opération de compensation du montant Mi au CRU. Ce dernier n'est alors crédité qu'au bout d'un certain délai ΔΤ.
A partir de l'instant T=0, le plafond dynamique de la carte duale du receveur R vis-à-vis du CVR/CRU varie et change continuellement en fonction des nouveaux virements monétiques mobiles instantanés reçus (291, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,281) aux (GAB) à partir du CRU,
1.3.2.3. Procédé CRU/PC2PNC de paiement mobile interpersonnel instantané :
L'émetteur bancarisé E émet à l'instant T=0 un virement monétique mobile de type PC2PNC intra bancaire ou interbancaire instantané d'un montant Mi de son compte courant bancaire CE vers le compte virtuel CVR/CRU d'un receveur R non bancarisé. Ce dernier compte est domicilié dans la même banque que celle de l'émetteur E ou dans une autre banque distincte réceptrice B.
Il en ressort que dans le procédé CRU/PC2PNC le plafond dynamique par rapport au CVR/CRU de la carte classique C du receveur R est augmenté instantanément (29, 25, 22) en T=0 du montant Mi transféré. Le bénéficiaire R peut donc payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche grâce au serveur externe SRI le cas échéant. Dans le même temps, un ordre de virement classique sous-jacent (41) est envoyé au SIB de la banque émettrice d'un montant Mi du CE vers le CRU (via le serveur distant SIT si le virement est interbancaire) : il s'agit là simplement d'une opération de compensation du montant Mi au CRU. Ce dernier n'est alors crédité qu'au bout d'un certain délai ΔΤ.
Pour le reste, et à partir de l'instant T=0, le plafond dynamique de la carte classique du receveur R vis-à-vis du CVR/CRU varie et change continuellement en fonction des virements monétiques mobiles instantanés nouveaux reçus (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,28) aux (GAB) à partir du CRU.
1.3.2.4. Procédé CRU/PNC2PC-CVR de paiement mobile interpersonnel instantané :
L'émetteur E non bancarisé émet à l'instant T=0 un virement monétique mobile intra bancaire de type PNC2PC d'un montant Mi au receveur bancarisé R. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire en question de son compte bancaire virtuel CVE vers le compte courant bancaire CRI ou vers le compte bancaire virtuel CVR1/CRU du bénéficiaire R. Ces deux derniers comptes sont domiciliés dans la même banque B que celle de l'émetteur E. Dans le procédé CRU/PNC2PC-CVR si l'émetteur E choisit d'effectuer un virement non instantané (52) vers le compte courant CRI du receveur R alors le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminué en T=0 du montant Mi par rapport au CVE/CRU. Il s'ensuit alors un ordre de virement classique 52 du compte CRU vers le compte CRI adressé directement au SIB de la banque B pour traitement. Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 48H.
Si par contre l'émetteur E choisit d'effectuer un virement monétique mobile instantané vers le compte virtuel CVR1 du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique de la carte duale CD de ce dernier est augmenté instantanément (291, 25, 22) en T=0 du montant Mi transféré par rapport au CVR1/CRU. Le bénéficiaire R peut donc payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche grâce au SRI le cas échéant. Dans le même temps, le plafond dynamique de la carte classique de l'émetteur E est automatiquement diminué (28, 25, 21) en T=0 du montant Mi par rapport au CVE/CRU : il s'agit là simplement d'un jeu de compensation du montant Mi entre le CVE et le CVR1 au sein même du CRU.
A partir de l'instant T=0, le plafond de la carte duale CD du receveur R vis-à-vis du CVR1/CRU varie et change continuellement en fonction des nouveaux virements monétiques mobiles instantanés reçus (291, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,281) aux (GAB) à partir du CRU.
1.3.2.5. Procédé CRU/PNC2PNC de paiement mobile interpersonnel instantané :
L'émetteur E non bancarisé émet à l'instant T=0 un virement monétique mobile intra bancaire instantané de type PNC2PNC d'un montant Mi de son compte bancaire virtuel CVE vers le compte virtuel CVR1 du receveur R non bancarisé.
Dans le procédé CRU/PNC2PNC le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminué (28, 25, 21) en T =0 du montant Mi par rapport au CVE/CRU. Il s'ensuit alors un jeu de compensation du montant Mi au sein même du CRU puisque dans le même temps le plafond dynamique de la carte classique du receveur R est augmenté (29, 25, 22) du montant Mi transféré par rapport au CVR1/CRU. Le bénéficiaire R peut donc payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche grâce au rôle le cas échéant du SRI.
Au-delà de l'instant T=0, le plafond dynamique de la carte classique du receveur R vis-à-vis du CVR1/CRU varie et change continuellement en fonction des nouveaux virements monétiques mobiles instantanés reçus (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,28) aux (GAB) à partir du CRU. 1.3.2.6. Procédé CRU/PNC2PC-CVR/BD de paiement mobile interpersonnel instantané :
L'émetteur E non bancarisé émet à l'instant T=0 un virement monétique mobile de type PNC2PC interbancaire cette fois-ci d'un montant Mi au receveur bancarisé R. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire en question de son compte bancaire virtuel CVE domicilié dans une banque Bl vers le compte courant bancaire CR2 ou vers le compte virtuel CVR2 du receveur R tous deux domiciliés dans une banque distincte B2.
Dans le procédé CRU/PNC2PC-CVR/BD si l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement non instantané vers le compte courant CR2 du receveur R alors le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminué (28, 25, 21) en T=0 du montant Mi par rapport au CVE/CRU domicilié à la banque Bl. Un ordre de virement classique 72 est adressé au SIB1 (avec la participation ultérieure du serveur distant SIT) de la banque Bl et ce directement du compte CRU vers le compte CR2 pour traitement. Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H.
Si par contre l'émetteur E choisit d'effectuer un virement monétique mobile instantané vers le compte virtuel CVR2 du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique de la carte duale CD de ce dernier par rapport au CVR2/CRUR (domicilié à la banque B2) est augmenté instantanément (291, 25, 22) en T=0 du montant Mi transféré. Le bénéficiaire R peut donc payer un service donné avec sa carte duale à cet instant même ou retirer son argent au (GAB) le plus proche grâce le cas échéant au SRI. Dans le même temps, le plafond dynamique de la carte classique de l'émetteur E est automatiquement diminué (28, 25, 21) en T du montant Mi par rapport au CVE/CRU (domicilié à la banque Bl). Au même instant un ordre de virement classique (sous- jacent 71) du CRU vers le CRUR d'un montant Mi est envoyé au SIB1 (avec la participation ultérieure du serveur distant SIT) pour remboursement.
A partir du temps T=0, le plafond dynamique de la carte duale du receveur R vis-à-vis du CVR2/CRUR varie et change continuellement en fonction des virements monétiques mobiles instantanés nouveaux reçus (291, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,281) aux (GAB) à partir du CRUR.
1.3.2.7. Procédé CRU/PNC2PNC/BD de paiement mobile interpersonnel instantané :
L'émetteur E non bancarisé émet à l'instant T=0 un virement monétique mobile de type PNC2PNC interbancaire instantané d'un montant Mi de son compte bancaire virtuel CVE domicilié dans une banque Bl vers le compte virtuel CVR2 du receveur R non bancarisé domicilié dans une banque différente B2.
Dans le procédé CRU/PNC2PNC/BD le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminuée (28, 25, 21) en T=0 du montant Mi par rapport au CVE/CRU. Il s'ensuit alors un ordre de virement classique sous-jacent 81 envoyé au SIB1 (avec le concours du serveur distant SIT) pour le remboursement du montant Mi du CRU (domicilié à la banque Bl) vers le CRUR (domicilié à la banque B2). Dans le même temps le plafond dynamique de la carte classique du receveur R est augmenté (29, 25, 22) du montant Mi transféré et ce par rapport au CVR2/CRUR. Le bénéficiaire R peut donc à partir de son compte CVR2 payer un service donné avec sa carte classique à cet instant même ou retirer son argent au (GAB) le plus proche grâce au SRI le cas échéant.
A partir de l'instant T=0, le plafond dynamique de la carte classique du receveur R vis-à-vis du CVR2/CRUR varie et change continuellement en fonction des virements monétiques mobiles instantanés nouveaux reçus (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24, 28) aux (GAB) à partir du CRUR.
1.3.2.8. Procédé de carte duale CD :
Ce procédé permet à un receveur R bancarisé d'un virement monétique mobile interpersonnel instantané (P2P) disposant d'un compte courant CR et virtuel CVR dans une banque B d'avoir une seule et même carte CD dite duale de paiement et de retrait aux (GAB) associée auxdits comptes courant et virtuel, ce dernier étant adossé au CRU.
En premier lieu, le receveur R utilise le mot de passe unique associé à sa carte duale CD à un (GAB) ou sur un (TPE) pour accéder au choix à l'un de ses deux comptes. En choisissant l'un ou l'autre compte, la demande d'un retrait interbancaire 90 d'un montant d'argent par le receveur R à un (GAB) ou sa demande de paiement d'un service donné au moyen d'un (TPE) 91 est toujours transmise dans les deux cas directement à un serveur externe SRI qui la transmet par liaison VPN 93 (Virtual Private Network) pour vérification à un serveur interne bancaire SIB appartenant à la banque B. Ladite demande est directement transmise au serveur interne bancaire SIB appartenant à la banque B si le retrait d'un montant d'argent à un (GAB) par le receveur R à partir de l'un de ses deux comptes CR ou CVR est intra bancaire 92.
Le serveur interne bancaire SIB réceptionne ladite demande une fois transmise et acceptée après une vérification d'identité, puis renvoie une interface unique au (GAB) ou sur (TPE) via le serveur externe SRI (93, 94) ou directement 95 si l'ordre émane d'une demande de retrait intra bancaire permettant ainsi au receveur R d'accéder au choix à l'un de ses comptes courant CR ou virtuel CVR domiciliés à la même banque B.
A partir de cette interface unique au (GAB) ou sur un (TPE), le receveur R a alors le choix de retirer un montant d'argent ou de payer un service en débitant directement son compte courant CR ou de retirer le montant M qui lui est viré instantanément ou encore de le dépenser en payant un service mais en débitant cette fois-ci directement le compte CVR/CRU (opération de débit du compte CRU). L'ordre afférant à ce choix est alors transmis soit au serveur externe SRI qui le renvoie à son tour au serveur interne bancaire SIB (94, 93) pour traitement dans le cas d'un retrait interbancaire ou d'un paiement par (TPE) dans un point de vente donné soit directement 95 au serveur interne bancaire SIB dans le cas d'un retrait intra bancaire. Le serveur interne bancaire SIB débite alors le compte choisi (CR ou CRU) par l'utilisateur R le cas échéant du montant M (viré instantanément) si ce dernier choisit d'utiliser son compte virtuel CVR.
Dans ce dernier cas le serveur interne bancaire SIB actualise le plafond dynamique Put de la carte duale CD du receveur R (dans la base de données centrale BSIB) en le décrémentant 23 du montant M et envoie un ordre de mise à jour (24, 96) par liaison VPN au serveur dédié SD qui procède à son tour à la décrémentation 281 (dans sa base de données dédiée BSD) du niveau du plafond dynamique Pot de ladite carte duale du même montant et ce par rapport au compte de réserve unique CRU domicilié à la banque B.
Dans le cas où le receveur R choisit d'utiliser son compte courant CR, celui-ci est débité 30 par le serveur interne bancaire SIB du montant d'argent dépensé et ce sans en rendre compte au serveur dédié SD. En effet ce dernier comme son nom l'indique est dédié (entre autres fonctions) à la gestion des plafonds dynamiques Pit des comptes CVRi ou CVEi (contenus dans sa base de données BSD) et non pas à la gestion des soldes des comptes courants CRi.
Enfin, quand le receveur R choisit de retirer en liquide le montant M de son compte virtuel CVR alors le serveur interne SIB transmet un ordre (93, 94, 95) de remise de billets d'argent au (GAB) quémandeur équivalents au montant M viré instantanément. Il transmet également un ordre de virement classique à partir du CVR vers le compte bancaire créditeur appartenant au point de vente si le receveur R paie un service donné au moyen de sa carte duale CD et d'un (TPE).
1.3.3 Avantages de l'invention par rapport à l'état de la technique antérieure
Un virement intra bancaire classique d'un compte bancaire vers un autre compte bancaire ouvert auprès de la même banque B est géré par le SB de celle-ci. Dans le cas d'un virement interbancaire entre deux comptes domiciliés dans des banques Bl et B2 distinctes alors des opérations intermédiaires de compensation sont d'abord effectuées : ces opérations sont gérées par le biais d'un SIT (Système Interbancaire de Télé-compensation).
En l'état actuel des choses, si un émetteur E souhaite virer une somme sur le compte d'un bénéficiaire R, alors cette opération de virement classique ne pourra être effective que plusieurs heures après l'ordre de virement. La durée d'exécution varie selon que le virement est initié au sein de la même agence, au sein de la même banque, ou entre deux banques différentes Bl et B2. En effet, ces virements ne sont traités qu'en une seule fois par le SB d'une banque donnée B en fin de journée pour ensuite être traités et finalisés par le SIT dans le cas d'un virement interbancaire : un délai ΔΤ est alors nécessaire. Ce délai généralement de 12h à 72h est dû au processus de collecte et d'itérations en fin de journée des virements intra bancaires et de compensation des virements interbancaires et aux opérations de vérifications tant au niveau intra bancaire qu'interbancaire et ce dans le but entre autres d'exclure toute erreur et d'éventuelles fraudes.
Dans le domaine du mobile et au niveau national, les solutions de virements d'argent mobiles déjà proposées par certains opérateurs téléphoniques et banques de la place assurent des opérations de virements monétiques mobiles de type PC2PC et/ou PC2PNC. Néanmoins, les virements mobiles de type PC2PC n'ont pas une composante CVR et donc ne se font pas de façon instantanée puisqu'il ne s'agit que de simples ordres de virements par téléphone mobile que ces banques exécutent en accusant un délai ΔΤ. Les virements mobiles de type PC2PNC sont quant à eux quasiment instantanés. Il n'en demeure pas moins que leurs bénéficiaires ne disposent pas de cartes de retrait et ne peuvent donc que retirer à un (GAB) spécifique l'argent qui leur est envoyé via un téléphone mobile ou en se déplaçant vers des points de retraits spécifiques en s'adressant à un agent avec tous les inconvénients y afférents. Ils ne peuvent donc payer un service instantanément au moyen d'une carte de paiement et d'un (TPE) dans un point de ventes avec l'argent qui leur est envoyé via le mobile d'un émetteur E.
Par conséquent et afin d'éliminer ces inconvénients ainsi que les effets gênants des délais techniques ΔΤ subis par les virements en question et les longues attentes qui en résultent, l'invention se propose de créer comme (on l'a décrit précédemment) un système noté CRU de comptes virtuels assimilé à un seul compte bancaire spécial nommé compte de réserve unique CRU au sein d'une banque donnée B et offrant le service sous-jacent à l'invention. Pendant et même au- delà de ce délai ΔΤ, ce compte relais met instantanément à la disposition d'un receveur R l'argent qui lui est viré par un émetteur E via un téléphone mobile. Ce dernier peut alors retirer cet argent aux (GAB) ou le dépenser directement en payant un service donné par l'intermédiaire de sa carte duale CD ou classique C et d'un (TPE).
Au final, les principaux avantages des nouveaux procédés de paiement mobile interpersonnel instantané (P2P) et les systèmes objets du présent mémoire (par rapport à l'existant) tant au niveau national qu'international sont de :
• permettre à tout utilisateur de téléphone mobile d'effectuer en toute heure des paiements ou des virements monétiques mobiles interpersonnels instantanés (P2P) de tous types PC2PC, PC2PNC, PNC2PC et PNC2PNC et ce de façon simple et sécurisée.
• donner la possibilité à tout utilisateur de téléphone mobile de pouvoir retirer instantanément de l'argent qui lui est viré (par un émetteur E via son téléphone mobile) au premier guichet automatique (GAB) rencontré avec une carte duale CD (s'il est déjà bancarisé) ou classique C de paiement et de retrait rechargeable à distance ce qui ne nécessite pas de se déplacer à un point de retrait spécifique et éloigné.
• permettre à tout receveur R d'un virement d'argent instantané (via le téléphone mobile d'un émetteur E) de le dépenser instantanément en payant un service directement avec une carte duale CD ou classique C de paiement ainsi rechargée et ce au moyen d'un terminal de paiement électronique (TPE).
• permettre à une banque B adoptant un tel service de couvrir son coût du capital (supporté) mis en réserve au crédit du CRU par les intérêts générés quotidiennement au profit de cette banque émanant des placements sur le marché monétaire des montants virés et ce pendant le délai normal ΔΤ d'exécution des virements classiques sous-jacents. permettre, grâce à l'architecture "orientée service " prônée par les procédés de paiement mobile interpersonnel instantané (P2P) et leurs systèmes, une intégration et un interfaçage réduits avec le système interne bancaire SB de n'importe quelle banque B adoptant ledit service et tout en étant facile à implémenter.
1.4 Présentation des dessins de la partie IV :
Figure 1A (Feuille 1/15) : Système CRU
Tous les bénéficiaires Ri de virements monétiques mobiles instantanés (P2P) domiciliés dans une même banque donnée B disposent de comptes virtuels (CVRi, Pit) formant un système noté CRU pouvant être assimilé à un compte relais unique appelé compte de réserve unique CRU. Ce compte peut être accédé par une multitude de cartes duales CDi ou classiques Ci de paiement et de retrait appartenant aux bénéficiaires Ri. Le système CRU est donc assimilé à un compte multicarte permettant à chaque bénéficiaire Ri de retirer de l'argent qui lui est viré en temps réel ou de payer (à la réception de son argent en temps réel) un service donné au moyen de sa carte duale ou classique associée à son compte virtuel (CVRi, Pit). Le plafond dynamique Pit de ce dernier change instantanément en fonction des virements monétiques mobiles, des retraits effectués aux (GAB) et enfin des paiements effectués au moyen d'un (TPE) mais sans jamais dépasser son plafond maximal autorisé.
Figure 2A (Feuille 2/15): Gestion des plafonds dynamiques
La gestion des plafonds dynamiques Pt (par rapport au compte de réserve unique CRU) des cartes classiques C ou duales CD de retrait et de paiement des utilisateurs du service objet de l'invention est assurée en grande partie par des programmes de gestion des bases de données BSD et BSIB hébergées respectivement dans les serveurs SD et SIB. Ces deux bases de données interagissent entre elles mutuellement (24, 25) en gérant les variations en temps réel des plafonds dits dynamiques desdites cartes lors de chaque opération de virement mobile d'argent au profit de leurs détenteurs ou à l'occasion de retrait ou de paiement effectuée par ces derniers.
Autrement dit, lorsqu'un émetteur E choisit d'envoyer à un instant t un montant d'argent instantanément via son mobile à un bénéficiaire R, son ordre de virement implique un enregistrement en temps réel de ce montant au crédit (29, 291) du compte CVR (du receveur R) adossé au compte CRU. Cette requête conduit ainsi à l'incrémentation (29, 291) instantanée (dans la base de données dédiée BSD gérée par le SD) du plafond dynamique Pt de la carte du receveur R du montant d'argent viré. Il s'ensuit alors une incrémentation (25, 22) dudit plafond du même montant mais cette fois dans la base de données centrale BSIB gérée par le SIB. Le plafond dynamique Pt est ainsi mis à jour en temps réel dans les deux bases de données suite au virement monétique mobile reçu par le receveur R.
Inversement, lorsque le bénéficiaire R décide à partir de l'instant t de dépenser en partie ou en totalité à partir du CRU le montant qui lui a été viré alors sa dépense implique un enregistrement 20 en temps réel du nouveau montant dépensé au débit de son compte CVR adossé au compte CRU. Cette requête conduit ainsi dans un premier temps à la décrémentation instantanée 20 (dans la base de données BSIB centrale gérée par le SIB) du plafond dynamique Pt de sa carte de type classique C ou duale CD du montant d'argent viré. Il s'ensuit alors une décrémentation (24, 28, 281) dudit plafond du même montant mais cette fois-ci dans la base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément dans les deux bases de données suite à la dépense effectuée par le receveur R d'une partie ou de la totalité du montant qui lui a été viré au moyen du téléphone mobile de l'émetteur E.
Par ailleurs, dans le cas d'un virement monétique mobile interpersonnel de type PNC2PC ou PNC2PNC, le plafond dynamique de la carte classique C associée au compte virtuel CVE de l'émetteur E est décrémenté (28, 25, 21) à son tour en temps réel mais cette fois l'ordre en question passe d'abord par la BSD du SD avant d'être traité par la BSIB du SIB.
Figure 3A (Feuille 3/15): Procédé CRU/PC2PC-CVR
L'émetteur E bancarisé émet à l'instant T un virement mobile intra bancaire ou interbancaire d'un montant Mi au receveur R bancarisé par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile de type Smartphone. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire en question de son compte courant bancaire CE vers le compte courant bancaire CR ou vers le compte virtuel CVR/CRU du receveur R, ces deux derniers étant domiciliés dans la même banque que celle de l'émetteur ou dans une autre banque distincte réceptrice B.
Dans le procédé mobile CRU/PC2PC-CVR, si l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte courant CR du receveur R alors ce transfert n'est pas instantané car il s'agit là juste d'un ordre de virement classique 32 adressé au SIB de la banque émettrice pour traitement (via le serveur externe SIT également si le virement est interbancaire). Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H.
Si par contre l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte virtuel CVR du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique Pt de la carte duale CD de ce dernier est augmenté instantanément (291, 25, 22) en T du montant Mi transféré par rapport au compte virtuel CVR/CRU. Le bénéficiaire R peut donc à partir de ce compte payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche (grâce au serveur externe SRI si le retrait est interbancaire). Dans le même temps, un ordre de virement classique sous-jacent 31 est envoyé au SIB du montant Mi du CE vers le CRU (au moyen du serveur externe SIT là-aussi si le virement est interbancaire) : il s'agit là simplement d'une opération de compensation du montant Mi au CRU. Ce dernier n'est alors crédité de ce montant qu'au bout d'un certain délai ΔΤ.
Pour le reste, et à partir du temps T, le plafond dynamique Pt de la carte duale du receveur R vis-à- vis du CVR/CRU varie et change continuellement en fonction des virements instantanés nouveaux reçus Mj (291, 25, 22), des paiements par carte au moyen d'un (TPE) ainsi que des retraits effectués (20, 24, 281) par le receveur R aux (GAB) à partir du CRU mais sans jamais dépasser son plafond maximal autorisé. Figure 4A (Feuille 4/15): Procédé CRU/PC2PNC
L'émetteur E bancarise émet à l'instant T un virement mobile intra bancaire ou interbancaire d'un montant Mi au receveur R par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile. L'émetteur E dans ce cas effectue le virement bancaire en question de son compte courant bancaire CE vers le compte virtuel CVR/CRU du receveur R non bancarisé. Ce dernier compte est domicilié dans la même banque que celle de l'émetteur E ou dans une autre banque distincte réceptrice B.
Dans le procédé mobile CRU/PC2PNC, le plafond dynamique Pt par rapport au compte virtuel CVR/CRU de la carte classique C du receveur R est augmenté instantanément (29, 25, 22) en T du montant Mi transféré. Le bénéficiaire R peut donc à partir de ce compte payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche (grâce au serveur externe SRI si le retrait est interbancaire). Dans le même temps, un ordre de virement classique sous-jacent 41 est envoyé au SIB de la banque émettrice du montant Mi du CE vers le CRU (en passant par le serveur externe SIT également si le virement est interbancaire) : il s'agit là simplement d'une opération de compensation du montant Mi au CRU. Ce dernier n'est alors crédité de ce montant qu'au bout d'un certain délai ΔΤ.
Pour le reste, et à partir du temps T, le plafond de la carte classique du receveur R vis-à-vis du CVR/CRU varie et change continuellement en fonction des virements instantanés nouveaux reçus Mj (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,28) par le receveur R aux (GAB) à partir du CRU mais sans jamais dépasser son plafond maximal autorisé des virements monétiques mobiles.
Figure 5A (Feuille 5/15): Procédé CRU/PNC2PC-CVR
L'émetteur E non bancarisé émet à l'instant T un virement mobile intra bancaire d'un montant Mi au receveur R bancarisé par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire en question de son compte bancaire virtuel CVE vers le compte courant bancaire CRI ou vers le compte virtuel CVR1/CRU du receveur R, ces deux derniers étant domiciliés dans la même banque B que celle de l'émetteur E.
Dans le procédé mobile CRU/PNC2PC-CVR, si l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte courant CRI du receveur R alors le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminuée (28, 25, 21) en T du montant Mi par rapport au compte virtuel CVE/CRU dans ce cas-ci. Il s'ensuit alors un virement classique 52 non instantané directement du compte CRU vers le compte CRI adressé au SIB de la banque B pour traitement. Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 48H.
Si par contre l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte virtuel CVR1 du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique Pt de la carte duale CD de ce dernier est augmenté instantanément (291, 25, 22) en T du montant Mi transféré par rapport au compte virtuel CVRl/CRU dans cas-ci. Le bénéficiaire R peut donc à partir de ce compte payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche (grâce au serveur externe SRI si le retrait est interbancaire). Dans le même temps, le plafond dynamique de la carte classique de l'émetteur E est automatiquement diminué en T du montant Mi par rapport au CVE/CRU : il s'agit là simplement d'un jeu de compensation du montant Mi entre les comptes virtuels CVE/CRU et CVRl/CRU adossés tous deux au CRU.
Pour le reste, et à partir du temps T, le plafond dynamique Pt de la carte duale du receveur R vis-à- vis du CVRl/CRU varie et change continuellement (sans jamais dépasser le montant maximal autorisé) en fonction des virements instantanés nouveaux reçus Mj (291, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,281) par le receveur R aux (GAB) à partir du CRU.
Figure 6A (Feuille 6/15): Procédé CRU/PNC2PNC
L'émetteur E non bancarisé émet à l'instant T un virement mobile intra bancaire d'un montant Mi au receveur R non bancarisé par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile. L'émetteur E dans ce cas effectue le virement bancaire en question de son compte bancaire virtuel CVE vers le compte virtuel CVR1 du receveur R domicilié à la même banque que celle de l'émetteur E.
Dans le procédé mobile CRU/PNC2PNC, le plafond dynamique de la carte classique C de l'émetteur E est automatiquement diminué (28, 25, 21) en T du montant Mi par rapport au compte virtuel CVE/CRU. Il s'ensuit alors un jeu de compensation du montant Mi au sein même du CRU puisque dans le même temps le plafond dynamique Pt de la carte classique du receveur R est augmenté (29, 25, 22) du montant Mi transféré et ce par rapport au CVRl/CRU. Le bénéficiaire R peut donc à partir de ce compte payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche grâce le cas échéant au serveur externe SRI.
A partir du temps T, le plafond Pt de la carte classique du receveur R vis-à-vis du CVRl/CRU varie et change continuellement sans jamais dépasser le montant maximal autorisé des virements monétiques mobiles et ce en fonction des virements instantanés nouveaux reçus Mj (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,28) aux (GAB) à partir du CRU.
Figure 7A (Feuille 7/15): Procédé CRU/PNC2PC-CVR/BD
L'émetteur E non bancarisé émet à l'instant T un virement mobile interbancaire d'un montant Mi au receveur R bancarisé par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile. L'émetteur E dans ce cas a le choix d'effectuer le virement bancaire en question de son compte bancaire virtuel CVE domicilié dans une banque Bl vers le compte courant bancaire CR2 ou vers le compte virtuel CVR2 du receveur R tous deux domiciliés dans une autre banque B2 distincte de Bl. Dans le procédé CRU/PNC2PC-CVR/BD, si l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte courant CR2 du receveur R alors le plafond dynamique de la carte classique de l'émetteur E est automatiquement diminué (28, 25, 21) en T du montant Mi par rapport au compte virtuel CVE/CRU. Il s'ensuit alors un ordre de virement classique 72 non instantané directement du compte CRU domicilié à la banque Bl vers le compte CR2 adressé au SIBl de la banque Bl pour traitement. L'ordre en question ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H.
Si par contre l'émetteur E de l'ordre de virement en question choisit d'effectuer un virement vers le compte virtuel CVR2 du receveur R (sur demande de celui-ci par exemple) alors le plafond dynamique Pt de la carte duale CD de ce dernier par rapport au CVR2/CRUR (domicilié à la banque B2) est augmenté instantanément (291, 25, 22) en T du montant Mi transféré. Le bénéficiaire R peut donc à partir de son compte CVR2/CRUR payer un service donné avec sa carte à cet instant même ou retirer son argent au (GAB) le plus proche et grâce au serveur externe SRI le cas échéant. Dans le même temps, le plafond dynamique de la carte classique E est automatiquement diminué en T du montant Mi par rapport au CVE/CRU (domicilié à la banque Bl). Au même instant un ordre de virement classique sous-jacent 71 de compensation est envoyé finalement au SIBl avec le concours du serveur externe SIT d'un montant Mi à effectuer du CRU vers le CRUR ce dernier étant domicilié à la banque B2.
A partir du temps T, le plafond dynamique Pt de la carte duale du receveur R vis-à-vis du CVR2/CRUR varie et change continuellement sans jamais dépasser le plafond maximal autorisé des virements monétiques mobiles et ce en fonction des virements instantanés nouveaux reçus Mj (291, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,281) aux (GAB) à partir du CRUR.
Figure 8A (Feuille 8/15): Procédé CRU/PNC2PIMC/BD
L'émetteur E non bancarisé émet à l'instant T un virement mobile interbancaire d'un montant Mi au receveur R non bancarisé par le biais d'un service USSD ou de l'application mobile installée sur son téléphone mobile. L'émetteur E dans ce cas effectue le virement bancaire en question de son compte bancaire virtuel CVE domicilié dans une banque Bl vers le compte virtuel CVR2 du receveur R domicilié dans une banque différente B2.
Dans le procédé CRU/PNC2PNC/BD le plafond dynamique de la carte classique de l'émetteur E est automatiquement décrémenté (28, 25, 21) en T du montant Mi par rapport au compte virtuel CVE/CRU. Il s'ensuit alors un ordre de virement classique sous-jacent 81 envoyé au SIBl avec le concours du serveur externe SIT d'un montant Mi du CRU vers le CRUR domiciliés respectivement à la banque Bl et B2. Dans le même temps le plafond dynamique Pt de la carte classique C du receveur R est incrémenté (29, 25, 22) du montant Mi transféré par rapport au compte virtuel CVR2/CRUR. Le bénéficiaire R peut donc à partir de ce dernier compte payer un service donné avec sa carte classique à cet instant même ou retirer son argent au (GAB) le plus proche et ce grâce au serveur externe SRI le cas échéant. Pour le reste, et à partir du temps T, le plafond dynamique Pt de la carte classique du receveur R vis-à-vis du CVR2/CRUR varie et change continuellement en fonction des virements instantanés nouveaux reçus Mj (29, 25, 22), des paiements par carte ainsi que des retraits effectués (20, 24 ,28) aux (GAB) à partir du CRUR mais sans jamais dépasser le montant maximal autorisé des virements monétiques mobiles.
Figure 9A (Feuille 9/15): Procédé de CARTE DUALE CD
Chaque receveur R bancarisé client d'une banque B disposant déjà d'un compte courant CR et enregistré au service de paiement mobile interpersonnel instantané (P2P) offert par ladite banque possède également un compte virtuel CVR. Par conséquent, ce receveur R se voit remettre une seule et même carte dite duale CD de paiement et de retrait aux (GAB) associée aussi bien à son compte courant CR que virtuel CVR adossé au CRU. Son propriétaire peut donc grâce à cette carte duale accéder à une interface aux (GAB) et aux (TPE) unique (90, 91, 92) lui donnant le choix d'accéder à l'un de ces deux comptes. S'il choisit d'accéder à son compte courant (94, 93, 95) alors il peut retirer le montant d'argent désiré ou le dépenser normalement par le biais de sa carte. Si par contre il opte pour l'utilisation de son compte virtuel (94, 93, 95, 96) alors il peut dans ce cas-ci retirer aux (GAB) la totalité ou une partie des fonds qui lui ont été virés en temps réel par le biais du téléphone mobile d'un émetteur E ou les dépenser en payant un service donné au moyen d'un (TPE).
Figure 1B (Feuille 10/15): Système intra bancaire : Cas (PC2PC-CVR)
L'émetteur E bancarisé client d'une banque B peut émettre en toute heure un virement mobile intra bancaire d'un montant M au receveur R bancarisé par le biais d'un service USSD (par le biais d'un serveur SU via des canaux de signaux GSM 102) ou d'une application installée sur son téléphone mobile TE via une connexion web sécurisée VPN 101 à un serveur central SC.
L'ordre de virement mobile en question est ensuite enregistré par le serveur externe SC. Ce dernier transmet l'information par le biais d'une connexion VPN 113 à un serveur dédié SD interne intégré au SB de la banque B. Le serveur SD ordonne alors au serveur interne de la banque SIB 105 de procéder au virement mobile (au choix du receveur R) du compte courant bancaire CE de l'émetteur E vers le compte courant bancaire CRI ou virtuel CVR1 (adossé au CRU) du receveur R. Dans le premier cas, le virement mobile 32 est traité par le SIB et exécuté au bout d'un délai normal ΔΤ. Dans le deuxième cas, ledit virement mobile est instantané puisqu'il est le résultat simultané de l'augmentation instantanée d'un montant M effectuée (dans sa propre base de données BSD 291) par le serveur dédié SD sur le plafond dynamique Pt de la carte duale CD associée au CVR1 et de l'ordre de virement classique sous-jacent 31 exécuté par le SIB du CE vers le CRU. La base de données centrale BSIB gérée par le SIB est alors notifié par le SD (25, 107) du nouveau montant du plafond 27 de la carte duale CD associée au compte CVR1 du receveur R. Les (GAB) et les (TPE) sont alors notifiés à leur tour par le SIB (109, 110) de ce nouveau montant lors de leur utilisation parle receveur R. Inversement, en cas de dépense ou de retrait aux (GAB) (à partir du CVR1/CRU) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré ou au moyen d'un (TPE), un ordre de dépense (109, 110) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation 23 instantanée (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte duale CD du receveur R du montant d'argent viré. Le SIB transmet ensuite au serveur SD un ordre de mise à jour (24, 107) dudit plafond Pt qu'il décrémente à son tour 281 du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant viré au moyen du téléphone mobile TE de l'émetteur E.
Enfin le serveur SIB transmet une confirmation de l'exécution dudit virement (via le serveur SD 106) au serveur SC 103 lequel la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 104 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS (Short Message Service) de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
Le receveur R a finalement le choix de payer 108 directement à partir du CVR1 adossé au CRU un service donné en utilisant sa carte duale CD au moyen d'un (TPE) (avec l'aide du serveur externe SRI) ou de retirer 108 la somme virée M ou une partie dm de cette somme au premier guichet automatique (GAB) rencontré et ce grâce au rôle le cas échéant du serveur externe SRI.
Figure 2B (Feuille 11/15): Système intra bancaire : Cas (PC2PNC)
L'émetteur E bancarisé client d'une banque B émet un virement mobile intra bancaire d'un montant M au receveur R non bancarisé par le biais d'un service USSD (par l'intermédiaire du serveur SU et via des canaux de signaux GSM 112) ou d'une application installée sur son téléphone mobile TE via une connexion web sécurisée (VPN) 111 au serveur central SC dans un premier temps.
Dans un deuxième temps, l'ordre du virement mobile instantané en question est enregistré par le serveur externe SC. Ce dernier transmet l'information par le biais d'une connexion VPN 113 à un serveur dédié SD interne intégré au SB de la banque B. Le serveur SD ordonne alors au SIB 115 de procéder à un virement classique sous-jacent 41 du compte courant bancaire CE de l'émetteur E vers le compte virtuel CVR1 (adossé au CRU) du receveur R. Dans ce cas, ledit virement mobile est instantané puisqu'il est le résultat simultané de l'incrémentation instantanée d'un montant M effectuée par le serveur dédié SD (dans sa propre base de données BSD 29) sur le plafond dynamique Pt de la carte classique C associée au CVR1 et de l'ordre de virement classique sous-jacent exécuté par le SIB du CE vers le CRU. La base de données centrale BSIB gérée par le SIB est alors notifié par le SD (25, 117) du nouveau montant du plafond de la carte classique C associée au compte CVR1 du receveur R. Les (GAB) et les (TPE) sont alors notifiés à leur tour par le SIB (119, 120) de ce nouveau montant lors de leur utilisation par le receveur R. Inversement, en cas de dépense ou de retrait aux (GAB) (à partir du CVRl/CRU) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré ou au moyen d'un (TPE), un ordre de dépense (119, 120) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation instantanée 20 (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte classique C du receveur R du montant d'argent viré. Le SIB transmet ensuite au serveur SD un ordre de mise à jour (24, 117) dudit plafond Pt qu'il décrémente à son tour 28 du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant viré au moyen du téléphone mobile TE de l'émetteur E.
Enfin le serveur SIB transmet une confirmation de l'exécution dudit virement (via le serveur SD 116) au serveur SC 113 lequel la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 114 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
Au final, le receveur R peut donc en utilisant sa carte classique C associée à son compte virtuel CVR1 adossé au CRU payer 118 directement un service donné au moyen d'un (TPE) (grâce à l'intervention à ce niveau du serveur externe SRI) ou retirer 118 la somme M virée instantanément ou une partie dm de cette somme (grâce au rôle le cas échéant du serveur externe SRI) au premier guichet automatique (GAB) rencontré.
Figure 3B (Feuille 12/15): Système intra bancaire : Cas (PNC2PC-CVR)
L'émetteur E non bancarisé dans une banque B émet dans un premier temps un virement mobile intra bancaire d'un montant M au receveur R bancarisé par le biais d'un service USSD (par le biais du serveur SU et via des canaux de signaux GSM 122) ou d'une application installée sur son téléphone mobile TE via une connexion web sécurisée (VPN) 121 au serveur central SC.
Dans un deuxième temps, l'ordre de virement mobile en question est enregistré par le serveur externe SC. Ce dernier transmet l'information par le biais d'une connexion VPN 123 à un serveur dédié SD interne intégré au SB de la banque B. Si l'émetteur E opte pour un virement vers le compte courant du receveur R sur demande de celui-ci par exemple, alors le serveur SD ordonne au SIB 126 de procéder au virement classique sous-jacent du compte bancaire virtuel CVE de l'émetteur E vers le compte courant bancaire CRI du receveur R. Dans ce cas, l'ordre de virement équivaut à un virement classique 52 entre le CRU et le CRI : il est alors traité par le SIB et exécuté au bout d'un délai normal ΔΤ. Dans le cas où l'émetteur E opte pour un virement en temps réel vers le compte virtuel du receveur R sur demande de celui-ci par exemple, ledit virement est alors instantané puisqu'il est le résultat simultané de l'augmentation instantanée d'un montant M effectuée par le serveur dédié SD (via la base de données BSD 291) sur le plafond dynamique Pt de la carte duale CD associée au CVR1 et de la décrémentation 28 du plafond dynamique de la carte classique associée au CVE du même montant. La base de données centrale BSIB gérée par le SIB est alors notifié par le SD (25, 27, 21, 125, 127) des nouveaux montants des plafonds desdites cartes associées aux comptes CVE et CVRl respectivement de l'émetteur E et du receveur R. Les (GAB) et les (TPE) sont alors notifiés à leur tour par le SIB (129, 130) de ces nouveaux montants au moment de leur utilisation par l'émetteur E ou le receveur R.
Inversement, en cas de dépense ou de retrait (à partir du CVR1/CRU) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré aux (GAB) ou au moyen d'un (TPE), un ordre de dépense (129, 130) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation 23 instantanée (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte duale CD du receveur R du montant d'argent viré. Le SIB transmet ensuite au serveur SD un ordre de mise à jour (24, 127) dudit plafond Pt qu'il décrémente à son tour 281 du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant viré au moyen du téléphone mobile TE de l'émetteur E.
Par ailleurs, dans ce cas de virement monétique mobile interpersonnel de type PNC2PC, le plafond dynamique de la carte classique C associée au compte virtuel CVE de l'émetteur E est décrémenté à son tour 28 instantanément mais l'information y afférente émane d'abord du SD via la BSD (25, 125) pour être ensuite traitée au niveau du SIB via la BSIB suivant un processus de décrémentation inverse.
Enfin le serveur SIB transmet une confirmation de l'exécution dudit virement (via le serveur SD 126) au serveur SC 123 lequel la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 124 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
In fine le receveur R a le choix de payer 128 directement à partir du CVRl adossé au CRU un service donné au moyen d'un (TPE) (grâce à l'intervention à ce niveau du serveur externe SRI) en utilisant sa carte duale CD de paiement et de retrait ou de retirer 128 la somme virée M ou une partie dm de cette somme (grâce au rôle le cas échéant du serveur externe SRI) au premier guichet automatique (GAB) rencontré.
Figure 4B (Feuille 13/15): Système intra bancaire : Cas (PNC2PNC)
L'émetteur E non bancarisé d'une banque B émet un virement mobile intra bancaire d'un montant M au receveur R non bancarisé par le biais d'un service USSD (par le biais du SU et via des canaux de signaux GSM 132) ou d'une application installée sur son téléphone mobile TE de type Smartphone via une connexion web sécurisée (VPN) 131 au serveur central SC dans un premier temps. Dans un deuxième temps, l'ordre de virement bancaire en question est enregistré par le serveur externe SC. Ce dernier transmet l'information par le biais d'une connexion VPN 133 à un serveur dédié SD interne intégré au SB de la banque B. Dans ce cas, ledit virement est instantané puisqu'il est le résultat simultané de l'incrémentation 29 instantanée d'un montant M effectuée par le serveur dédié SD sur le plafond dynamique Pt de la carte classique C associée au CVR1 et de la diminution 28 du même montant du plafond dynamique de la carte classique associée au CVE. Le serveur SIB est alors notifié par le SD (25, 135, 137) des nouveaux montants des plafonds desdites cartes associées aux comptes CVE et CVR1 respectivement de l'émetteur E et du receveur R. Les (GAB) et les (TPE) sont alors notifiés à leur tour par le SIB (139, 140) de ces nouveaux montants au moment de leur utilisation par l'émetteur E ou le receveur R.
Inversement, en cas de dépense ou de retrait (à partir du CVR1/CRU) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré aux (GAB) ou au moyen d'un (TPE), un ordre de dépense (139, 140) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation 20 instantanée (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte classique C du receveur R du montant d'argent viré. Le SIB transmet ensuite au serveur SD un ordre de mise à jour (24, 137) dudit plafond Pt qu'il décrémente à son tour 28 du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant viré au moyen du téléphone mobile TE de l'émetteur E.
Enfin le serveur SIB transmet une confirmation de l'exécution dudit virement (via le serveur SD 136) au serveur SC 133 lequel la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 134 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
Finalement le receveur R peut en utilisant sa carte classique C associée à son compte virtuel CVR1 adossé au CRU payer 138 directement un service donné au moyen d'un (TPE) (grâce à l'intervention à ce niveau du serveur externe SRI) ou retirer 138 la somme virée M ou une partie dm de cette somme au premier guichet automatique (GAB) rencontré (grâce au rôle le cas échéant du serveur externe SRI).
Figure 5B (Feuille 14/15): Système intra bancaire intégré
L'émetteur E domicilié dans une banque B émet un virement mobile intra bancaire d'un montant M au receveur ou bénéficiaire R domicilié dans la même banque et ce par le biais d'un service USSD (grâce au rôle du SU via des canaux de signaux GSM 142) ou d'une application installée sur son téléphone mobile TE via un réseau internet sécurisé (VPN) 141 au serveur central SC.
L'utilisateur E disposant d'un compte courant bancaire propre CE ou d'un compte virtuel CVE adossé au CRU domiciliés à la banque B transfère donc de l'argent par le biais de son téléphone mobile TE au bénéficiaire R disposant d'un compte courant propre CRI ou d'un compte virtuel CVRl adossé au CRU et domiciliés à la même banque B. Dans un système intégré, étant donné qu'il n'existe pas de serveur externe tel que le SC, le rôle de ce dernier est confondu avec celui du SD. L'ordre de virement est donc transmis directement au SD (via le SU le cas échéant).
Le serveur dédié SD interne au système interne SB de la banque B transmet l'ordre de virement mobile émis pour exécution (144, 145) au serveur interne bancaire SIB selon les modèles de virements monétiques mobiles interpersonnels (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC). Le SIB procède alors au virement intra bancaire classique (31, 32, 41, 52, 71, 72, 81, 145) entre les comptes objets dudit virement (hormis le cas d'un virement de type (PNC2PNC)). Ce virement est ensuite exécuté au bout d'un certain délai noté ΔΤ. Entre-temps, le système intra bancaire intégré va permettre dans tous les cas de virements déjà cités (hormis le cas d'un virement non instantané de type (PC2PC)), au serveur interne SD domicilié à la banque B de procéder en temps réel à l'augmentation dans sa propre base de données BSD (29, 291) du plafond dynamique Pt de la carte classique C ou duale CD du bénéficiaire R par rapport au compte de réserve unique CRU (domicilié à la banque B). Il s'ensuit alors de la part du serveur SD un ordre de mise à jour (25, 146) dudit plafond Pt adressé au serveur SIB. Ce dernier exécute cet ordre en incrémentant à son tour (22, 27) ledit plafond du même montant dans sa propre base de données centrale BSIB. Le plafond dynamique Pt est ainsi mis à jour suite au virement monétique mobile reçu par le receveur R. Il en résulte que le montant M viré est ainsi mis instantanément à la disposition du receveur R pour retrait aux (GAB) ou pour paiement d'un service donné par le biais d'un (TPE).
Inversement, en cas de dépense ou de retrait (à partir du CVR1/CRU) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré aux (GAB) ou au moyen d'un (TPE), un ordre de dépense (148, 149) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation (20, 23) instantanée (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte de type classique C ou duale CD du receveur R du montant d'argent viré. Le SIB transmet ensuite au serveur SD un ordre de mise à jour (24, 146) dudit plafond Pt qu'il décrémente à son tour du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant qui lui a été viré au moyen du téléphone mobile TE de l'émetteur E.
Par ailleurs, dans le cas de virement monétiques mobiles interpersonnels de type PNC2PC ou PNC2PNC, le plafond dynamique de la carte classique C associée au compte virtuel CVE de l'émetteur E est décrémenté à son tour 28 instantanément mais l'information y afférente émane d'abord du SD via la BSD 144 pour être ensuite traitée au niveau du SIB via la BSIB (25, 21) suivant un processus de décrémentation inverse.
Enfin le serveur SIB transmet une confirmation de l'exécution dudit virement au serveur SD 145 qui la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 143 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
In fine, le bénéficiaire R a donc le choix de retirer 147 immédiatement le montant M ou une partie dm de ce montant en tout temps au (GAB) le plus proche (avec le concours du serveur externe SRI si le retrait est interbancaire) ou de payer 147 par l'intermédiaire d'un (TPE) (avec le concours là aussi du serveur externe SRI) un service donné avec sa carte duale CD ou classique C associée selon le cas à son compte courant CRI et/ou virtuel CVR1 adossée de fait au CRU.
Figure 6B (Feuille 15/15): Système interbancaire global
L'émetteur E domicilié dans une banque Bl émet un virement mobile interbancaire d'un montant M au receveur ou bénéficiaire R domicilié dans une autre banque B2 et ce par le biais d'un service USSD (grâce au rôle du SU via des canaux de signaux GSM 152) ou d'une application installée sur son téléphone mobile TE via une connexion web sécurisée (VPN) 151 au serveur central SC.
L'émetteur E disposant d'un compte courant bancaire propre CE ou d'un compte virtuel CVE adossé au CRU domiciliés à la banque Bl transfère de l'argent par le biais de son téléphone mobile TE au bénéficiaire R disposant d'un compte courant propre CR2 ou d'un compte virtuel CVR2 adossé au CRUR et domiciliés à la banque B2. Le serveur central SC externe aux systèmes internes SBl et SB2 (respectivement de la banque émettrice Bl et de la banque réceptrice B2) transmet par connexion VPN 153 l'ordre du virement mobile émis à un serveur dédié SDl intégré en interne au SBl. Le serveur SDl transmet 157 un ordre du virement classique sous-jacent (31, 41, 71, 81) pour exécution au SIB1 selon les modèles de virements monétiques mobiles interpersonnels (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC). Le SIB1 procède alors au virement interbancaire classique entre les deux banques distinctes Bl et B2 et plus précisément entre les comptes objets dudit virement. Ce virement est ensuite exécuté par le SIT (Système Interbancaire de Télé-compensation) au bout d'un certain délai noté ΔΤ. Entre-temps, le système interbancaire global va permettre dans tous les cas de virements déjà cités (hormis le cas d'un virement non instantané de type (PC2PC)), que l'information soit transmise directement 154 et instantanément par connexion VPN du serveur central externe SC au serveur dédié SD2 domicilié à la banque B2. Ce dernier procède alors en temps réel dans sa propre base de données BSD2 à l'incrémentation (29, 291) d'un montant M des plafonds dynamiques Pt des cartes classiques C ou duales CD du bénéficiaire R par rapport au compte de réserve unique CRUR (domicilié à la banque B2). Le serveur interne SIB2 domicilié à la banque B2 est alors notifié par le SD2 (25, 159) du nouveau montant du plafond du compte CVR2 du receveur R. Le SIB2 incrémente (22, 27) à son tour ledit plafond du même montant dans sa propre base de données centrale BSIB2. Il en résulte que le montant M viré est ainsi mis instantanément à la disposition du receveur R pour retrait aux (GAB) ou pour paiement d'un service donné au moyen d'un (TPE). Les (GAB) et les (TPE) sont notifiés à leur tour par le SIB2 (162, 163) de ce nouveau montant au moment de leur utilisation par le receveur R.
Inversement, en cas de dépense ou de retrait (à partir du CVR2/CRUR) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré aux (GAB) ou au moyen d'un (TPE), un ordre de dépense (162, 163) est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB2. Ce dernier procède alors à la décrémentation (20, 23) instantanée (dans la base de données centrale BSIB2 gérée par le SIB2) du plafond dynamique Pt de la carte de type classique C ou duale CD du receveur R du montant d'argent viré. Le SIB2 transmet ensuite au serveur SD2 un ordre de mise à jour (24, 159) dudit plafond Pt qu'il décrémente à son tour (28, 281) du même montant dans sa propre base de données BSD2. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la consommation par le receveur R d'une partie ou de la totalité du montant qui lui a été viré au moyen du téléphone mobile TE de l'émetteur E.
Par ailleurs, dans le cas de virement monétiques mobiles interpersonnels de type PNC2PC ou PNC2PNC, le plafond dynamique de la carte classique C associée au compte virtuel CVE de l'émetteur E est décrémenté 28 à son tour instantanément mais l'information y afférente émane d'abord du SD1 via la BSD1 (25, 156) pour être ensuite traitée au niveau du SIB1 via la BSIB1 suivant un processus de décrémentation inverse.
Enfin le serveur SIB2 transmet une confirmation de l'exécution dudit virement (via le serveur SD2 158) au serveur SC 154 lequel la transmet à un serveur de messagerie SM par le biais d'un canal de signalisation 155 (norme GSM). L'émetteur E et le bénéficiaire R reçoivent alors en quelques secondes un SMS de confirmation (effectuée par le biais du serveur de messagerie SM) sur leurs téléphones mobiles (TE et TR) du succès du virement en question.
In fine, le bénéficiaire R a donc le choix de retirer 160 immédiatement le montant M ou une partie dM de ce montant en tout temps au (GAB) le plus proche (avec le concours du serveur externe SRI si le retrait est interbancaire) ou de payer 160 par l'intermédiaire d'un (TPE) (avec le concours là aussi du serveur externe SRI) un service donné avec sa carte duale CD ou classique C associée selon le cas à son compte courant CR2 et/ou virtuel CVR2 adossée de fait au CRUR.
1.5 Mode de réalisation de l'invention
La mise en place et la réalisation des systèmes et des procédés sous-jacents à la solution objet de l'invention impliquent différents éléments et systèmes. En effet, quatorze (14) principaux éléments et systèmes sont nécessaires au développement en aval de ladite solution. Ces systèmes sont :
• un téléphone mobile émetteur TE appartenant à un émetteur E
• un téléphone mobile récepteur TR appartenant à un receveur ou bénéficiaire R
• un serveur externe interactif distant SU destiné aux utilisateurs de téléphones basiques et assurant un service USSD de transmission de données via des canaux de signaux GSM et offrant une interface client dédiée aux échanges transactionnels induits par les virements monétiques mobiles
• une application mobile interactive agissant en tant qu'interface client hébergée dans le Smartphone des utilisateurs et dédiée aux échanges transactionnels induits par les virements monétiques mobiles. Elle est connectée via une connexion web sécurisée (VPN) directement au serveur central SC.
• un serveur central SC, chef d'orchestre de tous les échanges de données entre serveurs et systèmes par liaisons de type VPN ou GSM principalement et notamment entre les serveurs SU, SM, SD et le système interne bancaire SB
• un serveur d'information (interne) bancaire SIB d'une banque B
• un serveur SD dédié au service objet de l'invention s'interfaçant et s'intégrant directement au SIB d'une banque B
• un compte relais et de réserve unique CRU domicilié à la banque B
• une carte duale CD ou classique C de paiements et de retraits aux (GAB) rechargeable à distance et associée à un compte courant et/ou virtuel adossé au CRU et appartenant au receveur R
• un serveur SM qui assure le service de messagerie et de notifications des utilisateurs du service objet de l'invention
• un serveur externe distant SRI qui assure le service de gestion des services de retrait aux (GAB) lorsque les retraits sont interbancaires ainsi que les services de paiements par carte au moyen d'un (TPE)
• un serveur externe distant SIT Interbancaire de télé-compensation qui assure le service de gestion des virements interbancaires
• un guichet automatique bancaire (GAB)
• un terminal de paiement électronique (TPE)
A noter que dans le cas d'un système interbancaire global, chaque banque a son propre serveur dédié SD et interne SIB ainsi que son propre compte de réserve unique CRU. En référence au dessin 15 de la feuille 15, les deux banques distinctes sont notées Bl et B2 et leurs serveurs dédiés et internes ainsi que leur comptes de réserve sont respectivement (SD1, SIB1, CRU) et (SD2, SIB2, CRUR). 1.5.1 Eléments essentiels du système de paiement mobile interpersonnel instantané (P2P) et leurs rôles :
Les téléphones mobiles de l'émetteur E et du receveur R
Le service de paiement mobile interpersonnel instantané (P2P) objet de l'invention repose sur l'utilisation par l'émetteur E et le receveur R de téléphones mobiles de tous types (Smartphones ou basiques).
Le serveur distant interactif SU :
Le serveur distant SU permet de couvrir en version USSD l'ensemble des interactions de l'utilisateur d'un téléphone mobile de type basique avec le service de paiement mobile interpersonnel instantané(P2P) objet de l'invention. Ce serveur externe au SIB de la banque B est géré par un prestataire externe. Grâce à cette version, ce dernier a la possibilité de :
• activer son compte client pour la première fois après la saisie d'un code PIN temporaire remis par la banque B
• changer son code PIN une fois l'activation enclenchée
• demander l'accès au service de paiement mobile interpersonnel (P2P) grâce à la saisie du PIN définitif
• permettre de créer un ordre de virement mobile intra ou interbancaire et de l'envoyer par le biais d'un canal GSM sécurisé au serveur central SC: o d'un compte courant CE vers un autre compte courant CR ou compte virtuel CVR
(Basé sur le procédé CRU/PC2PC-CVR)
o d'un compte courant CE vers un compte virtuel CVR
(Basé sur le procédé CRU/PC2PNC)
o d'un compte virtuel CVE vers un compte courant CR
(Basé sur les procédés CRU/PNC2PC-CVR ou CRU/PNC2PC-CVR/BD)
o d'un compte virtuel CVE vers un autre compte virtuel CVR
(Basé sur les procédés CRU/PNC2PNC ou CRU/PNC2PNC/BD)
• communiquer les soldes et plafonds des comptes associés (courants ou virtuels) L'application mobile pour Smartphone :
L'application mobile pour Smartphone permet dé couvrir l'ensemble des interactions de l'utilisateur avec le service objet de l'invention en permettant les fonctionnalités suivantes :
• activation de l'application mobile en question
• exécution des mêmes fonctionnalités que celles offertes par le SU et décrites ci-haut L'application mobile peut exister sur différentes plateformes. La plus grande partie de l'application est développée sur un outil de génération multiplateforme tel que Phone Gap ce qui facilite grandement une extension de la logique de métier de l'application sans la redévelopper sur d'autres plateformes. Néanmoins, c'est le procédé technique de l'invention qui permet de savoir s'il faut développer tout en natif ou pas. Il est néanmoins nécessaire de créer des plugins à développer en code natif pour les aspects de sécurité, tels que la gestion des certificats.
Le serveur central SC :
Le serveur central SD est le chef d'orchestre de tous les échanges entre serveurs et systèmes entre autres les serveurs SU, S , SD1, SD2 et les systèmes internes bancaires SIB1 et SIB2 dans le cas de deux banques partenaires du service objet de l'invention. Plus spécifiquement, il permet de couvrir l'ensemble des interactions initiées par les utilisateurs dudit service en offrant la possibilité de :
• identifier et authentifier les acteurs du service objet de l'invention (utilisateurs, applications clients, banques et leurs serveurs dédiés, administrateurs du serveur central)
• crypter ses échanges avec les applications mobiles pour Smartphones et les serveurs dédiés SD
• générer des certificats électroniques pour les utilisateurs du service objet de l'invention
• activer et bloquer des comptes de clients
• activer et Bloquer des applications mobiles
• transmettre des ordres de virements mobiles aux SD, SD1 et SD2 pour tous les types de virements monétiques mobiles interpersonnels (PC2PC), (PC2PNC), (PNC2PC) et (PNC2PNC)
• modifier les codes PIN des utilisateurs du service objet de l'invention
• notifier les utilisateurs par SMS par le biais du SM
• connaître l'état des statistiques du système en calculant les volumes mensuels des commissions et du chiffre d'affaires et autres données nécessaires à la gestion administrative et financière du système de l'invention
• gérer les vols ou les pertes d'éléments d'authentification de comptes clients
• gérer des déclarations de transactions frauduleuses etc..
Le serveur interne bancaire SIB
Ce serveur est un élément interne au système d'information SB qui est l'ensemble organisé des ressources (matériels, logiciels, personnel, données et procédures) qui permettent de collecter, regrouper, classifier, traiter et diffuser de l'information au sein d'une banque donnée B offrant le service sous-jacent à l'invention.
En effet, l'utilisation combinée de moyens informatiques, électroniques et de procédés de télécommunications permet aujourd'hui -selon les besoins et les intentions exprimés- d'accompagner, d'automatiser et de dématérialiser quasiment toutes les opérations incluses dans les activités d'une banque B. L'invention implique nécessairement en premier lieu un interfaçage et une intégration des systèmes et des éléments du service de paiement mobile interpersonnel instantané (P2P) notamment le serveur SD avec un serveur du système d'information SIB d'une banque B offrant ce service. Les virements monétiques mobiles induits par l'invention sont exécutés en dernier lieu et en grande partie par le serveur SIB de ladite banque B. Les paiements au moyen de (TPE) et les retraits aux (GAB) par carte duale CD ou classique C sont également gérés en grande partie par le SIB mais avec le concours le cas échéant d'un serveur externe dédié SRI.
Le serveur SIB est l'élément exécutant en aval d'une grande partie des tâches afférentes aux virements monétiques mobiles. Il permet notamment de :
• calculer et modifier en temps réel les plafonds dynamiques Pt (en interaction avec le serveur dédié SD) des cartes duales CD ou classiques C dans une base de données centrale BSIB et ce après chaque opération de virement mobile, de paiement ou de retrait effectuées à partir des comptes virtuels des utilisateurs domiciliés à la même banque B
• vérifier, autoriser et enregistrer les paiements et retraits en relation avec un virement monétique mobile effectué respectivement au moyen d'un (TPE) ou aux (GAB)
• exécuter les ordres de virements monétiques classiques (émanant du serveur dédié SD) sous-jacents à tous les types de virements mobiles (PC2PC), (PC2PNC), (PNC2PC), (PNC2PNC)
• afficher les plafonds dynamiques en temps continu des cartes associées aux comptes virtuels des utilisateurs du service objet de l'invention
• afficher en temps continu le solde global du compte de réserve unique CRU
Le serveur dédié SD
Cas d'un système intra bancaire ou interbancaire global de paiement mobile interpersonnel instantané (P2P) :
Ce serveur est l'élément pivot entre les systèmes externes objet de l'invention (SU, SC.) et le système/serveur d'information interne SB/SIB d'une banque donnée B. Il permet notamment de :
• identifier et/ou authentifier les acteurs du service objet de l'invention (utilisateurs, serveur central SC, le système interne SIB de la banque B, les chargés de clientèle et les administrateurs du SD etc..)
• crypter ses échanges avec le serveur central SC et le serveur SIB
• créer des cartes duales CD ou classiques C de paiement ou de retrait aux (GAB) destinées aux utilisateurs du service objet de l'invention
• créer le compte de réserve unique nommé CRU au sein du SIB
• calculer et modifier en temps réel les plafonds dynamiques Pt (en interaction avec le serveur interne SIB) des cartes duales CD ou classiques C dans une base de données dédiée BSD et ce après chaque opération de virement mobile, de paiement ou de retrait effectuées à partir des comptes virtuels des utilisateurs domiciliés à la même banque B
• gérer le solde global du compte de réserve unique CRU • vérifier et autoriser les virements monétiques mobiles effectués au moyen d'un téléphone mobile TE d'un émetteur E
• ordonner au SIB de la banque B d'exécuter les ordres de virements monétiques classiques sous-jacents à tous les types de virements mobiles (PC2PC), (PC2PNC), (PNC2PC), (PNC2PNC)
• donner la possibilité au chargé de clientèle de :
o créer un compte virtuel CVR en saisissant les informations requises pour l'enregistrement au service objet de l'invention
o gérer les erreurs et les fraudes éventuelles d'utilisation de comptes virtuels douteux o « blacklister » et bloquer les services liés aux comptes virtuels douteux (à inscrire dans un fichier d'interdictions bancaires...),
o produire les codes PIN temporaires accompagnés des procédures d'activation du service en question
o réinitialiser les codes PIN des cartes de paiement et de retrait liés aux comptes virtuels
o imprimer les contrats du service offert par l'invention
• donner la possibilité à l'administrateur SD de :
o connaître l'état des statistiques du système en calculant les volumes journaliers, hebdomadaires et mensuels des virements et commissions, le chiffre d'affaires et autres données nécessaires à la gestion administrative et financière du système de l'invention
o limiter les plafonds dynamiques Pt des cartes et autres limitations, par exemple :
fixer les montants maximaux des virements autorisés
fixer les montants maximaux à retirer ou à dépenser en paiement par jour
fixer le niveaux plancher ou seuil du compte de réserve unique CRU en dessous duquel les retraits aux (GAB) et les paiements par (TPE) sont strictement interdits
o gérer les alertes dans les cas suivants par exemple :
si le nombre d'utilisateurs actifs dépasse un seuil prédéfini tolérable
si le montant des retraits aux (GAB) et les paiements par (TPE) journaliers dépassent un seuil critique prédéfini
o lister les comptes virtuels bloqués et les motifs de leurs blocages
o lister les virements suspects
o annuler les virements suspects
Cas d'un système intra bancaire intégré :
Dans le cas d'un tel système, le rôle du serveur interne SD est accru du fait qu'il exerce également le rôle exercé par le serveur central SC dans le cas d'un système intra bancaire ou interbancaire global. En effet, dans un système intégré, il n'existe pas de serveur externe tel que le SC et donc le rôle de ce dernier est confondu avec celui du SD. Le système CRU
Tous les comptes virtuels notés CVR impliqués par le service de paiement mobile interpersonnel instantané (P2P) objet de l'invention et domiciliés dans une même banque donnée B forment un système assimilé à un compte relais unique appelé compte de réserve unique CRU. Ce compte peut être accédé par une multitude de cartes duales CD ou classiques C de retrait et de paiement appartenant à des bénéficiaires R de virements monétiques mobiles : c'est donc un compte multicarte où chaque carte de retrait ou de paiement qui lui est adossée est en fait associée à un compte courant et/ou virtuel et dispose de son propre plafond dynamique en un temps t noté Pt.
C'est donc le système CRU formant le compte de réserve unique CRU qui assure l'instantanéité recherchée des virements monétiques mobiles interpersonnels de type PC2PNC, PNC2PC et PNC2PNC. En effet cette dernière est assurée par la mise à disposition instantanée des montants virés par un émetteur E à un bénéficiaire R et ce grâce à un jeu de variations des plafonds desdites cartes (duales ou classiques) de paiement ou de retrait. Le bénéficiaire R a donc le choix de retirer de ce compte relais l'argent qui lui est viré instantanément au premier (GAB) rencontré ou de le dépenser par le biais de sa carte duale ou classique de paiement et de retrait associée à son compte courant CR et/ou virtuel CVR/CRU. Ce compte de réserve est ainsi nommé car il est pré-provisionné par la banque B où il est domicilié des montants susceptibles d'être retirés aux (GAB) ou dépensés au moyen d'un (TPE) par les receveurs R enregistrés au service offert par ladite banque. La réserve à allouer à ce compte de réserve dépend du produit du nombre espéré prévu et estimé des utilisateurs potentiels du service en question par le montant espéré total estimé des paiements et retraits effectués par un utilisateur moyen dudit service le tout pondéré par un facteur réducteur égal au ratio Cooke (8%).
Le serveur de messagerie SM :
Le serveur externe de messagerie SM est connecté par le biais d'un canal de signalisation (norme GSM) au serveur central SC et permet à ce dernier de faire des notifications (aux utilisateurs du service objet de l'invention) via des messages SMS confirmant le succès des opérations de virements monétiques mobiles interpersonnels instantanés (P2P) et leurs réceptions dans les comptes courants ou virtuels des bénéficiaires. Ces SMS sont envoyés aux numéros des téléphones mobiles respectivement de l'émetteur E et du bénéficiaire R.
La carte classique ou duale CD de paiement et de retrait :
Chaque bénéficiaire ou receveur R utilisateur du service de paiement mobile interpersonnel instantané (P2P) objet de l'invention dispose d'un compte virtuel CVR de réception des virements monétiques instantanés. Il se voit remettre donc une carte classique de paiement et de retrait aux (GAB) associée directement à son compte virtuel lui-même adossé au CRU appartenant et domicilié à la même banque B que celle de l'utilisateur. Néanmoins dans le cas des utilisateurs déjà bancarisés (détenteurs déjà de comptes courants), l'invention propose et permet à ces derniers d'utiliser une seule et même carte dite duale CD de paiement et de retrait aux (GAB). Dès lors, cette carte est associée aux deux comptes du bénéficiaire bancarisé à savoir son compte courant CR et son compte virtuel CVE : son propriétaire peut donc grâce à cette carte duale accéder à une interface unique aux (GAB) et aux (TPE) lui donnant ainsi le choix de payer un service donné ou retirer les fonds qui lui ont été virés ou d'autres fonds à partir du compte choisi CR ou CVR.
En fin dé compte, et grâce à l'invention, l'utilisateur bancarisé du service en question n'aura à utiliser qu'une et une seule carte duale de paiement et de retrait associée simultanément à son compte courant et à son compte virtuel adossé au compte de réserve unique CRU.
Le serveur distant interbancaire SRI :
Le serveur externe SRI externe assure le service d'interopérabilité nationale des retraits effectués dans les guichets automatiques bancaires (GAB). Il est géré par un prestataire externe et permet donc à un client du service objet de l'invention de retirer l'argent qui lui est viré instantanément par téléphone mobile et ce dans n'importe quel (GAB) de n'importe quelle banque. Il est connecté de façon sécurisé aux SIB de toutes les banques.
Le serveur distant interbancaire SIT :
Le serveur distant externe SIT (serveur Interbancaire de télé-compensation) assure quant à lui le service électronique de gestion et de compensation des virements classiques interbancaires. Il est géré par un prestataire externe et permet donc à une banque Bl émettrice donnée de procéder à des virements interbancaires de fonds vers une autre banque B2 réceptrice. Les traitements de ces virements classiques interbancaires mettent généralement un certain délai ΔΤ pour être exécutés. Ce serveur est connecté de façon sécurisé aux SIB de toutes les banques.
1.5.2 Aspects fonctionnels et de sécurité de l'invention
1.5.2.1 Aspects fonctionnels
L'utilisateur aura le choix entre deux interfaces clients pour utiliser le service objet de l'invention :
• via une application mobile installée sur les téléphones mobiles de dernière génération
• via un service USSD assuré par un serveur interactif distant (SU)
1.5.2.1.1 Enregistrement au service objet de l'invention :
Toute personne physique non frappée d'une interdiction bancaire est autorisé à s'enregistrer au service en question et ce en créant un compte d'utilisateur (ou compte client) qui lui permet d'avoir un compte courant CR ou virtuel CVR. Il suffit au futur utilisateur du service de se rendre auprès d'un chargé de clientèle à l'une des agences de la banque B de son choix, muni :
• de sa carte d'identité (CIN)
• d'une attestation de domicile
• du numéro de téléphone à associer au service en question
• le cas échéant de son numéro de compte courant déjà existant (à associer au service)
• d'une autorisation de prélèvement automatique de frais et de commissions de son compte courant ou virtuel associés au service en question
Le chargé de clientèle remet au futur utilisateur un document expliquant comment activer et utiliser le service et le désactiver le cas échéant. Il est remis ensuite au client enregistré un code PIN temporaire d'une durée de vie de 30 min. Grâce à ce dernier, l'utilisateur peut activer sur le champ le service une première fois par le biais de son téléphone mobile après avoir téléchargé l'application mobile y afférente ou en appelant le numéro spécial d'accès au service USSD correspondant.
1.5.2.1.2 Activation initiale d'un compte d'utilisateur ou compte client :
Dans le cas où l'utilisateur opte pour le service USSD alors il doit pour activer son compte utilisateur une première fois appeler le numéro de téléphone spécial du serveur interactif distant SU qui lui demande la saisie du code PIN temporaire. Après vérification que le code PIN temporaire est bien celui associé au numéro appelant, le serveur SU demande alors à l'utilisateur de saisir un nouveau code PIN permanent de son choix qu'il doit ressaisir une seconde fois pour vérification.
Si par contre l'utilisateur opte pour le téléchargement de l'application mobile sur son téléphone portable alors dans ce cas il peut télécharger ladite application sur l'App Store ou sur Play Store ou sur d'autres plateformes. Une fois téléchargée, l'utilisateur peut activer le service en question en suivant les mêmes étapes que pour l'activation du service USSD décrites ci-haut.
1.5.2.1.3 Accès à l'interface de communication avec le service objet de l'invention :
L'émetteur E pourra donc accéder audit service après activation de ce dernier par deux moyens :
Via le service USSD pour téléphones mobiles d'entrée de gamme (type basique) :
L'utilisateur E compose un numéro de téléphone spécial pour se connecter au serveur interactif distant SU. Si son numéro d'appel est reconnu comme étant celui d'un utilisateur du service en question, alors le SU demande à l'utilisateur de saisir son code PIN permanent avant de lui donner un accès à l'interface de communication énumérant les menus possibles d'utilisation. Via l'application mobile pour téléphones mobiles de type Smartphone :
Les utilisateurs de téléphones mobiles de type Smartphone enregistrés au service utilisent l'application mobile y afférente après l'avoir téléchargée et installée depuis la plateforme idoine. Afin d'accéder au dit service, l'utilisateur E doit activer de nouveau l'application mobile sur son Smartphone en suivant les mêmes étapes que pour l'accès au service USSD décrites ci-haut.
1.5.2.1.4 Cinématique d'un virement monétique mobile intra bancaire instantané :
La cinématique technique des virements intra bancaires monétiques mobiles du compte d'un émetteur E vers le compte d'un bénéficiaire R est traitée en premier lieu par le serveur central SC qui transmet par connexion VPN l'information au SD installé au sein du système interne SB de la banque B.
Pour chaque type de virement intra bancaire monétique mobile PC2PNC et PNC2PC un ordre de virement sous-jacent est ensuite traité de façon classique par le serveur SIB de la banque B et ce en mettant un certain délai ΔΤ de quelques heures pour être exécuté et devenir effectif.
Entre-temps et parallèlement au lancement de ce virement classique, le compte CRU domicilié à la même banque B entre en action : l'argent viré est alors avancé et mis à la disposition du bénéficiaire R instantanément (hormis le type de virement PC2PC et PNC2PC) et ce grâce à des variations (exécutées dans la base de données BSD gérée par le SD) instantanées des plafonds dynamiques de la carte duale CD ou classique C de paiement et de retrait associée aux comptes courants CR et/ou CVR du receveur R. Le compte CRU est ainsi débité du montant viré et retiré par le receveur R de n'importe quel guichet automatique (GAB) ou dépensé par ce dernier lors du paiement d'un service donné par le biais de sa carte duale ou classique. Dans le cas d'un virement de type PNC2PNC, le virement monétique mobile se fait simplement par un jeu de compensation entre les plafonds dynamiques d'un compte virtuel émetteur CVE et celui d'un compte virtuel récepteur CVR puisque ces deux derniers sont domiciliés à la même banque B et adossés au même compte de réserve unique CRU. Enfin, le compte CRU est remboursé à postériori (hormis le type de virement PC2PC et PNC2PC) en étant crédité du montant viré suite à l'opération de virement classique déjà enclenchée du compte émetteur CE ou CVE vers le CRU.
1.5.2.1.5 Cinématique d'un virement monétique mobile interbancaire instantané :
La cinématique technique des virements interbancaires monétiques mobiles du compte d'un émetteur E vers le compte d'un bénéficiaire R est traitée en premier lieu par le serveur central SC qui transmet l'information par connexion VPN aux SIB1 et SIB2 serveurs internes respectivement des banques partenaires Bl et B2 par l'intermédiaire respectivement des SD1 et SD2 installés respectivement au sein des deux banques Bl et B2.
L'ordre de virement mobile interbancaire qui peut être de type PC2PC, PC2PNC, PNC2PC et PNC2PNC est d'abord exécuté de façon classique par le SIB1 de la banque Bl et par le SIT (serveur interbancaire de télé-compensation) en mettant un délai ΔΤ de plusieurs heures avant d'être effectif.
Entre-temps et parallèlement au lancement de ce virement classique, le compte CRUR domicilié à la banque B2 entre en action : l'argent viré est ainsi avancé et mis à la disposition du bénéficiaire R instantanément (hormis le type de virement PC2PC et PNC2PC) et ce grâce à des modifications dans la base de données dédiée BSD2 gérée par le SD2 des plafonds dynamiques de la carte duale CD ou classique C de paiement et de retrait associée aux comptes courants CR2 et/ou CVR2 du receveur R. Le compte CRUR est ainsi débité du montant viré et retiré par le receveur R de n'importe quel guichet automatique (GAB) ou dépensé par ce dernier lors du paiement d'un service donné par le biais de sa carte duale ou classique. Enfin le compte CRUR est remboursé à posteriori (hormis le type de virement PC2PC et PNC2PC) en étant crédité du montant viré suite à l'opération de virement classique déjà enclenchée du compte émetteur CE ou CVE vers le CRUR.
1.5.2.1.6 Désactivation temporaire du service objet de l'invention :
L'utilisateur du service en question peut en tout temps désactiver temporairement ce dernier à partir de son application mobile ou du service USSD. Cette désactivation protège toutes les données sensibles créées lors de l'activation initiale des deux applications et notamment le certificat électronique se rattachant à l'identité de l'utilisateur. Néanmoins, ce dernier pourra toujours réactiver le service via son application s'il le désire en utilisant son code PIN.
1.5.2.1.7 Clôture du service objet de l'invention :
Tout utilisateur du service en question peut clôturer définitivement son compte client en se rendant auprès d'un chargé de clientèle de la banque B offrant ledit service. Pour pouvoir réutiliser ce dernier, l'utilisateur est obligé de suivre la même procédure que lors de son enregistrement la première fois audit service.
1.5.2.2 Aspects de sécurité du système de l'invention :
Le service prôné par l'invention doit permettre à ses utilisateurs de faire des virements monétiques mobiles de manière très sûre et très sécurisée. Par conséquent, cela nécessite de sécuriser les connexions et les communications initiées entre le serveur central SC et :
• les téléphones mobiles des utilisateurs émetteurs
• le serveur dédié SD intégré au système d'information SB de la banque B dans le cas d'un système intra bancaire
• les serveurs dédiés SD1 et SD2 intégrés aux systèmes d'informations SB1 et SB2 des banques Bl et B2 dans le cas d'un système interbancaire global 1.5.2.2.1 Oubli du code PIN :
Si l'utilisateur oublie son code PIN, il peut le réinitialiser en se rendant auprès d'un chargé de clientèle de la banque B pour recevoir un nouveau code PIN temporaire ce qui lui permet de réactiver son service.
1.5.2.2.2 Changement du code PIN :
Si l'utilisateur désire modifier son code PIN, il lui suffit d'appeler le numéro spécial du serveur interactif SU ou directement depuis son application mobile sur Smartphone pour choisir l'option « Modifier mon code PIN ». Il est alors invité à saisir son code PIN actuel, puis le nouveau code PIN deux fois pour confirmation.
1.5.2.2.3 Vol et/ou perte d'éléments d'authentification :
En cas de vol ou de perte d'une ou de plusieurs informations ou éléments d'authentification - code PIN, carte SIM du numéro de téléphone associé au service proposé par l'invention, vol du Smartphone sur lequel l'application mobile est installée etc.- du titulaire du compte, alors ce dernier est tenu d'appeler immédiatement le service d'opposition et de perte de la banque B afin de faire bloquer toute transaction frauduleuse à partir de son compte d'utilisateur.
1.5.2.2.4 Gestion des certificats électroniques de sécurité
Pour rappel, le serveur central SC peut être joint par les utilisateurs enregistrés au service en question par le biais de deux types de téléphones mobiles :
• un Smartphone via l'application mobile activée qui y est installée
• un téléphone d'entrée de gamme basique via le service distant de type USSD
Enregistrement auprès d'une autorité de certification :
Les certificats électroniques gérés par le serveur central SC sont fournis aux applications mobiles ainsi qu'aux serveurs secondaires dédiés SD par une autorité de certification.
Cas du Smartphone :
Le réseau web (réseau internet) de communication entre le serveur central SC et l'application mobile étant ouvert, le code PIN ne suffit pas à authentifier l'utilisateur. Il est donc mis en place un mécanisme d'activation de l'application mobile par certificat électronique pour permettre aux échanges d'être authentifiés et donc sécurisés. Le canal de communication utilisé, quant à lui, est crypté par SSL (Secure Sockets Layer). Cas du téléphone basique :
Dans ce cas, le service est accessible en faisant un appel téléphonique au serveur distant interactif SU. Le code PIN qu'envoie l'utilisateur transite sur un réseau sécurisé en l'occurrence un canal de type GSM considéré de facto comme sûr (celui de l'opérateur téléphonique et prestataire concerné). De plus, le numéro de téléphone de l'appelant fourni par l'opérateur en question et combiné au code PIN permet d'authentifier l'utilisateur du service sans possibilités d'intrusions ou de fraudes. Enfin, il est à noter que ce canal est supposé déjà crypté par l'opérateur téléphonique déjà cité.
Identifiant d'activation de l'application mobile :
L'application mobile génère un identifiant unique pour toutes les opérations d'activation initiales du service et ce pour chaque carte SIM dont le titulaire est enregistré au service objet de l'invention. Cet identifiant d'activation est crypté puis envoyé au serveur central SC via un SMS : on s'assure ainsi que l'activation a bien été faite par le possesseur de la carte SIM enregistré au service. Une fois le service activé, l'application demande à l'utilisateur de saisir les informations suivantes :
• nom et prénom du titulaire du compte d'utilisateur
• le numéro de CIN dudit utilisateur
• le code PIN de ce même utilisateur
Ces informations sont accompagnées de l'identifiant unique d'activation et sont ensuite envoyées de façon cryptée au serveur central SC via un canal SSL en vue de l'activation finale de l'application mobile.
Certificat émis par le serveur central SC :
L'application mobile ainsi que les serveurs secondaires dédiés SD doivent disposer de certificats électroniques de la part du serveur central SC afin d'être authentifiés. Les informations devant être échangées entre ces systèmes par connexion VPN sont cryptées.
Réception d'un certificat électronique issu du serveur central SC :
Une fois que les informations ci-dessus sont validées (à la suite d'une première activation) par le serveur central SC alors ce dernier envoie des certificats électroniques devant être utilisés pour toutes les authentifications futures entre l'application mobile et les serveurs dédiés SD d'un côté et le serveur central SC de l'autre.
Durée de validité des certificats électroniques :
Tout certificat électronique de sécurité d'une connexion doit avoir une durée de validité renouvelable. En effet, l'application mobile ainsi que les serveurs dédiés SD doivent s'assurer automatiquement (avant toute ouverture de canaux sécurisés avec le serveur central SC) que leurs certificats électroniques n'ont pas expiré et/ou n'ont pas été révoqués par l'autorité de certification. En cas de révocation d'un certificat électronique donné ou d'expiration de sa durée de validité, alors la connexion y afférente est refusée automatiquement par le serveur central SC.
Sécurisation des connexions entre le serveur central SC et les serveurs dédiés SD :
Chaque banque B doit nécessairement installer un serveur SD dédié à la gestion des comptes virtuels objets de l'invention. Le serveur central SC n'étant pas toujours sur la même infrastructure que celle des serveurs secondaires dédiés SD, les liens entre le serveur central SC et les serveurs secondaires SD se font donc via un VPN sécurisé.
1.5.2.2.5 Gestion des fraudes et responsabilités
Le système de l'invention doit être capable de gérer les responsabilités en cas de fraudes internes ou externes avérées. L'historique des opérations doit donc être permis et stocké par ce système pendant un délai de prescription prédéfini. Ces opérations peuvent aller des opérations de virements monétiques mobiles interpersonnels (P2P) et leurs montants, de changements de code IN, de mémorisation des dates d'activations du service en question et des identités des utilisateurs (émetteurs et bénéficiaires de virements) aux échanges à travers les différents éléments du système dans son ensemble (systèmes internes des banques partenaires SIB, serveur central SC, serveurs secondaires dédiés SD, téléphones mobiles utilisés, enregistrements des serveurs distants interactifs SU et SM..).
1.5.2.2.6 Déclaration de transactions frauduleuses :
Si le titulaire d'un compte d'utilisateur constate sur son compte un virement qu'il n'a pourtant jamais demandé via les interfaces de l'application mobile ou du service USSD alors il doit considérer que son PIN a été volé : il est tenu dans ce cas d'appeler immédiatement le service d'opposition de la banque B afin de faire bloquer toute nouvelle transaction frauduleuse qui pourrait être faite à partir de son compte d'utilisateur .
1.5.3 Système intra bancaire de paiement mobile interpersonnel instantané (P2P) : cas général
Le système intra bancaire comprenant les éléments formant le système de paiement mobile interpersonnel instantané (P2P) permet à un émetteur E par le biais d'un service USSD (grâce au SU) ou d'une application mobile installée sur son téléphone mobile dans le cas d'un Smartphone (via le réseau internet et une connexion VPN sécurisée) d'effectuer au sein d'une même banque B et en toute heure un ordre de virement intra bancaire monétique mobile interpersonnel de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC) autrement dit de son compte courant CE et/ou virtuel CVE vers le compte courant CRI et/ou virtuel CVR1 d'un bénéficiaire R. Ledit ordre est transmis à un serveur central externe SC. Ce dernier après avoir procédé à l'authentification de l'émetteur E transmet l'ordre de virement en question directement à un serveur interne dédié SD intégré au système interne SB de la banque B et ce par le biais d'une connexion VPN. Dans les cas de virements de type (PC2PC), (PC2PNC) ou (PNC2PC) le SD ordonne à un serveur interne SIB de lancer un ordre classique de virement sous-jacent (non instantané) respectivement entre les comptes (CE et CRI), (CE et CVR1/CRU) ou (CVE/CRU et CRI). Parallèlement à cet ordre le SD transmet au SIB un autre ordre permettant à ce dernier de mettre instantanément à la disposition du bénéficiaire R de l'argent (avancé) sur un compte de réserve unique CRU domicilié à la même banque B. Cela se traduit dans les cas de transferts (PC2PNC) ou (PNC2PNC) par une incrémentation du plafond dynamique Pt du compte virtuel du receveur R en l'occurrence le compte CVR1/CRU adossé à un compte de réserve unique CRU.
Inversement, dans le cas d'un retrait aux (GAB) par le receveur R d'une partie ou de la totalité du montant qui lui a été viré (à partir du CVR1/CRU) ou d'un paiement d'un service au moyen de sa carte et d'un (TPE), le compte de réserve unique CRU est débité dudit montant et un ordre de débit est transmis (via le SRI le cas échéant) instantanément au serveur interne bancaire SIB. Ce dernier procède alors à la décrémentation instantanée (dans la base de données centrale BSIB gérée par le SIB) du plafond dynamique Pt de la carte classique C ou duale CD du receveur R du montant d'argent débité. Le SIB transmet ensuite au serveur SD un ordre de mise à jour dudit plafond Pt qu'il décrémente à son tour du même montant dans sa propre base de données BSD. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la dépense par le receveur R d'une partie ou de la totalité du montant viré au moyen du téléphone mobile TE de l'émetteur E.
Par ailleurs, dans le cas d'un virement monétique mobile interpersonnel de type PNC2PNC, le plafond dynamique de la carte classique C ou duale CD associée au compte virtuel CVE de l'émetteur E est décrémenté à son tour instantanément suivant un processus de décrémentation inverse puisque l'information y afférente émane d'abord du SD et de sa base de données BSD avant d'être traitée au niveau du SIB via la BSIB. L'émetteur E et le bénéficiaire R reçoivent alors un SMS de confirmation de la part d'un serveur de messagerie SM sur leurs téléphones mobiles (TE et TR) du succès de la transaction mobile en question.
Notons que dans le cas d'un système intra bancaire intégré de paiement mobile interpersonnel instantané (P2P), les rôles des serveurs SC et SD sont confondus de sorte qu'il n'existe qu'un seul serveur interne dédié SD intégré au SB de la banque B. Ce système est normalement le fait d'une banque optant pour un contrôle total du système de paiement mobile interpersonnel instantané (P2P) excluant ainsi toute forme de partenariat externe tout en réduisant ses coûts d'exploitation.
1.5.4 Système interbancaire global de paiement mobile interpersonnel instantané (P2P) :
Le système interbancaire comprenant les éléments formant le système de paiement mobile interpersonnel instantané (P2P) permet à un émetteur E disposant d'un compte courant propre CE ou virtuel CVE domiciliés à la banque Bl de transférer en toute heure et instantanément de l'argent à un bénéficiaire R dont le compte courant ou virtuel respectivement CR2 ou CVR2 sont domiciliés dans une autre banque distincte B2. Ledit virement est effectué par l'intermédiaire d'un service USSD (grâce à un serveur externe SU) ou d'une application mobile installée sur le téléphone mobile émetteur TE dans le cas d'un Smartphone. L'ordre de transfert interbancaire est envoyé dans un premier temps à un serveur externe SC via des connexions web sécurisés. Le type du transfert mobile d'argent en question peut être l'un ou l'autre des modèles de virements monétiques mobiles interpersonnel de type (PC2PC), (PC2PIMC), (PNC2PC) ou (PNC2PNC).
Dans un système interbancaire, et après avoir procédé à l'authentification de l'émetteur E, le serveur central SC externe aux systèmes internes SB1 et SB2 respectivement des banques émettrice Bl et réceptrice B2 transmet dans un premier temps via une connexion VPN l'ordre de virement en question émis à un serveur dédié SD1 interfacé en interne avec le serveur SIB1. Le serveur SD1 transmet ainsi et en premier lieu un ordre de virement mobile interbancaire classique sous-jacent de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC) entre les comptes domiciliés dans les deux banques distinctes concernées. Le virement est alors traité par le serveur externe SIT (Système Interbancaire de Télé-compensation). Parallèlement à cet ordre, le SC transmet directement au SD2 par une connexion VPN un autre ordre permettant à celui-ci de transmettre à son tour l'information au serveur interne SIB2 appartenant au SB2 de la banque réceptrice B2. Ce dernier met instantanément à la disposition du bénéficiaire R le montant d'argent viré sur un compte de réserve unique CRUR domicilié à la même banque B2. Cela se traduit dans les cas de transferts (PC2PIMC) ou (PNC2PNC) par une incrémentation en temps réel du plafond dynamique Pt du compte virtuel du receveur R en l'occurrence le compte CVR2/CRUR adossé au compte de réserve unique CRUR.
Inversement, en cas de dépense par le receveur R d'une partie ou de la totalité du montant viré aux (GAB) ou au moyen d'un (TPE), un ordre de dépense est reçu (via le SRI le cas échéant) en premier lieu et instantanément par le serveur interne bancaire SIB2. Ce dernier procède alors à la décrémentation instantanée du montant d'argent viré (dans la base de données centrale BSIB2 gérée par le SIB2) du plafond dynamique Pt de la carte de type classique C ou duale CD du receveur R. Le SIB2 transmet ensuite au serveur SD2 un ordre de mise à jour dudit plafond Pt qui décrémente à son tour ledit plafond du même montant dans sa propre base de données BSD2. Le plafond dynamique Pt est ainsi mis à jour instantanément suite à la dépense initiée par le receveur R d'une partie ou de la totalité du montant viré par l'émetteur E au moyen de son téléphone mobile TE.
Par ailleurs, dans le cas de virement monétiques mobiles interpersonnels de type PNC2PC ou PNC2PNC, le plafond dynamique de la carte classique C associée au compte virtuel CVE/CRU de l'émetteur E est décrémenté à son tour instantanément suivant un processus de décrémentation inverse puisque l'information y afférente émane d'abord du SD1 et de sa base de données BSD1 au sein de la banque réceptrice Bl avant d'être traitée au niveau du SIB1 via la BSIB1. L'émetteur E et le bénéficiaire R reçoivent alors un SMS de confirmation (effectuée par le biais d'un serveur externe de messagerie SM) sur leurs téléphones mobiles du succès du virement en question. 1.6 Application industrielle de l'invention :
L'invention propose de nouveaux systèmes et procédés de paiement mobile interpersonnel instantané (P2P) présentant une utilité spécifique ainsi qu'un intérêt public potentiel substantiel et crédible.
En effet, l'invention peut être directement utilisée par l'industrie bancaire constituant de ce fait un apport économique indéniable à ce secteur en termes de valeur ajoutée. La solution de paiement mobile interpersonnel instantané (P2P) sous-jacente à l'invention permettra l'émergence d'un nouveau service et partant l'éclosion de nouvelles perspectives économiques pour l'industrie bancaire notamment en lui faisant gagner de nouveaux clients jusque-là non bancarisés et en dehors de sa portée.
En offrant un nouveau service payant à ses anciens et nouveaux clients et en prélevant éventuellement une commission sur chaque virement monétique mobile interpersonnel instantané (P2P), l'industrie bancaire ne pourra qu'augmenter son chiffre d'affaires à moyen terme et partant contribuer à la croissance du PIB national. Les filiales des banques nationales à l'étranger pourraient offrir ce service à leur tour à leurs clients étrangers et ainsi améliorer leur compétitivité à l'échelle internationale.
Par ailleurs l'impact socio-économique de l'invention ne peut être limité au seul secteur bancaire. L'invention peut également avoir des retombées socio-économiques indirectes sur le secteur du commerce des biens et services. En permettant justement une dynamisation et une instantanéité des micro-paiements par le biais de virements mobiles interpersonnels d'argent (P2P) en association avec des cartes duales CD ou classiques C de paiement et de retrait rechargeables à distance, l'invention contribuera indirectement à l'augmentation d'un indicateur économique national à savoir la consommation des ménages en biens et services. Les acteurs économiques nationaux en général ne pourront donc qu'en ressentir l'impact sur leurs affaires contribuant ainsi à la création d'emplois et au développement socio-économique durable de notre pays. Par conséquent, l'invention pourrait être reconnue comme étant susceptible d'application industrielle.

Claims

II. Les revendications
1. Système intra bancaire de paiement mobile interpersonnel instantané (P2P) comprenant les éléments de paiement mobile interpersonnel instantané (P2P) et permettant à un émetteur (E) client d'une banque (B) d'effectuer en toute heure, en appelant d'un téléphone mobile basique un service USSD géré par un serveur externe (SU) ou en utilisant l'application installée sur son téléphone mobile (TE) dans le cas d'un Smartphone, un virement monétique mobile intra bancaire classique le cas échéant ou instantané de son compte bancaire courant (CE) ou virtuel (CVE) vers le compte bancaire courant (CRI) ou virtuel (CVR1) d'un receveur (R) domicilié à la même banque (B), caractérisé en ce que :
• ledit système comprend le téléphone mobile (TE) de l'émetteur (E), un serveur externe (SU), un serveur central (SC) externe au système interne (SB) de la banque (B), un serveur dédié (SD) interne au (SB), un serveur interne bancaire (SIB), un compte de réserve unique (CRU) domicilié à la banque (B), un serveur externe (SRI), un serveur externe de messagerie (SM), le téléphone mobile (TR) du récepteur (E), une carte duale (CD) ou classique (C) de retrait et de paiement aux (GAB/TPE) appartenant au receveur (R),
• et en ce que l'ordre de virement monétique mobile interpersonnel (P2P) émis de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC) peut être émis par l'émetteur (E) au moyen d'une application mobile installée sur son téléphone mobile (TE) de type Smartphone vers un serveur central (SC) via un réseau internet sécurisé (101, 111, 121, 131, 141),
• et en ce que le même ordre de virement monétique mobile interpersonnel (P2P) de type (PC2PC), (PC2PNC), (PIMC2PC) ou (PNC2PNC) peut être également émis par l'émetteur (E) de son téléphone mobile (TE) de type basique vers un serveur externe (SU) en utilisant un service de type USSD via une connexion de type GSM (ou équivalent) sécurisée (102, 112, 122, 132, 142),
• et en ce que dans ce dernier cas le serveur externe (SU) transmet directement via une liaison de type GSM (102, 112, 122, 132, 142) l'ordre de virement mobile intra bancaire en question à un serveur central (SC) externe au système interne (SB) de la banque (B),
• et en ce que le serveur central (SC), dans le cas où l'émetteur (E) utilise l'application mobile, procède à la vérification et à l'authentification du certificat électronique de cette dernière et transmet directement via une liaison VPN (103, 113, 123, 133) l'ordre de virement mobile intra bancaire en question au serveur dédié (SD) installé dans le système interne (SB) de la banque B,
• et en ce que le serveur (SD), dans le cas où le virement mobile est de type (PC2PNC) ou (PNC2PNC) procède à l'enregistrement en temps réel dans sa propre base de données (BSD) (29, 291) du montant dudit virement au crédit du compte virtuel (CVR1) du receveur (R) et en ordonnant au (SIB) d'en faire de même (25, 22, 27) dans sa base de données (BSIB). Il s'ensuit alors une incrémentation instantanée du plafond dynamique de la carte duale (CD) ou classique (C) adossée au compte virtuel (CVR1) du bénéficiaire (R) par rapport au (CRU),
• et en ce que le serveur (SD), dans le cas où le virement mobile est de type (PNC2PC) ou (PNC2PNC) procède à l'enregistrement instantané dans sa propre base de données (BSD) (28, 281) du montant dudit virement au débit du compte virtuel (CVE) de l'émetteur (E) et en ordonnant au (SIB) d'en faire de même (25, 21, 26) dans sa base de données (BSIB). Il s'ensuit alors une décrémentation instantanée du plafond dynamique de la carte classique (C) adossée au compte virtuel (CVE) de l'émetteur (E) par rapport au (CRU),
• et en ce qu'au même moment le serveur (SC) ordonne (103, 113, 123) au serveur (SIB) via le serveur (SD) (106, 116, 126) installé dans le système interne (SB) de la banque (B), dans le cas où ledit virement mobile est de type (PC2PC), (PC2PNC) ou (PNC2PC) de procéder à un virement classique sous-jacent intra bancaire (31, 32, 41, 52) entre les comptes objets dudit virement,
• et en ce que le serveur (SIB) permet ensuite à un compte de réserve unique (CRU) domicilié à la banque (B) de mettre instantanément et en toute heure à la disposition du bénéficiaire (R) le montant du virement directement (110, 120, 130, 140) si ce dernier retire l'argent dans un (GAB) appartenant à la banque (B) ou par l'intermédiaire notamment d'un serveur externe (SRI) (109, 119, 129, 139) s'il paye un service donné par le biais d'un (TPE) ou s'il retire son argent dans un (GAB) appartenant à une autre banque autre que (B),
• et en ce que le serveur (SIB) transmet au serveur (SD) une notification (106, 116, 126, 136) faisant état du succès de l'opération dudit virement mobile. Ce dernier la transmet au (SC) (103, 113, 123, 133) qui la transmet à son tour (104, 114, 124, 134) au serveur externe (SM) qui à son tour notifie le bénéficiaire (R) et l'émetteur (E) par SMS du succès de ladite opération de virement,
• et en ce que le serveur (SIB) permet finalement au bénéficiaire (R) d'utiliser sa carte duale (CD) (95) ou classique (C) de paiement et de retrait associée à son compte courant (CRI) et/ou à son compte virtuel (CVR1) en vue de payer (108, 118, 128, 138) un service donné avec le montant viré au moyen d'un (TPE) ou d'en retirer (108, 118, 128, 138) la totalité ou une partie dans n'importe quel guichet automatique (GAB) de n'importe quelle banque.
2. Système intra bancaire intégré de paiement mobile interpersonnel instantané (P2P) comprenant les éléments de paiement mobile interpersonnel instantané (P2P) et permettant à un émetteur (E) client d'une banque (B) d'effectuer en toute heure, en appelant d'un téléphone mobile basique un service USSD géré par un serveur externe (SU) ou en utilisant l'application installée sur son téléphone mobile (TE) dans le cas d'un Smartphone, un virement monétique bile intra bancaire classique le cas échéant ou instantané de son compte bancaire courant ) ou virtuel (CVE) vers le compte bancaire courant (CRI) ou virtuel (CVRl) d'un receveur (R) micilié à la même banque (B), caractérisé en ce que : ledit système comprend le téléphone mobile (TE) de l'émetteur (E), un serveur externe (SU), un serveur dédié (SD) intégré au (SB), un serveur interne bancaire (SIB), un compte de réserve unique (CRU) domicilié à la banque (B), un serveur externe (SRI), un serveur externe de messagerie (SM), le téléphone mobile (TR) du récepteur (E), une carte duale (CD) ou classique (C) de retrait et de paiement aux (GAB/TPE) et appartenant au receveur (R), et en ce que l'ordre de virement monétique mobile interpersonnel (P2P) émis de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC) peut être émis par l'émetteur (E) de son téléphone mobile (TE) de type Smartphone directement au serveur dédié intégré (SD) via un réseau internet sécurisé (141), et en ce que le même ordre de virement monétique mobile interpersonnel (P2P) de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PIMC) peut être également émis par l'émetteur (E) de son téléphone mobile (TE) de type basique au serveur externe (SU) en utilisant un service de type USSD via une connexion (142) de type GSM (ou équivalent) sécurisée, et en ce que dans ce dernier cas le serveur externe (SU) transmet directement via une liaison de type GSM (142) l'ordre de virement intra bancaire en question au serveur dédié (SD) intégré au système interne (SB) de la banque (B), et en ce que le serveur dédié intégré (SD), dans le cas où l'émetteur (E) utilise l'application mobile (141), procède à la vérification et à l'authentification du certificat électronique de cette dernière et transmet directement via une liaison VPN (144, 145) l'ordre de virement intra bancaire en question au serveur interne (SIB) installé dans le système interne (SB) de la banque B, et en ce que le serveur intégré (SD), dans le cas où le virement est de type (PC2PNC) ou (PNC2PNC) procède à l'enregistrement instantané dans sa propre base de données (BSD) (29, 291) du montant dudit virement au crédit du compte virtuel (CVRl) du receveur (R) et en ordonnant au (SIB) d'en faire de même (25, 22, 27) dans sa base de données (BSIB). Il s'ensuit alors une augmentation du plafond dynamique de la carte duale (CD) ou classique (C) adossée au compte virtuel (CVRl) par rapport au (CRU), et en ce que le serveur intégré (SD), dans le cas où le virement est de type (PNC2PC) ou (PNC2PNC) procède à l'enregistrement instantané dans sa propre base de données (BSD) (28, 281) du montant dudit virement au débit du compte virtuel (CVE) de l'émetteur (E) et en ordonnant au (SIB) d'en faire de même (25, 21, 26) dans sa base de données (BSIB). Il s'ensuit alors une diminution du plafond dynamique de la carte duale (CD) ou classique (C) adossée au compte virtuel émetteur (CVE) par rapport au (CRU),
• et en ce qu'au même moment le serveur (SD) installé dans le système interne (SB) ordonne (145) au serveur (SIB) de la banque (B), dans le cas où ledit virement mobile est de type (PC2PC), (PC2PNC) ou (PNC2PC) de procéder au virement classique intra bancaire sous- jacent (31, 32, 41, 52) entre les comptes objets dudit virement,
• et en ce que le serveur (SIB) permet ensuite au compte de réserve unique (CRU) domicilié à la banque (B) de mettre instantanément et en toute heure à la disposition du bénéficiaire (R) le montant du virement directement (149) si ce dernier retire de l'argent dans un (GAB) appartenant à la banque (B) ou par l'intermédiaire d'un serveur externe (SRI) (148) notamment s'il paye un service donné par le biais d'un (TPE) ou s'il retire son argent dans un (GAB) appartenant à une autre banque autre que (B),
• et en ce que le serveur (SIB) transmet au serveur intégré (SD) une notification (145) faisant état du succès de l'opération dudit virement mobile. Ce dernier la transmet à son tour au serveur externe (SM) (143) qui à son tour notifie le bénéficiaire (R) et l'émetteur (E) par SMS du succès de ladite opération de virement,
• et en ce que le serveur (SIB) permet finalement au bénéficiaire (R) d'utiliser sa carte duale (CD) (95) ou classique (C) de paiement et de retrait associée à son compte courant (CRI) et/ou à son compte virtuel (CVR1) afin de payer (147) un service donné avec le montant viré par le biais d'un (TPE) ou d'en retirer (147) la totalité ou une partie dans n'importe quel guichet automatique (GAB) de n'importe quelle banque.
3. Système interbancaire de paiement mobile interpersonnel instantané (P2P) selon la revendication 1 comprenant les éléments de paiement mobile interpersonnel instantané (P2P) et permettant à un émetteur (E) d'effectuer en toute heure, en appelant d'un téléphone mobile basique un service USSD géré par un service externe (SU) ou en utilisant l'application installée sur son téléphone mobile dans le cas d'un Smartphone, un virement monétique mobile interbancaire classique le cas échéant ou instantané de son compte bancaire courant (CE) ou compte bancaire virtuel (CVE) domiciliés dans une banque (Bl) vers le compte bancaire courant (CR2) ou virtuel (CVR2) d'un receveur (R) domiciliés dans une banque distincte (B2), caractérisé en ce que :
• ledit système comprend le téléphone mobile de l'émetteur (TE), un serveur (SU), un serveur central (SC) externe au (SB1) et au (SB2), un serveur dédié (SD1) interne au (SB1), un serveur interne bancaire (SIB1), un compte de réserve unique (CRU) domicilié à la banque (Bl), un serveur dédié (SD2) interne au (SB2), un serveur interne bancaire (SIB2), un compte de réserve unique (CRUR) domicilié à |a banque (B2), un serveur externe de messagerie externe (SM), un serveur externe (SRI), une carte duale (CD) ou classique (C) de retrait et de paiement aux (GAB/TPE) appartenant au receveur (R), et en ce que l'ordre de virement monétique mobile interpersonnel (P2P) émis de type (PC2PC), (PC2PNC), (PNC2PC) ou (PNC2PNC) peut être émis par l'émetteur (E) de son téléphone mobile (TE) de type Smartphone à un serveur central externe (SC) via un réseau internet sécurisé (151), et en ce que le même ordre de virement monétique mobile interpersonnel (P2P) de type (PC2PC), (PC2PNC), (PNC2PC) ou (PIMC2PNC) peut être également émis par l'émetteur (E) de son téléphone mobile (TE) de type basique à un serveur externe (SU) en utilisant un service de type USSD via une connexion de type GSM (152) ou équivalent sécurisée, et en ce que dans ce dernier cas le serveur externe (SU) transmet directement via une liaison de type GSM (152) l'ordre de virement interbancaire en question à un serveur central (SC) externe, et en ce que le serveur central (SC), dans le cas où l'émetteur (E) utilise l'application mobile, procède à la vérification et à l'authentification du certificat électronique de cette dernière et transmet directement via une liaison VPN (154) l'ordre de virement mobile interbancaire en question au serveur dédié (SD2) installé dans le système interne (SB2) de la banque B2, et en ce que le serveur (SD2), dans le cas où le virement interbancaire est de type (PC2PNC) ou (PNC2PNC) procède à l'enregistrement instantané dans sa propre base de données (BSD2) (29, 291) du montant dudit virement au crédit du compte virtuel (CVR2) du receveur (R) et en ordonnant au (SIB2) d'en faire de même (25, 22, 27) dans sa base de données (BSIB2). Il s'ensuit alors une augmentation du plafond dynamique de la carte duale (CD) ou classique (C) adossée au compte virtuel (CVR2) par rapport au (CRUR), et en ce que le serveur (SD1), dans le cas où le virement est de type (PNC2PC) ou (PNC2PNC) procède à l'enregistrement instantané dans sa propre base de données (BSD1) (28, 281) du montant dudit virement au débit du compte virtuel (CVE) de l'émetteur (E) et en ordonnant au (SIB1) d'en faire de même (25, 21, 26) dans sa base de données (BSIB1). Il s'ensuit alors une diminution du plafond dynamique de la carte duale (CD) ou classique (C) adossée au compte virtuel émetteur (CVE) par rapport au (CRU), et en ce qu'au même moment le serveur (SC) transmet directement via une liaison VPN (153) l'ordre de virement mobile interbancaire en question au serveur (SIB1) via le serveur (SD1) (157) installé dans le système interne (SB1) de la banque Bl, dans le cas où ledit virement mobile est de type (PC2PC), (PC2PNC) ou (PNC2PC) afin de procéder au virement classique interbancaire sous-jacent (31, 32, 41, 52, 71, 81) entre les comptes objets dudit virement et ce par l'intermédiaire du serveur externe (SIT), et en ce que le serveur (SIB2) permet ensuite au compte de réserve unique (CRUR) domicilié à la banque (B2) de mettre instantanément et en toute heure à la disposition du bénéficiaire (R) le montant du virement directement (163) si ce dernier retire de l'argent dans un (GAB) appartenant à la banque (B2) ou par l'intermédiaire d'un serveur externe (SRI) (162) notamment s'il paye un service donné par le biais d'un (TPE) ou s'il retire son argent dans un (GAB) appartenant à une autre banque autre que (B2),
• et en ce que les serveurs (SIBl) et (SIB2) transmettent respectivement (157, 158) aux serveurs (SD1) et (SD2) une notification faisant que chacun des deux fasse état du succès de l'opération dudit virement mobile à son niveau. Ces derniers la transmettent au (SC) (153, 154) qui la transmet (155) à son tour au serveur externe (SM) qui à son tour notifie le bénéficiaire (R) et l'émetteur (E) par SMS du succès de ladite opération de virement,
• et en ce que le serveur (SIB2) permet finalement au bénéficiaire (R) d'utiliser sa carte duale (CD) (95) ou classique (C) de paiement et de retrait associée à son compte courant (CR2) et/ou à son compte virtuel (CVR2) afin de payer (160) un service donné avec le montant viré par le biais d'un (TPE) ou d'en retirer (160) la totalité ou une partie dans n'importe quel guichet automatique (GAB) de n'importe quelle banque à partir de son compte courant ou à partir du compte (CRUR).
4. Système CRU, domicilié dans une banque (B) comprenant tous les comptes virtuels (CVR) domiciliés dans cette même banque, et assimilé à un compte relais unique de réception des paiements mobiles interpersonnels instantanés (P2P), caractérisé en ce que :
• c'est un compte de réserve multicarte pré-provisionné par la banque (B) des montants susceptibles d'être transférés par des émetteurs (E) via leurs téléphones mobiles à des bénéficiaires (R),
• et en ce qu'il permet d'avancer instantanément de l'argent transféré par un émetteur (E) via un téléphone mobile à un bénéficiaire (R) permettant à ce dernier d'y accéder par le biais de sa carte duale (CD) (95) ou classique (C) de retrait et de paiement associée à son compte courant (CR) et/ou compte virtuel (CVR),
• et en ce qu'il permet à ce dernier de retirer cet argent au premier (GAB) rencontré ou de le dépenser en payant un service donné au moyen d'un (TPE), assurant par-là l'instantanéité recherchée dans les virements monétiques mobiles interpersonnels de type (PC2PNC), (PNC2PNC),
• et en ce que chaque carte duale (CD) ou classique (C) associé au compte virtuel d'un bénéficiaire (R) dispose d'un plafond dynamique (Pt) propre de retrait ou de paiement par rapport au (CRU),
• et en ce que l'instantanéité des virements monétiques mobiles interpersonnels de type PC2PNC, PNC2PNC est assurée par la gestion en temps réel des plafonds dynamiques desdites cartes de paiement ou de retrait adossées au (CRU), • et en ce que ladite gestion est assurée mutuellement (24, 25) par le serveur (SD) dédié au moyen d'une base de données (BSD) dédiée et par le serveur interne bancaire (SIB) de la banque (B) au moyen d'une base de données centrale (BSIB),
• et en ce que la réserve à allouer à ce compte de réserve peut être équivalente au produit du nombre espéré estimé des utilisateurs potentiels du service objet de l'invention par le montant espéré total estimé des paiements et retraits effectués par un utilisateur moyen dudit service le tout pondéré par un facteur réducteur égal au ratio Cooke (8%).
5. Procédé C U/PC2PC-CVR de paiement mobile interpersonnel instantané (P2P) selon les revendications (1 ou 2 ou 3) et 4 permettant à un émetteur (E) bancarisé appelant de son téléphone basique le service USSD géré par le (SU) ou utilisant l'application installée sur son téléphone mobile de type Smartphone, d'effectuer au choix et à chaque instant (T) un virement monétique mobile intra ou interbancaire interpersonnel instantané d'un montant (Mi) de son compte courant bancaire (CE) vers le compte virtuel (CVR/CRU) d'un bénéficiaire (R) bancarisé à la banque réceptrice (B) ou de façon classique vers le compte courant (CR) de ce dernier, caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R),
• Choix de l'émetteur (E) d'effectuer un virement mobile instantané vers le compte virtuel (CVR/CRU) du receveur (R) : dans ce cas le plafond dynamique (Pt) de la carte duale (CD) de ce dernier par rapport au compte de réserve unique (CRU) domicilié à la banque réceptrice (B) est augmenté instantanément en (T) (291, 25, 22) du montant (Mi) transféré. Le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRU) en payant un service donné avec sa carte duale (CD) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche,
• Choix de l'émetteur (E) d'effectuer un virement mobile classique vers le compte courant (CR) du receveur (R) : dans ce cas un ordre (32) de virement classique d'un montant (Mi) est exécuté par le (SIB) de la banque émettrice du compte courant (CE) vers le compte courant bancaire (CR). Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H,
• Envoi automatique en (T) dans le cas d'un virement mobile instantané d'un ordre (31) de virement classique (sous-jacent) au (SIB) de la banque émettrice d'un montant (Mi) du compte courant (CE) de l'émetteur (E) vers le compte de réserve unique (CRU) : il s'agit là simplement d'une opération de remboursement ou de compensation du montant (Mi) au crédit du (CRU). Ce dernier n'est alors crédité qu'au bout d'un certain délai ΔΤ allant de 12H à 72H, • Variation instantanée en temps réel à partir de l'instant (T) du plafond dynamique (Pt) de la carte duale (CD) du receveur (R) vis-à-vis du (CVR/CRU) de façon continue en fonction des virements mobiles (291, 25, 22) instantanés nouveaux reçus (Mj) (33), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24 , 33, 281) aux (GAB).
6. Procédé CRU/PC2PNC de paiement mobile interpersonnel instantané (P2P) selon les revendications (1 ou 2 ou 3) et 4 permettant à un émetteur (E) bancarisé appelant de son téléphone basique le service USSD géré par le (SU) ou utilisant l'application installée sur son téléphone mobile de type Smartphone, d'effectuer à chaque instant (T) un virement monétique mobile intra ou interbancaire interpersonnel instantané d'un montant (Mi) de son compte courant bancaire (CE) vers le compte bancaire virtuel (CVR) adossé au (CRU) domicilié dans une banque (B) d'un bénéficiaire (R) non bancarisé, caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R),
• Augmentation instantanée en (T) (29, 25, 22) du plafond dynamique (Pt) de la carte classique (C) du receveur (R) par rapport au compte de réserve unique (CRU) domicilié à la banque réceptrice (B) du montant (Mi) transféré. Le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRU) en payant un service donné avec sa carte classique (C) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche,
• Envoi automatique en (T) d'un ordre (41) de virement mobile classique (sous-jacent) au (SIB) de la banque émettrice d'un montant (Mi) à effectuer du compte courant (CE) de l'émetteur (E) vers le compte de réserve unique (CRU) : il s'agit là simplement d'une opération de remboursement ou de compensation du montant (Mi) au crédit du (CRU). Ce dernier n'est alors crédité qu'au bout d'un certain délai ΔΤ allant de 12H à 72H,
• Variation instantanée en temps réel à partir de l'instant (T) du plafond dynamique (Pt) de la carte classique (C) du receveur (R) vis-à-vis du (CVR/CRU) de façon continue en fonction des virements mobiles instantanés nouveaux reçus (Mj) (29, 25, 22, 42), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24 , 28, 42) aux (GAB).
7. Procédé CRU/PNC2PC-CVR de paiement mobile interpersonnel instantané (P2P) selon les revendications (1 ou 2) et 4 permettant à l'émetteur (E) non bancarisé appelant de son téléphone basique le service USSD géré par le (SU) ou utilisant l'application installée sur son téléphone mobile de type Smartphone, d'émettre au choix en tout instant (T) un virement monétique mobile intra bancaire interpersonnel instantané d'un montant (Mi) de son compte courant bancaire virtuel (CVE) vers le compte bancaire virtuel (CVR1) d'un bénéficiaire (R) bancarisé ou de façon classique vers le compte courant (CRI) de ce dernier, caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R),
• Choix de l'émetteur (E) d'effectuer un virement mobile non instantané vers le compte courant (CRI) du receveur (R) : dans ce cas un ordre (52) de virement classique est exécuté par le (SIB) de la banque (B) d'un montant (Mi) du compte de réserve unique (CRU) domicilié dans cette banque vers le compte courant bancaire (CRI) domicilié à la même banque. Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 48H,
• Choix de l'émetteur (E) d'effectuer un virement monétique mobile instantané vers le compte virtuel (CVR1/CRU) du receveur (R),
• Diminution instantanée en (T) (28, 25, 21) d'un montant (Mi) dans les deux cas de transferts ci-dessus du plafond dynamique (Pt) de la carte classique (C) de l'émetteur (E) par rapport au compte de réserve unique (CRU),
• Augmentation instantanée en (T) (291, 25, 22) dans le cas du premier choix du plafond dynamique (Pt) de la carte duale (CD) du receveur (R) du montant (Mi) transféré par rapport au compte de réserve unique (CRU) : il s'agit là simplement d'une opération de compensation d'un montant (Mi) entre les plafonds des cartes de l'émetteur (E) et du receveur (R) au sein même du (CRU). Dans ce cas, le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRU) en payant un service donné avec sa carte duale (CD) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche,
• Variation instantanée en temps réel à partir de l'instant (T) du plafond dynamique de la carte duale (CD) du receveur (R) vis-à-vis du (CVR/CRU) de façon continue en fonction des virements mobiles instantanés nouveaux reçus (Mj) (22, 25, 53, 291), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24 , 53, 281) aux (GAB).
Procédé CRU/PNC2PNC de paiement mobile interpersonnel instantané (P2P) selon les revendications (1 ou 2) et 4 permettant à un émetteur (E) non bancarisé appelant de son téléphone basique le service USSD géré par le (SU) ou utilisant l'application installée sur son téléphone mobile dans le cas d'un Smartphone, d'effectuer en tout instant (T) un virement monétique mobile intra bancaire interpersonnel instantané d'un montant (Mi) de son compte bancaire virtuel (CVE) vers le compte bancaire virtuel (CVRl) d'un bénéficiaire (R) non bancarisé adossé au (CRU), caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R), • Diminution instantanée en (T) (28, 25, 21) du plafond dynamique de la carte classique (C) de l'émetteur (E) du montant (Mi) transféré par rapport au compte de réserve unique (CRU) domicilié à la banque (B),
• Augmentation instantanée en (T) (29, 25, 22, 62) du plafond dynamique de la carte classique (C) du receveur (R) du montant (Mi) transféré par rapport au compte de réserve unique (CRU) : il s'agit là simplement d'une opération de compensation d'un montant (Mi) entre les plafonds des cartes de l'émetteur (E) et du receveur (R) au sein même du (CRU). Le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRU) en payant un service donné avec sa carte classique (C) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche,
• Variation instantanée en temps réel à partir de l'instant (T) du plafond dynamique de la carte classique (C) du receveur (R) vis-à-vis du (CVR/CRU) de façon continue en fonction des virements mobiles instantanés nouveaux reçus (Mj) (22, 25, 29, 61), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24, 28, 61) aux (GAB).
9. Procédé CRU/PNC2PC-CVR/BD de paiement mobile interpersonnel instantané (P2P) selon les revendications 3 et 4 et 7 permettant à l'émetteur (E) non bancarisé d'émettre au choix à un instant quelconque (T), en appelant de son téléphone basique le service USSD géré par le (SU) ou en utilisant l'application installée sur son téléphone mobile de type Smartphone, un virement monétique mobile interbancaire interpersonnel instantané d'un montant (Mi) de son compte bancaire virtuel (CVE) domicilié à la banque (Bl) vers le compte bancaire virtuel (CVR2/CRÙR) d'un bénéficiaire (R) ou de façon classique vers son compte courant (CR2), ces deux derniers étant tous les deux domiciliés dans une autre banque distincte (B2), caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R),
• Choix de l'émetteur (E) d'effectuer un virement mobile classique vers le compte courant (CR2) du receveur (R) : dans ce cas un ordre de virement classique (72) est exécuté par le (SIB1) de la banque émettrice (Bl) d'un montant (Mi) du compte de réserve unique (CRU) domicilié dans cette dernière banque vers le compte courant bancaire (CR2) domicilié à la banque réceptrice (B2). Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H,
• Choix de l'émetteur (E) d'effectuer un virement monétique mobile instantané vers le compte virtuel (CVR2) du receveur (R) adossé au compte (CRUR) domicilié à la banque réceptrice (B2),
• Augmentation instantanée en (T) (291, 25, 22) dans le cas du dernier choix du plafond dynamique de la carte classique duale (CD) du receveur (R) du montant (Mi) transféré par rapport au compte de réserve unique (CRUR). Le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRUR) en payant un service donné avec sa carte duale (CD) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche,
• Diminution instantanée en (T) (28, 25, 21) dans les deux cas de transferts précédents du plafond dynamique de la carte classique (C) de l'émetteur (E) du montant (Mi) transféré par rapport au compte de réserve unique (CRU),
• Envoi automatique en (T) dans le cas du dernier choix d'un ordre de virement classique (sous-jacent) (71) au (SIB1) de la banque émettrice (Bl) d'un montant (Mi) à effectuer du compte de réserve unique (CRU) domicilié dans cette dernière banque vers le compte de réserve unique (CRUR) domicilié à la banque (B2). il s'agit là simplement d'une opération de remboursement du montant (Mi) au crédit du (CRUR). Ce dernier n'est alors crédité qu'au bout d'un délai ΔΤ' allant de 12H à 72H,
• Variation instantanée en temps réel à partir de l'instant (T) du plafond dynamique de la carte duale (CD) du receveur (R) vis-à-vis du (CRUR) de façon continue en fonction des virements mobiles instantanés nouveaux reçus (Mj) (291, 25, 22, 73), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24, 73, 281) aux (GAB).
10. Procédé CRU/PNC2PNC/BD de paiement mobile interpersonnel instantané (P2P) selon les revendications 3 et 4 et 8 permettant à un émetteur (E) non bancarisé d'émettre en un instant (T) en appelant de son téléphone basique le service USSD géré par le (SU) ou en utilisant l'application installée sur son téléphone mobile dans le cas d'un Smartphone, un virement monétique mobile interbancaire interpersonnel instantané d'un montant (Mi) de son compte bancaire virtuel (CVE) adossé au (CRU) et domiciliés à la banque (Bl) vers le compte bancaire virtuel (CVR2) d'un bénéficiaire (R) adossé au (CRUR) domiciliés à la banque (B2), caractérisé en ce qu'il comporte les étapes successives suivantes :
• Envoi par l'émetteur (E) en (T) du virement bancaire mobile en question d'un montant (Mi) à destination du receveur (R),
• Diminution instantanée en (T) (28, 25, 21) du plafond dynamique de la carte classique (C) de l'émetteur (E) du montant (Mi) transféré par rapport au compte de réserve unique (CRU) domicilié à la banque (Bl),
• Augmentation instantanée en (T) (29, 25, 22) du plafond dynamique de la carte classique (C) du receveur (R) du montant (Mi) transféré par rapport au compte de réserve unique (CRUR) domicilié à la banque (B2): Le receveur (R) peut donc à partir de l'instant (T) dépenser ce montant en partie ou en totalité à partir du (CRUR) en payant un service donné avec sa carte classique (C) au moyen d'un (TPE) dans un point de vente ou en le retirant du (GAB) le plus proche, • Envoi automatique en (T) d'un ordre (81) de virement classique sous-jacent au (SIB1) de la banque émettrice (Bl) d'un montant (Mi) à effectuer du compte de réserve unique (CRU) domicilié dans cette dernière banque vers le compte de réserve unique (CRUR) domicilié à la banque (B2). Il ne devient alors effectif qu'au bout d'un délai ΔΤ' allant de 12H à 72H,
• Variation instantanée en temps réel à partir de l'instant (†) du plafond dynamique de la carte classique (C) du receveur (R) vis-à-vis du (CRUR) de façon continue en fonction des virements mobiles instantanés nouveaux reçus (Mj) (29, 25, 22, 82), des paiements effectués au moyen d'un (TPE) ainsi que des retraits effectués (20, 24 , 28, 82) aux (GAB).
11. Procédé de carte duale CD selon les revendications (l ou 2 ou 3 ou 5 ou 7 ou 9) et 4 permettant au receveur bancarisé (R) d'un virement ou paiement mobile interpersonnel instantané (P2P) disposant d'un compte courant (CR) et virtuel (CVR) dans une banque (B) d'avoir une seule et même carte dite duale (CD) de paiement et de retrait aux (GAB) associée auxdits comptes courant et virtuel, ce dernier étant adossé au (CRU), caractérisé en ce qu'il comporte les étapes successives suivantes :
• En premier lieu, le receveur (R) (90, 91, 92) utilise un mot de passe unique associé à sa carte duale (CD) aux (GAB) pour retirer un montant d'argent (M) qui lui a été viré instantanément via le téléphone mobile d'un émetteur (E) ou pour le dépenser en payant un service donné dans un point de vente au moyen d'un (TPE),
• Transmission d'une demande de retrait interbancaire (90) du montant (M) par le receveur (R) aux (GAB) ou de paiement d'un service donné dans un point de vente par le biais d'un (TPE) (91) et ce directement à un serveur distant externe (SRI) qui la transmet par liaison VPN (93) pour vérification à un serveur interne bancaire (SIB) appartenant à la banque (B),
• Transmission d'une demande de retrait intra bancaire (92) du montant (M) par le receveur (R) aux (GAB) de ladite banque directement au serveur interne bancaire (SIB),
• Réception par ledit serveur interne bancaire (SIB) de l'une quelconque desdites demandes une fois transmise,
• Renvoi par le (SIB) après vérification d'une interface unique -au (GAB) ou sur (TPE)- via le serveur externe (SRI) (93, 94) ou directement (95) si l'ordre émane d'une demande de retrait intra bancaire permettant ainsi au receveur (R) d'accéder au choix à l'un de ses deux comptes à savoir son compte courant (CR) ou virtuel (CVR) domiciliés à la même banque (B),
• Choix du receveur (R) à partir de cette interface unique aux (GAB) ou sur un (TPE) de débiter son compte courant (CR) ou virtuel (CVR) du montant (M), Transmission de l'ordre afférant (94) à ce choix soit au serveur externe (SRI) qui le renvoie à son tour (93) au serveur interne bancaire (SIB) pour traitement dans le cas d'un retrait interbancaire ou d'un paiement par (TPE) dans un point de vente donné soit directement (95) au serveur interne bancaire (SIB) dans le cas d'un retrait intra bancaire,
Opération de débit du compte (CRU) (20) du montant (M) viré instantanément effectuée par le serveur interne bancaire (SIB) au moyen de la base de données centrale (BSIB) dans le cas où le receveur (R) choisit d'utiliser son compte virtuel (CVR),
Envoi dans ce cas par le serveur interne bancaire (SIB) d'un ordre de mise à jour par liaison VPN (24, 96) au serveur dédié (SD) qui procède alors dans la base de données dédiée (BSD) à l'enregistrement et la diminution (281) du niveau du plafond dynamique (Pit) de la carte duale (CD) du receveur (R) du montant (M) transféré et ce par rapport au compte de réserve unique (CRU) domicilié à la banque (B),
Opération de débit effectuée (30) dans la (BSIB) par le serveur interne bancaire (SIB) dudit compte courant (CR) d'un autre montant que (M) dans le cas où le receveur (R) choisit d'utiliser ce dernier et ce sans en rendre compte au serveur dédié (SD),
Transmission par le serveur interne (SIB) d'un ordre de remise du montant (M) ou un autre montant au (GAB) (93, 94, 95) quémandeur si le receveur R choisit respectivement de retirer le montant viré instantanément à partir de son compte virtuel (CVR/CRU) ou à partir de son compte courant (CR),
Transmission -toujours par le même serveur- d'un ordre de virement classique du compte courant (CR) ou virtuel (CVR/CRU) vers le compte bancaire créditeur appartenant au point de vente dans le cas d'un paiement d'un service donné au moyen d'un (TPE) par le biais de la carte duale (CD) du receveur (R).
PCT/MA2014/000017 2013-08-16 2014-08-15 Systemes et procedes de paiement mobile interpersonnel instantane (p2p) WO2015023172A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
MA36195 2013-08-16
MA36195A MA20150094A2 (fr) 2013-08-16 2013-08-16 Agencements et procédés de paiement mobile interpersonnel instantané

Publications (2)

Publication Number Publication Date
WO2015023172A2 true WO2015023172A2 (fr) 2015-02-19
WO2015023172A3 WO2015023172A3 (fr) 2015-04-09

Family

ID=51862499

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/MA2014/000017 WO2015023172A2 (fr) 2013-08-16 2014-08-15 Systemes et procedes de paiement mobile interpersonnel instantane (p2p)

Country Status (2)

Country Link
MA (1) MA20150094A2 (fr)
WO (1) WO2015023172A2 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
CN110214334A (zh) * 2016-10-28 2019-09-06 摩根大通国家银行 对网络支付应用分布式账本以作为金融交易结算和对账
US10445739B1 (en) 2014-08-14 2019-10-15 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US10997592B1 (en) 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11074577B1 (en) 2018-05-10 2021-07-27 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11295297B1 (en) 2018-02-26 2022-04-05 Wells Fargo Bank, N.A. Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet
US11410161B1 (en) 2014-04-30 2022-08-09 Wells Fargo Bank, N.A. Mobile wallet systems and methods
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
US11568389B1 (en) 2014-04-30 2023-01-31 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US11615401B1 (en) 2014-04-30 2023-03-28 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11853919B1 (en) 2015-03-04 2023-12-26 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer funds requests
US11948134B1 (en) 2019-06-03 2024-04-02 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US11995621B1 (en) 2021-10-22 2024-05-28 Wells Fargo Bank, N.A. Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services
US12045809B1 (en) 2018-08-30 2024-07-23 Wells Fargo Bank, N.A. Biller consortium enrollment and transaction management engine

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0514602D0 (en) * 2005-07-15 2005-08-24 Taylor Robert J R A method of enabling a user to purchase a utility and a system therefor

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11615401B1 (en) 2014-04-30 2023-03-28 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US10997592B1 (en) 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11593789B1 (en) 2014-04-30 2023-02-28 Wells Fargo Bank, N.A. Mobile wallet account provisioning systems and methods
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US12079802B1 (en) 2014-04-30 2024-09-03 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US12079803B1 (en) 2014-04-30 2024-09-03 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11295294B1 (en) 2014-04-30 2022-04-05 Wells Fargo Bank, N.A. Mobile wallet account provisioning systems and methods
US12056688B1 (en) 2014-04-30 2024-08-06 Wells Fargo Bank, N.A. Mobile device transaction systems and methods
US11410161B1 (en) 2014-04-30 2022-08-09 Wells Fargo Bank, N.A. Mobile wallet systems and methods
US11423393B1 (en) 2014-04-30 2022-08-23 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11935045B1 (en) 2014-04-30 2024-03-19 Wells Fargo Bank, N.A. Mobile wallet account provisioning systems and methods
US11568389B1 (en) 2014-04-30 2023-01-31 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11574300B1 (en) 2014-04-30 2023-02-07 Wells Fargo Bank, N.A. Mobile wallet systems and methods using trace identifier using card networks
US11587058B1 (en) 2014-04-30 2023-02-21 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11928668B1 (en) 2014-04-30 2024-03-12 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11748736B1 (en) 2014-04-30 2023-09-05 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11645647B1 (en) 2014-04-30 2023-05-09 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11651351B1 (en) 2014-04-30 2023-05-16 Wells Fargo Bank, N.A. Mobile wallet account provisioning systems and methods
US11663599B1 (en) 2014-04-30 2023-05-30 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US11132693B1 (en) 2014-08-14 2021-09-28 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US12086809B1 (en) 2014-08-14 2024-09-10 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US10445739B1 (en) 2014-08-14 2019-10-15 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US11853919B1 (en) 2015-03-04 2023-12-26 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer funds requests
US11734657B1 (en) 2016-10-03 2023-08-22 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
CN110214334A (zh) * 2016-10-28 2019-09-06 摩根大通国家银行 对网络支付应用分布式账本以作为金融交易结算和对账
CN110214334B (zh) * 2016-10-28 2023-08-08 摩根大通国家银行 对网络支付应用分布式账本以作为金融交易结算和对账
US11295297B1 (en) 2018-02-26 2022-04-05 Wells Fargo Bank, N.A. Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11074577B1 (en) 2018-05-10 2021-07-27 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US12045809B1 (en) 2018-08-30 2024-07-23 Wells Fargo Bank, N.A. Biller consortium enrollment and transaction management engine
US11948134B1 (en) 2019-06-03 2024-04-02 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US11995621B1 (en) 2021-10-22 2024-05-28 Wells Fargo Bank, N.A. Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services

Also Published As

Publication number Publication date
WO2015023172A3 (fr) 2015-04-09
MA20150094A2 (fr) 2015-03-31

Similar Documents

Publication Publication Date Title
WO2015023172A2 (fr) Systemes et procedes de paiement mobile interpersonnel instantane (p2p)
US10163084B2 (en) Banking systems controlled by data bearing records
US20190303931A1 (en) Method of, system for, data processing device, and integrated circuit device for implementing a distributed, ledger-based processing and recording of an electronic financial transaction
US20150026072A1 (en) Global world universal digital mobile and wearable currency image token and ledger
US20170032365A1 (en) Crypto-currency-based accrued value interoperability
US20150039517A1 (en) Cloud entertainment platform
FR3031613A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication.
WO2015028435A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants
WO2018154082A1 (fr) Système et procédé de traitement d'une transaction bancaire
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
FR3042894A1 (fr) Procede de securisation de traitement de donnees transactionnelles, terminal et programme d'ordinateur correspondant
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP3382628A1 (fr) Procédé de traitement de données par un terminal de paiement, terminal de paiement et programme correspondant
FR3069356A1 (fr) Procede et systeme de gestion d'un paiement par porte-monnaie electronique
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
Hossain et al. Analysis of centralized payment eco-system: A systematic review on e-payments
EP1354288A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
Murray Breaking Benjamin: Security Threats in Mobile Payment Applications
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
FR3020166A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
GB2512615A (en) Secure communications channel
GB2512617A (en) Content processing system
GB2512616A (en) Resource control system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14793636

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14793636

Country of ref document: EP

Kind code of ref document: A2