WO2015125126A2 - Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable - Google Patents

Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable Download PDF

Info

Publication number
WO2015125126A2
WO2015125126A2 PCT/IB2015/054717 IB2015054717W WO2015125126A2 WO 2015125126 A2 WO2015125126 A2 WO 2015125126A2 IB 2015054717 W IB2015054717 W IB 2015054717W WO 2015125126 A2 WO2015125126 A2 WO 2015125126A2
Authority
WO
WIPO (PCT)
Prior art keywords
user
account
virtual money
request
operator
Prior art date
Application number
PCT/IB2015/054717
Other languages
English (en)
Other versions
WO2015125126A3 (fr
Inventor
Patrick MANDENGUE
Original Assignee
Mandengue Patrick
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 Mandengue Patrick filed Critical Mandengue Patrick
Priority to PCT/IB2015/054717 priority Critical patent/WO2015125126A2/fr
Publication of WO2015125126A2 publication Critical patent/WO2015125126A2/fr
Publication of WO2015125126A3 publication Critical patent/WO2015125126A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS

Definitions

  • the field of the disclosure relates to the processing of transactions and, in particular, to the generation of a virtual currency and processing of transactions via a mobile communication channel.
  • GSMA Global System for Mobile Communications
  • the solution of transforming Airtime back to virtual money proposed here can be deployed by a trusted 3 rd party to solve the biggest technical and financial challenges of a collaborative Virtual Money Environment with a common Virtual currency, transferable by all mobile users, generated by all mobile operators, and understood by all banks.
  • Interoperability is easily achieved through the trusted Virtual Money operator that serves as an aggregator to all MNOs. Users from an operator A could then easily send Virtual money to a user from Operator B (a service which is inexistent today) ;
  • Cash out via merchant partners will be improved and secured thanks to ATM withdrawal with simply user phone number and PIN code. This is a technology that already exists with several financial institutions and is not part of the embodiment of this disclosure.
  • Embodiments of the disclosure aim to address these and other problems individually and collectively, at least to some extent.
  • a method to generate virtual money from user's airtime and debit operator airtime account provides a method of generating virtual money from prepaid airtime by transferring user prepaid airtime from user prepaid account to Virtual Money operator prepaid account.
  • the Virtual Money Operator will just need to be set up as an Airtime distributor in the MNO system.
  • the method comprises sending a request from a customer mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the user data by matching the data with customer data maintained in Mobile Network Operator Server; transferring the user request to the Virtual Money Operator ; verifying user request details (application code, user data, account, PIN-Personal Identification Number) ; sending an inter-account transfer request to the Mobile Network Operator Prepaid system to debit user and credit the Virtual Money Operator by the corresponding transaction value; receiving confirmation of the account adjustment request by the Mobile Network Operator; proceeding with the credit of the user virtual account in the Virtual Money Operator; sending an user account adjustment to the Virtual Money financial institution ; proceeding with the update of the user bank account in the Virtual Money Financial institution; and sending a confirmation message of the success of the operation to the user mobile communication device via the Mobile Network Operator.
  • the disclosure also provides a method of generating virtual money from prepaid airtime without the necessity of adjusting the prepaid account of the Virtual Money Operator which does not exist in this embodiment of the disclosure.
  • the method comprises sending a request from a customer mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the user data by matching the data with customer data maintained in Mobile Network Operator Server; transferring the user request to the Virtual Money Operator ; verifying user request details; sending an account request to the Mobile Network Operator Prepaid system to debit user by the corresponding transaction value; receiving confirmation of the account adjustment request by the Mobile Network Operator; proceeding with the credit of the user virtual account in the Virtual Money Operator; sending an user account adjustment to the Virtual Money financial institution ; proceeding with the update of the user bank account in the Virtual Money Financial institution ; proceeding with the compensation between Virtual Money bank and the Mobile Operator Bank; sending a confirmation message of the success of the operation to the user mobile communication device via the Mobile Network Operator.
  • the disclosure further provides a method transacting virtual money to credit user prepaid account with airtime termed airtime top-up.
  • the method comprises sending a request from a customer mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the user data by matching the data with customer data maintained in Mobile Network Operator Server; transferring the user request to the Virtual Money Operator ; verifying user request details ; sending a credit account request to the Mobile Network Operator Prepaid system with the corresponding transaction value; receiving confirmation of the account adjustment request by the Mobile Network Operator; proceeding with the debit of the user virtual account in the Virtual Money Operator; sending an user account adjustment to the Virtual Money financial institution; proceeding with the update of the user bank account in the Virtual Money Financial institution; and sending a confirmation message of the success of the operation to the user mobile communication device via the Mobile Network Operator; proceeding with the compensation between Virtual Money bank and the Mobile Operator Bank;
  • the disclosure also provides a method of transacting virtual money for on-net peer-to-peer transfer.
  • the method comprises sending a request from a sender mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the sender data by matching the data with user data maintained in Mobile Network Operator Server; transferring the sender request to the Virtual Money Operator ; verifying sender request ; proceeding with the debit of sender virtual account and credit of the receiver virtual account by the corresponding transaction value; sending an user account adjustment to the Virtual Money financial institution for both the sender and the receiver bank accounts; proceeding with the update of the sender and the receiver bank accounts in the Virtual Money Financial institution; and sending a confirmation message of the success of the operation to the user mobile communication device via the Mobile Network Operator.
  • the disclosure also provides a method of transacting virtual money for off-net peer-to-peer transfer.
  • the method comprises sending a request from a sender mobile communication device to the Virtual Money Operator via the sender's Mobile Network Operator; verifying the sender data by matching the data with user data maintained in sender's Mobile Network Operator Server; transferring the sender request to the Virtual Money Operator ; verifying sender request details; proceeding with the debit of sender virtual account and credit of the receiver virtual account by the corresponding transaction value; sending an user account adjustment to the Virtual Money financial institution; proceeding with the update of the sender and receiver bank accounts in the Virtual Money Financial institution ; and sending a confirmation message of the success of the operation to the sender and the receiver's mobile communication devices via the sender's Mobile Network Operator and receiver Mobile Network Operator respectively.
  • the disclosure further provides a method of transacting virtual money for international peer-to-peer transfer.
  • the method comprises sending a request from a sender mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the sender data by matching the data with user data maintained in Mobile Network Operator Server; transferring the sender request to the Virtual Money Operator ; verifying sender request details; sending an authorization request to the International Money Transfer Operator; proceeding with the debit of the sender virtual account and credit the receiver virtual account by the corresponding transaction value; sending an account adjustment to the Virtual Money financial institutions for both the sender and the receiver bank accounts; proceeding with the update of the sender and the receiver bank accounts in the Virtual Money Financial institutions respectively; and sending a confirmation message of the success of the operation to the users mobile communication devices via the sender and receiver Mobile Network Operators respectively.
  • the disclosure also provides a method for transacting virtual money for merchant payment.
  • the method comprises sending a request from a customer mobile communication device to the Virtual Money Operator via the Mobile Network Operator; verifying the user data by matching the data with customer data maintained in Mobile Network Operator Server; transferring the user request to the Virtual Money Operator ; verifying user request details ; sending an account request to the Merchant Billing system; receiving confirmation of the account adjustment request by the Merchant Billing System; proceeding with the debit of the user virtual account in the Virtual Money Operator; sending an user account adjustment to the Virtual Money financial institution; proceeding with the update of the user bank account in the Virtual Money Financial institution; and sending a confirmation message of the success of the operation to the user mobile communication device via the Mobile Network Operator.
  • FIG. 1 illustrates a block diagram of an exemplary embodiment of a module architecture of the Virtual Money Operator system is a schematic diagram that illustrates an embodiment of a system where a user generating and transacting virtual money via a mobile network, a virtual money operator, the Virtual financial institution, and the Mobile Operator Bank for compensation
  • FIG. 2 is a flowchart diagram that illustrates an embodiment of a system where an user generating virtual money via a mobile network, a virtual money operator and a financial institution as shown in FIG. 2
  • FIG. 2 is a flowchart diagram that illustrates another embodiment of a system where a user generating virtual money via a mobile network, a virtual money operator and a financial institution and the Mobile Operator Bank as shown in FIG. 2
  • FIG. 2 is a flowchart diagram that illustrates an embodiment of a system of a virtual money transaction for Airtime Top up via a mobile network, a virtual money operator and a financial institution as shown in FIG. 2 is a flowchart diagram that illustrates an embodiment of a system of a virtual money transaction for Airtime Top up via a mobile network, a virtual money operator and a financial institution and the Mobile Operator Bank as illustrated in FIG. 2
  • FIG. 1 is a schematic diagram that illustrates a system of transacting virtual money between 2 users through the same mobile network, a virtual money operator and a virtual money financial institution.
  • FIG. 5A is a flowchart diagram that illustrates a system of transacting virtual between 2 users through the same mobile network, a virtual money operator and a virtual money financial institution as illustrated in FIG. 5A in accordance with one embodiment of the present disclosure.
  • FIG. 1 is a schematic diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks in different countries, a virtual money operator and a virtual money financial institution .
  • FIG. 6A is a flowchart diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks in different countries, a virtual money operator and a virtual money financial institution as shown in FIG. 6A in accordance with one embodiment of the present disclosure.
  • FIG. 1 is a schematic diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks in different countries, a virtual money operator, a virtual money financial institution and an international Money transfer Operator.
  • FIG. 7A is flowchart diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks in different countries, a virtual money operator, a virtual money financial institution and an international Money transfer Operator as shown in FIG. 7A in accordance with one embodiment of the present disclosure.
  • FIG. 8A is a schematic diagram that illustrates an user transacting virtual money for merchant bill payment via a mobile network, a virtual money operator, a financial institution, a merchant billing system and the Merchant Bank.
  • FIG. 8B is a flowchart diagram that illustrates an user transacting virtual money for merchant bill payment via a mobile network, a virtual money operator, a financial institution, a merchant billing system and the Merchant Bank as shown in FIG. 8A in accordance with one embodiment of the present disclosure.
  • FIG. 1 illustrates a block diagram of an exemplary embodiment of a module architecture of the Virtual Money Operator system
  • FIG. 1 demonstrates in a simplified schematic form the architecture of the Virtual Money Operator System.
  • FIG. 1 does not purport to be comprehensive but merely illustrative.
  • an Application Communication Module 110 is composed of an Interactive Voice Response System 112, a Short Message Service center 114 and USSD Handler 116.
  • the Application Communication Module 110 is the key part of the Virtual money application that interacts with the User through the Mobile Network operator 210 serving here as a transit system.
  • the Application Communication Module 110 comprises a plurality of distributed and scalable network nodes which handle call setup logic and specialized routing instructions. There are various channels proposed in this embodiment.
  • the voice channel of the Application Communication Module 110 is managed by the IVR system 112 and responds through an intelligent logic to user response on her Mobile communication device.
  • the SMS Center 114 receives and sends short Messages to and from the application to the User Mobile communication device through the MNO SMS Center. Such messages are system commands or user information.
  • the USSD Handler receives and interprets the USSD code sent by the user mobile communication device by using the internal application logic.
  • the Security and control Module 120 is composed of a Security server 122 that has all the security logic of the application in terms of communication, payment, account management, reporting, and transactions; and a transaction security keys database 124 that generates and keep all the transactions keys that serve as unique transaction identifiers within the application and with external nodes.
  • the Security and Control Module 120 controls and is directly connected to the account Management Module 130, the Payment transaction Module 140 and an external Systems Node 190.
  • the Account Management Module regroup all the elements to manage Virtual Money accounts. It is composed of an account management server 132 that defines the logic of creating, deleting and managing virtual money accounts and virtual account users; it has 2 important databases: an user database 134 that keeps detailed information of all the virtual money users and get the information from the MNO user listing in their HLR (Home Location Register) and VLR (Visitor Location Register) and a virtual account database 136 with such information as creation date and account value in country currency.
  • HLR Home Location Register
  • VLR Visitor Location Register
  • the Payment Transaction Module 140 is the brain of the Virtual Money Application. It has the logic to make payments when certain pre-defined conditions are verified from the Security and control Module 120 and the Account Management Module 130. Its role is then to create transaction commands through its Payment transaction server 142 and sends to security server 122 to attach a unique transaction identifier from the Transaction Security keys database 124. When this operation is completed, the payment transaction is recorded in the Payment Transaction Database 144.
  • the External Systems Node 190 regroups important system interfaces: the MNO Interface 150 connects with Mobile Network Operators, Merchant billing System Interface 160 connects with Merchant Billing Systems and Virtual Financial Institution Interface 170 connects with various Financial Institutions systems. Each of these interfaces has internal logic and routing functionalities that will be further detailed.
  • the External Systems Node 190 also includes an Application Programming Interface 180 (API) to communicate with any external systems not listed here like other mobile money systems.
  • API Application Programming Interface 180
  • FIG. 2 is a schematic diagram that illustrates an embodiment of a system where a user generating and transacting virtual money via a mobile network, a virtual money operator, the Virtual financial institution, and the Mobile Operator Bank for compensation .
  • a mobile communication device 200 of a user communicates with a Mobile Network Operator via a base station system (not shown) which in turn connects to an Access Network made of a MSC and Home Location Register (HLR).
  • the mobile communication device 200 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 200 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • the base station system (not shown) comprises a base station controller (BSC) and a base transceiver station (BTS) with associated antenna.
  • BSC base station controller
  • BTS base transceiver station
  • the Access Network - mobile switching center (MSC) 212 forms part of the architecture of the Mobile Network Operator (MNO) system 210.
  • the access module 212 or service control point has screening logic to identify a request received from a user via the user's mobile communication device 200.
  • User's request infrastructure typically systems such as an interactive voice response (IVR) system (not shown), a short code (USSD) center 218 or a short message service (SMS) center 216, receives the request from the mobile communication device 200 via the Access Network 212.
  • IVR interactive voice response
  • USB short code
  • SMS short message service
  • the data relating to multiple user mobile airtime accounts is stored in a mobile service provider database 224.
  • Each user airtime account is associated and linked with the unique device identifier of the mobile communication device 200 of the user.
  • the mobile communication device data such as the International Mobile Subscriber Identity (IMSI) number of the user's mobile communication device 200, is also stored in the database 224.
  • the mobile service provider database 224 is also used to store user registration data and user mobile account data. This is discussed in more detail below.
  • the Virtual Money Operator architecture 100 as presented in one embodiment in FIG. 1 has all the logic and routing functionalities to allow and execute a payment transaction from a user request on a mobile communication device 200 that transited via a Mobile Network Operator 210.
  • the Virtual Money Bank 220 is an actual bank that stores user's bank accounts.
  • the unique bank accounts identifiers are the user IMSI and are stored in a Virtual Money Bank (VMB) Database 222.
  • VMB Virtual Money Bank
  • the VMB is further connected via ACH (Automated Clearing House) to MNO financial institution 230 for compensations. Further details of that particular operation below.
  • FIG. 3A is a flowchart diagram that illustrates an embodiment of a system where a user generating virtual money via a mobile network, a virtual money operator and a financial institution as shown in FIG. 2. It uses the various key elements of the system architecture shown in FIG 2.
  • a user that wants to generate Virtual money shall send the required request code 300 from her mobile communication device 200.
  • An example could be a simple ussd code like *123*5000# which generates 5000 francs in the user virtual money account.
  • the Virtual money generation request uses an inter-account transfer feature of Intelligent Network 214.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 302. It is called "white- list" screening.
  • the IN 214 orders Short Message Service Centre (SMSC) 216 to send a predefined Error message to the user.
  • SMSC Short Message Service Centre
  • the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security server 122 checks user credentials 304 with the Account Management server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216.
  • the user then receives the error message 306 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142 for treatment.
  • the payment transaction module server 142 creates a payment transaction with relevant information (user Mobile Station International Subscriber Directory Number - MSISDN, VMO prepaid account, transaction Value, Transaction ID) . That payment transaction is sent to the security and control server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent to Intelligent Network 214.
  • the Intelligent Network 214 interprets the payment transaction and executes an inter-account transfer 308 of airtime from User Airtime Account to Virtual Money Airtime Account. When this Inter-account operation is completed, the Intelligent Network (IN) 214 sends a confirmation message to the Payment transaction server 142. The Payment Transaction server 142 initiates an Account Credit instruction with a certain value to the account management server 132.
  • the Account management server 132 credits 310 the User Virtual account with the corresponding value and sends an instruction confirmation back to the Payment transaction server 142.
  • the Payment transaction Server 142 sends an account update command to the Virtual Money Bank (VMB) 220.
  • VMB Virtual Money Bank
  • the VMB 220 updates 312 the User Virtual Bank account, located in the VMB Database 222, with User Virtual Money Account value received from the command.
  • the VMB 220 sends the confirmation message back to the VMO payment transaction server 142.
  • the Payment transaction server 142 initiates an instruction to the SMSC 114 to send a pre-defined successful message 314 to SMSC 216.
  • the SMSC 216 transfers that message 316 to the user.
  • the user receives the confirmation message 318 on the Mobile communication device 200.
  • FIG. 3B is a flowchart diagram that illustrates another embodiment of a system where a user generating virtual money via a mobile network, a virtual money operator, a financial institution and the Mobile Operator Bank.
  • a user that wants to generate Virtual money shall send the required request code 300 from her mobile communication device 200.
  • An example could be a simple ussd code like *123*5000# which generates 5000 francs in the user virtual money account.
  • the Virtual money generation request is based on a fundamental accounting rule in Telecommunication Industry that states that revenue for a Mobile operator is only recognized when the user consumes any service of the Mobile Operator (Messaging, Voice, or data) .
  • the Airtime is refilled and not used yet for any of the Mobile operator services, that value in the user prepaid account does not belong to the Mobile Operator yet.
  • that is the principle applied .
  • the airtime value is debited from the user prepaid account and not transferred as it was the case in the previous embodiment of this disclosure.
  • a compensation between the Mobile Operator Bank and the Virtual Money Bank shall occur at the end of the transaction .
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 checks that the user is authorized to make such request 302. It is called "white- list" screening .
  • the IN 214 orders SMSC 216 to send a predefined Error message to the user.
  • the user request is then terminated and the user receives the Error message 306 on her mobile communication device 200.
  • VMO Virtual Money Operator
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security server 122 checks user credentials 304 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216 of the MNO 210.
  • the user receives the error message 306 on the mobile communication device
  • the user request is forwarded to the Payment transaction module 142 for treatment.
  • the payment transaction module server 142 creates a payment transaction with relevant information (user Mobile MSISDN, VMO prepaid account, transaction Value, Transaction ID) . That payment transaction is sent to the security and control Server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent to Intelligent Network 214.
  • the Intelligent Network 214 interprets the payment transaction and executes a debit airtime account command 320 from User Airtime Account. When this debit operation is completed, the IN 214 sends a confirmation message to the Payment Transaction Module 142. The Payment Transaction server 142 initiates an Account Credit instruction with a certain value to the account management Server 132.
  • the Account management server 132 credits 322 the User Virtual account located in the Virtual accounts database 136 with the corresponding value and sends an instruction confirmation back to the Payment transaction server 142.
  • the Payment transaction Server 142 creates an account update command to the Virtual Money Bank 220.
  • the Virtual Money Bank 220 updates 324 the User Virtual Bank account, located in the VMB Database 222, with User Virtual Money Account value received from the command.
  • the VMB 220 sends the confirmation message back to the VMO payment transaction server 142.
  • the Payment transaction server 142 initiates an instruction to the SMSC 114 within the Application Communication Module 110 to send a pre-defined successful message 326 to SMSC 216.
  • the SMSC 216 transfers that message 328 to the user.
  • the user then receives the confirmation message 330 on the Mobile communication device 200.
  • the Virtual Money Bank 220 also sends a compensation request 332 to MNO Bank with the relevant information on the transaction. This compensation operation shall be done on a daily basis depending on Banks and ACH agreement.
  • FIG. 4A is a flowchart diagram that illustrates an embodiment of a system where a user purchasing prepaid Airtime with virtual money via a mobile network, a virtual money operator and a financial institution as shown in FIG. 2. It uses the various key elements of the system architecture shown in FIG 2.
  • a user that wants to purchase prepaid Airtime with Virtual money shall send the required request code 400 from her mobile communication device 200.
  • An example could be a simple ussd code like *167*987654*5000# which transfer 5000 francs worth of prepaid airtime to user 987654 prepaid account.
  • the Virtual money generation request uses an inter-account transfer feature of Intelligent Network 214.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 402. It is called "white- list" screening.
  • the IN 214 orders SMSC 216 to send a predefined Error message to the user.
  • the user request is then terminated and the user received the Error message 406 on her mobile communication device 200.
  • the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control server 122.
  • the Security server 122 checks user credentials 404 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 If the authorization is not granted by the security server 122 because of an error in the user request code structure or an blacklisting of the user in the user database 134 or insufficient fund in the user Virtual Money account 136, the security server instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216 of the MNO 210.
  • the user then receives the error message 406 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142 for treatment.
  • the payment transaction module server 142 then creates a payment transaction with relevant information (Sender MSISDN, Receiver MSISDN, transaction Value, Transaction ID). That payment transaction is sent to the security and control server 122 to acquire a transaction security unique key from the database 124.
  • the now secure payment transaction is sent to MNO 210 and Intelligent Network 214 specifically.
  • the Intelligent Network 214 interprets the payment transaction and executes an inter-account transfer 408 of airtime from Sender prepaid Airtime Account to Receiver prepaid Airtime Account. When this Inter-account operation is completed, the IN 214 sends a confirmation message to the Payment transaction Server 142 in particular. The Payment Transaction server 142 initiates an Account debit instruction with a certain value to the account management Server 132.
  • the Account management server 132 then debits 410 the Sender Virtual account with the corresponding value and sends an instruction confirmation back to the Payment transaction server 142.
  • the Payment transaction Server 142 sends an account update command to the VMB 220.
  • the VMB 220 updates 412 the User Virtual Bank account with User Virtual Money Account, located in the VMB database 222, value received from the command.
  • the VMB 220 sends the confirmation message back to the payment transaction server 142.
  • the Payment transaction server 142 initiates an instruction to the SMSC 114 to send a pre-defined successful message 414 to SMSC 216.
  • the SMSC 216 transfers that message 416 to the user. The user then receives the confirmation message 418 on the Mobile communication device 200.
  • FIG.4B is a flowchart diagram that illustrates an embodiment of a system where a user generating virtual money via a mobile network, a virtual money operator and a financial institution as shown in FIG. 2. It uses the various key elements of the system architecture shown in FIG 2.
  • FIG.4B flowchart diagram that illustrates another embodiment of a system where a user purchasing prepaid Airtime with virtual money via a mobile network, a virtual money operator and a financial institution and the Mobile Operator Bank as shown in FIG 2. It uses the various key elements of the system architecture shown in FIG 2.
  • a user that wants to purchase prepaid Airtime with Virtual money shall send the required request code 400 from her mobile communication device 200.
  • An example could be a simple ussd code like *167*987654*5000# which transfer 5000 francs worth of prepaid airtime to user 987654 prepaid account.
  • the Virtual money generation request uses an inter-account transfer feature of Intelligent Network 214.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 402. It is called "white- list" screening.
  • the IN 214 orders SMSC 216 to send a predefined Error message to the user.
  • the user request is then terminated and the user received the Error message 406 on her mobile communication device 200.
  • the user request is forwarded by the MNO 210 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security server 122 checks user credentials 404 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 If the authorization is not granted by the security server 122 because of an error in the user request code structure or an blacklisting of the user in the user database 134 or insufficient fund in the user Virtual Money account, the security server instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216 of the MNO 210.
  • the user then receives the error message 406 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142 for treatment.
  • the payment transaction module server 142 then create a payment transaction with relevant information (Sender MSISDN, Sender prepaid account, Receiver MSISDN, transaction Value, Transaction ID) . That payment transaction is sent to the security and control Server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent to Intelligent Network 214.
  • the Intelligent Network 214 interprets the payment transaction and executes a debit airtime account command 420 from User Airtime Account. When this debit operation is completed, the IN 214 sends a confirmation message to the Payment transaction server 142. The Payment Transaction server 142 sends an Account Credit instruction with a certain value to the account management server 132.
  • the Account management server 132 credits 422 the User Virtual account with the corresponding value and sends an instruction confirmation back to the Payment transaction server 142.
  • the Payment transaction Server 142 then initiates an account update command to the Virtual Money Bank 220.
  • the Virtual Money Bank 220 updates 424 the User Virtual Bank account located in the VMB Database 222 with User Virtual Money Account value received from the command.
  • the VMB 220 sends the confirmation message back to the VMO payment transaction server 142.
  • the Payment transaction server 142 sends an instruction to the SMSC 114 to send a pre-defined successful message 426 to SMSC 216.
  • the SMSC 216 transfers 428 that message to the user.
  • the user then receives 430 the confirmation message on the Mobile communication device 200.
  • the Virtual Money Bank 220 sends a compensation request 432 to MNO Bank 230 with the relevant information on the transaction .
  • This compensation operation shall be done on a daily basis depending on MNO Bank 230, VMB 220 and ACH agreement.
  • FIG. 5A is a schematic diagram that illustrates a system of transacting virtual money between 2 users through the same mobile network, a virtual money operator and a virtual money financial institution
  • a mobile communication device 200 of a user communicates with a Mobile Network Operator via a base station system (not shown) which in turn connects to an Access Network made of a MSC and HLR.
  • the mobile communication device 200 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 200 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the base station system (not shown) comprises a base station controller (BSC) and a base transceiver station (BTS) with associated antenna.
  • BSC base station controller
  • BTS base transceiver station
  • the Access Network - mobile switching center (MSC) 212 forms part of the architecture of the Mobile Network Operator (MSP) system 210.
  • the access module 212 or service control point has screening logic to identify a request received from a user via the user's mobile communication device 200.
  • User's request infrastructure typically systems such as an interactive voice response (IVR) system (not shown), a short code (USSD) center 218 or a short message service (SMS) center 216, receives the request from the mobile communication device 200 via the Access Network 212.
  • IVR interactive voice response
  • USB short code
  • SMS short message service
  • the data relating to multiple user mobile airtime accounts is stored in a mobile service provider database 224.
  • Each user airtime account is associated and linked with the unique device identifier of the mobile communication device 200 of the user.
  • the mobile communication device data such as the IMSI number of the user's mobile communication device 200, is also stored in the database 224.
  • the mobile service provider database 224 is also used to store user registration data and user mobile account data. This is discussed in more detail below.
  • the Virtual Money Operator architecture 100 as presented in one embodiment in FIG. 1 has all the logic and routing functionalities to allow and execute a payment transaction from a user request on a mobile communication device 200 that transited via a Mobile Network Operator 210.
  • the Virtual Money Bank 220 is an actual bank that connects users' Virtual money accounts to actual user's bank account.
  • the unique bank accounts identifiers are the user IMSI and are stored in a Virtual Money Bank (VMB) Database 222.
  • VMB Virtual Money Bank
  • the VMB is further connected via ACH (Automated Clearing House) to MNO financial institution 230 for compensations. Further details of that particular operation below.
  • the user and her mobile communication device 500 is another user connected to the same Mobile Network Operator 210 as the user and mobile communication Device 200.
  • Thet user and her communication device 500 is in this embodiment of the disclosure the receiver of the service. It has to be noted that the receiver could be a person or a business entity like a merchant. In that latter case, this disclosure shall serve to facilitate merchant payment in stores.
  • FIG. 5B is a flowchart diagram that illustrates a system of transacting virtual money between 2 users through the same mobile network, a virtual money operator and a financial institution as shown in FIG. 5A. It uses the various key elements of the system architecture shown in FIG 5A.
  • a user that wants to transfer Virtual money to another user on the same Mobile Network shall send the required request code 502 from her mobile communication device 200.
  • An example could be a simple ussd code like *124*456789*5000# which transfer the value of 5000 francs from her virtual money account to user 456789 virtual money account.
  • the Virtual money transfer request uses an inter-account transfer feature of VMO's 100.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 504. It is called "white-list" screening.
  • the IN 214 orders SMSC 216 to send a predefined Error message to the user. The user request is then terminated and the user received the Error message 508 on her mobile communication device 200. If the authorization is granted by the IN 214, the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security and Control Server 122 checks 506 the integrity of the request code structure. In fact it is important to properly make the request and *123*456789*5000#is different to *123*5000*456789# .
  • the Security server 122 check user credentials 506 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216.
  • the user then receives the error message 508 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction Server 142 for treatment.
  • the payment transaction module server 142 creates a payment transaction with relevant information (user MSISDN, receiver MSISDN, transaction Value, Transaction ID). That payment transaction is sent to the security and control Server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent back to Payment transaction server 142.
  • the Payment Transaction server 142 sends an inter-account transfer instruction with a certain value to the account management server 132.
  • the Account management server 132 executes an inter-account transfer 510 from sender virtual money account to receiver virtual money account. Both sender and receiver virtual money accounts are located in Virtual accounts Database 136. When the inter-account transfer account is completed, the Account management server 132 sends a confirmation back to the Payment Transaction server 142.
  • the Payment transaction Server 142 receives the confirmation and initiates an account update command to the VMB 220.
  • the VMB 220 updates 512 both sender and receiver User Virtual Money Bank accounts with User Virtual Money Accounts value accordingly, both located in the VMB Database 222.
  • the VMB 220 sends the confirmation message back to the VMO payment transaction server 142.
  • the Payment transaction server 142 sends an instruction to the SMSC 114 to send a pre-defined successful message 514 to the sender and a pre-defined successful message 518 to the receiver via the SMSC 216.
  • the SMSC 216 transfers 516 the messages to the sender and the receiver respectively.
  • the sender then receives the confirmation message 518 on the Mobile communication device 200.
  • the receiver receives the confirmation message 520 on the mobile communication device 500.
  • FIG. 6A is a schematic diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks, a virtual money operator and a virtual money financial institution.
  • a mobile communication device 200 of a user communicates with a Mobile Network Operator via a base station system (not shown) which in turn connects to an Access Network made of a MSC and HLR.
  • the mobile communication device 200 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 200 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the base station system (not shown) comprises a base station controller (BSC) and a base transceiver station (BTS) with associated antenna.
  • BSC base station controller
  • BTS base transceiver station
  • the Access Network - mobile switching center (MSC) 212 forms part of the architecture of the Mobile Network Operator (MNO) system 210.
  • the access module 212 or service control point has screening logic to identify a request received from a user via the user's mobile communication device 200.
  • User's request infrastructure typically systems such as an interactive voice response (IVR) system (not shown), a short code (USSD) center 218 or a short message service (SMS) center 216, receives the request from the mobile communication device 200 via the Access Network 212.
  • IVR interactive voice response
  • USB short code
  • SMS short message service
  • the data relating to multiple user mobile airtime accounts is stored in a mobile service provider database 224.
  • Each user airtime account is associated and linked with the unique device identifier of the mobile communication device 200 of the user.
  • the mobile communication device data such as the IMSI number of the user's mobile communication device 200, is also stored in the database 224.
  • the mobile service provider database 224 is also used to store user registration data and user mobile account data. This is discussed in more detail below.
  • the Virtual Money Operator architecture 100 as presented in one embodiment in FIG. 1 has all the logic and routing functionalities to allow and execute a payment transaction from a user request on a mobile communication device 200 that transited via a Mobile Network Operator 210.
  • the Virtual Money Bank 220 is an actual bank that connects users' Virtual money accounts to actual user's bank account.
  • the unique bank accounts identifiers are the user IMSI and are stored in a Virtual Money Bank (VMB) Database 222.
  • VMB Virtual Money Bank
  • the VMB is further connected via ACH (Automated Clearing House) to MNO financial institution 230 for compensations. Further details of that particular operation below.
  • a user and mobile communication Device 600 connected to a Mobile Network Operator 610 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • the mobile communication device 600 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the Access Network - mobile switching center (MSC) 612 forms part of the architecture of the Mobile Network Operator (MNO) system 610 and a short message service (SMS) center 614.
  • MNO Mobile Network Operator
  • SMS short message service
  • FIG. 6B is a flowchart diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks, a virtual money operator and a virtual money financial institution as shown in FIG. 6A in accordance with one embodiment of the present disclosure.
  • a user that wants to transfer Virtual money to another user on the same Mobile Network shall send the required request code 620 from her mobile communication device 200.
  • An example could be a simple ussd code like *124*456789*5000# which transfer the value of 5000 francs from her virtual money account to user 456789 virtual money account.
  • the Virtual money transfer request uses an inter-account transfer feature of VMO 100.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 622. It is called "white-list" screening.
  • the IN 214 orders SMSC 216 to send a predefined Error message to the user.
  • the user request is then terminated and the user received the Error message 626 on her mobile communication device 200.
  • the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security and Control Server 122 checks 624 the integrity of the request code structure. In fact it is important to properly make the request and *123*456789*5000#is different to *123*5000*456789# .
  • the Security server 122 checks user credentials 624 with the Account Management server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 If the authorization is not granted by the security server 122 because of an error in the user request code structure or a blacklisting of the user in the user database 134 or insufficient fund in the user Virtual Money account, the security server instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216.
  • the user then receives the error message 626 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142 for treatment.
  • the payment transaction module server 142 creates a payment transaction with relevant information (sender MSISDN, receiver MSISDN, transaction Value, Transaction ID). That payment transaction is sent to the security and control server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent back to Payment transaction server 142.
  • the Payment Transaction server 142 sends an inter-account transfer instruction with a certain value to the account management server 132.
  • the Account management server 132 executes an inter-account transfer from sender virtual money account to receiver virtual money account. Both sender and receiver virtual money accounts are located in Virtual accounts Database 136. When the inter-account transfer operation is completed.
  • the Account management server 132 sends a confirmation back to the Payment Transaction server 142.
  • the Payment transaction Server 142 receives the confirmation and initiates an account update command to the VMB 220.
  • the VMB 220 updates 632 both sender and receiver User Virtual Money Bank accounts, located in VMB Database 222, with Sender and receiver Virtual Money Accounts value respectively.
  • the VMB 220 sends the confirmation message back to the payment transaction server 142.
  • the Payment transaction server 142 initiates an instruction to the SMSC 114 to send a pre-defined successful message 634 to the sender and a pre-defined successful message 638 to the receiver via the SMSC 216.
  • the SMSC 216 transfers the messages to the sender and the receiver respectively.
  • the sender then receives the confirmation message 636 on the Mobile communication device 200.
  • the receiver receives the confirmation message 640 on the mobile communication device 600
  • FIG. 7A is a schematic diagram that illustrates a system of transacting virtual money between 2 users through two separate mobile networks located in different countries, a virtual money operator, a virtual money financial institution and an international Money transfer Operator.
  • a mobile communication device 200 of a user communicates with a Mobile Network Operator via a base station system (not shown) which in turn connects to an Access Network made of a MSC and HLR.
  • the mobile communication device 200 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 200 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the base station system (not shown) comprises a base station controller (BSC) and a base transceiver station (BTS) with associated antenna.
  • BSC base station controller
  • BTS base transceiver station
  • the Access Network - mobile switching center (MSC) 212 forms part of the architecture of the Mobile Network Operator (MNO) system 210.
  • the access module 212 or service control point has screening logic to identify a request received from a user via the user's mobile communication device 200.
  • User's request infrastructure typically systems such as an interactive voice response (IVR) system (not shown), a short code (USSD) center 218 or a short message service (SMS) center 216, receives the request from the mobile communication device 200 via the Access Network 212.
  • IVR interactive voice response
  • USB short code
  • SMS short message service
  • the data relating to multiple user mobile airtime accounts is stored in a mobile service provider database 224.
  • Each user airtime account is associated and linked with the unique device identifier of the mobile communication device 200 of the user.
  • the mobile communication device data such as the IMSI number of the user's mobile communication device 200, is also stored in the database 224.
  • the mobile service provider database 224 is also used to store user registration data and user mobile account data. This is discussed in more detail below.
  • the Virtual Money Operator architecture 100 as presented in one embodiment in FIG. 1 has all the logic and routing functionalities to allow and execute a payment transaction from a user request on a mobile communication device 200 that transited via a Mobile Network Operator 210.
  • the Virtual Money Bank 220 is an actual bank that connects users' Virtual money accounts to actual user's bank account.
  • the unique bank accounts identifiers are the user IMSI and are stored in a Virtual Money Bank (VMB) Database 222.
  • VMB Virtual Money Bank
  • the VMB is further connected via ACH (Automated Clearing House) to MNO financial institution 230 for compensations. Further details of that particular operation below.
  • the mobile communication device 700 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 700 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the Access Network - mobile switching center (MSC) 712 and a short message service (SMS) center 714 form part of the architecture of the Mobile Network Operator (MNO) system 710.
  • MSC Mobile Switched Access Network - mobile switching center
  • SMS short message service
  • MNO Mobile Network Operator
  • the Mobile Network Operator 710 is located in a different country than MNO 210
  • An international Money Transfer Operator (IMTO) 720 that processes currencies conversion and authorizes money transfer from country to country.
  • IMTO international Money Transfer Operator
  • FIG.7B is a flowchart diagram that illustrates a system of transacting virtual between 2 users through two separate mobile networks located in different countries, a virtual money operator and a virtual money financial institution as shown in FIG. 7A in accordance with one embodiment of the present disclosure.
  • a user that wants to transfer Virtual money to another user on a Mobile Network located in a different country shall send the required request code 730 from her mobile communication device 200.
  • An example could be a simple ussd code like *189*456789*5000# which transfer the value of 5000 francs from her virtual money account to international user's MSISDN 456789 virtual money account.
  • the Virtual money transfer request uses an inter-account transfer feature of VMO 100.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 732. It is called "white-list" screening. If the authorization is not granted by the IN 214, the IN 214 orders SMSC 216 to send a predefined Error message to the user. The user request is then terminated and the user received the Error message 626 on her mobile communication device 200.
  • the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control server 122.
  • the Security and Control Server 122 checks 734 the integrity of the request code structure. In fact it is important to properly make the request and *189*456789*5000#is different to *189*5000*456789# .
  • the Security server 122 checks user credentials 734 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 If the authorization is not granted by the security server 122 because of an error in the user request code structure or a blacklisting of the user in the user database 134 or insufficient fund in the user Virtual Money account 136, the security server instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216. The user then receives the error message 738 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142.
  • the Payment Transaction Server 142 sends the request to the International Money Transfer Operator 720 that should check 736 the sender request, the sender credentials, the currencies of the countries and the currencies exchange conversion.
  • the IMTO 720 shall inform the Payment Transaction Server 142 that instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216 of the MNO 210.
  • the user then receives the error message 738 on the mobile communication device 200.
  • the IMTO 720 shall inform the Payment Transaction Server 142.
  • the payment transaction module server 142 then creates a payment transaction with key information (user MSISDN, receiver MSISDN, transaction Value, Transaction ID). That payment transaction is sent to the security and control server 122 to acquire a transaction security unique key from the database 124. The now secure payment transaction is sent back to Payment transaction server 142.
  • the Payment Transaction server 142 sends an inter-account transfer instruction with a certain value to the account management server 132.
  • the Account management server 132 then executes an inter-account transfer 740 from sender virtual money to receiver virtual money account. Both sender and receiver virtual money accounts are located in Virtual accounts Database 136. When the inter-account transfer account is completed. The Account management server 132 sends a confirmation back to the Payment Transaction server 142.
  • the Payment transaction Server 142 receives the confirmation and initiates an account update command to the VMB 220.
  • the VMB 220 updates 742 both sender and receiver Virtual Money Bank accounts, both located in the VMB Database 222, with sender and receiver Virtual Money Accounts value respectively received from the Payment Transaction Server 142 command.
  • the VMB 220 sends the confirmation message back to the payment transaction server 142.
  • the Payment transaction server 142 sends an instruction 744 to the SMSC
  • the SMSC 114 sends a pre-defined successful message 746 to the sender and a pre-defined successful message 750 to the receiver via the SMSC 714.
  • the sender then receive the confirmation message 748 on the Mobile communication device 200.
  • the receiver receives the confirmation message 752 on the mobile communication device 700.
  • a mobile communication device 200 of a user communicates with a Mobile Network Operator via a base station system (not shown) which in turn connects to an Access Network made of a MSC and HLR.
  • the mobile communication device 200 is typically a mobile or cellular telephone, a smart phone or a Personal Digital Assistant (PDA).
  • PDA Personal Digital Assistant
  • the mobile communication device 200 has a unique device identifier, such as an international mobile subscriber identity (IMSI), associated with it.
  • IMSI international mobile subscriber identity
  • the base station system (not shown) comprises a base station controller (BSC) and a base transceiver station (BTS) with associated antenna.
  • BSC base station controller
  • BTS base transceiver station
  • the Access Network - mobile switching center (MSC) 212 forms part of the architecture of the Mobile Network Operator (MNO) system 210.
  • the access module 212 or service control point has screening logic to identify a request received from a user via the user's mobile communication device 200.
  • User's request infrastructure typically systems such as an interactive voice response (IVR) system (not shown), a short code (USSD) center 218 or a short message service (SMS) center 216, receives the request from the mobile communication device 200 via the Access Network 212.
  • IVR interactive voice response
  • USB short code
  • SMS short message service
  • the data relating to multiple user mobile airtime accounts is stored in a mobile service provider database 224.
  • Each user airtime account is associated and linked with the unique device identifier of the mobile communication device 200 of the user.
  • the mobile communication device data such as the IMSI number of the user's mobile communication device 200, is also stored in the database 224.
  • the mobile service provider database 224 is also used to store user registration data and user mobile account data. This is discussed in more detail below.
  • the Virtual Money Operator architecture 100 as presented in one embodiment in FIG. 1 has all the logic and routing functionalities to allow and execute a payment transaction from a user request on a mobile communication device 200 that transited via a Mobile Network Operator 210.
  • the Virtual Money Bank 220 is an actual bank that connects users' Virtual money accounts to actual user's bank account.
  • the unique bank accounts identifiers are the user IMSI and are stored in a Virtual Money Bank (VMB) Database 222.
  • VMB Virtual Money Bank
  • the Merchant Billing system 800 produces user bills and shall connect to Virtual Money Operator 100 for remote bill payment.
  • An example can be a Billing system of a utility company or a Satellite Company.
  • FIG.8B is a flowchart diagram that illustrates an embodiment of a system where a user paying a merchant bill with virtual money via a mobile network, a virtual money operator, a financial institution and a merchant billing system as shown in FIG. 8A. It uses the various key elements of the system architecture shown in FIG 8A.
  • a user that wants to pay her bill with Virtual money shall send the required request code 810 from her mobile communication device 200.
  • An example could be a simple ussd code like *145*654321*5000# which transfer 5000 francs from the user virtual money account to the merchant bill code 654321.
  • the user request transits via the Mobile Network Operator system 210.
  • the MNO 210 especially the IN 214 checks that the user is authorized to make such request 812. It is called "white- list" screening.
  • the MNO orders SMSC 216 to send a predefined Error message to the user.
  • the user request is then terminated and the user received the Error message 818 on her mobile communication device 200.
  • the user request is forwarded by the IN 214 to the Virtual Money Operator 100 Application through the Ussd handler 218.
  • the VMO 100 receives the user request through its Application communication module 110 which sends it to the Security and Control Server 122.
  • the Security server 122 checks user credentials 814 with the Account Management Server 132 and request structure with the USSD handler 116.
  • the security server 122 analyzes the responses from the account management server 132 and the ussd handler 116.
  • the security server 122 If the authorization is not granted by the security server 122 because of an error in the user request code structure or an blacklisting of the user in the user database 134 or insufficient fund in the user Virtual Money account 136, the security server instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216.
  • the user then receives the error message 818 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142.
  • the Payment Transaction Server 142 initiates the request to the Merchant Billing System 800 that should check 816 the user request, the user bill code and the user bill value.
  • the Merchant Billing System 800 shall inform the Payment Transaction Server 142 that instructs the SMSC 114 to send a predefined error message to the user via the SMSC 216. The user then receives the error message 818 on the mobile communication device 200.
  • the user request is forwarded to the Payment transaction server 142.
  • the payment transaction server 142 creates a payment transaction with key information (user MSISDN, bill code, transaction Value, Transaction ID) . That payment transaction is sent to the security and control server 122 to acquire a transaction security unique key from the Keys database 124.
  • the now secure payment transaction command is sent to Payment Transaction server 142 which sends it to merchant Billing System for payment 820.
  • the Merchant Billing System 800 shall confirm the transaction payment to the payment Transaction server 142.
  • the Payment Transaction Server 142 initiates an account update request to the Account management server which debits 822 the User Virtual account with the corresponding value of the transaction and send an instruction confirmation back to the Payment transaction server 142.
  • the Payment transaction Server 142 sends an account update command to the VMB 220.
  • the VMB 220 updates 824 the User Virtual Bank account, located in the VMB Database 222, with User Virtual Money Account value received from the command.
  • the VMB 220 sends the confirmation message back to the payment transaction server 142.
  • the Payment transaction server 142 sends an instruction to the SMSC 114 within the Application Communication Module 110 to send a pre-defined successful message 826 to SMSC 216.
  • the SMSC 216 transfers that message 828 to the user.
  • the user then receives the confirmation message 830 on the Mobile communication device 200.

Landscapes

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

Abstract

L'invention se rapporte à un procédé de génération de monnaie virtuelle à partir d'un temps d'utilisation prépayé. Ledit procédé comprend : l'envoi à un opérateur de monnaie virtuelle, par un dispositif de communication mobile d'abonné, d'une demande passant par un opérateur de réseau mobile ; la vérification des données de l'utilisateur par le biais de la mise en correspondance de ces données et des données de l'abonné conservées par le serveur de l'opérateur de réseau mobile ; l'obtention d'une autorisation de service en provenance de l'opérateur de réseau mobile ; le transfert de la demande de l'utilisateur à l'opérateur de monnaie virtuelle ; la vérification des détails de la demande de l'utilisateur (code d'application, données de l'utilisateur, compte, numéro d'identification personnel (PIN)) ; l'envoi d'une demande de virement inter-comptes au système prépayé de l'opérateur de réseau mobile afin de débiter l'utilisateur et de créditer le compte de temps d'utilisation prépayé de l'opérateur de monnaie virtuelle conformément à la valeur de transaction correspondante ; la réception de la confirmation d'une demande de rajustement de compte par l'opérateur de réseau mobile ; le crédit du compte virtuel de l'utilisateur auprès de l'opérateur de monnaie virtuelle ; l'envoi d'un rajustement de compte d'utilisateur à l'institution financière gérant la monnaie virtuelle ; la mise à jour du compte bancaire de l'utilisateur auprès de l'institution financière gérant la monnaie virtuelle ; et l'envoi d'un message de confirmation de la réussite de l'opération au dispositif de communication mobile de l'utilisateur par l'intermédiaire de l'opérateur de réseau mobile. L'invention porte également sur des procédés permettant d'effectuer différents types de transactions de paiement et de transferts d'argent associés, ainsi que sur des systèmes de transactions de paiement.
PCT/IB2015/054717 2015-06-24 2015-06-24 Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable WO2015125126A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2015/054717 WO2015125126A2 (fr) 2015-06-24 2015-06-24 Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2015/054717 WO2015125126A2 (fr) 2015-06-24 2015-06-24 Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable

Publications (2)

Publication Number Publication Date
WO2015125126A2 true WO2015125126A2 (fr) 2015-08-27
WO2015125126A3 WO2015125126A3 (fr) 2016-04-07

Family

ID=53510949

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2015/054717 WO2015125126A2 (fr) 2015-06-24 2015-06-24 Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable

Country Status (1)

Country Link
WO (1) WO2015125126A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3045192A1 (fr) * 2015-12-10 2017-06-16 Orange Procede de gestion d'une transaction monetaire

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8662384B2 (en) * 2006-02-28 2014-03-04 Google Inc. Text message payment

Non-Patent Citations (1)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3045192A1 (fr) * 2015-12-10 2017-06-16 Orange Procede de gestion d'une transaction monetaire

Also Published As

Publication number Publication date
WO2015125126A3 (fr) 2016-04-07

Similar Documents

Publication Publication Date Title
US11880820B2 (en) Mobile payment station system and method
US10902397B2 (en) Interoperable financial transactions via mobile devices
EP1922681B1 (fr) Gestion de compte mobile
CA2838655C (fr) Systeme et procede pour l'execution d'operations financieres a l'aide d'un dispositif mobile
US20020181710A1 (en) Mobile transaction system and method
WO2013067910A1 (fr) Système et procédé de paiement dynamique basés sur une technologie de communication asynchrone
WO2006066484A1 (fr) Systeme et procede de paiement
US20080125080A1 (en) Method and system for value transfer between mobile-phone users
RU2011126196A (ru) Система и способ предоставления кредита
US20160026991A1 (en) Mobile account management
WO2003009243A1 (fr) Systeme mobile de transfert electronique de fonds, et procede y relatif
JP2011044151A (ja) 安全な携帯端末支払いのための方法とシステム
CN101730023A (zh) 短信支付的方法和***
RU2482538C1 (ru) Способ оплаты товаров и услуг для традиционной и электронной коммерции
WO2015125126A2 (fr) Procédés et systèmes de transaction à l'aide d'une monnaie virtuelle générée à partir d'un temps d'utilisation prépayé dans un environnement de télécommunication interopérable
Knospe et al. Online payment for access to heterogeneous mobile networks
Fong et al. Mobile mini-payment scheme using SMS-credit
CN103886451A (zh) 一种采用临时***的手机支付***和相应方法
US20030126074A1 (en) System and method for allowing and making a monetary payment using communications network
WO2020198764A2 (fr) Procédé et système pour des paiements mobiles codés par un terminal
US10482459B2 (en) System and method for automated account creation via a mobile wireless device in a payment system
WO2007118428A1 (fr) Dispositif de service de transfert électronique fiable sans mot de passe, et carte de transfert et procédé correspondants
Mbinkeu New Perspectives of Mobile Payment Platform for Developing Countries
CN114549172A (zh) 一种轻量级手机银行业务的实现***和实现方法
KR20090021996A (ko) 전화기 광고비 정산처리 방법 및 시스템과 이를 위한기록매체

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 13/06/2018)

122 Ep: pct application non-entry in european phase

Ref document number: 15733922

Country of ref document: EP

Kind code of ref document: A2