WO2019028481A1 - Mobile payment system - Google Patents

Mobile payment system Download PDF

Info

Publication number
WO2019028481A1
WO2019028481A1 PCT/ZA2017/050041 ZA2017050041W WO2019028481A1 WO 2019028481 A1 WO2019028481 A1 WO 2019028481A1 ZA 2017050041 W ZA2017050041 W ZA 2017050041W WO 2019028481 A1 WO2019028481 A1 WO 2019028481A1
Authority
WO
WIPO (PCT)
Prior art keywords
buyer
data package
payment system
payer
mobile payment
Prior art date
Application number
PCT/ZA2017/050041
Other languages
French (fr)
Inventor
Svenn Sivert SIVERTSEN
Albert WILKES
Original Assignee
Just Pay (Pty) Ltd.
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 Just Pay (Pty) Ltd. filed Critical Just Pay (Pty) Ltd.
Priority to PCT/ZA2017/050041 priority Critical patent/WO2019028481A1/en
Publication of WO2019028481A1 publication Critical patent/WO2019028481A1/en

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/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • 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]
    • G06Q20/3223—Realising banking transactions through 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices

Definitions

  • This invention relates to a mobile payment system for paying for goods and/or services at a point of purchase.
  • a mobile payment system for facilitating a monetary transaction between a buyer and a seller, the system including at least the steps of:- - providing a monetary value of a transaction to a mobile device of the buyer;
  • the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the buyer, and an identifier associated with the seller; and transmitting the credit data package to the mobile device of the buyer;
  • the credit data package may be returned to the server for further processing.
  • the server may reconcile the monetary amount spent l by a buyer with the account(s) of the buyer after a transaction has been successfully completed.
  • the completion of a successful transfer of monetary value between a buyer and a seller may be followed by a physical action.
  • the physical action may, for example, be the opening of a boom gate at a parking lot, the opening of a boom gate at a toll gate, the dispensing of a product from a vending machine, a service being rendered, and the like.
  • the monetary value of the transaction may be provided to the mobile device of the buyer by means of NFC.
  • This can take the form of data transmission between an NFC device of the seller and the mobile device of the buyer or the monetary value can be encoded in an NFC tag which may be read and decoded by the mobile device of the buyer.
  • the monetary value may be provided to the mobile device of the buyer manually.
  • the buyer may be requested by the system to enter an identification code into the mobile device after which the monetary value may be entered manually.
  • the credit request data package may include additional data such as, for example, the date and time at which the package was generated.
  • the credit data package may include additional data such as, for example, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
  • the mobile device of the buyer If the mobile device of the buyer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the buyer transmits the credit request data package to the server of the system.
  • the credit request data package may be transmitted to the NFC device of the seller via NFC and then it may be transmitted to the server of the system by the seller.
  • a credit data package has been generated by the server of the system, this may be transmitted to the NFC device of the seller and then via NFC to the mobile device of the buyer.
  • the monetary value may be provided to the mobile device of the buyer manually as described above.
  • the buyer may be presented with an option for using a pre-purchased credit data package which may be stored on the mobile device of the buyer.
  • the buyer may at any time request a pre-purchased credit data package for use when, for example, the account of the buyer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
  • the buyer may access an application loaded on the mobile device of the buyer supporting the mobile payment system and may click on an associated icon to access a pre-purchased credit data package function.
  • the buyer may be requested to enter a PIN number or other means of identifying the buyer such as, for example, a fingerprint.
  • the buyer may then be presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package.
  • an associated request may be sent to the server of the system by the mobile device of the buyer.
  • a pre-purchased credit data package may be generated by the server and sent to the mobile device of the buyer where it may be stored for future use.
  • the pre-purchased credit data package may at least include data regarding the monetary value thereof and the identity of the buyer. If the account of the buyer does not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server may send a message to the buyer informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package. Accordingly, the option of using of a pre-purchased credit data package may also be presented to the buyer in the event that the virtual and/or actual bank account of the buyer has insufficient funds to carry out the requested monetary transaction. In this case, the server may generate and send an "out of funds" message to the mobile device of the buyer. The buyer may then elect to use a pre-purchased credit data package.
  • Each pre-purchased data package may have a fixed monetary value assigned thereto. Accordingly, it may happen that the monetary value of the pre-purchased data package is larger than that of the monetary value of the transaction to be completed.
  • the buyer In order to access a pre-purchased data package, the buyer may be requested to enter an identification code and, once this has been verified by the system, the buyer may manually enter the monetary value of the pre-purchased credit data package he would like to use.
  • the system may generate a secondary credit data package using the data of the pre-purchased credit data package to which the system may add information such as, for example, the monetary value entered by the buyer, an identifier associated with the seller, the fact that the transaction is being carried out without the use of NFC or online capabilities, and the like.
  • the mobile device of the buyer may convert the secondary credit data package into a QR code which may be displayed on the mobile device of the buyer so that it is readable by the QR reading device of the seller.
  • Verification of the validity of the data encoded in the QR code by the server may then be requested by the seller and, if verification was successful, a message may be sent to the buyer and the seller indicating a successful monetary transaction.
  • the secondary credit data package may be returned to the mobile device of the buyer after the monetary value of the successfully completed transaction has been deducted from its fixed value, thereby creating a new pre-purchased credit data package having a different fixed value.
  • the buyer may have one or more accounts associated with the system.
  • the account may be a virtual account or an actual bank account.
  • the buyer may purchase credit data packages, each package having a fixed monetary value. These pre-purchased credit data packages may be stored on the mobile device of the buyer and may typically be used if the account(s) of the buyer does not have sufficient funds or cannot be accessed.
  • the mobile payment system may be supported by an application which may be loaded on the mobile device of the buyer.
  • the seller may have a complementary application loaded at the point of purchase.
  • the mobile payment system is used to pay for fast-moving consumer goods which may be paid for upon delivery of the goods to the buyer.
  • a circumstance may arise where either insufficient goods were delivered and/or some of the goods are damaged and therefore not accepted by the buyer.
  • the server of the system may be requested to generate a new invoice based on the number of goods actually accepted by the buyer.
  • the new invoice may be transmitted by the server to a mobile device of the buyer.
  • the new invoice details may be transmitted to a mobile device of the seller via NFC.
  • the invoice may be converted to a QR code and displayed on the device of the buyer where it may be read by a reading device of the seller.
  • a mobile payment system for facilitating a monetary transaction between a payer and a recipient, the system including at least the steps of:- providing a monetary value of a transaction to a mobile device of the payer; transmitting a credit request data package to a server of the system which credit request data package includes at least data regarding the monetary value and data identifying the payer and the recipient; ascertaining whether or not one or more accounts of the payer contain funds exceeding the monetary value; if sufficient funds are available, the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the payer, and an identifier associated with the recipient; and transmitting the credit data package to the mobile device of the payer; converting the credit data package into a QR code and displaying same on the mobile device of the payer so that it is readable by a mobile device of the recipient; and requesting verification of the validity of the data encoded in the QR code by the
  • This embodiment may be used to transfer funds between private individuals. It is however to be appreciated, that it can also be used to transfer funds between a buyer and a seller.
  • the mobile device of the payer and recipient may be a cellular telephone.
  • the credit data package may be stored on the mobile device of the recipient for further processing.
  • the mobile device of the recipient may send all received credit data packages to the system server at pre-selected intervals, e.g. daily or weekly.
  • the server may reconcile the monetary amount to be credited to the recipient with the account(s) of the recipient.
  • the monetary value of the transaction may be provided to the mobile device of the payer by means of NFC during which the mobile devices of the payer and recipient are placed close to each other. In the event that the mobile devices of the payer and recipient are not NFC enabled or NFC is not available, the monetary value may be provided to the mobile device of the payer manually.
  • the credit request data package may include additional data such as, for example, the date and time at which the package was generated.
  • the credit data package may include additional data such as, for example, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
  • the mobile device of the payer If the mobile device of the payer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the payer transmits the credit request data package to the server of the system.
  • the credit request data package may be transmitted to the mobile device of the recipient via NFC and then it may be transmitted to the server of the system by the recipient.
  • the monetary value may be provided to the mobile device of the payer manually as described above.
  • the payer may be presented with an option for using a pre-purchased credit data package which may be stored on the mobile device of the payer.
  • the payer may at any time request a pre-purchased credit data package for use when, for example, the account of the payer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
  • the payer may access an application loaded on the mobile device of the payer supporting the mobile payment system and may click on an associated icon to access a pre-purchased credit data package function.
  • the payer may be requested to enter a PIN number or other means of identifying the payer such as, for example, a fingerprint.
  • the payer may then be presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package.
  • an associated request may be sent to the server of the system by the mobile device of the payer.
  • a pre-purchased credit data package may be generated by the server and sent to the mobile device of the payer where it may be stored for future use.
  • the pre-purchased credit data package may at least include data regarding the monetary value thereof and the identity of the payer.
  • the server may send a message to the payer (and optionally the recipient) informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package.
  • the option of using of a pre-purchased credit data package may also be presented to the payer in the event that the virtual and/or actual bank account of the payer has insufficient funds to carry out the requested monetary transaction.
  • the server may generate and send an "out of funds" message to the mobile device of the payer and optionally, to that of the recipient.
  • the payer may then elect to use a pre-purchased credit data package.
  • Each pre-purchased data package may have a fixed monetary value assigned thereto. Accordingly, it may happen that the monetary value of the pre-purchased data package is larger than that of the monetary value of the transaction to be completed.
  • the payer may be requested to enter an identification code and, once this has been verified by the system, the payer may manually enter the monetary value of the pre-purchased credit data package he would like to use.
  • the system may generate a secondary credit data package using the data of the pre-purchased credit data package to which the system may add information such as, for example, the monetary value entered by the payer, an identifier associated with the seller, the fact that the transaction is being carried out without the use of NFC or online capabilities, and the like.
  • the mobile device of the payer may convert the secondary credit data package into a QR code which may be displayed on the mobile device of the payer so that it is readable by the mobile device of the recipient.
  • Verification of the validity of the data encoded in the QR code by the server may then be requested by the recipient and, if verification was successful, a message may be sent to the payer and the recipient indicating a successful monetary transaction.
  • the secondary credit data package may be returned to the mobile device of the payer after the monetary value of the successfully completed transaction has been deducted from its fixed value, thereby creating a new pre-purchased credit data package having a different fixed value.
  • the payer may have one or more accounts associated with the system.
  • the account may be a virtual account or an actual bank account.
  • the mobile payment system may be supported by an application which may be loaded on the mobile devices of the payer and the recipient.
  • Figure 1 shows a flow diagram representing a general overview of an embodiment of a mobile payment system in accordance with the present invention
  • Figures 2A and 2B show flow diagrams in which the mobile payment system is associated with a physical action that is performed after a successful monetary transaction between a buyer and seller has taken place;
  • Figure 3 shows a flow diagram representing a general overview of an alternative embodiment of a mobile payment system in accordance with the present invention.
  • reference numeral 10 generally indicates a mobile payment system in accordance with the present invention.
  • a buyer wishes to purchase goods and/or services from a seller (not shown). Details of a monetary transaction to be completed are entered into an electronic device of the seller at the point of purchase, after which a mobile device of the buyer (in this case, a cellular telephone) is presented.
  • a mobile device of the buyer in this case, a cellular telephone
  • the cellular telephone is placed close to the electronic device of the seller and the monetary value of the goods and/or services to be purchased is transferred to the cellular telephone via NFC.
  • a credit request data package is sent from the cellular telephone to the server.
  • the credit request data package includes at least data regarding the monetary value and data identifying the buyer and the seller.
  • the server If one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer, where it is converted to a QR code and presented to the seller where it is scanned.
  • the credit data package includes at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the buyer, an identifier associated with the seller, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
  • the seller verifies the authenticity of the credit data package with the server of the system.
  • the credit data package is returned to the server for further processing, i.e. to reconcile the applicable account of the buyer.
  • a message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
  • a credit data package request is sent from the cellular telephone to the electronic device of the seller via NFC. If the electronic device of the seller is able communicate with the server of the system, a credit data request is sent to the server via the electronic device of the seller.
  • the server If one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer via the electronic device of the seller, where it is converted to a QR code and presented to the seller where it is scanned.
  • the seller then verifies the authenticity of the credit data package with the server of the system. Thereafter, the credit data package is returned to the server for further processing, i.e. to reconcile the applicable account of the buyer.
  • a message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
  • the electronic device of the seller requests a pre-purchased credit data package stored on the cellular telephone of the buyer via NFC.
  • the pre-purchased credit data package is typically purchased when the buyer has funds in his account and wishes to obtain a pre-purchased credit data package for use when, for example, the account of the buyer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
  • the buyer accesses an application loaded on the mobile device of the buyer supporting the mobile payment system and clicks on an associated icon to access a pre-purchased credit data package function.
  • the buyer is requested to enter a PIN number or other means of identifying the buyer such as, for example, a fingerprint.
  • the buyer is then presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package.
  • an associated request is sent to the server of the system by the mobile device of the buyer.
  • a pre-purchased credit data package is generated by the server and sent to the mobile device of the buyer where it is stored for future use.
  • the pre-purchased credit data package at least includes data regarding the monetary value thereof and the identity of the buyer.
  • the server sends a message to the buyer informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package.
  • the server uses a pre-purchased credit data package to generate a secondary credit data package which is transmitted to the cellular telephone of the buyer where it is concerted to a QR code and presented to the seller where it is scanned.
  • the seller verifies the authenticity of the secondary credit data package with the server of the system. Thereafter, the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the fixed value of the pre-purchased credit data package used for the transaction, thereby creating a new pre-purchased credit data package having a different fixed value and which is then sent to the cellular telephone of the buyer for future use.
  • a message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
  • the buyer accesses an application associated with the system on his cellular telephone and enters the value of the monetary transaction manually.
  • the server of the system If the cellular telephone is online, the server of the system is accessed and if one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer, where it is converted to a QR code and presented to the seller where it is scanned.
  • the seller verifies the authenticity of the credit data package with the server of the system.
  • the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the account of the buyer.
  • a message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
  • the buyer accesses a pre-purchased credit data package stored on his cellular telephone. If the value of the pre-purchased credit data package is equal to or larger than the value of the monetary transaction, it is converted to a QR code and presented to the seller where it is scanned. If the value of the pre-purchased credit data package is smaller than the value of the monetary transaction, no transaction between the buyer and seller takes place.
  • the seller sends the pre-purchased credit data package to the server of the system for verification and the server logs the value of the monetary transaction.
  • a message showing a declined transaction is displayed on the device of the seller. If the pre-purchased credit data package is successfully verified by the server, a QR code is sent to and displayed on the electronic device of the seller, which QR code includes data as to the difference in value (if any) of the value of the monetary transaction and that of the pre-purchased credit data package.
  • the QR code is scanned by the cellular telephone of the buyer and the pre- purchased credit data package is updated with the remaining value.
  • the server of the system reconciles the pre-purchased credit data package with the value of the monetary transaction that it has been used for after which an appropriate message is sent to the cellular telephone of the buyer together with a secondary credit data package having a fixed value equal to its original fixed value minus the value of the monetary transaction for which the original pre-purchased credit data package was used.
  • the flow diagram represents use of the mobile payment system for initiating a physical action.
  • the physical action is the opening of a boom gate when entering a parkade when the buyer still has an outstanding amount payable to the parkade operator (selle).
  • the buyer has not paid an outstanding account due to the parkade operator (seller)
  • access will be denied until such time as the outstanding amount has been paid.
  • the flow diagram represents use of the mobile payment system for initiating a physical action.
  • the physical action is the opening of a boom gate when exiting a parkade.
  • the "calculated monetary value" referred to in the flow diagram is the amount due to the parkade operator (seller) by the car owner (buyer).
  • the seller can elect to open the boom gate to allow the buyer to exit despite not having sufficient funds to pay for the current calculated monetary value.
  • the seller can elect to allow the buyer to pay the calculated monetary value at a cashier.
  • reference numeral 12 generally indicates a mobile payment system according to an alternative embodiment of the present invention.
  • FIG. 3 facilitates a monetary transaction between a payer and a recipient (not show), which are typically both private individuals.
  • Details of a monetary transaction to be completed are entered into an electronic device of the recipient.
  • the mobile devices of the payer and recipient are cellular telephones.
  • both the device of the payer and recipient are NFC-enabled, the respective cellular telephones are placed close to each other and the monetary value entered is transferred to the cellular telephone of the payer via NFC. If the cellular telephone is able to access a server of the system (i.e. it is online), a credit request data package is sent from the cellular telephone of the payer to the server.
  • the credit request data package includes at least data regarding the monetary value and data identifying the payer and the recipient.
  • the server If one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer, where it is converted to a QR code and presented to the recipient where it is scanned using the mobile device of the recipient.
  • the credit data package includes at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the payer, an identifier associated with the recipient, the date and time at which the package was generated, whether the data exchange took place via NFC and/ or online, without using NFC and/or online.
  • the recipient then verifies the authenticity of the credit data package with the server of the system.
  • the credit data package is stored on the cellular telephone of the recipient for further processing.
  • a credit data package request is sent from the cellular telephone of the payer to the cellular telephone of the recipient via NFC.
  • a credit data request is sent to the server via the cellular telephone of the recipient.
  • the server If one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer via the cellular telephone of the recipient, where it is converted to a QR code and presented to the recipient for scanning.
  • the recipient then verifies the authenticity of the credit data package with the server of the system. Once the authenticity of the credit data package has been verified, a message confirming a successful monetary transaction is sent both to the cellular telephones of the payer and the recipient.
  • the credit data package is stored on the cellular telephone of the recipient for further processing.
  • the payer has the option of requesting a pre-purchased credit data package stored on the cellular telephone of the payer.
  • the pre-purchased credit data package is typically purchased when the payer has funds in his account and wishes to obtain a pre-purchased credit data package for use when, for example, the account of the payer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
  • the payer accesses an application loaded on the mobile device of the payer supporting the mobile payment system and clicks on an associated icon to access a pre-purchased credit data package function.
  • the payer is requested to enter a PIN number or other means of identifying the payer such as, for example, a fingerprint.
  • the payer is then presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package.
  • an associated request is sent to the server of the system by the mobile device of the payer. If the account of the payer has sufficient funds, a pre-purchased credit data package is generated by the server and sent to the mobile device of the payer where it is stored for future use.
  • the pre-purchased credit data package at least includes data regarding the monetary value thereof and the identity of the payer. If the account of the payerdoes not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server sends a message to the cellular telephone of the payer (and optionally to that of the recipient) informing him that his account does not have sufficient funds to generate the requested pre- purchased credit data package.
  • the server uses a pre-purchased credit data package to generate a secondary credit data package which is transmitted to the cellular telephone of the payer where it is converted to a QR code and presented to the recipient for scanning.
  • the recipient verifies the authenticity of the secondary credit data package with the server of the system.
  • a message confirming a successful monetary transaction is sent both to the cellular telephones of the payer and recipient. Thereafter, the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the fixed value of the pre-purchased credit data package used for the transaction and allocated to an account of the recipient. A new pre-purchased credit data package having a different fixed value is created, which is then sent to the cellular telephone of the payer for future use.
  • an associated message is sent to the cellular telephone of the payer (and optionally the recipient) and no transaction between the payer and recipient takes place. If the cellular telephones of the payer and recipient are not NFC-enabled or NFC is not available, the payer accesses an application associated with the system on his cellular telephone and enters the value of the monetary transaction manually.
  • the server of the system If the cellular telephone of the payer is online, the server of the system is accessed and if one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer, where it is converted to a QR code and presented to the cellular telephone of the recipient for scanning.
  • the recipient verifies the authenticity of the credit data package with the server of the system. Thereafter, the credit data package is stored on the cellular telephone of the recipient for further processing by the server, i.e. the monetary value of the successfully completed transaction is deducted from the account of the payer and is credited to the account of the recipient.
  • a message confirming a successful monetary transaction is sent to the cellular telephones of the payer and recipient.
  • the payer accesses a pre-purchased credit data package stored on his cellular telephone. If the value of the pre-purchased credit data package is equal to or larger than the value of the monetary transaction, it is converted to a QR code and presented to the cellular telephone of the recipient for scanning.
  • the recipient sends the pre-purchased credit data package to the server of the system for verification and the server logs the value of the monetary transaction. If the pre-purchased credit data package is not successfully verified by the server, a message showing a declined transaction is displayed on the cellular telephones of the payer and recipient.
  • QR code is sent to and displayed on the electronic device of the recipient, which QR code includes data as to the difference in value (if any) of the value of the monetary transaction and that of the pre-purchased credit data package.
  • the QR code is scanned by the cellular telephone of the payer and the pre- purchased credit data package is updated with the remaining value.
  • the server of the system reconciles the pre-purchased credit data package with the value of the monetary transaction that it has been used for after which an appropriate message is sent to the cellular telephone of the payer together with a secondary credit data package having a fixed value equal to its original fixed value minus the value of the monetary transaction for which the original pre-purchased credit data package was used.
  • a message confirming a successful monetary transaction is sent to the cellular telephones of the payer and recipient.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (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

Details of a monetary transaction to be completed are entered into an electronic device of the seller at the point of purchase, after which a mobile device of the buyer is presented. If both the device of the buyer and seller are NFC-enabled, the cellular telephone is placed close to the electronic device of the seller and the monetary value of the goods and/or services to be purchased in transferred to the cellular telephone via NFC. If the cellular telephone is able to access a server of the system a credit data package request in the form of a credit request data package is sent from the cellular telephone to the server. The credit request data package includes at least data regarding the monetary value and data identifying the buyer and the seller.

Description

MOBILE PAYMENT SYSTEM
Field of the Invention
This invention relates to a mobile payment system for paying for goods and/or services at a point of purchase.
Summary of the Invention
According to the invention, there is provided a mobile payment system for facilitating a monetary transaction between a buyer and a seller, the system including at least the steps of:- - providing a monetary value of a transaction to a mobile device of the buyer;
- transmitting a credit request data package to a server of the system which credit request data package includes at least data regarding the monetary value and data identifying the buyer and the seller;
- ascertaining whether or not one or more accounts of the buyer contain funds exceeding the monetary value;
- if sufficient funds are available, the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the buyer, and an identifier associated with the seller; and transmitting the credit data package to the mobile device of the buyer;
- converting the credit data package into a QR code and displaying same on the mobile device of the buyer so that it is readable by a reading device of the seller; and
- requesting verification of the validity of the data encoded in the QR code by the server and, if the data encoded in the QR code is found to be valid, transmitting a message to the buyer and seller that a successful transfer of the monetary value between the buyer and seller has taken place.
Following a successful transaction, the credit data package may be returned to the server for further processing. The server may reconcile the monetary amount spent l by a buyer with the account(s) of the buyer after a transaction has been successfully completed.
The completion of a successful transfer of monetary value between a buyer and a seller may be followed by a physical action. The physical action may, for example, be the opening of a boom gate at a parking lot, the opening of a boom gate at a toll gate, the dispensing of a product from a vending machine, a service being rendered, and the like.
The monetary value of the transaction may be provided to the mobile device of the buyer by means of NFC. This can take the form of data transmission between an NFC device of the seller and the mobile device of the buyer or the monetary value can be encoded in an NFC tag which may be read and decoded by the mobile device of the buyer.
In the event that the mobile device is not NFC-enabled or the seller does not have an NFC device or an NFC tag, the monetary value may be provided to the mobile device of the buyer manually.
In this case, the buyer may be requested by the system to enter an identification code into the mobile device after which the monetary value may be entered manually.
The credit request data package may include additional data such as, for example, the date and time at which the package was generated.
Similarly, the credit data package may include additional data such as, for example, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
If the mobile device of the buyer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the buyer transmits the credit request data package to the server of the system.
If the mobile device of the buyer does not have internet connectivity when the credit request data package is to be transmitted, the credit request data package may be transmitted to the NFC device of the seller via NFC and then it may be transmitted to the server of the system by the seller. When a credit data package has been generated by the server of the system, this may be transmitted to the NFC device of the seller and then via NFC to the mobile device of the buyer.
If the mobile device of the buyer does not have internet connectivity when the credit request data package is to be transmitted and is not NFC-enabled, the monetary value may be provided to the mobile device of the buyer manually as described above.
As the mobile device of the buyer has no internet connectivity and can therefore not connect to the server of the system, the buyer may be presented with an option for using a pre-purchased credit data package which may be stored on the mobile device of the buyer.
The buyer may at any time request a pre-purchased credit data package for use when, for example, the account of the buyer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed. In order to request a pre-purchased credit data package, the buyer may access an application loaded on the mobile device of the buyer supporting the mobile payment system and may click on an associated icon to access a pre-purchased credit data package function.
The buyer may be requested to enter a PIN number or other means of identifying the buyer such as, for example, a fingerprint.
The buyer may then be presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package. Once the buyer has made his selection, an associated request may be sent to the server of the system by the mobile device of the buyer.
If the account of the buyer has sufficient funds, a pre-purchased credit data package may be generated by the server and sent to the mobile device of the buyer where it may be stored for future use.
The pre-purchased credit data package may at least include data regarding the monetary value thereof and the identity of the buyer. If the account of the buyer does not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server may send a message to the buyer informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package. Accordingly, the option of using of a pre-purchased credit data package may also be presented to the buyer in the event that the virtual and/or actual bank account of the buyer has insufficient funds to carry out the requested monetary transaction. In this case, the server may generate and send an "out of funds" message to the mobile device of the buyer. The buyer may then elect to use a pre-purchased credit data package.
Each pre-purchased data package may have a fixed monetary value assigned thereto. Accordingly, it may happen that the monetary value of the pre-purchased data package is larger than that of the monetary value of the transaction to be completed. In order to access a pre-purchased data package, the buyer may be requested to enter an identification code and, once this has been verified by the system, the buyer may manually enter the monetary value of the pre-purchased credit data package he would like to use.
The system may generate a secondary credit data package using the data of the pre-purchased credit data package to which the system may add information such as, for example, the monetary value entered by the buyer, an identifier associated with the seller, the fact that the transaction is being carried out without the use of NFC or online capabilities, and the like.
The mobile device of the buyer may convert the secondary credit data package into a QR code which may be displayed on the mobile device of the buyer so that it is readable by the QR reading device of the seller.
Verification of the validity of the data encoded in the QR code by the server may then be requested by the seller and, if verification was successful, a message may be sent to the buyer and the seller indicating a successful monetary transaction. The secondary credit data package may be returned to the mobile device of the buyer after the monetary value of the successfully completed transaction has been deducted from its fixed value, thereby creating a new pre-purchased credit data package having a different fixed value.
The buyer may have one or more accounts associated with the system. The account may be a virtual account or an actual bank account. In addition, the buyer may purchase credit data packages, each package having a fixed monetary value. These pre-purchased credit data packages may be stored on the mobile device of the buyer and may typically be used if the account(s) of the buyer does not have sufficient funds or cannot be accessed.
The mobile payment system may be supported by an application which may be loaded on the mobile device of the buyer. The seller may have a complementary application loaded at the point of purchase.
In one embodiment of the invention, the mobile payment system is used to pay for fast-moving consumer goods which may be paid for upon delivery of the goods to the buyer. A circumstance may arise where either insufficient goods were delivered and/or some of the goods are damaged and therefore not accepted by the buyer.
In such an event, the server of the system may be requested to generate a new invoice based on the number of goods actually accepted by the buyer. The new invoice may be transmitted by the server to a mobile device of the buyer. The new invoice details may be transmitted to a mobile device of the seller via NFC.
In the event that the buyer and/or seller do not have an NFC-enabled mobile device, the invoice may be converted to a QR code and displayed on the device of the buyer where it may be read by a reading device of the seller.
The remainder of the monetary transaction between the buyer and seller may take place as described above.
According to an alternative embodiment of the invention, there is provided a mobile payment system for facilitating a monetary transaction between a payer and a recipient, the system including at least the steps of:- providing a monetary value of a transaction to a mobile device of the payer; transmitting a credit request data package to a server of the system which credit request data package includes at least data regarding the monetary value and data identifying the payer and the recipient; ascertaining whether or not one or more accounts of the payer contain funds exceeding the monetary value; if sufficient funds are available, the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the payer, and an identifier associated with the recipient; and transmitting the credit data package to the mobile device of the payer; converting the credit data package into a QR code and displaying same on the mobile device of the payer so that it is readable by a mobile device of the recipient; and requesting verification of the validity of the data encoded in the QR code by the server and, if the data encoded in the QR code is found to be valid, transmitting a message to the mobile devices of the payer and recipient that a successful transfer of the monetary value between the payer and recipient has taken place.
This embodiment may be used to transfer funds between private individuals. It is however to be appreciated, that it can also be used to transfer funds between a buyer and a seller.
The mobile device of the payer and recipient may be a cellular telephone.
Following a successful transaction, the credit data package may be stored on the mobile device of the recipient for further processing.
The mobile device of the recipient may send all received credit data packages to the system server at pre-selected intervals, e.g. daily or weekly. The server may reconcile the monetary amount to be credited to the recipient with the account(s) of the recipient.
The monetary value of the transaction may be provided to the mobile device of the payer by means of NFC during which the mobile devices of the payer and recipient are placed close to each other. In the event that the mobile devices of the payer and recipient are not NFC enabled or NFC is not available, the monetary value may be provided to the mobile device of the payer manually.
The credit request data package may include additional data such as, for example, the date and time at which the package was generated.
Similarly, the credit data package may include additional data such as, for example, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
If the mobile device of the payer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the payer transmits the credit request data package to the server of the system.
If the mobile device of the payer does not have internet connectivity when the credit request data package is to be transmitted, the credit request data package may be transmitted to the mobile device of the recipient via NFC and then it may be transmitted to the server of the system by the recipient.
When a credit data package has been generated by the server of the system, this may be transmitted to the NFC device of the recipient and then via NFC to the mobile device of the payer.
If the mobile device of the payer does not have internet connectivity when the credit request data package is to be transmitted and is not NFC-enabled, the monetary value may be provided to the mobile device of the payer manually as described above.
As the mobile device of the payer has no internet connectivity and can therefore not connect to the server of the system, the payer may be presented with an option for using a pre-purchased credit data package which may be stored on the mobile device of the payer.
The payer may at any time request a pre-purchased credit data package for use when, for example, the account of the payer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed. In order to request a pre-purchased credit data package, the payer may access an application loaded on the mobile device of the payer supporting the mobile payment system and may click on an associated icon to access a pre-purchased credit data package function. The payer may be requested to enter a PIN number or other means of identifying the payer such as, for example, a fingerprint.
The payer may then be presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package. Once the payer has made his selection, an associated request may be sent to the server of the system by the mobile device of the payer.
If the account of the payer has sufficient funds, a pre-purchased credit data package may be generated by the server and sent to the mobile device of the payer where it may be stored for future use. The pre-purchased credit data package may at least include data regarding the monetary value thereof and the identity of the payer.
If the account of the payer does not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server may send a message to the payer (and optionally the recipient) informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package.
Accordingly, the option of using of a pre-purchased credit data package may also be presented to the payer in the event that the virtual and/or actual bank account of the payer has insufficient funds to carry out the requested monetary transaction. In this case, the server may generate and send an "out of funds" message to the mobile device of the payer and optionally, to that of the recipient. The payer may then elect to use a pre-purchased credit data package.
Each pre-purchased data package may have a fixed monetary value assigned thereto. Accordingly, it may happen that the monetary value of the pre-purchased data package is larger than that of the monetary value of the transaction to be completed. In order to access a pre-purchased data package, the payer may be requested to enter an identification code and, once this has been verified by the system, the payer may manually enter the monetary value of the pre-purchased credit data package he would like to use. The system may generate a secondary credit data package using the data of the pre-purchased credit data package to which the system may add information such as, for example, the monetary value entered by the payer, an identifier associated with the seller, the fact that the transaction is being carried out without the use of NFC or online capabilities, and the like. The mobile device of the payer may convert the secondary credit data package into a QR code which may be displayed on the mobile device of the payer so that it is readable by the mobile device of the recipient.
Verification of the validity of the data encoded in the QR code by the server may then be requested by the recipient and, if verification was successful, a message may be sent to the payer and the recipient indicating a successful monetary transaction.
The secondary credit data package may be returned to the mobile device of the payer after the monetary value of the successfully completed transaction has been deducted from its fixed value, thereby creating a new pre-purchased credit data package having a different fixed value. The payer may have one or more accounts associated with the system. The account may be a virtual account or an actual bank account.
The mobile payment system may be supported by an application which may be loaded on the mobile devices of the payer and the recipient.
Detailed Description of the Invention The invention will now be described by way of the following, non-limiting examples with reference to the accompanying drawings.
In the drawings:
Figure 1 shows a flow diagram representing a general overview of an embodiment of a mobile payment system in accordance with the present invention; Figures 2A and 2B show flow diagrams in which the mobile payment system is associated with a physical action that is performed after a successful monetary transaction between a buyer and seller has taken place; and
Figure 3 shows a flow diagram representing a general overview of an alternative embodiment of a mobile payment system in accordance with the present invention.
In Figure 1 , reference numeral 10 generally indicates a mobile payment system in accordance with the present invention.
Referring now to Figure 1 , a buyer (not shown) wishes to purchase goods and/or services from a seller (not shown). Details of a monetary transaction to be completed are entered into an electronic device of the seller at the point of purchase, after which a mobile device of the buyer (in this case, a cellular telephone) is presented.
If both the device of the buyer and seller are NFC-enabled, the cellular telephone is placed close to the electronic device of the seller and the monetary value of the goods and/or services to be purchased is transferred to the cellular telephone via NFC.
If the cellular telephone is able to access a server of the system (i.e. it is online), a credit request data package is sent from the cellular telephone to the server. The credit request data package includes at least data regarding the monetary value and data identifying the buyer and the seller.
If one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer, where it is converted to a QR code and presented to the seller where it is scanned. The credit data package includes at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the buyer, an identifier associated with the seller, the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online. The seller then verifies the authenticity of the credit data package with the server of the system.
Thereafter, the credit data package is returned to the server for further processing, i.e. to reconcile the applicable account of the buyer. A message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
In the event that the cellular telephone is unable to access the server of the system (i.e. it is not online), a credit data package request is sent from the cellular telephone to the electronic device of the seller via NFC. If the electronic device of the seller is able communicate with the server of the system, a credit data request is sent to the server via the electronic device of the seller.
If one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer via the electronic device of the seller, where it is converted to a QR code and presented to the seller where it is scanned.
The seller then verifies the authenticity of the credit data package with the server of the system. Thereafter, the credit data package is returned to the server for further processing, i.e. to reconcile the applicable account of the buyer.
A message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
In the event that the accounts of the buyer do not have sufficient funds available to cover the value of the monetary transaction to be carried out, the electronic device of the seller requests a pre-purchased credit data package stored on the cellular telephone of the buyer via NFC.
The pre-purchased credit data package is typically purchased when the buyer has funds in his account and wishes to obtain a pre-purchased credit data package for use when, for example, the account of the buyer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
In order to request a pre-purchased credit data package, the buyer accesses an application loaded on the mobile device of the buyer supporting the mobile payment system and clicks on an associated icon to access a pre-purchased credit data package function.
The buyer is requested to enter a PIN number or other means of identifying the buyer such as, for example, a fingerprint.
The buyer is then presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package. Once the buyer has made his selection, an associated request is sent to the server of the system by the mobile device of the buyer.
If the account of the buyer has sufficient funds, a pre-purchased credit data package is generated by the server and sent to the mobile device of the buyer where it is stored for future use.
The pre-purchased credit data package at least includes data regarding the monetary value thereof and the identity of the buyer.
If the account of the buyer does not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server sends a message to the buyer informing him that his account does not have sufficient funds to generate the requested pre-purchased credit data package.
If the value(s) of the pre-purchased credit data package(s) stored on the cellular telephone of the buyer is equal to or exceeds the value of the monetary transaction, the server uses a pre-purchased credit data package to generate a secondary credit data package which is transmitted to the cellular telephone of the buyer where it is concerted to a QR code and presented to the seller where it is scanned.
The seller verifies the authenticity of the secondary credit data package with the server of the system. Thereafter, the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the fixed value of the pre-purchased credit data package used for the transaction, thereby creating a new pre-purchased credit data package having a different fixed value and which is then sent to the cellular telephone of the buyer for future use.
A message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
In the event that the value of the pre-purchase data packages is smaller than the value of the monetary transaction, an associated message is sent to the cellular telephone of the buyer and no transaction between the buyer and seller takes place.
If the cellular telephone of the buyer is not NFC-enable or NFC is not available at the point of purchase, the buyer accesses an application associated with the system on his cellular telephone and enters the value of the monetary transaction manually.
If the cellular telephone is online, the server of the system is accessed and if one or more accounts of the buyer have sufficient funds available for concluding the monetary transaction with the seller, the server generates a credit data package and transmits this to the cellular telephone of the buyer, where it is converted to a QR code and presented to the seller where it is scanned.
The seller verifies the authenticity of the credit data package with the server of the system.
Thereafter, the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the account of the buyer.
A message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller.
In the event that the cellular telephone of the buyer is not online and therefore cannot access the server or if the account of the buyer does not have sufficient funds to cover the value of the monetary transaction, the buyer accesses a pre-purchased credit data package stored on his cellular telephone. If the value of the pre-purchased credit data package is equal to or larger than the value of the monetary transaction, it is converted to a QR code and presented to the seller where it is scanned. If the value of the pre-purchased credit data package is smaller than the value of the monetary transaction, no transaction between the buyer and seller takes place.
The seller sends the pre-purchased credit data package to the server of the system for verification and the server logs the value of the monetary transaction.
If the pre-purchased credit data package is not successfully verified by the server, a message showing a declined transaction is displayed on the device of the seller. If the pre-purchased credit data package is successfully verified by the server, a QR code is sent to and displayed on the electronic device of the seller, which QR code includes data as to the difference in value (if any) of the value of the monetary transaction and that of the pre-purchased credit data package.
The QR code is scanned by the cellular telephone of the buyer and the pre- purchased credit data package is updated with the remaining value.
Once the cellular telephone of the buyer has re-established an online connection, the server of the system reconciles the pre-purchased credit data package with the value of the monetary transaction that it has been used for after which an appropriate message is sent to the cellular telephone of the buyer together with a secondary credit data package having a fixed value equal to its original fixed value minus the value of the monetary transaction for which the original pre-purchased credit data package was used.
A message confirming a successful monetary transaction is sent both to the cellular telephone of the buyer and the electronic device of the seller. Referring now to Figure 2A, the flow diagram represents use of the mobile payment system for initiating a physical action. In this case, the physical action is the opening of a boom gate when entering a parkade when the buyer still has an outstanding amount payable to the parkade operator (selle). In the event that the buyer has not paid an outstanding account due to the parkade operator (seller), access will be denied until such time as the outstanding amount has been paid. As the flow diagram is self-explanatory and the transactions are the same or similar to those described in Figure 1 , Figure 2A will not be described further in detail.
Referring now to Figure 2B, the flow diagram represents use of the mobile payment system for initiating a physical action. In this case, the physical action is the opening of a boom gate when exiting a parkade. The "calculated monetary value" referred to in the flow diagram is the amount due to the parkade operator (seller) by the car owner (buyer).
In the event that the buyer is well-known to the seller and has proven himself as credit worthy, the seller can elect to open the boom gate to allow the buyer to exit despite not having sufficient funds to pay for the current calculated monetary value. Alternatively, the seller can elect to allow the buyer to pay the calculated monetary value at a cashier.
As the flow diagram is self-explanatory and the transactions are the same or similar to those described in Figure 1 , Figure 2B will not be described further in detail. Referring now to Figure 3, reference numeral 12 generally indicates a mobile payment system according to an alternative embodiment of the present invention.
The embodiment shown in Figure 3 facilitates a monetary transaction between a payer and a recipient (not show), which are typically both private individuals.
Details of a monetary transaction to be completed are entered into an electronic device of the recipient. In the embodiment shown, the mobile devices of the payer and recipient are cellular telephones.
If both the device of the payer and recipient are NFC-enabled, the respective cellular telephones are placed close to each other and the monetary value entered is transferred to the cellular telephone of the payer via NFC. If the cellular telephone is able to access a server of the system (i.e. it is online), a credit request data package is sent from the cellular telephone of the payer to the server. The credit request data package includes at least data regarding the monetary value and data identifying the payer and the recipient.
If one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer, where it is converted to a QR code and presented to the recipient where it is scanned using the mobile device of the recipient.
The credit data package includes at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the payer, an identifier associated with the recipient, the date and time at which the package was generated, whether the data exchange took place via NFC and/ or online, without using NFC and/or online.
The recipient then verifies the authenticity of the credit data package with the server of the system.
Once the authenticity of the credit data package has been verified, a message confirming a successful monetary transaction is sent both to the cellular telephones of the payer and the recipient.
Following a successful transaction, the credit data package is stored on the cellular telephone of the recipient for further processing.
In the event that the cellular telephone of the payer is unable to access the server of the system (i.e. it is not online), a credit data package request is sent from the cellular telephone of the payer to the cellular telephone of the recipient via NFC.
If the cellular telephone of the recipient is able communicate with the server of the system, a credit data request is sent to the server via the cellular telephone of the recipient.
If one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer via the cellular telephone of the recipient, where it is converted to a QR code and presented to the recipient for scanning.
The recipient then verifies the authenticity of the credit data package with the server of the system. Once the authenticity of the credit data package has been verified, a message confirming a successful monetary transaction is sent both to the cellular telephones of the payer and the recipient.
Following a successful transaction, the credit data package is stored on the cellular telephone of the recipient for further processing.
In the event that the accounts of the payer do not have sufficient funds available to cover the value of the monetary transaction to be carried out, the payer has the option of requesting a pre-purchased credit data package stored on the cellular telephone of the payer. The pre-purchased credit data package is typically purchased when the payer has funds in his account and wishes to obtain a pre-purchased credit data package for use when, for example, the account of the payer does not have sufficient funds to complete a transaction or when the server of the system cannot be accessed.
In order to request a pre-purchased credit data package, the payer accesses an application loaded on the mobile device of the payer supporting the mobile payment system and clicks on an associated icon to access a pre-purchased credit data package function.
The payer is requested to enter a PIN number or other means of identifying the payer such as, for example, a fingerprint. The payer is then presented with an option of selecting a pre-purchased credit data package having a predetermined monetary value or himself selecting the monetary value of the pre-purchased credit data package. Once the payer has made his selection, an associated request is sent to the server of the system by the mobile device of the payer. If the account of the payer has sufficient funds, a pre-purchased credit data package is generated by the server and sent to the mobile device of the payer where it is stored for future use.
The pre-purchased credit data package at least includes data regarding the monetary value thereof and the identity of the payer. If the account of the payerdoes not have sufficient funds to cover the monetary value of the requested pre-purchased credit data package, the server sends a message to the cellular telephone of the payer (and optionally to that of the recipient) informing him that his account does not have sufficient funds to generate the requested pre- purchased credit data package.
If the value(s) of the pre-purchased credit data package(s) stored on the cellular telephone of the payer is equal to or exceeds the value of the monetary transaction, the server uses a pre-purchased credit data package to generate a secondary credit data package which is transmitted to the cellular telephone of the payer where it is converted to a QR code and presented to the recipient for scanning.
The recipient verifies the authenticity of the secondary credit data package with the server of the system.
Once verification has been completed, a message confirming a successful monetary transaction is sent both to the cellular telephones of the payer and recipient. Thereafter, the credit data package is returned to the server for further processing, i.e. the monetary value of the successfully completed transaction is deducted from the fixed value of the pre-purchased credit data package used for the transaction and allocated to an account of the recipient. A new pre-purchased credit data package having a different fixed value is created, which is then sent to the cellular telephone of the payer for future use.
In the event that the value of the pre-purchase data packages is smaller than the value of the monetary transaction, an associated message is sent to the cellular telephone of the payer (and optionally the recipient) and no transaction between the payer and recipient takes place. If the cellular telephones of the payer and recipient are not NFC-enabled or NFC is not available, the payer accesses an application associated with the system on his cellular telephone and enters the value of the monetary transaction manually.
If the cellular telephone of the payer is online, the server of the system is accessed and if one or more accounts of the payer have sufficient funds available for concluding the monetary transaction with the recipient, the server generates a credit data package and transmits this to the cellular telephone of the payer, where it is converted to a QR code and presented to the cellular telephone of the recipient for scanning.
The recipient verifies the authenticity of the credit data package with the server of the system. Thereafter, the credit data package is stored on the cellular telephone of the recipient for further processing by the server, i.e. the monetary value of the successfully completed transaction is deducted from the account of the payer and is credited to the account of the recipient.
A message confirming a successful monetary transaction is sent to the cellular telephones of the payer and recipient.
In the event that the cellular telephone of the payer is not online and therefore cannot access the server or if the account of the payer does not have sufficient funds to cover the value of the monetary transaction, the payer accesses a pre-purchased credit data package stored on his cellular telephone. If the value of the pre-purchased credit data package is equal to or larger than the value of the monetary transaction, it is converted to a QR code and presented to the cellular telephone of the recipient for scanning.
The recipient sends the pre-purchased credit data package to the server of the system for verification and the server logs the value of the monetary transaction. If the pre-purchased credit data package is not successfully verified by the server, a message showing a declined transaction is displayed on the cellular telephones of the payer and recipient.
If the pre-purchased credit data package is successfully verified by the server, a QR code is sent to and displayed on the electronic device of the recipient, which QR code includes data as to the difference in value (if any) of the value of the monetary transaction and that of the pre-purchased credit data package.
The QR code is scanned by the cellular telephone of the payer and the pre- purchased credit data package is updated with the remaining value.
Once the cellular telephone of the payer has re-established an online connection, the server of the system reconciles the pre-purchased credit data package with the value of the monetary transaction that it has been used for after which an appropriate message is sent to the cellular telephone of the payer together with a secondary credit data package having a fixed value equal to its original fixed value minus the value of the monetary transaction for which the original pre-purchased credit data package was used.
A message confirming a successful monetary transaction is sent to the cellular telephones of the payer and recipient.
It is to be appreciated, that the invention is not limited to any particular embodiment, example, or configuration as hereinbefore described and/ or illustrated.

Claims

A mobile payment system for facilitating a monetary transaction between a buyer and a seller, the system including at least the steps of:- providing a monetary value of a transaction to a mobile device of the buyer; transmitting a credit request data package to a server of the system which credit request data package includes at least data regarding the monetary value and data identifying the buyer and the seller; ascertaining whether or not one or more accounts of the buyer contain funds exceeding the monetary value; if sufficient funds are available, the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the buyer, and an identifier associated with the seller; and transmitting the credit data package to the mobile device of the buyer; converting the credit data package into a QR code and displaying same on the mobile device of the buyer so that it is readable by a reading device of the seller; and requesting verification of the validity of the data encoded in the QR code by the server and, if the data encoded in the QR code is found to be valid, transmitting a message to the buyer and seller that a successful transfer of the monetary value between the buyer and seller has taken place.
A mobile payment system as claimed in claim 1 , wherein following a successful transaction, the credit data package is returned to the server for further processing.
A mobile payment system as claimed in claim 1 or claim 2, wherein the server reconciles the monetary amount spent by a buyer with the account(s) of the buyer after a transaction has been successfully completed.
A mobile payment system as claimed in any one of claims 1 to 3, wherein the completion of a successful transfer of monetary value between a buyer and a seller is followed by a physical action.
5. A mobile payment system as claimed in claim 4, wherein the physical action is selected from the group including: the opening of a boom gate at a parking lot, the opening of a boom gate at a toll gate, the dispensing of a product from a vending machine, a service being rendered, and the like.
6. A mobile payment system as claimed in any one of the preceding claims, wherein the monetary value of the transaction is provided to the mobile device of the buyer by means of NFC.
7. A mobile payment system as claimed in any one of claim 1 to 5, wherein, when no NFC is available, the monetary value is provided to the mobile device of the buyer manually.
8. A mobile payment system as claimed in claim 7, wherein the buyer is requested by the system to enter an identification code into the mobile device after which the monetary value is entered manually.
9. A mobile payment system as claimed in any one of the preceding claims, wherein the credit request data package includes data as to the date and time at which the package was generated.
10. A mobile payment system as claimed in any one of the preceding claims, wherein the credit data package includes data as to the date and time at which the package was generated, whether the data exchange too place via NFC and/ or online, without using NFC and/or online.
1 1. A mobile payment system as claimed in any one of the preceding claims, wherein, if the mobile device of the buyer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the buyer transmits the credit request data package to the server of the system.
12. A mobile payment system as claimed in any one of claims 1 to 10, wherein, if the mobile device of the buyer does not have internet connectivity when the credit request data package is to be transmitted, the credit request data package is transmitted to the NFC device of the seller via NFC and then it is transmitted to the server of the system by the seller. A mobile payment system as claimed in claim 12, wherein, when a credit data package has been generated by the server of the system, this is transmitted to the NFC device of the seller and then via NFC to the mobile device of the buyer.
A mobile payment system as claimed in claim 1 , wherein if the mobile device of the buyer does not have internet connectivity when the credit request data package is to be transmitted and is not NFC-enabled, the monetary value is provided to the mobile device of the buyer manually.
A mobile payment system as claimed in claim 14, wherein the buyer is requested by the system to enter an identification code into the mobile device after which the monetary value is entered manually.
A mobile payment system as claimed in claim 14 or claim 15, wherein the system presents the buyer with an option for using a pre-purchased credit data package which are stored on the mobile device of the buyer.
A mobile payment system as claimed in claim 16, wherein each pre- purchased data package has a fixed monetary value assigned thereto.
A mobile payment system as claimed in claim 16 or claim 17, wherein, in order to access a pre-purchased data package, the buyer is requested to enter an identification code and, once this has been verified by the system, the buyer manually enters the monetary value of the pre-purchased credit data package he would like to use.
A mobile payment system as claimed in claim 18, wherein the system generates a secondary credit data package using the data of the pre- purchased credit data package to which the system adds information relating to at least: the monetary value entered by the buyer, an identifier associated with the seller, the fact that the transaction is being carried out without the use of NFC or online capabilities, and the like.
A mobile payment system as claimed in claim 19, wherein the mobile device of the buyer converts the secondary credit data package into a QR code which is displayed on the mobile device of the buyer so that it is readable by the QR reading device of the seller.
21. A mobile payment system as claimed in claim 20, wherein verification of the validity of the data encoded in the QR code by the server is requested by the seller and, if verification was successful, a message is sent to the buyer and the seller indicating a successful monetary transaction. 22. A mobile payment system as claimed in claim 21 , wherein the secondary credit data package is returned to the mobile device of the buyer after the monetary value of the successfully completed transaction has been deducted from its fixed value, thereby creating a new pre-purchased credit data package having a different fixed value. 23. A mobile payment system as claimed in any one of the preceding claims, wherein the buyer has one or more virtual and/or real accounts associated with the system.
24. A mobile payment system as claimed in any one of the preceding claims, wherein the buyer has an option of purchasing pre-purchased credit data packages, each package having a fixed monetary value, which pre-purchased credit data packages are stored on the mobile device of the buyer and are used if the account(s) of the buyer does not have sufficient funds or cannot be accessed.
25. A mobile payment system as claimed in any one of the preceding claims, wherein the system is supported by an application which is loaded on the mobile device of the buyer.
26. A mobile payment system as claimed in claim 25, wherein a complementary application is loaded at the point of purchase on an electronic device of the seller. 27. A mobile payment system for facilitating a monetary transaction between a payer and a recipient, the system including at least the steps of:- providing a monetary value of a transaction to a mobile device of the payer; transmitting a credit request data package to a server of the system which credit request data package includes at least data regarding the monetary value and data identifying the payer and the recipient; ascertaining whether or not one or more accounts of the payer contain funds exceeding the monetary value; if sufficient funds are available, the server generating a credit data package including at least the following data: an amount equal to at least the monetary value transmitted in the credit request data package, a unique identifier associated with the payer, and an identifier associated with the recipient; and transmitting the credit data package to the mobile device of the payer; converting the credit data package into a QR code and displaying same on the mobile device of the payer so that it is readable by a mobile device of the recipient; and requesting verification of the validity of the data encoded in the QR code by the server and, if the data encoded in the QR code is found to be valid, transmitting a message to the mobile devices of the payer and recipient that a successful transfer of the monetary value between the payer and recipient has taken place.
28. A mobile payment system as claimed in claim 27, wherein the mobile devices of the payer and recipient are a cellular telephone.
29. A mobile payment system as claimed in claim 27 or claim 28, wherein, following a successful transaction, the credit data package is stored on the mobile device of the recipient for further processing.
30. A mobile payment system as claimed in any one of claims 27 to 29, wherein the monetary value of the transaction is provided to the mobile device of the payer by means of NFC during which the mobile devices of the payer and recipient are placed close to each other.
31. A mobile payment system as claimed in any one of claims 27 to 29, wherein, if the mobile devices of the payer and recipient are not NFC enabled or NFC is not available, the monetary value is entered into the mobile device of the payer manually.
32. A mobile payment system as claimed in any one of claims 27 to 31 , wherein the credit request data package includes additional data such as, for example, the date and time at which the package was generated.
33. A mobile payment system as claimed in any one of claims 27 to 32, wherein the credit data package includes additional data as to the date and time at which the package was generated, whether the data exchange took place via NFC and/ or online, without using NFC and/or online.
34. A mobile payment system as claimed in any one of claims 27 to 33, wherein, if the mobile device of the payer has internet connectivity when the credit request data package is to be transmitted, the mobile device of the payer transmits the credit request data package to the server of the system.
35. A mobile payment system as claimed in any one of claims 27 to 33, wherein, if the mobile device of the payer does not have internet connectivity when the credit request data package is to be transmitted, the credit request data package is transmitted to the mobile device of the recipient via NFC from where it is transmitted to the server of the system by the recipient.
36. A mobile payment system as claimed in claim 35, wherein, when a credit data package has been generated by the server of the system, this is transmitted to the NFC device of the recipient and then via NFC to the mobile device of the payer.
37. A mobile payment system as claimed in claim 35 or 36 wherein, if the account of the payer does not have sufficient funds, a pre-purchased credit data package stored on the mobile device of the payer is requested.
38. A mobile payment system as claimed in claim 37, wherein, in order to access a pre-purchased data package, the buyer is requested to enter an identification code and, once this has been verified by the system, the buyer manually enters the monetary value of the pre-purchased credit data package he would like to use.
39. A mobile payment system as claimed in claim 38, wherein the pre-purchased credit data package at least includes data regarding the monetary value thereof and the identity of the payer.
40. A mobile payment system as claimed in any one of claims 27 to 39, wherein the payer has one or more virtual and/or real accounts associated with the system.
41. A mobile payment system as claimed in any one of claims 27 to 40, wherein the payer has an option of purchasing pre-purchased credit data packages, each package having a fixed monetary value, which pre-purchased credit data packages are stored on the mobile device of the buyer and are used if the account(s) of the payer does not have sufficient funds or cannot be accessed.
42. A mobile payment system as claimed in any one of claims 27 to 41 , wherein the mobile payment system is supported by an application which is loaded on the mobile devices of the payer and the recipient.
43. A mobile payment system according to the invention, as hereinbefore generally described.
44. A mobile payment system as specifically described with reference to or as illustrated in any one of the accompanying drawings.
45. A mobile payment system including any new and inventive integer or combination of integers, substantially as herein described.
PCT/ZA2017/050041 2017-08-03 2017-08-03 Mobile payment system WO2019028481A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/ZA2017/050041 WO2019028481A1 (en) 2017-08-03 2017-08-03 Mobile payment system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/ZA2017/050041 WO2019028481A1 (en) 2017-08-03 2017-08-03 Mobile payment system

Publications (1)

Publication Number Publication Date
WO2019028481A1 true WO2019028481A1 (en) 2019-02-07

Family

ID=60473689

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/ZA2017/050041 WO2019028481A1 (en) 2017-08-03 2017-08-03 Mobile payment system

Country Status (1)

Country Link
WO (1) WO2019028481A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090276347A1 (en) * 2008-05-01 2009-11-05 Kargman James B Method and apparatus for use of a temporary financial transaction number or code
WO2009146111A2 (en) * 2008-04-02 2009-12-03 Global 1 Enterprises, Inc. Mobile telephone transaction systems and methods
US20140344157A1 (en) * 2011-11-08 2014-11-20 Secure Payment Technologies Gmbh Method and device for carrying out cashless payment
WO2015028664A1 (en) * 2013-08-30 2015-03-05 Gemalto Sa Method for authenticating transactions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009146111A2 (en) * 2008-04-02 2009-12-03 Global 1 Enterprises, Inc. Mobile telephone transaction systems and methods
US20090276347A1 (en) * 2008-05-01 2009-11-05 Kargman James B Method and apparatus for use of a temporary financial transaction number or code
US20140344157A1 (en) * 2011-11-08 2014-11-20 Secure Payment Technologies Gmbh Method and device for carrying out cashless payment
WO2015028664A1 (en) * 2013-08-30 2015-03-05 Gemalto Sa Method for authenticating transactions

Similar Documents

Publication Publication Date Title
US7552094B2 (en) Optical payment transceiver and system using the same
US20140052607A1 (en) Secure payment system using a mobile phone, and payment method using same
US8336763B2 (en) System and method for processing transactions
JP2008204448A (en) Value insertion using bill pay card preassociated with biller
CA2604348A1 (en) Mobile phone charge card notification and authorization method
EP1021802A2 (en) Method for checking rightful use of a debit card or similar means giving right of disposing of a bank account
CA2608926A1 (en) In-lane money transfer systems and methods
US20140279537A1 (en) Financial transaction system and method capable of utilizing a mobile device
JP2002541601A (en) Person-to-person, person-to-company, company-to-person, and company-to-company financial transaction systems
CN108335103A (en) A kind of deducting money method and system based on digital cash
JP2009532814A (en) Method and system for enhancing consumer payments
CN102132317A (en) Systems and methods for providing vending network
EP2998916A1 (en) Method and system for carrying out payment transactions
US10402795B2 (en) Prefunding for money transfer send transactions
TW200805186A (en) Method and apparatus for payment without payment card infrastructure
CN110910155A (en) Information processing apparatus, recording medium, and information processing method
KR20110135260A (en) Individual prepayment system, and operating method thereof
KR20030068603A (en) Paying system using cellular phone and the method
US20140358779A1 (en) Method Of Conducting Financial Transactions Using A Phone Node In Communication With A Transactional Server
EP1059597A2 (en) A system and method for doing electronic commerce
EP2680206A2 (en) Secure payment system using a mobile phone, and payment method using same
WO2019028481A1 (en) Mobile payment system
KR102121780B1 (en) Cryptocurrency transaction system and method of cryptocurrency transaction service
JP2006040249A (en) System and method for operating prepaid card service
KR100394527B1 (en) An Electronic Payment Method Using A Value-Added Network

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: 17804785

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17804785

Country of ref document: EP

Kind code of ref document: A1