WO2011137493A1

WO2011137493A1 - Remittance system and method

Info

Publication number: WO2011137493A1
Application number: PCT/AU2011/000521
Authority: WO
Inventors: Richard Poulden; Gregory Weldon
Original assignee: Miller, Neil
Priority date: 2010-05-05
Filing date: 2011-05-05
Publication date: 2011-11-10

Abstract

The present application discusses a system and method for effecting remittance of funds (100) wherein an initiating party (101) sends a request (110) for remittance of funds of a specified denomination to an intended recipient (102) via mobile handset (109) to a central access number which is associated system. System (100) then verifies the request before generating a unique (32) character alphanumeric token (117). The system then proceeds to transmit (115) the first (25) characters (117a) (session ID), of the (32) character alphanumeric token (117) under an SSL connection to the recipient's (102) mobile phone (114). A WAP session is then opened on the recipient's mobile utilising the session ID (117a) to download a barcode (116) which includes the last (7) characters (Verification Number) (117b), of the (32) character alphanumeric token (117). The barcode is then scanned to effect remittance to the specified denomination to the intended recipient (102).

Description

TITLE

REMITTANCE SYSTEM AND METHOD

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to a remittance system and method. In particular although not exclusively the present invention relates to a system and method for effecting remittance between two parties via a handheld device.

Discussion of the Background Art

Payment remittance between two parties can be by affected in a variety of ways. One simple example is the use of postal money order, but this is often very slow, unreliable and not amenable for use in international transfers. An alternative is to effect remittance via bank transfer this requires the recipient to have access to the banking^r facilities of the institution with which they^' have established the account. There are often times however, where such facilities are not available. In many countries, including many developing societies, handheld devices such as PDAs, mobile phones and the like have become widely available, with most families owning at least one mobile phone. For example, according to one report, China had about 500 million mobile phone subscribers among a total population of 1.3 billion. A number of electronic payment remittance systems have been devised to take advantage of such wide availability of mobile phones. For example, U.S. Patent Publication No. 20080270246 entitled "Global electronic payment system" discusses an electronic payment system whereby cell phones can be used as one of many possible input devices for both the remittance sender and remittance receiver. This system, however, does not involve payment of cash to the remittance receiver, rather the remittance receiver is required to have an established account with a financial institution within e.g. the ACH/SWIFT network in order to receive payment. Another example of such an electronic payment system is discussed in U.S. Patent. Publication No. 20080249930 entitled "International Remittance System Based on Payment Card Accounts with Access by Mobile Telephone" describes a funds transfer system which involves two mobile telephone operating companies, two financial institutions, and a payment processing network operating company for transferring funds from the first financial institution to the second financial institution to benefit a recipient who owns a mobile telephone. The recipient must also, maintain an account in one of the financial institutions, which transmits to the recipient a notice . indicative of receipt of said funds transfer.

Accordingly, there is a need for a system and method for facilitating transfer of funds via a mobile phone, which obviates the heed for the intended recipient to maintain an account with a financial institution or ^{: '}mobile phone service provider (e.g. any pre-paid phone is sufficient) etc, in order to receive the funds.

SUMMARY OF THE INVENTION

Disclosure of the Invention

Accordingly in one aspect of the present invention there is provided a system for facilitating a funds transfer between an initiating party and a receiving party, said system comprising:

a remittance agency said remittance agency including at least one server, wherein the at least one server is configured, on receipt of a funds transfer request from the initiating party, to:

verify that the initiating party maintains an account with the remittance agency;

install: on the initiating party's mobile device ah application wherein the application is configured to forward to the at least one server the particulars of the requested funds transfer including the identity of the receiving party and amount of funds to be transferred;

send a notification to the receiving party of . the request for funds transfer; install on the receiving party's mobile, device, on acknowledgement of receipt of the notification, the application wherein the application is configured to forward to the at least one server information relating to the configuration of the receiving party's mobile handset; .

generate responsive to the receipt of the information relating to the configuration of the receiving party's mobile device a token;

forward a first portion of the token to the receiving party's mobile device thereby causing the application to translate the first portion of the token to a uniform resource locator (URL) for use by the receivin party's mobile handset; and

: generate and forward a barcode on access of the URL by the receiving party's mobile device, said barcode including a second portion of the token and information regarding the amount of the requested transfer; .

a plurality of authorised agents each authorised agent including a scanning device coupled to a remittance agency; and

wherein the amount of funds to be transferred is remitted to the receiving party by one of the authorised agents by scanning the barcode whereon the at least one server to issue a payment authorization in the requested transfer amount.

In a further aspect of the present invention there is provided a method of remitting funds, said method including the steps of:

receiving at a remittance agency a request from an initiating party to initiate a funds transfer to a receiving party;

verifying that the initiating party has a valid account with the remittance agency;

installing on the initiating party's mobile device an application, wherein said application is configured to forward to the remittance agency particulars of the requested funds transfer including the identity receiving party and amount to be transferred; . . _.

sending in response to the information forwarded by the application a notification of the funds transfer request to the receiving party;

receiving an acknowledgment from the receiving party of the notification of the funds transfer request; - installing on the receiving party's mobile device the application, wherein the application is further configured to transmit information relating to the receiving party's mobile device's configuration to the remittance agency;

generating at the remittance agency responsive to the receipt of the information relating to the configuration of the receiving party's mobile handset a token;

forwarding a first portion of the token to the receiving party's mobile handset whereon the application translates the first portion of the token to a uniform resource locator (URL);

retrieving at the receiving party's mobile handset from the URL a barcode generated by the remittance agency, said barcode including a second portion of the token and wherein the receiving party presents the barcode to an authorised agent of the remittance agency;

verifying at the remittanc agency that the barcode is valid on receipt of a request for verification by said authorised agent;

. issuing a payment authorization to the authorised agent on validation of the barcode whereon the authorised agent pays . the receiving party the amount to be transferred; and

debiting th initiating; party's account with the remittance agency in the amount of the transfer. _;

In another aspect of the present invention there is provided a system for facilitating: a funds transfer between an initiating party and a receiving party, said system comprising:

a remittance agency said- remittance agency including at least one server, wherein the at least one server is configured, on receipt of a registration request form an initiating party:

install on the initiating party's mobile device an application wherein the application is configured to forward to the at least one server particulars of a request for. funds transfer to the receiving party including the receiving party's identity and amount to be transferred:

verify that the initiating party maintains an account with the remittance agency; generate a token oh verification that the initiating party maintains an account with the remittance agency;

generate a uniform resource locator (URL) utilising a first portion of the token;

forward to the URL receiving party;

forward a second portion of the token to a host server;

whereby activation of the URL by the receiving party's mobile handset causes the host server to generate, and forward to the receivihg party a barcode, said barcode including the second portion of the token;

a plurality of authorised agents each authorised agent including a scanning device coupled to the remittance agency; and

wherein the amount of funds to be transferred is remitted to the receiving party by one of the authorised agents by scanhihg the' barcode whereon the at least one . server to issue a payment authorization in the requested transfer amount.

In yet another aspect of the invention there is provided a method of remitting funds between ah initiating party and a receiving party, said method including the steps of: receiving at a remittance agency a request for registration from the initiating party;

installing on the initiating party's mobile device an application wherein said application is configured to forward to the remittance agency particulars of a funds transfer request from said initiating party including a transfer amount and the receiving party's identity

generating at the remittance agency a token On verification that the initiating party ^: maintains an account with the remittance agency;

generating a uniform resource locator (URL) utilising a first portion of the token;

forwarding the URL to the receiving party's mobile device;

forwarding a second portion of the token to a host server;

transmitting, a barcode generated by the host server to the receiving party in response to activation of the URL by the receiving party, said barcode including a second portion of the token and wherein the receiving party presents the barcode to an authorised agent of the remittance agency;

verifying at the remittance agency that the barcode is valid on receipt of a request for verification by said authorised agent;

issuing a payment authorization to the authorised agent on validation of the barcode whereon the authorised agent pays the receiving party the amount to be transferred.

Preferably the communication between the remittance agency and the initiating party, receiving party and authorized agent are conducted via a secure sockets layer (SSL) connection. ^■

The request from an initiating party to initiate the funds transfer may be sent via SMS, MMS, email or the like. Suitably the notification ^{^}of the funds transfer request and acknowledgement of funds transfer request . may be in the form of an SMS, MMS, email or the like. ^' ? .

The application may be deployed as a plug-in or applet for a pre-existing application on the mobile phone or as a stand alone application. Suitably the application provided the initiating party with the ability to cancel the funds transfer at any stage prior to the receiving party, presenting the barcode to the authorised agent for redemption. On receipt of such a ancellation request the remittance agency may void or disable the barcode from further use. Suitably the token is a 32 character alphanumeric token. Preferably the first portion of the tpken is composed of the first 25 characters of the 32 character alphanumeric token and the second portion of the token is composed of the last 7 characters of the 32 character alphanumeric token. The translation of the first portion of the token to the URL may involve forming the URL by appending the first token with a preset URL prefix. The preset URL prefi may denote a specific class of mobile handset protocol to for example the preset URL may denote the use of a wireless protocol such as WAP, WML, WIP, WURFL etc.

Preferably the information relating to the receiving party's mobile handset includes the information on the mobile handset manufacturer, operating system, model number and/or regional encoding being utilised.

The barcode may be in the form of a 6 to 12 segment EAN barcode. The barcode may be provided to the receiving party's mobile handset in the form of an image file such as a Wireless Application Protocol Bitmap (wbmp), jpeg, gif, tiff, pdf or the like.

The authorised agent/s may be any entity registered with the remittance agency as a financial partner and may include such entities as financial institutions (i.e. banks, building societies, co-operatives etc), retail outlets (i.e. Costco, WallMart, Spa, Marks & Spencer, Coles, Myer, Grace Brother, David Jones etc). The payment of the recipient by the authorised agent may be made in cash or in the case where the agent is a retail outlet the payment to the recipient can be made in the form of store credit. The method may also include the steps of prior to installation of the applicatio on the receiving party's: mobile handset forwarding from the remittance agency a request for confirmation of the particulars of the transfer to the initiating party; and receiving at the remittance agency a confirmation message from the initiating party. In the case of the system the at least one server may be further configured to prior to installation of the application on the receiving party's mobile handset forward a request for confirmation of the particulars of the transfer to the initiating party; and receive a confirmation message from the initiating party. Suitably the validation of the barcode includes matching the second portion of the token contained in the bar code with the first portion of the token to produce a single token and comparing the single token with the generated token to determine if match exists. In the event that there is no match the remittance agency may deactivate the barcode.

Preferably the initiating party and. the receiving party are in different geographical locations. For instance the two parties may simply be in different locations in the same city, different states or provinces or even different countries.

BRIEF DETAILS OF THE DRAWINGS In order that this invention may be more readily understood and put into practical effect, reference will now be made to the accompanying drawings, which illustrate preferred embodiments of the invention, and wherein:

FIG. 1 is a schematic diagram of a remittance system according to one embodiment of the present invention; and

FIG. 2 is a schematic diagram of a remittance system according to a further embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION With reference to Fig 1 there is illustrated a system, which the applicant has termed VOIPay, for effecting remittance of funds 00 according to one embodiment of the present invention. As shown a party 101 who wishes to initiate the remittance of funds to an intended recipient 102, is firstly required to register with the VOIPay system 100. In this particular example the initiating party 101 registers with the VOIPay system 100 by entering relevant details into a registration form provided on a web portal 103 in order to establish a VOIPay Account. The information from the form is sent via the web portal 103 to a VOIPay gateway 104 to the central VOIPay centre 105 (remittance agency) for processing. In this instance the VOIPay centre 105 includes a front end server 106 and a database 107.

On receipt of the registration information provided by the initiating party 101 the VOIPay centre 105 proceeds to verify the initiating party's 101 identity and credentials. Once the information received from the initiating party 101 is verified a VOIPay account is created for the initiating party 101. This VOIPay account typically includes information such as the sender's identity, address, income and credit information etc. The VOIPay account is then stored to the database 107 for use in later funds transfer transactions; On successful registration with the VOIPay system the initiating party 101 is provided with a pin code to access the VOIPay account to initiate transfers and to enable the initiating party 101 to access and edit details relating to the account, activate or deactivate the account, via for example a main account's administration page provided via web portal 103. While the above registration process has been discussed in above in relation to a direct registration procedure i.e. user . initiates registration via access point provided by the system, it will be appreciated by those of skill in the art that registration with the VOIPay system could be affected indirectly. For example registration with the system could be via a third party financial service provider 108 such that the bank or other financial service company. In such an instance registration with the VOIPay system could be integrated into the registration procedure for the financial service provider's 108 online systems etc.

Once the initiating party 101 has registered with the VOIPay system they are free to utilise the system to initiate transfer any denomination of funds to a desired recipient 102.. As shown the initiating party 101 sends a request 110 to the VOIPAY centre 105 via the VOIPay gateway 103 in order to initiate the transfer. In this particular example initiating party sends a request 1 10 for remittance via mobile handset 109 to the VOIPay gateway 104 over mobile communications network 1 11. The request 1 10 in this particular instance is in the form of a WAP request containing the remittance amount which is for example is sent to a central access number which is associated VOIPay system.

In an alternate arrangement of the system 100, the remittance request 110 could be sent as an SMS to a central number associated with the remittance agency 105. Any SMS sent to the central number are routed by the SMSC to the appropriate VOIPay gateway 104, which then forwards the request to the VOIPay centre 105 for authentication. It will of course be appreciated by those of skill in the art that the SMS need not be routed via an appropriate VOIPay gateway 104 but could be directly forwarded by the serving SMSC to the VOIPAy centre 105 for processing.

On receipt of the request 110 the VOl Pay centre's front end 106 then requests 1 12 the provision of certain information from the initiating party 101 e.g. initiating party's Caller ID, pin number etc. Once the front end 106 receives the requested credentials from the initiating party 101 it proceeds to look up the accounts database 107 to verify if the ^' initiating party 101 has an account with the system. During the authentication procedure the VOIPay system also verifies if there are sufficient funds in the initiating party's 101 VOIPay account for the remittance request to be honoured. If there is insufficient funds the system sends a message to the initiating party 101 advising that there are insufficient funds to effect the transfer. The initiating party 101 may then be provided with: the option initiate the fund the transfer request using a different source of funds, e.g. art account with a financial institution 108 with which VOIPay has an established relationship, or via a credit card account etc, or to simply terminate the. request until additional funds are transferred to the VOIPay account.

Following successful authentication, the VOIPay front end 106 pushes to the initiating party's mobile phone 109, an application 113 (which the applicant has termed VOIPay_REMIT) together with an SMS service indicator (SMS SI). The application program is provided to facilitate the provision of a secure connection between the initiating party's mobile phone 109 and the VOIPay system-, While there is a sufficient level of security provided under standard SMS protocols they are not generally regarded as being suitable for the transfer of financial information. The VOIPAY_REMIT application is designed to establish a secure socket layer (SSL) connection between the VOIPAY system and the initiating party's phone 109 the SSL connection. Upon installation of VOIPAY__REMIT, to the initiating party's phone 109 the initiating party is required to enter into the VOIPAY_REMIT interface (API) the intended recipient's 102 mobile phon number, remittance amount and their pin number (if assigned). This information is then transmitted to the VOIPay front end server 106 via the SSL connection provided by VOIPAY_REMIT application, On receipt of the relevant details from the VOIPAY_REMIT application the front end server .106 sends . a Verification Message to the initiating party's mobile phone 109 signifying acceptance of the requested transaction. The verification message may include the details of the request such as Remittance Amount, Recipient's Name and Recipient's Mobile Phone Number which are then displayed to the initiating party 101 to ensure the details of the request are correct. If the details are correct the initiating party 101 then sends a confirmation message to the VOIPay front end server 106. If the details of the request contained in the verification message are incorrect the initiating party 101 is able to cancel the request.

Once the request is confirmed the VOIPay front end 106 proceeds to generate a unique 32 character alphanumeric token 117. The VOIPay system pushes the VOIPay_REMIT application together wit an SMS service indicator to the recipient's mobile phone 14. The SMS may include details relating to the initiating party 101 such as their name and phone number. Once the VOIPay_REMIT application is installed on the recipient's mobile phone 114 the VOIPay front end server 106 then proceeds to transmit 115 the first 25 characters 117a (session ID), of the 32 character alphanumeric token 117 under an SSL connection provided by the VOIPay_REMIT application. The VOIPay_REMIT application then proceeds to open a Wireless Application Protocol (WAP) session with WAP server 1 15 utilising the session ID 117a of to formulate the address of a WAP URL by appending the session ID 1 17a to a preset URL prefix e.g. https/WAP/getbarcode=************************* wherein each "*" represents a single alphanumeric character (i.e. the session ID 1 17a act as the URI). The WAP URL is then utilised by the VOIPay_REMIT to download from the VOIPay front end 105 a barcode 1 16 which includes the last 7 characters (Verification Number) 117b, of the 32 character alphanumeric token 1 17.

In one iteration of the present invention the recipient 102 may be required to send a confirmation massage to the VOIPay centre 105 in order to proceed with remittance of the funds. On receipt of the recipient's 102 confirmation massage the VOIPay system would then push the VOIPay_REMIT application together with an SMS service indicator to the recipient's mobile phone 114. Once the VOIPay_REMIT application is installed the system proceeds to generate the alphanumeric-token 1 17 and send the relevant components i.e. the session ID 1 17a, and Verification Number 1 17b in the manner discussed above. The barcode may be in any suitable bar code format for this instance it may be a 6 to 12 segment EAN barcode. To further enhance security the barcode may only be valid for a specified period of time, e.g. from about 5 minutes to a few days. The barcodes are analogous to a check issued from a standard checking account. A check is valid for e.g. ninety days after which time the check will not be redeemable and becomes stale. Depending on the nature of the remittance, the length of time within which the barcode is valid depends on many factors and can be set by the either the initiating party 101 or by the system (i.e. a default value is set if no time value is specified by the initiating party 101). If the barcode is not presented for redemption during the specified period the VOIPay system marks the barcode as expired to prevent its further usage.

As will be appreciated by those of skill in the art different models of mobile handsets format and display information received via SMS and/or^' MMS messages differently depending on their operating system, character sets etc. As the present system relies primarily on the display of the barcode to ensure transfer it is vital that the barcode is provided in appropriate format for the mobile device utilised by the intended recipient 102. To ensure that proper formatting of the barcode the VOIPay_REMIT application transmits information regarding the mobile handset of the recipient such as manufacturer id, model number, operating system etc. The front ^■ end server 106 then asses the type of handset and transmits the right type of code for that phone. In One particular embodiment of the invention the barcodes are sent by the front end server 106 in the form of a wbmp (wireless bit map), the wbmp being formatted with an appropriate header and padding as required to permit display o the image on the barcode on the recipient's handset.

. V · ·

In addition to the type of handset utilised by the recipient the delivery of the barcode is also affected by the region of deployment. Different encoding of the barcode is required for specific geographic regions for example in Asia UTF16 encoding is required so proper display of Asian language characters is possible. Likewise specific encoding is required to ensure proper display of other languages that do not conform to UTF 8 or Western European encoding schemes. In order to ensure that the proper encoding is utilised the VOIPay_REMIT application interrogates the recipient's phone 1 14 to determine the type of encoding presently being utilised by the phone. This informatiori is then passed to the front end server 106 which then ensures that the appropriate encoding scheme is utilised in the packaging and transfer of the barcode to the recipient's phone 1 14. To further enhance. the security of the system time based voiding of the barcode the may also be provided. In addition to this the VOIPay system may also al ow the initiating party 101 to monitor their currently pending transfer request via the VOIPay_REMIT application and if required void one or more requests at any time prior to redemption by the recipient 102.

During the download of the barcode the front end server 106 associates the Verification Number 117b with the session identifier 117a. The session identifier along with all relevant information on the initiating and receiving parties 101 ,102 is then stored in a log for later use during the redemption process which is discussed in greater detail below. Likewise a listing of full length tokens that remain active within the system, i.e. those that are not associated with voided or expired barcodes, is also maintained.

In order to receive the remittance in the amount specified in the transfer, the recipient 102 is required to present the barcode to a designated' Financial Partner (FP) 118 of the VOIPay system such as a bank or retail chain etc. Each FP is assigned a Merchant ID and an account ID and key within the VOIPay system.

On presentation of the barcode by the recipient 102 the FP 8 then scans the code to retrieve the Verification Number 117b encoded therein. The retrieved Verification . Number 1 17b is then forwarded by the FP server 119 to the VOIPay front end server 106 along with the FP's merchant and account IDs. The- front end server 106 then verifies the FP's r ierchant ID and account ID. Once the front end server 106 has established that the FP 1 18 is a valid FP it then proceeds to search the log of session identifiers to locate a matching entry for the retrieved Verification Number 117b.

Once a match for the retrieved Verification Number 1 17b is determined the front end server 106 then is able to retrieve all the necessary information pertaining to the initiating party, the receiving party, the amount proposed for transfer and the session ID 117a. The front end server 106 then combines the retrieved Verification Number 117b with the matching session ID 117a to produce a 32 character alphanumeric token, this token is then compared with the listing of all active tokens within the system as a final check of the validity of the redemption request being made by the . intended recipient 102 via the FP 118. Upon successful verification of the redemption request, the front end server 106 returns an authorization code to the FP 18. Upon receipt of the Authorization Code, the FP 118 pays cash 120 to the recipient 102 in the amount initially requested by the initiating party 101. The FP's server 119 then sends a completion message to the VOIPay front end 106, which deactivates the barcode. The front end 106 then debit the transfer amount from the initiating party's account. FP's 1 18 backend reconciliation gateway 121 then negotiates with the VOIPay centre to ensure that appropriate funds are remitted to the FP 1 18 to cover the cash payment to the recipient 102.

In the above example the VOPay system pushes the VOIPay_^REMIT application to the initiating and receiving party on receipt of their confirmation to facilitate the transfer, thus the above example the VOIPay_REMIT application could be deployed ^■ as a plug-in or applet for a pre-existing application on the mobile phone. However, as will be appreciated by those of skill in the art the VOIPay_REMIT application could be provided as a stand alone application which can be download to the mobile phone of a user once registered with the system. In such an instance the initial signalling via SMS between the initiating and receiving party with the VOIPay centre is not required as the all request would be handle through the VOIPay_REMIT application over an SSL connection. It should also be noted that the remittance need not be in the form of cash. For example where the FP 118 is a retail outlet the remittance may be in the form of store credit i.e. $10, $20, $100 etc. Alternatively the transaction could be in the form of a _. cash advance from a credit card held by the initiating party in this case the initiating party acts as a pseudo FP in that they are realising funds to themselves. However in practice validation and remittance is negotiated with the backend systems of the financial institution or credit card authority which issued the card to the initiating party. Fig 2 depicts an alternate arrangement 200 of the remittance system according to a further embodiment of the present invention. As shown the initiating party _.102 registers with the VOIPay system 200 via a financial service portal 201 equipped with a number of VOIPay Remit tools to permit the financial service portal 201 to push the VOIPay_REMIT application to the initiating party's phone 109. The VOIPay_REMIT application in this instance is typically installed to the initiating party's phone 109 via a WAP push initiated by the financial service portal 201 when registration is complete. It will of course be appreciated by those of skill in the art that while, the financial services portal in this example is shown as a stand alone portal within the central VOIPay centre 105 (remittance agency) it could be deployed as an application running on- the VOIPay front end server 106 or as a remotely deployed standalone application.

Once the VOIPay_REMIT application is installed on the initiating party's phone 109 the initiating party 102 is free to send a remittance request to any recipient 102. To initiate the remittance request, the initiating party is required to enter into the API provided by the VOIPay_REMIT application a PIN. On verification of the PIN the initiating party 101 is the requested by the VOIPay_REMIT application to enter the relevant transfer details such as the recipient's phone number and the desired amount to be transferred. The request 110 is then sent by the VOIPay_REMIT application the VOIPay centre 105 via the VOIPay gateway 103.

On receipt of the request the front end 106 then proceeds to look up the accounts database 107 to verify if the initiating party 1.01 has a valid account with the system 200. The front end 106 at this stage also verifies if the initiating party 101 has sufficient funds in their VOIPay account to complete the requested transfer. Following successful authentication, the VOIPay front end 106 then generates the proceeds to generate a unique 32 character alphanumeric token 117.

As in the above example the token is split into two sections a first section of 25 ' characters 7a (session ID), and a second section of 7 characters 1 7b (verification number). The session ID 1 17a to formulate the address of a WAP URL by appending the session ID 117a to a preset URL prefix e.g. https/WAP/getbafcode-* **************** wherein each "*" represents a single alphanumeric character (i.e. the session ID 117a act as the URI). The URL is then sent to the recipient's mobile 114 via SMS, while the verification number 117b is sent . via the VOIPay gateway 104 to an appropriate WAP server 1 15. Just prior to forwarding the URL to the recipient the front end 106, again verifies that the initiating party 101 has sufficient funds to complete the transfer. If there are sufficient funds available the front end 106 debits the initiating: party's account and deposits the. funds to a clearing account 202.

On activation of the URL 204 by the recipient 102 the WAP server 115 generates a barcode 116 containing the Verification Number 117b. The barcode 116 which is preferably in the form of a wireless bitmap (WBMP) is then pushed 206 to the recipient's, phone 114 in a markup language which is determined by the device/Software which initiated the request for the barcode 116 over the URL. For example the barcode maybe delivered in WAP, HDML, imode, mml, xhtml, cwgui, voicexml, pda mark-up or the like. By utilising the WBMP file format the system is provided with a degree of backward compatibility e.g. back to and including the WAP 1.0 standard.

As with the example discussed in relation to Fig 1 above once the recipient 102 has retrieved the barcode 116 they are then able to present it to a financial service provider 1 18 where, it is scanned to retrieve the Verification Number 117b encoded . therein. The Verification Number 1 17b is then stored into the financial service provider 1 18 POS system 1 19 which may be a stand alone application provided by the VOIPay system or a private POS interfaced with VOIPay system via an API 203 made available to. financial service provider 1 8 on registration with the system.

The retrieved Verification Number 1 17b is then combined with the POS information (i.e merchant ID, account ID) and forwarded to the VOIPay gateway 104 for qualification (i.e. a closed loop transaction between the VOIPay gateway, financial service provider 118 and recipient is formed). The VOIPay gateway 104 then forwards the relevant details to the VOIPay front end for verification in a simailr manner to that discussed in relation to Fig. 1 above. Once a match for the Verification number 117b, merchant and account IDs the VOIPay front end 106 issues an authentication message to the financial service provider 118 at which time the financial service provider 118 pays cash 120 to the recipient 102 in the amount initially requested by the initiating party 101. Oh payment of the remittance to the recipient 102 the financial service provider 's POS system 1 9 then sends a completion message to the VOIPay gateway 104 which sends a barcode deactivation notification to the VOIPay front end 106, which then deactivates the barcode. The financial service provider 1 18 backend reconciliation gateway 121 then negotiates with the VOIPay centre105 to ensure release of the funds from the clearing account 202 to the financial service provider 118 to cover the cash payment to the recipient 102.

In the event that the financial service provider 118 does not. have sufficient, cash to cover the request on receipt of . the authentication message they may refuse to honour the request If the request is refused the financial service provider's POS system 119 informs the VOIPay gateway of the refusal. The VOIPay which gateway then communicates the refusal to the VOIPay front end 106 to prevent the deactivation of the barcode so that the recipient has the opportunity encash the barcode at alternate financial service provider 118 who is registered with the system.

It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto, as would be apparent to persons skilled in the relevant art, are deemed to fall within the broad scope and ambit of the present invention described herein.

Claims

1 . A method of remitting funds, said method including the steps of:

receiving at a remittance agency a request from an initiating party to initiate a 5 funds transfer to a receiving party;

installing on the initiating party's mobile handset an application, wherein said application is configured to forward to the remittance agency particulars of the 10 requested funds transfer including the identity receiving part and amount to be transferred;

. sending in response to the information forwarded by the application a · • notification of the funds transfer request to the receiving party;

receiving an acknowledgment from the receiving party of the notification of the 15 funds transfer request;

installing on the receiving party's mobile handset the application, wherein the application is configured to transmit information relating to the receiving party's mobile handset's configuration to the remittance agency;

: generating at the remittance agency responsive to the receipt of the ^• 20 information relating to the configuration of the receiving party's mobile handset a token; ·.-.^{' '■} · .: ^{: "}

;> forwarding a first portion of the token to the receiving party's mobile handset whereon the application translates the first portion of the token to a uniform resource locator (URL); . ^'

25 retrieving at the receiving party's mobile handset from the URL a barcode compiled by the remittance agency, said barcode including a second portion of the : token and wherein the receiving party presents the barcode to an authorised agent of the remittance agency;

verifying at the remittance agency that the barcode is valid on receipt of a 30 request for verification by said authorised agent;

issuing a payment authorization to the authorised agent on validation of the barcode whereon the authorised agent pays the receiving party the amount to be transferred; and debiting the initiating party's account with the remittance agency in the amount of the transfer.

2. The method of claim: 1 wherein communication between the remittance 5 agency and the initiating party, receiving party and authorised agent are conducted via a secure sockets layer (SSL) connection. .

3. The method of claim 1 wherein the request from an initiating party to initiate the funds transfer is sent via SMS.

10 _{. .} ; ·.. ^· _.

4. The . method of claim 1 wherein the notification of the funds transfer request and acknowledgement of funds transfer request are sent via SMS.

5. The method of any one of claims 1 to 4^' wherein the barcode is a 6 to 12 15 segment EAN barcode. ·

6. The method of any one of claims 1 to 5 further including the steps of prior to installation of the application on the receiving party's mobile handset:

forwarding form the remittance agency a request for confirmation of the 20 particulars of the transfer to the initiating party; and

receiving at the remittance agency a confirmation message from the initiating party.

7. The method of any one of claims 1 to 6 wherein the application enables the : 25 initiating party to cancel the funds transfer at any stage prior to the receiving party presenting the barcode to the authorised agent for redemption.

8. The method of claim 7 wherein the remittance agency voids the barcode on cancellation of the funds transfer by initiating party.

30 ·:

9. The method of any one of claims 1 to 8 wherein the token is a 32 character alphanumeric token.

10. The method of claim 9 wherein the first portion of the token is composed of the first 25 characters of the 32 character alphanumeric token and the second portion of the token is composed of the last 7 characters of the 32 character alphanumeric . token.

1 1. The method of any one of claims 1 to 10 wherein the information relating to : the receiving party's mobile handset includes the information on the mobile handset manufacturer, operating system, model number and/or regional encoding being utilised.

■^{·' "■}

12. The method of any one of claims 1 to 1 wherein the URL is formed by _λ appending the first portion of the token to a preset URL prefix.

13. The method of claim 12 wherein the URL is a URL for a WAP page,

: ¾

14. The method of claim 13 wherein the barcode is transmitted as a Wireless Application Protocol Bitmap (wbmpj.

15. The method of any one of claims 1 to. 14 wherein the authorised agent is a financial institution;

16. The method of any one of claims 1 to 14 wherein the authorised agent is retail store.

17. The method of claim 15 or 16, wherein the payment of the recipient by the authorised agent is made in cash

18. The method of claim 16, wherein the payment to the recipient is made in the form of store credit.

19. A system for facilitating a funds transfer between an initiating party and a receiving party, said system comprising:

•a remittance agency said remittance agency including at least one- server, wherein the at least one server is configured, on receipt of a fund^'s transfer request from the initiating party, to:

install on the initiating party's mobile handset an application wherein the application is configured to forward to the at , least one server the particulars of the requested funds transfer including the identity of the receiving party and amount of funds to be transferred;

send a notification to the receiving party of the request for funds transfer;

. install on the receiving party's mobile handsets, on acknowledgement of receipt of the notification, the application wherein the application is configured to forward to the at least one server information relating tb the configuration of the receiving party's mobile handset;

generate responsive to the receipt of the information relating to the configuration of the receiving party's mobile handset a token;

forward a first portion of the token to the receiving party's mobile handset thereby causing the application to translate the first portion of the token to a uniform resource locator (URL) for use by the receiving party's mobile handset; and generate and forward a barcode on access of the URL by the receiving party's mobile handset, said barcode including a second portion of the token and information regarding the amount of the requested transfer;

wherein the amount of funds to be transferred is remitted to the receiving party by one of the authorised agents by scanning the barcode.

:

20. The system of claim 19 wherein communication between the remittance agency and the initiating party, receiving party and authorised agent are conducted via a secure sockets layer (SSL) connection.

21. The system of claim 19 wherein the request from the initiating party to initiate the funds transfer is sent to the at least one server via SMS.

22. The system of claim 19 wherein the at least on server is configured to transmit the notification of the funds transfer request via SMS.

23. . The system of claim 19 wherein acknowledgement of receipt of the notification of the funds transfer request is sent to the at least one server via SMS.

24. The system of any one of claims 19 to 23 wherein the barcode is a 6 to 12 segment EAN barcode.

25. The system of any one of claims 19 to 24 wherein the at least one server is further configured to prior to installation of the application on the receiving party's mobile handset:

forward a request for confirmation of the particulars of the transfer to the . initiating party; and

receive a confirmation message

26. The system of any one of claims 19 to 25 wherein the application enables the initiating party to cancel the funds transfer at any stage prior to the receiving party presenting the barcode to the authorised agent for redemption.

27. The system of claim 26 wherein the at least one server voids the barcode on cancelation of the funds transfer by initiating party.

28. The system of any one of claims 19 to 27 wherein the token is a 32 character alphanumeric token.

29. The system of claim 28 wherein the first portion of the token is composed of the first 25 characters of the 32 character alphanumeric token and the second portion of the token is composed of the last 7 characters of the 32 character alphanumeric token.

30. The system of any one of claims 19 to 29 wherein the information relating to the receiving, party's mobile handset ineludes the information on the mobile handset manufacturer, operating system, model number and/or regional encoding being utilised.

31. The system of any one of claims 19 to 30 wherein the URL is formed by appending the first portion of the token to a preset URL prefix.

32. The system of claim 31 wherein the URL is a URL for a WAP page.

33. The system of claim 32 wherein the barcode is transmitted as a Wireless Application Protocol Bitmap (wbmp).

34. The system of claim any one of claims 19 to 33, wherein the payment of the recipient by the authorised agent is made in cash .

35. The system of any one of claims 19 to 34, wherein the initiating party and the receiving party are in different geographical locations.

36. The method of any one of claims 1 to 18, wherein the initiating party and the receiving party are in different geographical locations,

37: The method of any one of claims 1 to 18 or 37 wherein the application is deployed as a plug-in or applet for a pre-existing application.

38. The system of any one of claims 1 to 36 wherein the application is deployed as a plug-in or applet for a pre-existing application.

39. A method of remitting funds between an initiating party and a receiving party, said method including the steps of:

receiving at a remittance agency a request for registration from the initiating party; installing on the initiating party's mobile device an application wherein said application is configured to forward to the remittance agency particulars of a funds transfer request from said initiating party including a transfer amount and the receiving party's identity

verifying that the initiating party has a valid account with the remittance agency- generating , at the remittance agency a token on verification that the initiating party maintains an account with the remittance agency;

forwarding the URL to the receiving party's mobile device;

forwarding a second portion of the token to a host server;

transmitting a barcode generated^' by the host server to the receiving party in response to activation of the URL by the receiving party, said barcode including a second portion of the token and wherein the receiving party presents the barcode to an authorised agent of the remittance agency;

40. A system for facilitating a funds transfer between ah initiating party and a receiving party, said system comprising: : ; y ^■

a remittance agency said remittance agency including at least one server, wherein the at least one server is configured, on receipt of a registration request form an initiating party:

install on the initiating party's mobile device an application wherein the application is configured to forward to the at least one server particulars of a request for funds transfer to the receiving party including the receiving party's identity and amount to be transferred:

1 verify that the initiating party maintains a account with the remittance agency; generate a token on verification that the initiating party maintains an account with the remittance agency;

forward to the URL receiving party;

forward a second portion of the token to a host server;

whereby activation of the URL by the receiving party's mobile handset causes the host server to generate and forward to the receiving party a barcode, said barcode including the second portion of the token;