PH12013000171A1

PH12013000171A1 - CREDIT FACILITY SYSTEM and METHOD

Info

Publication number: PH12013000171A1
Application number: PH12013000171A
Authority: PH
Inventors: Vea Orlando; Fernandez Benjamin; Villanueva Angelito; Ibasco Alex; Diamante Sherwin; Gaw Gilbert
Original assignee: Smart Hub Inc
Priority date: 2013-06-14
Filing date: 2013-06-14
Publication date: 2015-02-02

Abstract

A system or method for using universal load as a medium for payment for government agencies, private billers and for other payment related use cases supporting a plurality of subscribers, both prepaid and postpaid through a separate mobile wallet reloadable through various channel including, but not limited to, existing airtime retailers via mobile, online or via a mobile application through a direct debit from subscriber's savings account/current account (CASA) bank deposits, and/or creidt card to top-up BayadLoad wallet with e-money at par (at face value) equivalent monetary value; settled through a pre-funded account with a partner bank upon redemption of payment transaction; using SMS, USSD or mobile application as bearer channel.

Description

CREDIT FACILITY SYSTEM AND METHOD

FIELD OF THE INVENTION

The present invention relates to systems and methods for providing credit facilities within a communications network. In particular although not exclusively the present invention relates to the provision of airtime recharge services within mobile communication networks. Even more particularly, the present invention relates to a system and method to pay for government contributions, particularly for members of a social security system.

DISCUSSION OF THE BACKGROUND ART

Most mobile communications systems at present employ two charging paradigms, post-paid and pre-paid. Most post-paid mobile phone services are provided via a contract between the user and a service provider. Under the post-paid paradigm the user is billed at the end of each billing cycle based on their level of usage.

Under the pre-paid paradigms, the user typically purchases the handset along with a set amount of network credit. The user is then free to access the network until they run out of credit. A user may add more credit to the pre-paid account at any time. This is known as "topping up" the account. This top up can be affected by a credit/debit card transaction with the provider or by purchasing a "top-up card" at a retail outlet. The top-up card is stamped with a unique code (often under a scratch-off panel) which can be redeemed on the phone for credit. Credit for a pre-paid mobile phone may have a time limit, for example 90 1 days from the date the last credit was added. In these cases, customers who do not add more credit before expiration will lose their remaining balance, and the service (and its associated phone number) may be discontinued.

One problem with the use of pre-paid mobiles is the difficulty in recharging credit when the user is outside their service provider's network (e.g. user is roaming internationally). In such instances users are unable to purchase recharges cards from their particular service provider. However, as mentioned above, the user has the option to recharge credit by utilising credit or debit cards. Typically, this recharge facility is provided in the form of a web portal, dial in service via a pre-programmed service number or SMS service. The dial in and SMS recharge can be particularly problematic if the user has insufficient credit to initiate the call or send the SMS. Likewise the web portal requires the user to be able to access the Internet, consequently there may be significant delays between being notified of lack of credit and recharge during which the user is unable to access the network and in some instances unable to receive calls. The delays can be further exacerbated as the user's home network takes some time to register the update in credit values, further delays can occur as the change in credit values is propagated through to the host network.

Under the laws of Philippines, also known as the Kasambahay Law, it requires employers of househelp to remit monthly membership contributions to the

Home Development Mutual Fund (Pag-IBIG Fund) and premium payments to the Philippine Health Insurance Corp. (PhilHealth) and the Social Security

System (SSS).

Thus there is a need for Domestic Workers (aka Kasambahay) to pay their social protection coverage without the need to go out/travel and spend hours to pay via over-the-counter (OTC) transaction to a Bank or Bayad Center. Since

Domestic Workers (aka Kasambahay) are often occupied fulfilling their duties, they normally don’t have time to go out to pay their bills.

Accordingly there is a need for a system and method that allows for payment for government agencies, private billers and for other payment related use cases where consumers may conduct transactions using a mobile device and is reloadable through various channels, including existing airtime retailers via mobile, online or via a mobile application, through a direct debit from subscriber's savings account/current account (CASA) bank deposits, and/or credit card to top-up BayadlLoad wallet with e-money at par (at face value) equivalent monetary value; and settle through a pre-funded account with a partner bank upon redemption of payment transaction, using either an SMS,

USSD or mobile application as bearer channel.

SUMMARY OF THE INVENTION

Throughout this document, unless otherwise indicated to the contrary, the terms “comprising”, “consisting of’, and the like, are to be construed as non- exhaustive, or in other words, as meaning “including, but not limited to".

It would be advantageous to provide a system and method of universal load as a medium for payment for government agencies, private billers and for other payment related use cases supporting a plurality of subscribers, both prepaid 16 and postpaid through a separate mobile wallet reloadable through various channel including, but not limited to, existing airtime retailers via mobile, online or via a mobile application through a direct debit from subscriber's savings account/current account (CASA) bank deposits, and/or credit card to top-up

BayadlLoad wallet with e-money at par (at face value) equivalent monetary value; settled through a pre-funded account with a partner bank upon redemption of payment transaction; using SMS, USSD or mobile application as bearer channel.

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 illustrating the transfer of credit between users of two networks according to one embodiment of the present invention

FIG. 2 is a schematic diagram illustrating one possible configuration of a credit provision facility according to one embodiment of the present invention

FIG. 3 is a schematic diagram illustrating one possible configuration of airtime provision to a mobile subscriber according to one embodiment of the present invention

FIG. 4 depicts one possible structure for a rate card according to one embodiment of the present invention

FIG. 5 is a schematic diagram illustrating the process steps associated with providing a mobile subscriber with additional credit

FIG. 6 is a schematic diagram illustrating the relationship between network providers, dealers and retailers according to one embodiment of the present invention

FIG. 7 is a schematic diagram illustrating the process steps associated with enrolling a network provider on the credit provision system according to one embodiment of the present invention

FIG. 8 is a schematic diagram illustrating the process steps associated with providing a dealer with credit according to one embodiment of the present invention;

FIG. 9 is a schematic diagram illustrating the process steps associated with providing a retailer with credit according to one embodiment of the present invention

FIG. 10A and 10B are flow charts illustrating the login and change password processes according to one embodiment of the present invention.

FIG. 11 is a schematic diagram illustrating the transfer of airtime between two mobile subscribers according to one embodiment of the present invention

FIG. 12 is an example of a series of user screens for initiating transfer of airtime from one mobile subscriber to another according to one embodiment of the present invention

FIG. 13 is a schematic diagram illustrating the process steps associated : with the transfer of airtime between mobile subscribers

FIG. 14 is a schematic diagram representing another possible application environment for the credit provision system according to one embodiment of the present invention

FIG. 15 is a schematic diagram illustrating one possible configuration of a credit provision system for the purchasing of goods and services according to one embodiment of the present invention.

FIG. 16 is a schematic diagram illustrating one possible configuration of a credit provision system for facilitating transactions between subscribers and third parties according to one embodiment of the present invention.

FIG. 17 is a schematic diagram illustrating one possible configuration of a credit provision system for facilitating transactions between subscribers and third parties according to one embodiment of the present invention.

FIG. 18 is a schematic diagram illustrating one possible configuration of a credit provision system for facilitating transactions between subscribers and third parties according to one embodiment of the present invention, and

FIG. 19 is a schematic diagram depicted how commissions for various transactions may be distributed to all relevant parties according to one embodiment of the invention.

FIG. 20 is a schematic diagram illustrating the process steps associated with registering basic subscriber information.

FIG. 21 is a schematic diagram illustrating the process steps associated with registering billing account information.

FIG. 22 is a schematic diagram illustrating the process steps associated with the reload of money via a retailer.

FIG. 23 is a schematic diagram illustrating the process steps associated with.the subscriber sending a balance inquiry to the system.

FIG. 24 is a schematic diagram illustrating the process steps associated with the payment of SS, Pag-IBIG or PhilHealth as employee.

FIG. 25 is a schematic diagram illustrating the process steps associated with the payment of SS, Pag-IBIG or PhilHealth by someone other than the employee.

FIG. 26 is a schematic diagram illustrating the process steps associated with the subscriber locking the account.

FIG. 27 is a schematic diagram illustrating the process steps associated with the subscriber unlocking the account.

FIG. 28 is a schematic diagram illustrating the process steps associated with the subscriber requesting for information from the system.

FIG. 29 is a schematic diagram illustrating the process steps associated with the subscriber requesting help from the system.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The service allows all prepaid and postpaid subscribers to pay for government contributions particularly for members of the Social Security System, Philippine

Health Insurance Corporation and Home Development Mutual Fund (Pag-IBIG

Fund). The service aims to provide a convenient, seamless, secure, and accessible alternative payment channel using the subscriber load sourced using a separate wallet other than the airtime wallet. A telecommunications provider can partner with a bank as a settlement entity for credit to individual payee government accounts for the invention to work.

This would provide a convenient, seamless, secure, and accessible alternative payment channel, with existing retailers and stores for a telecommunications provider being able to provide this service. The many subscribers that can potentially use this payment facility will benefit accordingly, especially with the lack of additional registration needed. Even subscribers from other telecommunications providers can also use this payment service.

For customers of this facility, they will not be required to remember their account numbers everytime, all is required is a one-time registration via SMS to the telecommunications provider. The telecommunications provider can also provide a 24-hour balance inquiry system, a 24-hour payment window time, as well as an ability to view, download or print collection receipt. The system would be able to determine whether a subscriber has a valid account and would respond accordingly.

For further ease of concept, the system can also recognise when a single user with matching address is registered with multiple account, for example for all three accounts in the Philippines: PhilHealth, SSS or Pag-IBIG Fund. By applying transitivity across the various databases, especially using matching details like addresses and Smartmin, the subscriber is recognised the same person and the system allows the subscriber to use all three services uses the same identification. Such processes can be done by the system in the background without the subscriber being aware of us, with further prompting triggering actions for the subscriber to take or approve accordingly. With such a system in place, a subscriber can do anonymous purchases on the public transport system or store purchases. The backend reconciliation system goes through the various databases and after removing inconsistent address, the fully matched records become certified identities, allowing them to easier access to the benefits of all the databases. By using this as the basis for better knowing the subscribers, this can also be used for data mining, advertisement matching or even monitoring purposes.

The following procedures are details of an exemplary of a system using the above mentioned method in various procedures:

Registration

During this process, the basic information and account details of the subscriber is captured. This can be done via SMS, for example, in a <Keyword> <First

Name> <Middle Name>: <Last Name> <Date of Birth MMDDYY> format. Thus a user may input “Reg Sherwin Anana Diamante 082180" using SMS into his mobile device and send it off to the system.

The system would then either inform the subscriber that the notification was successful or not. In the case of a successful notification, the system informs the subscriber that the registration is complete and that the wallet can be loaded (or reloaded) at any of the authorised telecommunication provider's many retailers. For example, the system may reply:

MMMDD HH:MM

Registration Complete! You may now load your BayadlLoad wallet from any SMART retailer.

T&C by reloading your reload wallet you agree to the terms and condition in this website: www.bayadload.com

REF#

MMMDD HH:MM

Step 2: Pls register your Billing Account Number by sending “Acct PIF <Acct#> PHL < Acct#> SSS < Acct#>" for Pagibig, PhilHealth and SSS

Sample 1: Acct PIF 12345678901 PHL PIF 12345678901 SSS PIF 12345678901 or

You can also register 1 account only by sending “Acct PIF < Acct#>"

Sample 2: Acct PIF 12345678901

REF# in the case of a declined notification, the system would prompt the user to retry based on the errors in the SMS, for example, for invalid syntax, the system may reply:

MMMDD HH:MM

Pls retry. Send msg below to 8888 ‘Reg <firstName> <MiddleName> <Lastname> <Date of Birth

MMDDYY>.

Sample: Reg Sherwin Anana Diamante 082180

REF#12345678

In the case of an invalid keyword, the system may reply:

MMMDD HH:MM :

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should the account be unavailable for some reason, the system may reply:

BayadLoad account cannot be edited:

MMMDD HH:MM

BayadlLoad account cannot be edited.

REF#<12345678901> 3131 access code

The subscriber can instruct the system to register the billing information by using the syntax <Keyword> <Biller Code> <Account Number>. Thus a user may send the following via SMS, “Acct PHL 2394823498". The system may then inform the subscriber of the successful notification by sending

MMMDD HH:MM

You have the option to lock this account by sending “Lock <4 Digit PIN>” to 8888. After a successful lock, you can unlock this account anytime by sending “Unlock <4 Digit PIN> to 8888

REF#<12345678901>

Alternatively, the system may decline the notification if the syntax is incorrect:

MMMDD HH:MM

Please send “Acct <Biller Code> <Acct#> to 8888.

Valid BillerCodes are “PHL” for PhilHealth, “PIF” for Pag-IBIG fund and ‘SSS’ for SSS. REF#<12345678901> : orif the account is locked:

MMMDD HH:MM

This account is currently locked. Please Unlock first. 9 J

REF#12345678 - or if the subscriber has no basic registration:

MMMDD HH:MM

MIN is not yet registered for BayadLoad. Pls send the syntax below to 8888 ‘Reg <firstName> <MiddleName> <Lastname> <Date of Birth

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901> or if there is an invalid command or keyword:

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should the subscriber wish to update basic information or account details, the registration procedure can be repeated. In some cases, such updates are only allowed if the account has a balance of 0 and no transaction has been executed previously. The Process to handle updates when there is a balance will be defined separately.

The subscriber would have to reload money into the account or e-wallet and J one of the methods is to go through a retailer. The amount to be reloaded would depend on the retailer and this can be any amount. The retailer would send an

SMS to the system using the syntax <Keyword> <targetMIN> <amount>. For example, “Load 09192700045 300".

The system would then notify both the retailer and subscriber accordingly if the transaction was successful. For example, the system would send the following to the retailer:

MMMDD HH:MM

You have successfully loaded P200 to Sherwin's BayadlLoad Wallet via 09192700045.

New Load wallet balance is P195.

REF#<123456789>

And send the following to the subscriber:

MMMDD HH:MM

P200 was successfully loaded to your BayadLoad Wallet.

New BayadLoad wallet balance is P400.

Before paying please remember to load 12% more on top of the payment premium amount to avoid inconvenience.

REF#<123456789>

In the case of a declined notification, the system can send the following message, depending on the nature of the message. For insufficient balance, the system would send:

MMMDD HH:MM

Your load wallet account has no sufficient balance to fulfill this transaction. Your available balance is only P90.

REF#<12345678901>

For maximum aggregate limit reached, the system may send:

MMMDD HH:MM

Sorry the maximum target limit of target BayadlLoad wallet has been reached. Your available balance is only P10,000.

REF#<12345678901>

Forinvalid syntax, the system may send: !

MMMDD HH:MM

Please send “Pay <MIN> <billerCode> <amount>" to 8888.

Valid BillerCodes are “PHL” for PhilHealth, “PIF” for Pag-IBIG fund and ‘SSS’ for SSS.

REF#<12345678901>

If the subscriber is not yet registered with the system, the following message can be sent:

MMMDD HH:MM

MIN is not yet registered for BayadlLoad. Pls send the syntax below to 8888 ‘Reg <firstName> <MiddleName> <Lastname> <Date of Birth

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin -Anana Diamante 082180 [email protected]

REF#<12345678901>

In the case of an invalid keyword, the following message can be sent:

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should the subscriber wish to check the balance of the account, this can be done via SMS by a keyword, <Keyword>. For example, by sending “Bal” to the system, the system would then reply in the case of a successful notification:

MMMDD HH:MM

The available balance of your BayadLoad wallet is P200.

REF#<123456789>

And the following for a declined notification:

BayadLoad Account is locked:

MMMDD HH:MM

This is currently locked. Please Unlock first,

REF#12345678

And if the subscriber is not registered with the system, the following message may be sent:

MMMDD HH:MM

MIN is not yet registered for BayadLoad. Pls send the syntax below to 8888 ‘Reg <firstName> <MiddleName> <lLastname> <Date of Birth

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901>

As usual, in the case of an invalid keyword, the system sends the following message:

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

As an employee, the subscriber may wish to pay either one of the healthcare system, and this can be easily done by sending an SMS to the system using the syntax <Keyword> <Biller Code> <Amount>, example “Pay SSS 200".

In the case of a successful notification, the system informs the subscriber as such:

MMMDD HH:MM

You have successfully paid P200 to SSS account 123456789 of Sherwin

Diamante. P24 convenience fee was deducted to your BayadlLoad

Wallet.

Your new BayadlLoad wallet balance is P76. :

REF#<123456789>

At the early stage of the system, multiple payments using a single SMS may not be supported yet, although this can be easily implementable at a later stage by scaling up the various systems needed.

In the case of a declined notification, the system informs the subscriber accordingly: For a locked account:

MMMDD HH:MM

This is currently locked. Please Unlock first.

REF#12345678

For an insufficient balance:

MMMDD HH:MM

Your BayadLoad wallet account has no sufficient balance.

Please remember to load 12% more on top of the payment premium amount to avoid inconvenience.

REF#<12345678901>

For an invalid syntax:

MMMDD HH:MM

Please send “Pay <billerCode> <amount>" to 8888.

Valid BillerCodes are PHL for PhilHealth, PIF for Pag-IBIG fund and SSS for SSS.

REF#<12345678901>

And if the subscriber is not registered with the system:

MMMDD HH:MM

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901> :

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should someone other than the subscriber with to pay into the account, that person would have to register with the system first. Then, the following syntax can be used: <Keyword> <biller code> <Amount> <MIN of Member Employee>. For example, “Pay SSS 200 09192700045".

In the case of a successful notification, the system responds to the employee and payor accordingly as follows:

To Employee:

MMMDD HH:MM

Lito Villanueva paid P200 to your SSS with acct#123456789.

REF#<123456789>

To Payor:

MMMDD HH:MM

You have successfully paid P200 to SSS account 123456789 of Sherwin

Diamante. P24 convenience fee was deducted to your BayadlLoad

Wallet. : ]

Your new BayadLoad wallet balance is P76.

REF#<123456789>

MMMDD HH:MM

This is currently locked. Please Unlock first.

REF#12345678 ]

For an insufficient balance: i

MMMDD HH:MM

Your BayadLoad wallet account has no sufficient balance. ]

Please remember to load 12% more on top of the payment premium J amount to avoid inconvenience.

REF#<12345678901>

{ al

For an invalid syntax:

MMMDD HH:MM

Please send “Pay <billerCode> <amount>" to 8888.

REF#<12345678901>

And if the subscriber is not registered with the system:

MMMDD HH:MM

MIN is not yet registered for BayadlLoad. Pls send the syntax below to 8888 “Reg <firstName> <MiddleName> <Lastname> <Date of Birth

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901>

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

The subscriber is also able to lock the account within the system by using SMS, using the syntax <Keyword> <PIN>, for example “Lock 1234".

If the notification is successful, the system replies to the subscriber: :

MMMDD HH:MM

Your account is locked. Please send “Unlock <PIN>" to unlock this account

REF#<123456789>

By locking the account, the subscriber is no longer able to pay or find out the j balance of the account, or even edit details of the account. Instead, the subscriber can only reload the account through a retailer, or accept payment from a third party payor to the account. There may be also instances where the subscriber or the system can specify that the account be locked after a certain number of transactions. The system may send the following message:

MMMDD HH:MM

Your account is locked. Please send “Unlock <PIN>" to unlock this account

REF#<123456789>

MMMDD HH:MM

This is currently locked. Please Unlock first.

REF#12345678

For an insufficient balance:

MMMDD HH:MM

Your BayadLoad wallet account has no sufficient balance.

REF#<12345678901>

For an invalid syntax:

MMMDD HH:MM

Please send “Pay <billerCode> <amount>" to 8888.

REF#<12345678901>

And if the subscriber is not registered with the system:

MMMDD HH:MM

MMDDYY> <emailAdd ~ Optional>.

Co

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901>

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should the account be already locked, the system sends: ~ MMMDD HH:MM

Your account is already locked.

REF#<12345678901>

The subscriber can unlock the account to continue using it. This can be done using the same syntax <Keyword> <PIN>, for example “Unlock 1234".

If this occurs during a transaction where the account is locked, the system may send:

MMMDD HH:MM

Your account is locked. Please send “Unlock <PIN>" to unlock this account

REF#<123456789>

In the case of a declined notification, the system informs the subscriber accordingly:

For an account that is locked:

MMMDD HH:MM

This is currently locked. Please Unlock first.

REF#12345678

For an invalid syntax:

MMMDD HH:MM

=

Please send “Lock <4 digit PIN> to 8888".

REF#<12345678901>

And if the subscriber is not registered with the system:

MMMDD HH:MM

MMDDYY> <emailAdd — Optional>.

Sample: Reg Sherwin Anana Diamante 082180 [email protected]

REF#<12345678901>

MMMDD HH:MM

Please see list of valid keywords below:

Reg, Acct, Lock, Unlock, Info, Bal, Pay, History,

Help, Help Reg, Help Acct, Help Lock, Help Pay, Help History

REF#<12345678901>

Should the account be already unlocked, the system sends:

MMMDD HH:MM

Your account is already unlocked.

REF#<12345678901>

With reference to Fig 1 there is illustrated an overview of system functionality for the provision of credit to subscribers of the participating communications networks according to one embodiment of the present invention. As shown two networks, network A 101 and network B 102 allow subscribers of network A 103 to roam (roaming subscriber 105) within network B and vice versa (i.e. roaming subscriber 106 in network A).

As is the case with most current pre-paid credit paradigms, subscribers 103, 104 are free to purchase additional airtime from their local retailers 107, 108.

Unlike standard pre-paid arrangements, however, the exemplified system in this instance allows for roaming subscribers 105, 106 to purchase additional credit from retailers in the current host network 101, 102. The purchasing of credit outside a subscriber's local network 101, 102 is discussed in greater detail below.

In addition to allowing a subscriber to purchase additional credit outside their local network, the system also allows for the transfer of credit between various subscribers. For example if a subscriber purchases a pre-paid service on network A and the subscriber maintains a post-paid service on network B, any leftover airtime on the pre-paid service could be credited back to the subscribers post-paid service via a suitable transfer process 112 e.g. peer to peer .

To permit subscribers to purchase airtime from their local network via the current host network the system utilises a central credit facility. An example of one possible arrangement of a centralised settlement facility 200 is illustrated in

Fig 2. As shown networks A 101, and B 102 are coupled to the settlement facility 200 to permit the transfer of funds associated with a credit request to the

Transfer Server (TS) 201 of the settlement facility 200.

The (TS) 201 in this instance is an application running on at least one server 202 disposed within the settlement facility 200. The TS 201 is responsible for

Co co-ordinating the purchasing of airtime by various subscribers, retailers and dealers across both networks. As shown the TS 201 maintains an account for each of the registered users 203;, 203,,..., 203n. Each account contains a settling account 204 information, configuration data 205 and transaction logs 206.

The settling accounts 204 may include information relating to the amount of available credit for a given user. Indeed for most individual users the settling account simply contains the amount of available credit. However in the case of dealers and retailers the settling account 204 can contain additional information such as commissions and sales and others as may be deemed pertinent (discussed in greater detail below).

The configuration data 205 for each user can include information relating to the network configuration for the particular user, rate card and commissioning scheme etc. The transaction log 206 maintains a log of all transactions for reporting and settlement (system should be able to determine the breakdown or allocation of the transaction amount into sales and commissions)

As illustrated various users (subscribers 103,105(as seen in Fig. 2) dealers 601a, 601b (not shown) and retailers 107,108) can access the settlement facility 200 in a variety of manners. For instance a user could access the settlement facility via web portal an ATM, a POS or a kiosk 207. Alternatively the user could access the settlement facility 200 via phone 208 keyword, menu,

SMS or USSD command. The settlement facility 200 may be coupled to the backend billing systems 209, 210 of network A and network B respectively. On receiving a request for additional credit the settlement facility 200 passes the request to the TS 201 which then processes the request. The appropriate credit j value in the user's settling account is adjusted accordingly and the user is billed via his/her home network billing system 209, 210.

As shown in Fig 2 the settlement facility has access to foreign currency facilities 211. This enables the system to convert the requested amount of credit to a common base rate before forwarding the requested credit value to TS 201 for processing. The manner in which the credit request is processed is discussed in greater detail below.

Fig 3 depicts one example of how the settlement facility 200 can be utilised to effect airtime recharge for a roaming subscribers 105,106 in a host network. As shown the roaming subscriber 105 purchases additional airtime from a retailer 108 with host network 102. The retailer 108 then forwards the purchase request to the settlement facility 200.

In this particular example, the roaming subscriber 105 requests $HK40 in additional credit. This value is then forwarded to the settlement facility 200. The settlement facility then converts the cash value to an e-value via an Electronic

Value Transaction (EVT). In the present example, the EVT involves the conversion of the $HK40 to an equivalent US dollar amount. The US dollar amount can then be equated to an equivalent load denomination offered on the subscriber's home network by the TS 201. The load denominations offered are determined by the relevant networks party to the partnering agreement. These values are stored in a standard rate card. An example of the rate card is shown in Fig 4. As shown, the rate card lists the minimum load denominations in USD and the applicable currencies of the member networks. The minimum denominations are set in accordance with the Standard Retail Price (SRP) for airtime (in local currency) of each of the participating networks. The SRP is ] comprised of the Rate Card Cost (Electronic Value equivalent of the airtime being sold, which is inclusive of any applicable tax such as VAT) and the Mark- up (which serves as the Retailer's earnings).

Once the TS 201 has determined the load denomination, it proceeds to debit the retailer's settling account 301 in the amount of credit purchased by the : subscriber 105 and credits the user's home network settling account 302 the amount of credit purchased in the home networks local currency based on the values contained in the rate card. The home network 101 then updates the roaming subscriber's airtime credit 303 based on the received funds and sends back an SMS acknowledgement to the retailer and subscriber 304 of the successful completion of the transaction. This acknowledgement could also be in another form or media, such as an email.

A more detailed view of the process of the inter-network purchasing of additional credit is shown in Fig 5. Here the subscriber buys airtime from a host network retailer 108; the retailer 108 then sends a load airtime transaction request (step 501) to the TS 201. On receipt of the request the TS 201 performs a validation 502 to determine if the retailer 108 is a validly registered user. At this stage the TS 201 also determines whether the transfer is a domestic or international transfer and whether the retailer is transacting within the host network's country. Once the validation step is complete, the TS 201 then proceeds to retrieve the available denominations and their Standard Retail

Price (step 503). The retrieved denomination is calculated by the TS 201 converting the requested denomination for load into the conversion rate based on the rate card table (see Fig 4) plus any local taxes applicable. The TS 201 then advises the retailer 108 of the available denominations (step 504). The retailer then selects the appropriate denomination and sends a confirmation (step 505) to the TS 201.

On receipt of the confirmation, the TS 201 then validates the request (step 506).

If the request is valid, the system then computes the converted cost (step 507) (converted cost = denomination cost x conversion rate). The TS 201 then reviews the retailer's settling account to ensure they have sufficient credit to enable the transaction (step 508). If there is sufficient credit to enable the transaction, the TS 201 proceeds to debit the retailer's settling account (step 509). The TS 201 then sends the reload request (step 510) to the subscriber's home network billing system 210. The billing system 210 then credits the subscriber's airtime allocation with the received load denomination (step 511) and sends a response back to the TS 201 signalling the successful update (step ]

512). A notification is then sent to the subscriber (step 513) and the retailer (step 514) advising them of successful completion of the reload operation.

If there is no sufficient credit to enable the transaction, the TS 201 will then check if there is a credit provider with whom the retailer has an existing credit agreement. If there is a credit provider with whom the retailer has an existing credit agreement, then the system checks for the amount of credit available for the retailer. If the amount of credit available for the retailer from the credit provider is sufficient to cover the requested transaction, then the system debits this amount from the settlement account of the credit provider and credits the same to the settlement account of the retailer.

If there is no credit provider with whom the retailer has an existing credit agreement, the retailer can then obtain the credit necessary to enable the 16 transaction from a dealer. The settlement account of the dealer is checked if it would be sufficient to provide the credits requested by the retailer. If the settlement account of the dealer is sufficient to provide the credits requested by the retailer, the amount corresponding to the airtime required by the subscriber is debited from the settlement account of the dealer and credited to the settlement account of the retailer.

The TS 201 then proceeds to debit the retailer's settlement account (step 509).

The TS 201 sends the reload request (step 510) to the subscriber's home network billing system 210. The billing system 210 then credits the subscriber's airtime with the received load denomination (step 511) and sends a response back to the TS 201 signalling the successful update (step 512). A notification is then sent to the subscriber (step 513), the retailer (step 514), and the credit provider or the dealer, as the case may be, advising them of successful completion of the reload operation.

If the settlement account of the dealer is not sufficient to provide the credits requested by the retailer, the system then checks if there is a credit provider

. with whom the dealer has an existing credit agreement. If there is a credit provider with whom the dealer has an existing credit agreement, then the system checks for the amount of credit available for the dealer. If the amount of credit available for the dealer from the credit provider is sufficient to cover the requested transaction, then the system debits this amount from the settlement account of the credit provider and credits the same to the settlement account of the dealer. The same amount is then debited from the settlement account of the dealer, and in turn credited to the settlement account of the retailer.

The TS 201 then proceeds to debit the retailer's settlement account (step 509).

The TS 201 sends the reload request (step 510) to the subscriber's home network billing system 210. The billing system 210 then credits the subscriber's airtime with the received load denomination (step 511) and sends a response back to the TS 201 signalling the successful update (step 512). A notification is then sent to the subscriber (step 513), the retailer, the credit provider and/or the dealer (step 514), as the case may be, advising them of successful completion of the reload operation.

If the available credit in the settlement account of the retailer and/or the dealer is not sufficient to enable the transaction and there is no credit provider as provided for in the foregoing, the TS 201 then declines the transaction and notifies the retailer of such fact and the reason for the denial.

Once the reload is effected, the TS 201 then proceeds to compute the commissions for the dealer through which the retailer purchases credit and the commission for the host network (step 515). The dealer commission is calculated on the basis of the converted cost multiplied by the agreed : commission rate and dealer's share. Likewise the host network commission is calculated on the basis of the converted cost multiplied by the agreed ] commission rate and host network's share. Once the commissions are calculated the TS 201 proceeds to credit the dealer's and host network's settling accounts (step 516) with the appropriate amounts. Once this is complete, the

:

TS 201 then proceeds to calculate the sales amount for the subscriber's home network (step 517) (home network sales = denomination cost x conversion rate — agent network and dealer commissions). The sales value is then credited to the home networks settling account (step 518).

As can be seen from the above discussion, in order to effect settling of the requested credit value, the participating dealers, retailers of the host networks are required to have a level of available credit within their settling accounts to permit sale and transfer of airtime to subscribers. The system, however, also provides for making credit available through credit providers having existing credit arrangements with the dealers and/or the retailers.

Typically the dealers purchase credit from their local network provider which inturn is provided with an amount of credit as part of their airtime sales commitment upon entry into the partnering agreement. Fig 6 shows this hierarchy of network providers, dealers and retailers. Under the present system, the network providers 101,102 have the ability to enrol dealers 601a, 601b onto the system, modify the dealer profile and remove dealer from the system. Dealers 601a, 601b are able to enrol a number of retailers 107,108 onto the system. Dealers 601a, 601b sell credit to the retailers as part of the enrolment process.

Retailers 107, 108 earn money based on the percentage mark up applied to the sale of credit to subscribers. For each sale, the retailer makes the enrolling dealer 601a, 601b earns a percentage commission. Network providers 101, 102 then earn a percentage commission on all sales made by dealers to retailers and retailers to subscribers.

Commissions may then be en-cashed by the dealers 601a, 601b and network providers 101, 102. There are a number of commission payment models that may be utilised. For example, commissions may paid back on a just in time basis. The commission scheme utilised to effect transfer is determined by the network providers on entry into the partnering agreement.

Fig 7 illustrates the process of crediting a network provider's electronic settling account. Here the provider gives an airtime sales commitment as agreed to in the partnering agreement between the participating networks. The actual value transmitted by the network provider 101,102 is the agreed sales commitment plus the service fee for utilising the settlement facility (preferably in US Dollars).

For example if the network provider agrees to a $100, 000 sales commitments and the settlement facility has a 2% commission, the transfer request would in fact be for $102, 000. The settlement facility then converts the received transfer request to a US dollar amount and deducts the required service fee before forwarding the transfer request (step 702) to the TS 201. The TS 201 then converts the received value back to the local currency of the enrolling network provider based on the exchange rate at the date of the original transfer request (step 703). The TS 201 then credits the network provider's settling account with a load denomination equivalent to the received value (step 704) and then sends a notification back to the network provider (step 705) of the deposit of the load credit.

Fig 8 depicts the transfer of credit between the network provider and an authorised dealer 601a, 601b for the network. Here the dealer 601a, 601b purchases a set amount of credit (step 801) from the network provider for later resale to the dealer's retail network. The network provider then sends a transfer request (step 802) to the TS 201. The TS 201 then performs a validation on the sending and receiving parties (i.e. network provider and dealer making purchase)- step 803. If both parties are validly registered the with the system then the TS 201 proceeds to check if the network provider's settling account has sufficient balance to deliver the requested credit to the dealer (step 804). If the balance of the network provider's account has sufficient credit then the TS 201 debits the network provider's account (step 805) and credits the dealers account with the requested amount of credit (step 806). The TS 201 then sends

. an SMS, MMS or flash notification message via USSD or STK to both 601a, 601b of the successful completion of the transfer request (steps 807a, 807b respectively). Such message may also be an email or any notification in another form or medium. Similarly, Fig. 8 can also depict the transfer of credit between the network provider and a credit provider, where the credit provider is treated as an authorised dealer

Moreover, Fig. 8 may likewise depict the transfer of credit between the credit provider and a dealer 601a, 601b. This contemplates an instance when the dealer does not have sufficient settlement credits required to consummate a credit load request from its retailers. Here, the dealer 601a, 601b obtains a certain amount of credit (step 801) from the credit provider for subsequent resale to the dealer's retail network. The credit provider then sends a transfer request (step 802) to the TS 201. The TS 201 performs validation on the sending and receiving parties (step 803). If both parties are validly registered with the system, then the TS 201 proceed to check if the credit provider's settlement account has sufficient balance to deliver the requested credit to the dealer (step 804). If the balance of the credit provider's account has sufficient credit then the TS 201 debits the credit provider's account (step 805) and credits the dealer's account with the requested amount of credit (step 806).

Otherwise, the transaction is declined. Due notification is then sent to the parties.

A similar process is employed for the transfer of credit between the dealer 601a, 601b and retailer 107, 108, as shown in Fig 9. The retailer 107, 108 purchases credit from their specified dealer 601a, 601b. The dealer 601a, 601b initiates a transfer request (step 901) to the TS 201. The TS 201 then proceeds to validate the request (step 902). During the validation the TS 201 firstly checks if the target account and transfer amount is valid. The TS 201 then proceeds to check if the target (retailer) account is enrolled to the source (dealer) account and if the source account has enough credit. Once it is established that the proposed transaction is valid, the TS 201 proceeds to debit the dealer's settling account (step 903) and credit the retailers settling account (step 904). Once the transaction is complete, the TS 201 sends a notification to the retailer 107, 108 (step 905) and to the dealers 601a, 601b (step 906). Another way to look at Fig. 9 is that in the case of transfer of credit between a credit provider 601a, 601b and retailer 107, 108. Instead of outright purchase of credit, however, payment from retailer 107, 108 to the credit provider 601a, 601b may be deferred in such terms as may have been previously agreed upon by both parties.

It should be noted that the transactions between the network provider, dealer, retailer and/or credit provider are performed directly with the TS 201 and do not require the settlement facility to perform a conversion to US dollars. As it will no doubt be appreciated by those skilled in that art as the TS 201 stores the credit values in the home currency of the network then there is no need to perform a currency conversion as all parties in the transactions illustrated in Figs 7 to 9 utilise the same currency.

As briefly mentioned above, the TS 201 also maintains a commission and sales accounts as part of the general settling account, which store the commissions conferred and revenues generated by sales to the network service providers, dealers and retailers.

The commissions account is generally only applicable to network providers and dealers as retailers earn revenue through the mark-up they place over the counter sale of the load credit. The values stored in the commissioning accounts for various dealers can be en-cashed at a later date. For example, the network provider may be provided with the ability to deplete the dealer's electronic settlings account for commissions in exchange for cash or load credit.

In such instances the dealer goes to an encashment centre designated by the network provider and requests for redemption of commissions earned. The dealer is presented with the option of taking the commissions in the form of cash or additional load credit. Once the dealer selects the desired form of redemption the network provider initiates the transfer by submitting the dealer's request to the TS 201, which then checks the dealer's commission account and collates the total commissions payable. The TS 201 then proceeds to check if the network provider has sufficient credit in their settling account to cover the commission payable and if so debits the networks provider's account and transfers the appropriate monetary value to an account of the dealer's choice.

The TS 201 then proceeds to clear the commissions account of the dealer.

If dealer opts to redeem the commissions in the form of credit, the TS 201 checks the network provider's account to determine whether there is enough credit to complete the transaction. The TS 201 then proceeds to debit the dealer's commissions account and the network service provider's settling account of the corresponding value of load credit, before finally crediting the dealer's settling account with the credit value corresponding to the commission earned by the dealer. The TS 201 then notifies both parties of the successful completion of the transaction.

The en-cashing of commissions at the network service provider level differs slightly to that of the en-cashing scheme between dealer and network service provider. In the case of the network service provider, the settlement facility performs a sweep of all electronic settling accounts for commissions owed to a particular network service provider. The settlement facility then collates these commissions and deposits them into the relevant network provider's bank account. A similar en-cashing process to that discussed in relation to the redemption of commissions owed to a particular network is used to redeem the sales made by a particular network. In this case the settlement facility sweeps the sales account of the relevant network and deposits the appropriate amount into the relevant network provider's bank account.

In addition to the above, the system also provides a number of auxiliary ] functions to the network providers, dealers and retailers are summarised in table 1 below:

Inquire Balance: This transaction allows the Agent Network to view the current balance

Load Credit of its Electronic Settling Account for Credit Load.

Transaction Flow + Agent Network initiates (via mobile or web) Balance Inquiry transaction for Credit Load and submits transaction. eo UTS processes request. o Agent Network receives notification containing balance information.

Commissions of its Electronic Settling Account for Commissions.

Transaction Flow o Agent Network initiates (via mobile or web) Balance Inquiry transaction for Commissions and submits transaction. e UTS processes request. s Agent Network receives notification containing balance information.

Inquire Balance: This transaction allows the Home Network to view the current balance

Sales of its Electronic Settling Account for Sales.

Transaction Flow . ¢ Home Network initiates (via mobile or web) Balance Inquiry transaction for Sales and submits transaction. e UTS processes request.

Home Network receives notification containing balance information.

Inquire Balance: This transaction allows the Dealer to view the current balance of its o Follows the same flow as inquire balance for network provider set out above.

Inquire Balance: This transaction allows the Dealer to view the current balance of its

Commissions Electronic Settling Account for Commissions. * Follows the same flow as inquire balance for network provider set out above.

Acct. Management: | This transaction allows the Dealer to define a PIN that can be used to

Set PIN protect or ‘Lock’ the Credit Load Menu. This does not apply to web- based or USSD-based transactions.

Transaction Flow » Dealer selects Set PIN transaction on the Credit Load Menu. s Inputs desired PIN, confirms PIN and submits. e UTS processes request. : » Dealer receives a notification for the successful transaction.

Acct. Management: | This transaction allows the Dealer to change the current PIN. ]

Change PIN Transaction Flow + Dealer selects Change PIN transaction on the Credit Load Menu. * Inputs current PIN, new PIN, confirms new PIN and submits. 1 ¢ UTS processes request. » Dealer receives a notification for the successful transaction.

Acct. Management: | This transaction allows the Dealer to Lock or Unlock the Credit Load

Lock/Unlock Menu. ]

Functionalities 1 = Lock hides all options of the Credit Load Menu (e.g. Transfer, ;

Inquire Balance), except Unlock, Change PIN and Call Hotline ] * Unlock exposes all options of the Credit Load Menu (when E previously Locked). PIN entry will be required for this transaction . 31 i

1 prerequisite: Dealer has performed Set PIN).

Acct. Management: | This transaction allows the Dealer to initiate a voice call to the

Call Hotline assigned after sales group upon selecting the Call Hotline option in the Credit Load Menu. inquire Balance: This transaction allows the Retailer to view the current balance of its

Credit Electronic Settling Account for Credit Load. » Follows the same flow and logic as inquire balance for network provider set out above.

Acct. Management: | This transaction allows the Retailer to define a PIN that can be used

Set PIN to protect or ‘Lock’ the Credit Load Menu. This does not apply to web- based or USSD-based transactions. e Follows the same flow and logic as per dealer acct management set pin set out above.

Acct. Management: | This transaction allows the Retailer to change the current PIN.

Change PIN + Follows the same flow and logic as set out in dealer change pin set out above.

Acct. Management: | This transaction allows the Retailer to Lock or Unlock the Credit Load

Lock/Unlock Menu.

Has the same functionalities as described in dealer lock/unlock set out above.

Acct. Management: | This transaction allows the Retailer to initiate a voice call to the ]

Call Hotline assigned after sales group upon selecting the Call Hotline option in f the Credit Load Menu.

Table 1: Summary Auxiliary Functions for Account Management on TS

Fig 10 A depicts one possible configuration of a user login process according to one embodiment of the present invention. To initiate login the user enters their assigned user ID and password (step 1001). The system then determines if the user name and password are valid (step 1002). If so the system then proceeds to check if this is the user first login (step 1003). If it is the users first login, the system then initiates a change password process which is described in greater detail below (see Fig 10B). 1

If the user name and password are valid and have been utilised for a previous login, the system proceeds to verify the status of the user's account (step 1005).

If the user's account has been blocked, the system advises the user that the 1 account is not valid and returns to the initial login screen (step 1006). If the user's account status is valid, the system then proceeds to verify the users access level (step 1007) and then open the appropriate home screen with the relevant user options (as set out in table 1 above). ]

eo »

Fig 10B depicts one possible implementation of the change password function.

The process is initiated (step 1009) by the user selecting the change password word button. The system then requests the user to verify his/her current password, or in the case where it is initial login discussed above the system verifies whether the assigned password is valid (step 1010). If the password is invalid, the system notifies the user and returns to the main user screen (step 1011).

In the event that the password is valid the system then requests that the user enter the new password (step 1012). The system then requests the user to re- enter the new password for verification (step 1013). Once verified the system updates the password (step 1014), before returning the user to the main user screen (step 1015).

It will be appreciated by those skilled in the art that while the above system has been described in relation to the transfer of credit between networks that the system is equally applicable to the provision of credit within a single network (i.e. wherein the host and home network are the same).

The system also provides subscribers with the ability to transfer airtime charged to a subscriber's post-paid account to a pre-paid account of their choosing or vice versa, via the use of a peer to peer operation 112. Such a transfer scheme is also applicable for the transfer of airtime from one pre-paid subscriber to another pre-paid subscriber. An example of the peer to peer transfer 112 of airtime between subscribers is shown in Fig 11.

In this example, a subscriber of network B wishes to transfer airtime to a subscriber in network A. The load airtime transaction is initiated through SMS,

MMS, WAP, or by sending a keyword or USSD command. Once the request is initiated, the sending party 1101 inputs the desired recipient's 1104 mobile i number and airtime denomination. The request is then sent to the TS 201 for processing. The TS 201 then validates the initiating party's and recipient's mobile numbers to determine if they are registered users of the system. If so, the TS 201 debits the initiating party's home network billing system and then credits the airtime to the recipient's home billing system. Both the initiating party and the recipient are then notified of the successful transfer of airtime between the subscribers.

Fig 12 depicts one example of a series of user screens that may be initiated on a subscriber's handset to effect transfer of airtime. As shown, the user accesses the transfer procedure by selecting it from the user option menu (step 1201). The user is then required to enter the mobile number they wish to transfer airtime to (step 1202). Once the recipient's mobile number has been entered the initiating party is then required to enter the desired transfer amount in the recipient's local currency (step 1203). To confirm the transfer of the requested amount the initiating party is then required to enter a pre-assigned personal identification number (PIN) (step 1204). Once the transfer is effected, the initiating subscriber is then advised of the transfer and the amount billed to their home account (step 1205).

A more detailed view of the transfer process is depicted in Fig 13 as above, where the initiating party 1101 sends a transfer request 1301 to the TS 201, which then proceeds to validate the request (step 1302). During the validation the TS determines the type of transfer requested e.g. post-paid to prepaid etc.

Once the TS 201 has validated the request it proceeds to retrieve the available denominations (step 1303) and convert the retrieved denominations to the host network's currency (step 1304). The TS 201 then sends a reply (step 1305) to the initiating party 1101 advising of the available denominations and the prices associated with each. The initiating party 1101 then selects the desired denomination and confirms the transfer (step 1306).

On receipt of the confirmation the TS 201 then proceeds to calculate a converted value (step 1307 selected denomination x conversion rate). A request is then sent (step 1308 which includes the initiating party's mobile number and the converted value) to the host network billing system 209 which then processes the request (step 1309) and sends a response (step 1310) to the TS 201. The TS 201 then sends a request (step 1311 which includes the recipient's mobile number and the desired denomination) to the recipient's home network billing system 210, which processes the request (step 1312) and sends a response to the TS 201 (step 1313). The TS 201 then sends notifications to the initiating party (step 1314) and the recipient (step 1315) advising of the successful completion of the transaction.

Once the TS 201 has notified the initiating and receiving parties, it then computes the converted cost associated with the transaction (step 1316) (denomination cost x conversion rate). The TS 201 then proceeds to determine if the host network has sufficient credit (step 1317) and if so the TS 201 proceeds to deduct the converted cost from the host networks settling account (step 1318). The system then proceeds to calculate the commissions due to the host network (step 1319) (denomination cost x conversion cost x commission rate). The calculated commission is then credited to the host networks settling account (step 1320). Finally the TS 201 calculates the value of sales due to the home network 210 (step 1321) (denomination cost x conversion rate — commissions) and credits these to the home networks settling account (step 1322).

Fig 14 illustrates a further possible application of the credit provisioning system according to one embodiment of the present invention. Here the system is utilised to purchase various third party goods and services. As shown, a consumer 1403 (e.g. a mobile subscriber, small retail store etc) can access a number of products and services offered by a number of manufacturers 1401 and third party retailers (lead stores) 1402. In this particular example, the credit is exchanged for goods and services as opposed to airtime per the above examples. Consequently the TS 201 not only maintains settling accounts for each user but it is also configured to maintain an inventory of items for sale in : the case of manufacturers 1401, the lead stores 1402 and goods purchased in the case of customers 1403. Accordingly the TS 201 manages the purchasing and settlement. In addition to this the TS 201 is also tied to one or more logistic providers 1405. This enables the system to provide inventory tracking and distribution services between the manufacturers 1401, lead stores 1402 and consumers 1403.

Fig 15 depicts one example of how a purchase may be affected via the TS 201.

As shown a consumer 1403 is free to view the various goods and service on offer from manufacturers 1401 and retailers 1402 via an access point 1503, which in this instance is either a web portal 1501 or mobile network 1502.

When the consumer 1403 identifies the item he/she wishes to purchase, he/she initiates a purchasing request to the TS 201. The purchasing request contains the store identification, the item code and the quantity. The system then checks the stores inventory list 1405 contained in their member account to ensure that the item is in stock and if so the system places a purchase order which is saved to the transaction logs of the store and consumer 1403 making the purchase. The store is then notified regarding the pending transaction (email, SMS, MMS etc).

The store then issues a purchase invoice for the transaction. This is then stored in the transaction logs 206 of both the consumer and the issuing store. When the consumer wishes to complete the transaction, the system retrieves the purchase invoice and displays it to the consumer for review. If the consumer is satisfied that the details of the purchase are correct, they then issue a payment request. On receipt of the payment request the system proceeds to check the consumer's settling account to ensure they have sufficient credit to complete the transaction. If the consumer has sufficient credit, the system proceeds to debit the consumer's settling account in the required amount and credit the store’s settling account.

The system then notifies the store of the transfer of credit, the store then issues a purchase receipt. The purchase receipt is then sent back to the consumer to verify the successful completion of the transaction. A copy of the purchase receipt is stored in transaction logs 206 of the store and consumer. By maintaining a copy of the receipt within both parties member accounts the system can readily resolve any disputes that may arise over the order etc.

As with the airtime loading system above, the trading system allows distributors to sell goods to dealers who in turn are able to sell to the retailers. Indeed the purchasing process that occurs at the service provider end is similar to the purchasing process occurring between the consumer and retailer. For instance a dealer can review the inventory of a various distributors and select the items he wish to purchase from the distributor.

The supply of the goods from the distributor to the dealer can be administered under two possible usage scenarios. Under the first possible supply model, the dealer may take the goods on credit. In this instance the dealer is free to select the goods they wish to purchase from the distributor. Once the dealer has made their desired selections, he issues a purchase request including the distributor

ID, the items for purchase and the quantities of each item required. On receipt of the purchase request the system proceeds to check the dealer's inventory account to ensure that the dealer has sufficient stock to fulfil the request. If there is sufficient stock to fulfil the request, the distributor is then notified of the pending transaction (via email, SMS etc). The distributor issues a purchase invoice for the requested goods, the invoice is then saved to the transaction log of the distributor and dealer. The stock items are then debited from the distributor's inventory list and credited to the dealer's inventory list.

The dealer is then free to sell the stock items to retailers, the stock items are on ] sale at suitable mark up. On sale of the goods to the retailers, the dealer's settling account is credited in the sales amount. To effect settlement with the distributor, the dealer sends a request to the system to retrieve the relevant purchase invoice utilising an access code or keyword associated with the purchase invoice number. The system then checks if the invoice number is valid and then verifies if there is sufficient credit in the dealer's settling account to complete the transaction. If so the system debits the dealer's settling account and credits the distributor's settling account. Both the dealer and distributor receive notifications from the system on successful completion of the transaction.

The alternate usage model is that of a commission model. Here the dealer purchases an agreed volume of inventory from the distributor. In this instance, the dealer sends a purchase order including the distributor ID and agreed purchase amount to the system, the system then checks the dealer's account to ensure that there is sufficient credit to proceed with the transaction. If so the system proceeds to debit the dealer's settling account and credits the distributor's settling account. The distributor then advises the system of the stock items to transfer from its inventory listing to the dealer's inventory listing.

On transfer of the stock items, the system provides the dealer with a listing of the incoming stock. The dealer is then free to sell the stock at the recommend ] price for each sale. The dealer's settling account is credited by the amount of the recommended sale price set by the distributor. A corresponding entry is also made in the dealer's commissions account in accordance with the agreed commissioning scheme in place between the dealer and the distributor.

The commissions may be redeemed on a periodic basis or at the initiation of the 1 dealer. In the case of a periodic redemption process, the system performs a sweep of the dealer's account for any unpaid commissions (i.e. values stored in dealers commissions account). The settlement facility then collates these commissions and arranges for transfers of the appropriate funds to be transferred from the relevant distributor's settling account into the dealer's selected bank account. The system then notifies the dealer and the distributor ; of the transfer.

Inthe case of a dealer initiated transfer, the dealer sends a transfer request to the system which then verifies whether the dealer and the distributor are validly registered members of the system. If so the system then proceeds to check if L the distributor's settling account has sufficient funds to affect the transfer of the required funds to the dealer. In the event that the distributor's account contains sufficient credit, the system arranges transfer of the appropriate funds to the dealer's bank account. The system then notifies the distributor and dealer of the transfer.

As shown, the system may also be linked to various financial institutions 1404.

This enables the system to en-cash the credit accumulated by retailers, dealers and distributors directly into the account of their choosing. In addition, linking into various financial institutions 1404 provides the consumer with the option to purchase credit directly from the credit facility. For example, a consumer can logon to their account with the settlement facility and request additional credit, the system then debits the selected bank account of the consumer in the amount of the credit request and then updates the amount of available credit in the consumers settling account.

Fig 16 depicts an example of how the member's account on the TS 201 may be linked to various accounts owned by an individual to effect transactions with various parties. As shown, bank accounts 1604, credit or debit cards 1605, and virtual cash accounts 1606 are all linked or bound to a member's account which acts as a virtual account 1601. The binding of the accounts in this manner effectively blurs the difference between the virtual account 1601 and the accounts to which it is linked, because the virtual account serves as proxy to the bound accounts. Thus the virtual account merely serves as a repository of credentials for the bound accounts. Any transactions via the virtual account causes the translation or look-up of the account credentials mapped or bound to virtual account to permit the system to negotiate approval of the transaction as if directly transacting using the bound account. A settlement account is provided at the merchant 1607 backend, so that the system can calculate and credit commissions and whatever fees that are due to each party involved in the transaction. In any transaction between the member and the merchant 1607, the bank accounts 1604, credit or debit cards 1605, or virtual cash accounts

1606 are transparent to the merchant 1607 as these are encapsulated in virtual account 1601.

Fig 17 depicts one example of how transactions can be made using the virtual account 1601. In this particular case, the virtual account is a physical device that is associated with the virtual account 1601. As shown the physical device may include, but is not limited to, a magnetic stripe card 1709 which needs to be swiped at a magnetic card reader at the merchant 1607 side, an RFID key chain 1710 for contactless transaction, a contactless or proximity card, smart card or the like.

The system may be further adapted to allow over-the-air transactions, for example via a mobile phone 1711. In such cases, the virtual account 1601 is associated with the mobile phone 1711, sharing identifiers such as but not limited to SIM (Subscriber Identity Module), account, and IME! (International

Mobile Equipment Identity) numbers and similar information.

In the above scenarios, the merchant 1607 is actually transacting with the virtual account 1601 through a physical device. However the use of such a physical device is not always necessary. As shown the virtual account 1601 has two associated properties, the identifier 1703 and the body 1702. Utilizing the identifier 1703 it is possible to conduct a transaction without an associate physical device. In such instances the indentifer 1703 is inputted directly into the merchant's payment gateway 1708 which could form part of a storefront or website.

Fig 18 depicts yet a further example of how the virtual account 1601 may be utilized to conduct transactions with various merchants 1607. In this particular example several subsidiary accounts 18014, 1801,, 18013 are created from a virtual account. Each subsidiary account 18014, 1801,, 1801; is coupled to a subsidiary settlement account 1802, 1802,, 1802;. An account holder may transfer funds in any amount from his nominated account through the virtual account 1601 to the subsidiary settlement account 1802, 18022, 1802; within the subsidiary account 1801,, 1801,, 1801;. Transaction limits, may be imposed on any subsidiary settlement account 1802,, 1802, 1802; just as a credit card account could have a credit limit, but which may also include other parameters of limitation such as frequency or time of use. Funds available through the virtual account 1601 may be converted to an intermediate value, which could be any common or agreed currency base in the foreign exchange or a non-currency-based numeric representation based on an arranged conversion factor, and transferred directly from the fund source to the specific subsidiary accounts in such amount or quantity as may correspond to the transferred fund in the intermediate value.

When transacting with a merchant 1607 via the subsidiary account 1801,, 1801,, 1801,, the subsidiary settlement account 18024, 1802;, 1802; is debited with the transaction value, which is in turn credited to the merchant settlement account 1812. Such transaction contemplates only instances where the merchant requires a specific or dedicated settlement account; otherwise, the transaction should draw funds directly from the nominated fund source through the virtual account 1601 and not from the subsidiary settlement account 18024, 1802, 1802;

One advantage to the use of such subsidiary account 18014, 18012, 1801; may be created for a specific purpose. For instance, a transportation system 1807 (i.e. specific class of merchant 1607) may require a micropayment system with a co-branded access card. A subsidiary account 1801, may be created with a subsidiary settlement account 18024 which is mapped to the settlement account 1 of the transport system 1812. A metro card co-branded with the transportation system may then be issued, the metro card being linked to the subsidiary ] account 18014. This metro card is then used for entry and exit to the facilities of the transportation system 1807, and every time it is used, the subsidiary settlement account 1802 is debited with the value corresponding to the fare for travel, which in turn is credited to the settlement account 1812 of the transportation system 1807. When the value contained in the subsidiary settlement account 1802, is insufficient for a particular transaction, it may be replenished or topped up with credit from the nominated fund source through the virtual account 1601, provided that such is within the parameters of limitations imposed on the subsidiary account 18014.

In the event that the metro card is used, for instance, in a transaction such as purchase of goods where there is no specific subsidiary settlement account 1802, from which the value of the transaction may be debited the system firstly determines the point of use from which the source of funds or credits is based and then draws funds to cover the transaction directly from the nominated fund source through the virtual account 1601.

With reference to Fig 19, there is illustrated an example of how the automatic payment of commissions to the appropriate party is done through the settlement accounts. As shown is an individual A transferring the amount of $100 from his bank account 1904 through the virtual account 1601, to his settlement account 1914. Assuming one-to-one equivalency between the currency in use and the credit units, the value 100 will be debited from the bank account 1904 and credited to the settlement account 1914. ]

If individual A transacts with merchant B for example in the amount of 50 credits, the amount will be debited from his settlement account 1914. The transaction between may then trigger automatic payment of commissions, assuming that for such transaction, commissions are due to logistics provider (Account C) and supplier (Account D). As shown, 40 credits are credited to the settlement account of merchant B 1912 less the commissions for the parties to whom commission is due. In this example, the settlement account of logistics provider C 1916 is credited with 8 credits, while the settlement account of supplier D 1917 is credited with 2 credits, their respective commissions.

Assuming further that merchant B decides to cash-in on his settlement credits, the amount of 40 credits which is the current value of his settlement account,

shall be debited from said account 1912, and credited in the amount of its monetary equivalent 40 dollars to his bank account 1918. For purposes of accounting, it has been shown in Fig 19 that transactions in both the settlement and banking systems balance out.

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.

Omi bus aim p< Crtelrt Facil stom 1 Meth

Wade Smart Unk ne. 14 301