WO2022123392A1

WO2022123392A1 - Method and system for utility vending, payments and debt collateralization

Info

Publication number: WO2022123392A1
Application number: PCT/IB2021/061100
Authority: WO
Inventors: Yannis BENLACHTAR
Original assignee: Benlachtar Yannis
Priority date: 2020-12-11
Filing date: 2021-11-30
Publication date: 2022-06-16
Also published as: ZA202103539B

Abstract

Methods and systems are provided for utility vending, payments and debt collateralization. A method includes receiving a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter. The user is determined as being eligible to be advanced the payment of the product or service as a loan. The amount requested is recorded against a loan account of the user. When notification is received of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter, at least a part of the tendered payment is obtained and offset against the loan account of the user.

Description

METHOD AND SYSTEM FOR UTILITY VENDING, PAYMENTS AND DEBT COLLATERALIZATION

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application number 2020/07731 filed on 1 1 December 2020, which is incorporated by reference herein.

FIELD OF THE INVENTION

This invention relates to method and systems for vending a utility, payment methods, and methods for providing collateral to a loan or debt. The utility may be electricity, water, gas, or the like.

BACKGROUND TO THE INVENTION

In certain markets, utility distribution to consumers and enterprises (such as electricity, water, gas and heating) is done on a prepaid basis where the utility is purchased in advance and then consumed. Typically, a prepayment meter is installed on customers’ premises and may require a customer or user to effect the loading of prepayment credit onto the meter. In “offline meters”, that is meters to which direct data access is not possible, this is mostly done by manually entering a prepayment token consisting of a numeric sequence into the meter via a keypad, or using a magnetic or a payment card on which such prepayment credit may be loaded and transferred by swiping the magnetic card on the meter itself. For “online” meters, that is meters to which direct data communication from a remote computing device such as a vending server is possible, this may be done over the air by telecommunication means.

When a prepayment meter credit is low, the consumer visits a vendor and uses a meter identifier to request a prepayment credit token from the vendor. The vendor may be a physical retailer outlet, or may be a virtual vendor with which the consumer communicates through a web interface, mobile application or the like.

The vendor may forward the request to an intermediate aggregator which then forwards the request to a vending server associated with a utility provider. On receipt of the token request, the vending server generates a credit token for the specified amount. The meter is configured to maintain the credit account and, as the utility is consumed, the meter deducts consumed utility units from the remaining credit. Generally, in the case of “offline meters”, the meter is further configured to automatically disconnect the utility supply to the consumer when a zero balance is reached. The consumer is then required to purchase a pre-paid utility credit token and the vended token must then manually be entered into the meter by means of a customer interface unit (CIU), typically having a keypad (or other input means such as a touch screen) and a display.

Thin pre-payment typically requires a so-called “smart” (or “online”) meter equipped with remote communication means for bi-directional remote communication to and from the meter. In thin prepayment, the remaining credit utility balance of the consumer is not maintained on the meter, but typically on a remote server in a utility credit account registered to the consumer. The meter is to a large extent only responsible for the metrology aspect, i.e. to measure the consumed units of the utility. The meter then either periodically sends a consumption reading to the server or is polled by the server for a consumption reading. These meters typically do not have a CIU and all configuration of the meter is typically performed either by remote communication or through a hardware communication port provided on the meter.

When a consumer wishes to replenish their utility credit account, a desired amount of utility credit is purchased either through an e-commerce service providing pre-paid utility vending or at a brick and mortar retail outlet providing pre-paid utility vending services. However, the consumer is not presented with a token, because the credit account of the consumer is automatically credited at the server. Since these meters do not generally maintain the credit account on the meter itself, the meters by themselves do not automatically disconnect the utility supply upon reaching a zero. Instead, in order to disconnect (and reconnect) the supply when the consumer’s balance held at the server is zero, the server must send a remote instruction to the meter.

Regardless of the type of meter (whether an online (smart) or offline meter), it presents an undesirable situation to the consumer when the prepayment credit runs out. This rings true especially for the indigent, who may not have immediate access to internet-based vending portals from which pre-paid utility tokens may be purchased, thereby reconnecting their utility supply. The consumer is then effectively left in the lurch without any access to a critical utility needed for cooking, heating and other essentials.

Most pre-paid utility meters are configured to indicate to the consumer when the remaining credit balance is approaching a zero balance by visual and/audible means. However, this may go unnoticed and the consumer may only become aware of a zero balance on their utility meter after the utility has been disconnected. It may furthermore be that the relevant customer is unable to purchase prepayment credit due to lack of funds, not having access to a credit or overdraft facility, or such facility having been depleted.

The Applicant considers there to be room for improvement.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention there is provided a computer-implemented method, the method executed at a service provider server and comprising: receiving a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; determining that the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; recording the amount advanced against a loan account of the user; receiving notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and obtaining at least a part of the tendered payment and offsetting it against the loan account of the user.

These features may enable the utility meter associated with the user to serve as collateral for the advanced amount. The utility meter of the user is an essential utility and it is virtually guaranteed that the user must at some point tender payment for either the vending of a prepayment utility voucher, or tender payment for their post-paid account.

Receiving a request for the advancing of the payment of a product or service on credit as a loan to a user associated with a utility meter may be for the payment of a service or product to the benefit of a third party, and the method may further include forwarding the payment of the product or service to either the third party or the supplier of the product or service.

Recording the amount requested against a loan account of the user may include recording either or both of a transaction fee and interest associated with the amount advanced as a loan to the user against the loan account of the user. Recording the amount requested against a loan account of the user may include deducting either or both of a transaction fee and interest associated with the amount advanced as a loan to the user before the advance is effected.

Obtaining at least a part of the tendered payment and offsetting it against the loan account of the user may comprise receiving notification from a utility provider of a vending request made to it, and deducting at least a part of the tendered payment as at least partial repayment of the value of the loan account.

Obtaining at least a part of the tendered payment and offsetting it against the loan account of the user may include an immediate or near-immediate obtaining of the tendered payment from the entity to which payment was tendered.

Obtaining at least a part of the tendered payment and offsetting it against the loan account of the user may be performed by means of a periodic account reconciliation with the entity to which payment was tendered.

The request for the vending of a prepayment utility voucher for the utility meter is received via any one of the group consisting of: a short message service centre; a Unstructured Supplementary Service Data gateway; a web-based portal or mobile application; an interactive voice recording; and a point of sale.

The method may further include determining that at least part of an amount requested for the advancing of the payment of a product or service on credit as a loan to the user exceeds a credit limit associated with the user; and blocking a part or a total of the amount advanced as a loan.

The block may be removed upon the offsetting of at least part of the amount reflected in the loan account of the user.

Blocking a part or a total of the amount of the amount requested as a loan may include putting a reserve on the total or partial amount of the amount requested as a loan.

The amount requested for the advancing of the payment of a product or service on credit as a loan to a user associated with a utility meter may be for the vending of a prepayment utility voucher on credit as a loan to the user. The method may further include effecting the vending of a prepayment utility voucher for the utility meter with which the user is associated or a utility meter associated with a third party as a loan to the user and effecting the provision of the prepayment utility voucher for onward forwarding to or input into the relevant utility meter. The relevant utility meter for which the prepayment utility voucher is vended may be an online meter with which remote data communication is enabled. Effecting the provision of the vended prepayment voucher for onward forwarding to or input onto the relevant utility meter may comprise updating the relevant utility meter remotely to reflect the vended utility.

The method may further include receiving a request from the user to enable automated vending of a utility voucher as a loan to the user and providing it for onward forwarding to the relevant (online) utility meter, the request including a threshold at which the automated vending is triggered, and optionally a value of the voucher to be automatically vended. It may be detected that the remaining utility credit on the relevant meter is below the threshold. It may further be determined that the user has not yet reached a credit limit for the automated vending. A utility voucher may be vended as a loan to the user and its provision effected for onward forwarding to the relevant utility meter.

The request received from the user to enable automated vending of a utility voucher as a loan may include a value of the utility voucher to be automatically vended.

The relevant utility meter for which the prepayment utility voucher is vended may be an offline meter which requires the input of the voucher onto the utility meter via a customer interface unit. Effecting the provision of the vended prepayment voucher for onward forwarding to or input onto the relevant utility meter may comprise presenting a user of the relevant utility meter with a voucher code or token to be entered onto the relevant utility meter.

Recording a value associated with the vended prepayment utility voucher against a loan account of the user may include recording one or more of a transaction fee, interest, and a commission associated with the vended prepayment utility voucher against the loan account of the user.

Recording a value associated with the vended prepayment utility voucher against a loan account of the user may include deducting one or more of a transaction fee, interest, and a commission associated with the vended prepayment utility voucher from the value of the voucher to be vended.

Obtaining at least a part of the tendered payment and offsetting it against the loan account of the user may comprise reconciling a service fee and/or a commission levied on the amount requested to be advancing on credit as a loan to a user; and a service fee and/or commission levied by a vendor to whom the user tendered the payment.

Obtaining at least a part of the tendered payment and offsetting it against the loan account of the user may comprise receiving a vended utility voucher for the tendered amount, converting the vended voucher into two or more vouchers having a combined value of the tendered amount, providing one of the converted vouchers for onward forwarding to or input onto the utility meter, and withholding the remainder of the vouchers as repayment for one or more of: a principal utility value previously provided to the user as a loan, a service fee, and an interest amount.

Vending a prepayment utility voucher as a loan to the user may include vending the prepayment utility voucher at an increased tariff rate relative to the nominal tariff rate charged to the utility meter.

In accordance with a further aspect of the invention there is provided a system including a memory for storing computer-readable program code and a processor for executing the computer- readable program code, the system comprising: a data source component arranged to receive a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; a real-time decision engine arranged to determining whether the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; a reporting and revenue assurance module arranged to record the amount advanced against a loan account of the user; a third-party data interface component arranged to receive notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and wherein the reporting and revenue assurance module is further arranged to obtain at least a part of the tendered payment and offsetting it against the loan account of the user.

In accordance with a further aspect of the invention there is provided a computer program product, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; determining that the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; recording the amount advanced against a loan account of the user; receiving notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and obtaining at least a part of the tendered payment and offsetting it against the loan account of the user.

Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

Figure 1 is a schematic diagram of an exemplary system for facilitating vending, payment and debt collateralization in accordance with the invention;

Figure 2 a schematic diagram of the integration of the service provider system with other components shown in Figure 1 ;

Figure 3A is a swim-lane flow diagram of a method for vending a utility in accordance with this invention;

Figure 3B is a swim-lane flow diagram showing alternative steps in a method for vending a utility;

Figure 3C is a swim-lane flow diagram of a method for advancing a loan for a product or service in accordance with this invention;

Figure 4 is a swim-lane flow diagram of a variation of a method for vending a utility;

Figure 5 is a swim-lane flow diagram of a further variation of a method for vending a utility;

Figure 6 is a block diagram showing functional modules of a service provider server; Figure 7 illustrates an example of a computing device in which various aspects of the disclosure may be implemented;

Figure 8 illustrates an exemplary flow of information between the service provider system and an insurer; and

Figure 9 illustrates an exemplary payment flow for an online transaction using Direct Utility Billing (DUB).

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Exemplary embodiments of methods for utility vending, payments and debt collateralization are disclosed below. A method may be executed at a server of a service provider that facilitates the method for utility vending, performing payments and debt collateralization. The service provider need not be integral to the system of a utility provider and, in various embodiments, will be a system external to the utility provider systems.

The utility provider may provide various functional components that are accessible by the service provider server via an application programming interface (API). For example, the utility provider may provide a prepayment voucher vending system accessible via an API. Similarly, it may provide meter management modules, which may facilitate remote communication with online meters, accessible to the service provider server via the API. The method executed at the service provider server may recite steps that require the relevant functionality to be accessed via the API from the utility provider. For example, where a step recites “vending a utility voucher”, it is implied that the service provider server accesses the prepayment voucher vending module and interacts with it in order to facilitate the vending of the relevant voucher. As a further example, where remote communication with an online meter is performed by the service provider server, it may be implied that it does so via the meter management module of the utility provider, accessed via the API.

The method includes receiving a request for the advancing of the payment of a product or service on credit as a loan to a user associated with a particular utility meter. In some embodiments, this may take the form of receiving a request for the vending of a prepayment utility voucher for the utility meter on credit as a loan to a user associated with the utility meter. In other embodiments, this may take the form of requesting the advancing of the payment of a product or service of a third party (e.g. a streaming video service subscription).

The utility meter may be installed at a residence or other premises used or occupied by the user, and the user may previously have enrolled and registered with the service provider in order to utilise this method. The user is therefore dependent on the utility meter for the provision of a basic household necessity, e.g. electricity. The loan is to be recovered from the future tendering of payment towards a utility of the utility meter (either prepayment utility voucher or post-payment account payment). The fact that the utility is such an essential utility virtually guarantees a future payment being tendered therefor, from which the loan may be (at least partially) recovered, which provides security or collateral for the loan. As part of the registration procedure, the relevant meter may be linked with an account of the user, thereby “associating” the utility meter with the user.

The method includes determining that the user is eligible for being vended a prepayment utility credit voucher as a loan. This determination may be made based on various data sources accessible to the service provider server, via API’s. For example, it may obtain user-specific data from the utility provider system including “know your customer” (KYC) information, utility consumption history, current balance and Customer Relationship Management (CRM) information. Additionally, the service provider server may access and obtain data relating to the relevant user from different sources such as application information (e.g. from brokers), credit bureau reports, social networks, data from the customers’ devices, telecom data and bank accounts & digital wallets information. It will be appreciated that, as part of a user registration and enrolment process, the user may provide the requisite permissions for the service provider server to access these data sources.

If the user is determined to be eligible, the amount requested is recorded against a loan account associated with the user. In embodiments where the request was the vending of a utility as a loan, a prepayment utility credit voucher is vended as a loan to the user and provides it for onward forwarding to or input onto the utility meter. The specific manner in which the vended voucher is presented may depend on the type of meter, and the medium utilised by the user to submit the request for the voucher. With an online meter, the meter may merely be remotely updated with the vended utility credit, requiring no further user intervention. The user may be notified of a successful vending as a loan via a preconfigured medium, e.g. via short message service to their mobile phone.

If the meter is an offline meter, the user is typically presented with a token. The token is generally an encrypted dataset represented as a clear text numeric sequence, which may be entered via a keypad of the meter’s customer interface unit. The meter may then decrypt the token an update its own internal prepayment utility registers with the amount of vended utility.

As mentioned above, the request for the advancing of the payment of a product or service on credit as a loan to the user (associated with the utility meter) may take the form of requesting the advancing of the payment of a product or service of a third party (e.g. a streaming video service subscription). The method may then include forwarding the payment of the product or service to either the third party or the supplier of the product or service. For example, the payment of the product or service may be forwarded to the third party (a friend or relative of the user associated with the utility meter, say) in the form of a voucher to be handed, submitted, or inputted to the provider of the relevant service or product. Alternatively, payment may be directly made to an account of the third party (the friend, relative, or the like) maintained by the provider of the service or product.

The loan account may be stored in a database accessible to the service provider server. In some embodiments the loan account may be maintained on the service provider server. In other embodiments, the loan account may be maintained on a utility provider server, at a point of sale, or the storage of any other third-party device or platform that may be accessible to the service provider server, possibly with the service provider server being granted read and write permissions to the database. The recorded value may be a monetary value, i.e. a monetary value of the amount loaned (e.g. monetary value of a vended utility, or of a third-party payment), or may alternatively be expressed in a unit of measurement of the relevant unit of the utility, where applicable. For example, in the case of electricity, the value may be expressed in kWh. In the case of water, the value may be expressed in litres (or kilolitres).

Subsequently, typically a number of days later (depending on the amount of utility vended as loan, and the user’s utility consumption) a notification is received that the user has tendered payment for either the vending of a prepayment utility voucher for the utility meter (in the case of a prepayment meter) or towards the payment of a post-payment utility account associated with the utility meter (in the case of a post-payment meter). The payment may have been tendered directly to the utility provider (via a point of sale). This request is not for a further vending as a loan, but payment is tendered during this transaction. The entity to which payment is tendered (for example the utility provider, or point of sale) notifies the service provider thereof, prompting a check to be done as to whether the relevant user’s loan account reflects an outstanding loan, in embodiments where the user’s loan account is maintained by the service provider. In some embodiments, the user’s loan account may be maintained by or tracked by the utility provider system. In such embodiments, the utility may perform the checking of whether the user’s loan account reflects an outstanding loan, and notification thereof sent to the service provider.

At least a part of the tendered payment is then secured, received, or obtained and then offset against the loan account of the user, thereby effecting repayment of (at least part of) the loan. Figure 1 is a schematic representation of a system for facilitating utility vending, payments and debt collateralization in accordance with the invention. Starting at the bottom of the figure, the system (100) includes two sets of meters: a first set of online meters (102) and a second set of offline meters (104). The online meters (102) may also commonly be referred to as “smart meters”, “connected meters” or similar terminology, and have the capability of remote communication. The remote communication may be one-way (i.e. remote communication with the meter), or bi-directional (i.e. remote communication to and from the meter).

The online meters (102) typically use standard technologies such as Automated Meter Reading (AMR) or Advanced Metering Infrastructure (AMI) and are typically linked to an aggregator (106) (also known as a concentrator) which is then connected to the backend systems provided by the servers (108) within the utility provider’s system (110). This communication connection is indicated by connection (C1 ) via a telecommunication network (112) that can be wired, wireless or a combination of both as indicated by connection (C2). Typically, the online meters utilise communication methods such as radio frequency (RF), power-line communication (PLC) or cellular communication, possibly via a built-in or connected GSM module or modem (not shown).

The methods and systems disclosed herein are agnostic to the specific communication medium by which the meters are connected to the utility provider system (1 10) as such low-level communication protocols are typically abstracted by high-level communication libraries.

The utility provider system (1 10) provides various functions known in the industry, and which may be utilised via an API (1 18) for the implementation of the methods disclosed herein. These functions may be provided by various functional modules implemented on the utility provider server (108), all accessible via the API (1 18) of the utility provider system (1 10). These functions may include managing billing or user accounts (1 14), prepayment utility voucher vending, payment management, remote communication with the online meters (102), data storage and databases (116), and providing customer care. It will be appreciated that the utility provider system (1 10) may make the API (118) available via middleware for performance and security reasons. The various modules of the utility provider (110) may be accessed via API (1 18) using various protocols known in the art, including hypertext transfer protocol (HTTP), HTTP secure (HTTPS), Simple Object Access Protocol (SOAP), Extensible Markup Language (XML), Representational State Transfer (REST), JavaScript Object Notation (JSON), file transfer protocol (FTP), secure shell (SSH) FTP or SFTP, Standard Transfer Specification (STS) protocols, Wireless Smart Utility Network (Wi-SUN) protocols, and the like.

Certain types of online or “smart” meters, such as AMI type meters, can switch between prepay and post-pay modes and both modes are compatible with the methods disclosed herein. The users (120) (or customers) having offline (prepay) meters (104) would buy vouchers (tokens) from physical or online points of sales (POS) (122) and input the voucher number on the customer interface unit (CIU) (105) of the meter. Another method may be to load a magnetic card at the physical POS (122) and swipe it on the offline meter (104).

The utility provider system (110) is connected to physical or online points of sale (122) to enable users (120) to recharge their prepaid meters (102, 104) or pay a post-pay bill as shown by connection (C3).

A service provider system (150) connects to the utility provider system (110) (or its API (1 18)) via connection (C4), the points of sale via connection (C5), the users via connection (C6) and to third parties via connection (C7) as described in further detail below. The connectivity can be an internet connection or a virtual private network (VPN), for example.

The service provider system (150) includes a service provider server (152) on which the method in accordance with the invention may be executed. The service provider server (152) has access to a database (154) on which data associated with users (120) of the methods in accordance with this invention is stored. This may include user loan accounts (156), against which a loan to a user (120) is recorded (e.g. the vending of a utility voucher as a loan).

Figure 2 shows the mechanisms by which the service provider system (150) and its server (152) may integrate with other components shown in Figure 1 , thereby utilising the functionality of the respective components to facilitate the execution of the methods disclosed herein. Referring to the left-hand side of Figure 2, the block representing the utility provider system (1 10) provides various functional modules (as aforesaid). All these modules may be accessible via the API (118) using the communication protocols listed above.

These include a meter management module providing functionalities such as managing the connection with the meters, getting meter statuses or readings, updating the meter software, reporting errors and fraud, and the like. The service provider system (150) can receive notifications regarding meters with low balance and out of credit meters. The notifications may be used as marketing triggers to the consumers and as part of an automated utility vending feature of the methods disclosed herein, discussed in more detail below. The service provider system (150) can receive notifications regarding meter recharging in real or near-real time. This may be used to recover the loan once a customer recharges as explained further below. Additionally, this module may be used to add or deduct credit directly on the meter or to display messages on the meter. The vending module has functionalities such as creating vouchers or tokens, managing them and crediting them to the meter or the billing module (described below). This module may be used by the service provider system (150) and its server (152) to obtain utility vouchers that can be communicated to the meters (102, 104) or the consumers (120) as described in the methods below. The service provider system (150) and its server (152) may further utilise this module to modify the voucher value, number and optionally split the voucher, and credit a previously issued (but not yet communicated) voucher.

The billing module includes the functionality of updating meter credits, calculating consumption and applying consumption tariffs. This module may be used by the service provider system (150) and its server (152) to add credit to the users’ accounts (1 14) (in order to provision the loan). As aforementioned, the service provider system (150) may also maintain a loan account (156) of users in its own database (154), particularly in cases where the user’s meter is an offline meter (104), and a “prepayment account” is not managed remotely, but on the meter itself.

Therefore, particularly in the case of “thin prepayment”, online meters (102), and even in postpayment modes, this module may be used by the service provider system (150) and its server (152) to apply a special tariff on the loaned utility units; and to deduct credit from the users’ accounts (114) to recover the loan. The deduction can be partial or a full deduction. It may also be used to obtain account status and fraud events, to apply a fee on the recharged credit, and apply a special tariff on the recharged utility units to pay back the loan. Instead of recovering the loan at once, the service provider system (150) may apply an additional or higher tariff to gradually recover the loan.

The data module includes the functionality of obtaining users’ account information (114) through a data warehouse (or a mediation layer). The data warehouse is typically a database (116) that holds users’ account data (1 14). The mediation layer, on the other hand, manages the data records generated by the billing module. The data module may be used by the service provider system (150) and its server (152) to obtain “know your customer” (KYC) information such as name, address, contact number, ID number; obtain (historic) consumption information; obtain data record files to further process them; and obtain user account (1 14) status.

The customer relationship management (CRM) module may be used by the service provider system (150) and its server (152) to provide first line customer care support; to provide credit information and transaction history; to provide second line of support and ticketing management (customer care may not be able to solve an issue and open a ticket); and to provide capabilities to the customer care to provide a loan. This module may often be utilised by the utility provider system (110) itself to check the loan transaction history of their users, credit limits and any loan collateralization with 3rd parties. This module may also be used to manage debt portability, i.e. when a customer moves address, by either closing any existing debt and stop any collaterals; or by transferring the debt and collaterals onto the new meter number.

These functional blocks may also be accessible via a single node (such as a middleware) that aggregates all these functionalities.

Referring to the right-hand side of Figure 2, the block representing the communication channels and user interfaces with which the service provider system (150) may communicate and interface with users (120) and point of sale (122) agents to provide push notifications, loan information, and interfaces for loan application. These modules are, similarly as above, accessible by means of an API. These include a short message service centre (SMS-C) module, that may be used by the service provider system (150) and its server (152) to send an SMS to a mobile phone of a user (120). It also includes an Unstructured Supplementary Service Data gateway module (USSD- GW), which may be used to establish a USSD communication session with a user (120) by means of their mobile phone. It further includes a web and mobile application server module, operable by the service provider system (150) to provide a web-based user interface or platform, or a mobile device application, for interfacing with users (120) and point of sale (122) agents. It further includes an interactive voice recording (IVR) module, operable by the service provider system (150) to provide an IVR-based communication session with a user (120).

A further communication channel or interface is a point of sale module, operable by the service provider system (150) to send marketing notifications; receive loan requests; provide credit information (such as a credit limit), payment terms, fees, penalties and terms and conditions; and send vended vouchers. It may further be utilised to deduct the loans. A user (120) with an outstanding loan may purchase utility credit directly from an (external) POS (122). Through integration the service provider system (150) may receive notification thereof, and can deduct the loan value or part thereof from the amount tendered for the utility voucher at the POS (122).

These SMS messages or USSD sessions, and other communication mediums mentioned above may be used to communicate marketing notifications to users (120); to receive loan requests using keywords (or menu based in the case of USSD); to provide credit information such as credit limit, payment terms, fees, penalties and terms and conditions; to send payment reminders to users; to confirm a loan status (such as accepted, rejected, in process, open, paid, and the like); to confirm the credit and debit operations of a meter (102); to send a vended voucher to a user (120); to confirm loan repayment to a user (120); and to provide a transaction history to a user (120). Referring now to the bottom of Figure 2, the block representing third-party systems and service providers (170) indicates that the service provider system (150) may integrate with various third- party institutions or data sources (via an API) such as financial institutions, insurers, financial brokers, retailers, eCommerce, borrowers, and the like. By utilising these data sources, the service provider system (150) may perform credit scoring - a score that gives an indication of the credit worthiness of a user (120). The service provider system (150) may also thereby obtain or compile a credit report that may include aggregated information of the consumption and credit behaviour of the relevant user (120). The service provider system (150) may also thereby determine or obtain a credit limit: the advisable limit value based on the affordability assessment of the relevant user (120); and a propensity scoring: a score of user’s (120) preferences and the likelihood of taking certain offers or services.

Through these data sources, the service provider system (150) may determine whether a user (120) is eligible for being vended a prepayment utility credit voucher as a loan.

Further functionality or data that the service provider system (150) may access through these 3^rd party sources or services including KYC verification: verification of name, address, contact details, ID document, profession, etc. It further provides the functionality of loan collateralization: the service provider system (150) may give the option for lenders to collect the outstanding loans from future utility meter payments. It also provides the functionality of insurance scoring, and claim and fraud verification. Certain data points and risk scoring can be shared with insurers to price insurance premiums such as home insurance. These can also be used to verify claims and combat fraud. For instance, an insurer may verify water meter data to cross-check a water flooding claim.

Figure 3A is a swim-lane flow diagram showing a method (300) for vending a utility in accordance with this invention. Figure 3 shows the general steps of the method, with more specific applications thereof being illustrated and described with reference to flow diagrams shown in subsequent figures. The flow diagram of Figure 3 indicates steps taken at, and data exchanged between, the utility provider server (108), the service provider server (152), a user (120), and a meter (102, 104) associated with the user (as indicated by the headings of the lanes).

It is assumed that a user (120) that is desirous to use the method (300) and to request (302) the vending of a utility as a loan, has already enrolled and registered with the service provider system (150), has provided the requisite permissions for the system (150) to access information of the user, and that the user is duly registered and has a user account (1 14) with the utility provider system (1 10). The service provider server (152) receives (304) a request from the user (120) for the vending of a prepayment utility voucher for a utility meter (102, 104) of (or associated with) the user. The request is for the voucher to be issued on credit, i.e. as a loan to a user. The request from the user (120) may be obtained through any number of channels as described above (e.g. via SMS, a USSD session, a mobile application, a POS (122), etc.) The utility meter may be installed at a residence or other premises used or occupied by the user (120).

The service provider server (152) then determines (306) whether the user is eligible for being vended a prepayment utility credit voucher as a loan. This may be determined through accessing 3^rd party data sources to obtain credit scoring, credit reports, consumption and credit behaviour of the relevant user (120), and a credit limit of the user (120) as described above. The service provider server (152) may also request and receive (308) information relating to the user (120) from the utility provider server (108), which may also be utilised in determining whether the user is eligible.

If it is determined that the user (120) is not eligible, the request is denied, and the user may be notified via the channel that the request (302) had been received. If the user is determined to be eligible, a prepayment utility credit voucher is vended (310). The service provider server (152) may utilise the vending module of the utility provider system (110) via the API (1 18) and the voucher generated at the utility provider server (108) then sent (312) back to the service provider server (152). The vended voucher is vended as a loan to the user (120). The vended utility voucher is then provided (314) for onward forwarding to or input onto the utility meter, depending on the type of meter.

In the case of an online meter (102), the service provider server (152) may cause the vended utility voucher to be remotely sent to and loaded (318) onto the meter (via the API (118)). In the case of an offline meter (104), the vended utility voucher may be provided to and received (316) by the user (120) via the same communication channel as the request (302) was sent. The user (120) may then load (318) the vended utility voucher into the meter (104) by means of the meter’s customer interface unit (104) (e.g. a keypad on the meter). The user may be notified of a successful vending as a loan via a preconfigured medium, e.g. via short message service to their mobile phone.

A value associated with the vended prepayment utility voucher is then recorded (320) against a loan account of the user. In the case of either an online meter (102) or an offline meter (104) , the loan account (156) may be one maintained by the service provider system (150) and may also be recorded on the utility provider system (1 10) in a loan tracking account (1 15) maintained in a utility database (116). The loan tracking account (1 15) may be utilised as the primary loan account or may be used as a redundancy. The service provider server (152) may update the loan tracking account (115) via the API (118). In the case of an online meter (102), the utility provider system (110) may already maintain a user account (114), which may be utilised for “thin prepayment”. In such cases, the value associated with the vended prepayment utility voucher may be recorded against this user account (1 14), accessible by the service provider server (152) via the API (118). The recorded value may be a monetary value, i.e. the monetary value of the amount of vended utility or may alternatively be expressed in a unit of measurement of the relevant unit. For example, in the case of electricity, the value may be expressed in kWh.

Subsequently, typically a number of days later (depending on the amount of utility vended as loan, and the user’s utility consumption) a notification is received (322) by the service provider system (152) that the user (120) has requested the vending of a prepayment utility voucher. The user (120) may have initiated a transaction to purchase a utility voucher directly from the utility provider, e.g. via a point of sale (122), for which immediate payment is tendered. The entity at which this transaction was initiated by the user (120) may then send (321 ) the notification received (322) by the service provider server (152). This may prompt the service provider server (152) to check (324) whether the relevant user’s loan account (156) reflects an outstanding loan. This check may also be done by the utility provider server (108), having reference to the loan tracking account (115) maintained at the utility provider system (110) and accessible to the utility provider server (108).

At least a part of the tendered payment is then secured, received, or obtained (326). The utility provider system (1 10) may send (328) at least a part of the tendered amount to the service provider system (150). This is then offset (330) against the loan account (156) of the user (120), thereby effecting repayment of (at least part of) the loan.

Instead of using at least of a part of the tendered (monetary) amount as per step (326), the offsetting (330) against the loan account (156) may be by means of the vended voucher. For instance, a customer who has an outstanding loan of 20 may purchase a voucher of value 100 for which immediate payment is tendered. The voucher system may then create a voucher (voucher number “123456”, say) of value 100. The service provider server (152) may then modify voucher “123456” (possibly via the API (118)) to reflect a value of 80 or replace the original voucher number (i.e. voucher “123456”) by another number (voucher number “123457”, say) with a value of 80.

Further alternatively, the original voucher may be split into two or more vouchers. For instance the service provider server (152) may utilise the vending module of the utility provider system (110) to create a voucher number (e.g. voucher number “123456”) of value 100, and then split it into 3 vouchers: one of value 80 that is communicated to the user (e.g. voucher number “123457”), a voucher of value 18 which represents the principal value of the loan advanced (e.g. voucher number “123458”), and a voucher of value 2 which represents a service fee, transaction fee, commission or interest (e.g. voucher number “123459”). The principal and fee vouchers may be kept retained by the service provider server (152) for revenue assurance purposes and only the voucher with the value of 80 communicated to the user.

The service provider system (152) may inform the user (120) upon partial or full repayment of the loan by means of any of the above-mentioned communication channels, e.g. by means of an SMS sent to a mobile device of the user (120).

Figure 3B shows alternative method steps (350) for receiving notification of a request for the vending of a further prepayment utility voucher; and obtaining at least a part of the tendered payment and offsetting it against the loan account of the user. The preceding steps, i.e. the requesting of the vending of the utility as a loan, may be performed substantially similar as in steps (302) to (320) in Figure 3A.

However, as shown in Figure 3B, subsequently, the user (120) may request (352) and tender payment for the vending of a utility at a POS (122). The POS (122) may be a brick and mortar outlet, or may be an eCommerce vendor, for example. Due to the integration of the POS (122) in the system (100) and, more particularly, the communication enabled between the service provider server (152) and the POS (122), steps of the method (300, 350), may be implemented (at least in part) through communication between the POS (122) and the service provider server (152).

The POS (122) receives the request for the vending of the utility. For example, the user (120) may request the purchase of utility of a certain value at a checkout point at a retail store. The POS (122) then queries (354) the service provider server (152) as to whether the relevant user (120) has a loan outstanding. Depending on the implementation, this information may be recorded against the user account (1 14) or the loan tracking account (115) at the utility provider system (110), the loan account (156) at the service provider system (150); or even a loan tracking account at the POS system. The service provider server (152), by receiving the query (354) from the POS (122) thereby receives notification of the user’s (120) request for the vending of a further prepayment utility voucher for the utility meter (102, 104) for which immediate payment is tendered.

The service provider server (152) or the POS (122) then checks (356) whether there is a loan outstanding and, if so, it notifies the POS (122) as such. The POS (122) receives (358) the query result and vends the total amount of requested utility as per usual. However, if the service provider server (152) determines that a loan is outstanding, it notifies the POS (122) thereof, and the POS (122) receives (358) the query result showing a loan being outstanding and an instruction to deduct at least part of the tendered amount for the offsetting thereof against the loan. The POS (122) then requests (360), from the utility provider server (108), the vending of an amount of utility to the value of the tendered amount, minus the part thereof to be offset against the loan. Upon receipt of the request, the utility provider server (108) vends and issues (352) the utility in the requested (adjusted) amount and forwards the vended utility voucher to the POS (122) for onward presentation to the user (120), whom receives (366) the utility voucher.

The POS (122) and the service provider server (152) may, immediately or at some later time, reconcile the amount deducted from the amount tendered by the user (120), thereby obtaining at least a part of the tendered payment and offsetting it against the loan account of the user.

Figure 3C is a swim-lane flow diagram showing a payment method (370) in accordance with this invention. In the methods of Figures 3A and 3B, the user (120) requested the vending of a prepayment utility voucher as a loan. In Figure 3C, the method (370) illustrates how the invention may be utilised to make payment for any third-party (170) product or service as well, e.g. a streaming video subscription, or even groceries.

This method (370) and the numerous variations thereof within the scope of the invention may be termed “Direct Utility Billing” (DUB).

The service provider server (152) receives (372) a request (371 ) from a user (120) for the advancing of the payment of a third-party (170) product or service on credit as a loan to a user. The service provider server (152) then determines (373) whether the user (120) is eligible for being provided the loan in the form of a payment of the product or service to the third party (170). As before, this may be determined through accessing third-party data sources to obtain credit scoring, credit reports, consumption and credit behaviour of the relevant user (120), and a credit limit of the user (120). The service provider server (152) may also request and receive (374) information relating to the user (120) from the utility provider server (108), which may also be utilised in determining whether the user is eligible. In embodiments where a user account (114) at the utility provider system (110) is utilised to record loans to the relevant user (120), this information may also include a current loan balance. This may be used to determine whether a credit limit of the user (120) would be exceeded should the presently requested loan be granted.

If it is determined that the user (120) is not eligible, the request is denied, and the user may be notified via the channel that the request (372) had been received. If the user is determined to be eligible, a payment may be made to the third party (170). This payment may be received (376) immediately (or near-immediately), or the service provider system (150) may have an configuration set up for a periodic reconciliation of accounts between the relevant third party (170) and the service provider server (152).

The loan may then be recorded (377) against a loan account of the user (120). In the case of either an online meter (102) or an offline meter (104), the loan account (156) may be one maintained by the service provider system (150). In the case of an online meter (102), the utility provider system (110) may already maintain a user account (114), which may be utilised for “thin prepayment”. In such cases, the loaned amount may be recorded against this user account (114), accessible by the service provider server (152) via the API (1 18). In this instance, the recorded value would likely be may be a monetary value, i.e. the monetary value paid to the third-party (170) for the relevant product or service.

It will be appreciated that the method in Figure 3C illustrates only the steps providing the loan to the user, and that any combination of steps providing the loan, and steps collecting the loan may be combined.

The remainder of the method (370) (i.e. the loan collection steps) shown in Figure 3C may therefore be substantially similar as steps (321 ) to (330) of the method described with reference to Figure 3A.

Figure 4 is a swim lane diagram illustrating a method (400) that is a variation of part of the method (300) of Figure 3A and, more particularly, the steps in requesting the vending of utility as a loan to a user. This method (400) may be utilised where the meter is an online meter (102), in which case the utility provider system (1 10) may maintain a user account (114) that reflects the remaining utility credit of a meter (102) of a particular user (120). The utility provider server (108) may detect that the remaining utility credit reflected in the user account (114) of a particular user is depleted, or below a certain threshold. It may then send (402) a low or “out of credit” message to the service provider server (152) which, in turn, then performs an eligibility check (404) as described above to determine whether the relevant user (120) is eligible to be offered vending utility as a loan to them. As part of this process, it may exchange user information (406) with the utility provider server (108).

The service provider server (152) then sends (408) an offer to vend utility as a loan to the user (120), and may optionally (or as a further step after acceptance) provide the user (120) with the available options (e.g. a value of the utility loan). During the eligibility check (404), a credit limit may be determined for the particular user (120) and they can take one or multiple utility advances up to the credit limit. Customers may input a preferred amount or may select one or multiple predefined units

Should the user (120) decline the offer, the method may end. Alternatively, the user may accept the offer and request (410) the vending of a prepayment utility voucher for the utility meter (102) as a loan to the user, including the selected loan option. The offer and subsequent communication between the service provider server (152) and the user (120) may occur through any number of channels as described above (e.g. via SMS, a USSD session, email, a mobile application, and the like) and may even be displayed on a display of the meter (102), prompting for acceptance of the offer via an input of the meter (102) itself (e.g. a keypad or touch display).

The request for the vending of the utility as a load is received (412) by the service provider server (152) which causes the utility to be vended and provided (414) for input into the meter (102). As such, the service provider server (152) causes the utility provider server (108) to vend (416) the utility via the API (118), and to remotely load the vended utility on the meter (102). It will be appreciated that the loading (418) of the vended utility on the meter (102) may merely comprise the updating of a display of the meter (102), as the actual remaining utility credit may be maintained in a user account (1 14) administered by the utility provider system (110).

The user may be notified of a successful vending as a loan via a preconfigured medium, e.g. via short message service to their mobile phone, or via the medium which the earlier offer (408) and acceptance (410) was performed.

A value associated with the vended prepayment utility voucher is then recorded (420) against a loan account of the user. As aforementioned, this may either comprise recording it against the loan account (156) maintained by the service provider system (150) the user account (1 14) maintained by the utility provider system (1 10).

The remainder of the method may be similar to steps (322) to (330) shown and described with reference to Figure 3.

Figure 5 is a swim lane diagram of a method (500) that is a variation to that described with reference to Figure 4. In this method (500), an automatic vending of credit on loan to the user is configured and utilised.

As an initial step, the user (120) may request (502) the enabling of the automatic vending function. As a prerequisite, the user may previously have been determined to be eligible for this function through eligibility checks as aforementioned. The service provider server (152) receives and enables (504) the automatic vending of utility as a load to the user (120). Optionally, and particularly if not set before, the user (120) may request (506) values to be set for the automatic vending. This may include the value of the utility to be vended per automatic vending event, and optionally also the threshold at which the automatic vending should be triggered. This request (and its values) is received and set (508) by the service provider server (152). The threshold value may be communicated to the utility provider server (108) to enable it to alert the service provider server (152) of an out of credit event (402). Alternatively, the service provider server (108) may periodically poll the utility provider server (108) to obtain the current remaining utility credit reflected in the user account (1 14) of the user (120), and then trigger the automatic vending event according to the polled data. As a further alternative, the service provider system (150) may set the credit limit and the auto-loan functionality directly on the meter by allowing the metering system to go negative.

The remainder of the method may be substantially similar as steps (402) to (418) of the method described with reference to Figure 4, followed by steps substantially similar to steps (322) to (330) shown and described with reference to Figure 3.

As alluded to before, after the utility has been vended as a loan, the service provider server (152) may cause a modification of the tariff plan specifically for the loaned amount. For instance the standard rate for 1 kWh of electricity may be is 10 cents, but for the loaned electricity may be set at 1 1 cents per kWh. This may either be done by changing the rate on the meter (104), or the billing module of the utility provider system (110). An additional method may be to credit the loan to a sub-account on the administered by the utility provider system (110) (e.g. a sub-account of the user account (1 14)) band assign it different attributes (such as a different tariff). Similarly, the tariff may be restored to its nominal value upon the loaned amount being recovered.

It will be appreciated by those skilled in the art that the automatic vending function described with reference to Figure 4 may be applied mutatis mutandis to the payment of a recurring subscription as a loan (instead of automatically vending utility as a loan).

Various components may be provided for implementing the methods described above with reference to Figures 3 to 5. Figure 6 is a block diagram which illustrates exemplary components which may be provided by a service provider server (152) in a system for vending a utility.

The service provider server (152) may include a processor (602) for executing the functions of components described below, which may be provided by hardware or by software units executing on the service provider server (152). The software units may be stored in a memory component (604) and instructions may be provided to the processor (602) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the service provider server (152) may be provided remotely.

As indicated on the left-hand side of Figure 6, the service provider server (152) may receive different types of data from the utility provider system (110) including KYC information, consumption history, current balance and CRM (Customer Relationship Management) information. These various data sources may be accessible via the API (1 18). Additionally, the service provider server (152) may receive and process data relating to the user (120) from various 3^rd party (170) sources such as application information (e.g. from brokers), credit bureau reports, social networks, data from the user’s devices, telecommunications data and bank accounts and digital wallets information.

The service provider server (152) includes a data management and assurance module (606) that ensures that the incoming data, whether real-time or offline, is properly and efficiently processed, cleaned and normalized then saved to a very low latency and highly available database (154). Speed and high availability are of paramount importance here because this core infrastructure provides critical data and parameters to a real-time decision engine, a credit scoring module, a propensity scoring module and a reporting/CRM module of the service provider server (152) simultaneously. These modules are described in more detail below. The data can be anonymized and exposed to third parties using standard hashing techniques.

There are two levels of data assurance procedure that are carried out on the data: quantitative and qualitative. The former ensures that the data is in the expected format and that the correct amount of data has been received. The latter checks the data sanity and data trends.

The service provider server (152) further includes a scoring and risk management module (608). The service provider server (152) has the capability to calculate credit risk (and eligibility) for each user (120) and may provide a credit score that indicates the probability of customer to default or their credit worthiness; and pre-approved instant loans.

This is enabled by using the user’s data from the utility provider system (110) in addition to combining it with the aforementioned external (or 3^rd-party) sources. Machine learning (ML) and artificial intelligence (Al) techniques may be applied to the data at large scale. This may include frameworks for creating machine learning pipelines, allowing for easy implementation of feature extraction, selections, and transformations on any structured dataset. Model training for the ML and Al techniques can create challenging models at set intervals, automatically generate detailed validation reports (model discriminatory power) and can be instantly integrated with a real-time decision engine (RTDE) (610). The algorithms may parse hundreds of data points and look for relationships between the different variables in the data. The bespoke models are built using proprietary algorithms based on: Neural Network, Decision trees and random forest, Ensemble, Logistic Regression, and Genetic Algorithm.

The service provider server (152) further includes a risk management and limit allocation component (612). One of the most important tasks of this module is to assess a user’s (120) repayment capacity and calculate the credit limit that can be safely provided to this user (120). This may be done by building limit assessment models based on the data from the utility provider system (1 10) in combination with external (3^rd party) sources and derive an affordability index and a credit limit allocation. The models may be based on ML and Al techniques.

The RTDE (610) mentioned above is responsible for providing an instant approval or disapproval of loans. It does this by having the ability to fetch data (from the data management and assurance module (606)) in real-time and implement the scoring models (from a credit scoring module (614)), limit assignment (from the risk Management and limit allocation module (612)) and combine them with the business rules that third-parties (170) may implement. The RTDE (610) may enable portfolio segmentation based on different criteria and applying different logic for different segments.

The service provider server (152) further includes a propensity scoring module (616). Similar to credit scoring, the propensity scoring module (616) uses advanced Al and ML techniques on the data obtained from the utility provider system (1 10) in combination with external (3^rd-party) data to create a user profile index that can be used for marketing purposes. The propensity score may provide the likelihood of the following factors:

• a most likely time that a user would respond to marketing campaigns (hour of the day, day of the week, week of the month, month of the year);

• the likelihood of a user taking a type of a financial product;

• the likelihood of a user taking a type of an insurance product;

• the likelihood of churning (i.e. the user changing supplier);

• client purchase intentions; and

• the likelihood of the user being a community influencer.

The service provider server (152) further includes a customer relationship management (CRM) module (618). This module may often be utilised to check the loan transaction history of a user (120), credit limits and any loan collateralization with 3rd parties. This module may also be used to manage debt portability, i.e. when a user (120) moves address, by either closing any existing debt and stop any collaterals; of by transferring the debt and collaterals onto the new meter number.

The service provider server (152) further includes a reporting and revenue assurance (RA) module (620) that generates standard and bespoke reports for the utility provider system (1 10) and other 3rd parties; and a data sharing module (622) that exposes API’s for 3rd parties to obtain primary data, secondary data, credit scores and propensity scores;

The service provider server (152) further includes a Risk Strategy Console (624) that provides an interface for third parties to setup their own risk strategy and business rules on the real-time decision engine (RTDE) discussed above, including changing of the rules and eligibility criteria, setting different levels of custom scoring ranges (for example AAA, AA, A, BBB, BB), application of risk-based pricing strategies, and Dynamic Limit Assignment.

The service provider server (152) has a subscription management module (626) to manage subscriptions and micro-charging on the behalf of third-parties (170). As aforementioned, the methods described herein may be equally used for automatic vending of utility on loan; as well as automatic payment as a loan to third-parties (170) of subscriptions. The subscriptions and microcharging can be carried out on a daily, weekly, monthly, trimester, etc. Alternatively, the third- party (170) may send a request for the payment of the subscription to the subscription management module (626) of the service provider server (152).

Revenue assurance is an important process to ensure the correct recording of loan disbursement, loan recovery, payments and collateralization and then the correct calculation of transactions and revenues.

The reporting and revenue assurance (RA) module (620) facilitates the correct recording and tracking of transactions and revenues, as well as account reconciliation procedures as described above. It facilitates this by firstly managing a ledger or account (114, 156) on the utility provider system (1 10) or the service provider system (150) that could be in the form of a database, tables, sub-account or a counter on the charging system or any other sub-system. Secondly, special fields are added (also known as tokens) to the data records of the utility provider system. These include, but are not limited to: a. a transaction number; b. a transaction timestamp and value; c. a type of transaction (e.g. advance, principal, fee, payment, collateral, etc.); d. a tariff type; e. a debt collateralization / payment reference number; f. a lender I merchant name; g. a lender/merchant reference name and number; h. a payment or loan due date; i. flags; and j. a payment schedule.

As described above, where the methods herein are utilised to perform payment to a third party for a product or service as a loan to the user, the payment to the third party need not be made immediately. A reconciliation may be configurated between the service provider server (152) and the relevant third party.

The reporting and revenue assurance (RA) module (620) may facilitate the reconciliation process. The special fields enumerated above may be used as checks and balances during this reconciliation process. These special fields may further be used to verify transaction details in the combatting of fraud.

RA module (620) may be configured to, as part of the reconciliation facilitated thereby, reconciliate the offset a commission of a vendor that vended the utility token against the commission of the service provider (152) for the loaned amount. As described above, the user may, subsequent to a loan, purchase a utility token or voucher at a vendor, which may be a physical retailer outlet, or may be a virtual vendor with which the consumer communicates through a web interface, mobile application or the like. These are merely non-limiting examples of vendors through which utility tokens or vouchers may be purchased.

The vendor may forward the utility token purchase request to an intermediate aggregator which then forwards the request to a vending server associated with a utility provider. For having facilitated the vending of the utility token or voucher, the vendor may receive a commission. For example, the user (120) may purchase a $20 utility token or voucher from the vendor (at a POS (122) for example), for which the vendor may obtain an exemplary commission of 1 % ($0.20) from the utility provider (110). However, at the time that the service provider (150) provided a loan to the user (see steps 302 to 320 in Figure 3 for example), the service provider (150) may have also received a commission. For example, if the loan amount was $10, the service provider (150) may have earned a commission of 1% thereon, i.e. $0.10.

To avoid a double commission on the utility provider (110), the RA module (620) may reconcile the two transactions and offset the commission of the loan against the commission of the vended voucher. After all, the user (120) purchased $20 in total, and the utility provider (110) should pay commissions of $0.20 and not $0.30. The RA module (620) may also offset the commission on fees involved, such as service fee or a transaction fee.

Figure 7 illustrates an example of a computing device (700) in which various aspects of the disclosure may be implemented. The computing device (700) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

The computing device (700) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (700) to facilitate the functions described herein. The computing device (700) may include subsystems or components interconnected via a communication infrastructure (705) (for example, a communications bus, a network, etc.). The computing device (700) may include one or more processors (710) and at least one memory component in the form of computer-readable media. The one or more processors (710) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (700) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.

The memory components may include system memory (715), which may include read only memory (ROM) and random-access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (715) including operating system software. The memory components may also include secondary memory (720). The secondary memory (720) may include a fixed disk (721 ), such as a hard disk drive, and, optionally, one or more storage interfaces (722) for interfacing with storage components (723), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

The computing device (700) may include an external communications interface (730) for operation of the computing device (700) in a networked environment enabling transfer of data between multiple computing devices (700) and/or the Internet. Data transferred via the external communications interface (730) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (730) may enable communication of data between the computing device (700) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (700) via the communications interface (730). The external communications interface (730) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry. The external communications interface (730) may include a subscriber identity module (SIM) in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the computing device (700). One or more subscriber identity modules may be removable from or embedded in the computing device (700).

The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (710). A computer program product may be provided by a non-transient or non-transitory computer- readable medium, or may be provided via a signal or other transient or transitory means via the communications interface (730).

Interconnection via the communication infrastructure (705) allows the one or more processors (710) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (700) either directly or via an I/O controller (735). One or more displays (745) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (700) via a display or video adapter (740).

The invention therefore provides various advantages. As a first advantage, it may provide customers with a prepaid utility system with a convenient way to recharge their prepayment utility credit. The customer need not even have a debit or a credit card for online payment, or an internet connection, nor is the customer dependent on the availability of a brick and mortar point of sale. The invention may provide a convenient method to obtain a utility advance and repay at a later time.

Additionally, the invention provides financial inclusion to customers using the prepaid meters that may otherwise have been financially excluded due to the lack of financial history or a low credit rating. A major issue facing lenders in many markets is how to assess the credit worthiness of the unbanked and underbanked and how to collateralize the loans. The invention disclosed herein provides the advantage of connecting to third parties such as financial institutions and retailers and helps the financially excluded in at least two ways:

1 ) It may provide more accurate scoring based on their utility consumption behaviour and give more insights on their affordability levels; and

2) By artificially collateralizing the loan (or part of the loan) against future utility payments, the lenders reduce their cost of risk and can pass on the cost savings to the consumers. In other words, the consumers benefit by paying lower fees and interests.

These advantages may be illustrated by the following case studies.

Case study 1 - unsecured loans:

Consumers may apply for a loan and to get a cheaper rate they may provide their utility meter number and accept the terms and conditions that any arrears can be recovered from the current credit or future recharges of the utility meter.

Case study 2 - credit/store card:

Consumers may qualify for a credit or store card if they provide their utility meter number and accept the terms and conditions that any outstanding loan over a certain period (e.g. 90 days) can be recovered from the current credit or future recharges of the utility meter. The credit card becomes linked to the meter number.

Case study 3 -

For consumers who do not have a payment card or are uncomfortable proving card details online, this invention can help retailers process the purchase while providing a payment facility. For instance, the customer may be given 14 days to make the payment through mobile banking or by paying at a physical store. Through the interfacing of the service provider system (150) and third-parties (170), the invention may also enable the following functionalities to such third-parties:

1 ) Providing an interface to input the customers details and their meter numbers;

2) Cross-checking the user details against the information held by the utility company;

3) Providing a One Time Password (OTP) service to verify the user. The OTP can be sent to the third-party or shared directly with the user via any electronic means. One option may be to send the OTP to the registered mobile number with the utility company to prevent fraud;

4) Providing a proof of presence of the customer on the meter premises. By sending the OTP to the utility meter we ensure that the customer is present at the same place. This is a service given to the lenders to verify identity and address;

5) Providing an interface to collect the customers consent to share their information and to accept to pay any outstanding debt from their utility credit;

6) Providing an interface to trigger the collection of debt from existing credit or future recharges using methods described above with reference to Figure 3;

7) Providing an interface to block a part or a total of the existing credit or future recharges until the customers repay their debt. The block can be done: a) For existing credit by putting a reserve on the total or partial amount of the utility credit. b) For future recharges by putting a part or the full payment amount in an escrow account or sub-account. Alternatively it can be done by blocking the communication of the voucher after it is generated by the utility company platform or the distributor.

8) Providing an interface to unblock any previously blocked credit when the debt is settled;

9) providing these interfaces in the form of web interface, API’s or an SDK for a mobile application.

Further advantages enabled by the invention: Financial inclusion The invention may assist such a category of excluded customers to obtain financial services with better terms such as better loan interests or a more convenient repayment schedule. For instance, a financial institution may charge a high interest rate (e.g. 24% interest per annum) for unsecured loans but if the customer accepted to share their prepaid meter number and the accept the terms and conditions, the interest rate may be reduced to a much lower interest rate (e.g. 15% per annum). The customer gets a better deal because the financial institution can reduce the cost of risk.

Further advantages enabled bv the invention: Insurance pricing and claim/fraud management

The invention may hold further downstream benefits to the insurance industry in that it may assist insurers to better price the premiums for life and non-life insurance products such, as home insurance. Furthermore, it may assist insurers in assessing insurance claims and to combat fraud.

In the first instance, the credit scoring, propensity scoring, the credit report and certain utility data points may be used points to determine a premium for life and non-life insurance, in addition to enabling the cross-checking customer information. By way of example, an insurer may use the following information to price a home insurance policy: a) Energy consumption can be correlated with the size of the property and the number of electrical appliances; b) Energy efficiency can give an indication on the quality of the appliances (and thus disposable income); c) Consumption pattern can give an indication if the property is a main residence or a secondary home; and d) The frequency of energy outages in an area can give an indication on the likelihood of appliance damage.

In the second instance, i.e. to combat fraud, the insurer may cross-check insurance claims with meter data to combat fraud. For example, insurance companies can use the following information: a) Recorded tempering with the meter to investigate fraudulent claims; and b) Water consumption in a particular timeframe to check a water flooding claim.

The service provider system (150) may provide APIs to insurance companies for the following functionalities:

Cross check user information with the utility data; • Provide proof of presence in the address by sending a code to the meter;

• Provide a credit score and a credit report;

• Provide detailed report on the consumption behaviour and meter data during an agreed time frame (e.g. hourly, daily, weekly, monthly, etc.);

• Provide a propensity score; and

• Secondary information (i.e. extracted from the primary data) to assist with premium calculation or claim processing.

Figure 8 shows an example of the flow between the Financial Platform and the insurance company/broker.

At (801 ) the insurer company/broker provides an option for the user to consent to obtain more information from the utility provider system. Once the user accepts, the insurer initiates a call to an Information Request API that may be provided by the service provider system. Through this API the insurer requests the parameters it needs. Steps (802) and (803) can be hosted on a merchant platform or transferred to the service provider system.

At (802) the customers are prompted to enter their meter number and then their details are checked on the utility bill platform. If the details do not match, then the mismatch is reported to the insurance and the session may be terminated.

At (803) an OTP is generated and sent to the user via an online meter or any electronic means. The service provider system then receives and authenticate the input from the user.

At (804), once the user is authenticated, the requested parameters are sent to the insurer.

Moreover, the invention may provide a novel method of paying for goods and services online without the need for payment card. The method provided by the invention may enable “Direct Utility Billing” where payment is added to the bill or deducted from current or future credit recharges for prepaid customers.

Direct Utility Billing (DUB) (also exemplified and described with reference to Figure 3C above) is a new payment method that allows users to pay for online goods, products, support and services with the credit on their utility meter. Figure 9 shows the payment flow for an online transaction.

At (901 ) the third-party merchant provides an option to pay via DUB on the checkout page. Once the user selects this option, the merchant initiates a call to the Payment Request API provided by the service provider system. Through this API the merchant may send the user information and the amount requested. Steps (902) and (903) can be hosted on the merchant platform or transferred to the service provider system (similar to 3D secure for credit cards)

At (902) the user is prompted to enter their meter number, and then their details and balance are checked on the utility provider system. If the details do not match, then the session may be terminated, and an error message is sent to the merchant. If the customer has a prepaid meter and the balance is not sufficient, the service provider system may run the credit scoring (or eligibility check) and if the user is eligible for a loan then a credit facility may be offered.

At (903) an OTP is generated and sent to the user via the smart meter or any electronic means. The service provider system then receives and authenticates the input from the user. This is but one exemplary authentication method. An alternative exemplary authentication method may be to ask the user to input two or more digits from their latest utility token, for example to input the last 4 digits of the last utility token (for example their last electricity token). This type of challenge may be dynamic, and so on a next authentication, for example, the user may be challenged to enter the first 4 digits of their last utility token, or the first two and the last two digits, et cetera.

At (904), once the user is authenticated, the payment amount is debited from the user account on the utility provider system. For prepaid users the payment amount can be debited from their current prepay credit. Alternatively, the payment can be deducted from future recharges (using methods described above). For post-paid users, the payment amount can be added to the next post-pay bill.

An acknowledgement message may be sent to the merchant platform to notify of a successful transaction. The session is returned to the merchant domain if steps (902) and (903) were on the service provider system.

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient or non-transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non- transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD- ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations, such as accompanying flow diagrams, are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention set forth in any accompanying claims.

Finally, throughout the specification and any accompanying claims, unless the context requires otherwise, the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Claims

CLAIMS:

1 . A computer-implemented method, the method executed at a service provider server and comprising: receiving a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; determining that the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; recording the amount advanced against a loan account of the user; receiving notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and obtaining at least a part of the tendered payment and offsetting it against the loan account of the user.

2. The method as claimed in claim 1 wherein receiving a request for the advancing of the payment of a product or service on credit as a loan to a user associated with a utility meter is for the payment of a service or product to the benefit of a third party, the method further including forwarding the payment of the product or service to either the third party or the supplier of the product or service.

3. The method as claimed in claim 1 or 2 wherein recording the amount requested against a loan account of the user includes recording against the loan account of the user either or both of a transaction fee and interest associated with the amount advanced as a loan to the user.

4. The method as claimed in claim 1 or 2 wherein recording the amount requested against a loan account of the user includes, before the advance is effected, deducting either or both of a transaction fee and interest associated with the amount advanced as a loan to the user.

5. The method as claimed in any one of claims 1 to 4 wherein obtaining at least a part of the tendered payment and offsetting it against the loan account of the user comprises receiving notification from a utility provider of a vending request made to it, and deducting at least a part of the tendered payment as at least partial repayment of the value of the loan account.

35 The method as claimed in any one of claims 1 to 5 wherein obtaining at least a part of the tendered payment and offsetting it against the loan account of the user includes an immediate or near-immediate obtaining of the tendered payment from the entity to which payment was tendered. The method as claimed in any one of claims 1 to 5 wherein obtaining at least a part of the tendered payment and offsetting it against the loan account of the user is performed by means of a periodic account reconciliation with the entity to which payment was tendered. The method as claimed in any one of claims 2 to 7 wherein the request for the vending of a prepayment utility voucher for the utility meter is received via any one of the group consisting of: a short message service centre; a Unstructured Supplementary Service Data gateway; a web-based portal or mobile application; an interactive voice recording; and a point of sale. The method as claimed in any one of claims 1 to 8 further including determining that at least part of an amount requested for the advancing of the payment of a product or service on credit as a loan to the user exceeds a credit limit associated with the user; and blocking a part or a total of the amount advanced as a loan. The method as claimed in claim 9 further including removing the block upon the offsetting of at least part of the amount reflected in the loan account of the user. The method as claimed in claim 9 or 10 wherein blocking a part or a total of the amount of the amount requested as a loan may include putting a reserve on the total or partial amount of the amount requested as a loan. The method as claimed in any one of claims 1 to 11 wherein the amount requested for the advancing of the payment of a product or service on credit as a loan to a user associated with a utility meter is for the vending of a prepayment utility voucher on credit as a loan to the user, the method further including effecting the vending of a prepayment utility voucher for the utility meter with which the user is associated or a utility meter associated with a third party as a loan to the user and effecting the provision of the prepayment utility voucher for onward forwarding to or input into the relevant utility meter. The method as claimed in claim 12 wherein the relevant utility meter for which the prepayment utility voucher is vended is an online meter with which remote data communication is enabled, and wherein effecting the provision of the vended prepayment

36 voucher for onward forwarding to or input onto the relevant utility meter comprises updating the relevant utility meter remotely to reflect the vended utility.

14. The method as claimed in claim 12 or 13 wherein the utility meter for which a prepayment utility voucher is vended is an online meter, and wherein the method includes: receiving a request from the user to enable automated vending of a utility voucher as a loan to the user and providing it for onward forwarding to the relevant utility meter, the request including a threshold at which the automated vending is triggered, and optionally a value of the voucher to be automatically vended; detecting that remaining utility credit on the relevant meter is below the threshold; determining that the user has not yet reached a credit limit for the automated vending; and vending a utility voucher as a loan to the user and effecting its provision for onward forwarding to the relevant utility meter.

15. The method as claimed in claim 14 wherein the request received from the user to enable automated vending of a utility voucher as a loan includes a value of the utility voucher to be automatically vended.

16. The method as claimed in claim 12 wherein the relevant utility meter for which the prepayment utility voucher is vended is an offline meter which requires the input of the voucher onto the utility meter via a customer interface unit, and wherein effecting the provision of the vended prepayment voucher for onward forwarding to or input onto the relevant utility meter comprises presenting a user of the relevant utility meter with a voucher code or token to be entered onto the relevant utility meter.

17. The method as claimed in any one of claims 12 to 16 wherein recording a value associated with the vended prepayment utility voucher against a loan account of the user includes recording one or more of a transaction fee, interest, and commission associated with the vended prepayment utility voucher against the loan account of the user.

18. The method as claimed in any one of claims 12 to 16 wherein recording a value associated with the vended prepayment utility voucher against a loan account of the user includes deducting one or more of a transaction fee, interest, and commission associated with the vended prepayment utility voucher from the value of the voucher to be vended.

19. The method as claimed in any one of claims 17 and 18 wherein obtaining at least a part of the tendered payment and offsetting it against the loan account of the user comprises reconciling a service fee and/or a commission levied on the amount requested to be advancing on credit as a loan to a user; and a service fee and/or commission levied by a vendor to whom the user tendered the payment.

20. The method as claimed in any one of claims 12 to 19 wherein obtaining at least a part of the tendered payment and offsetting it against the loan account of the user comprises receiving a vended utility voucher for the tendered amount, converting the vended voucher into two or more vouchers having a combined value of the tendered amount, providing one of the converted vouchers for onward forwarding to or input onto the utility meter, and withholding the remainder of the vouchers as repayment for one or more of: a principal utility value previously provided to the user as a loan, a service fee, an interest amount; and a commission.

21 . The method as claimed in any one of claims 12 to 20 wherein vending a prepayment utility voucher as a loan to the user includes vending the prepayment utility voucher at an increased tariff rate relative to the nominal tariff rate charged to the utility meter.

22. A system including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the system comprising: a data source component arranged to receive a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; a real-time decision engine arranged to determining whether the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; a reporting and revenue assurance module arranged to record the amount advanced against a loan account of the user; a third-party data interface component arranged to receive notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and wherein the reporting and revenue assurance module is further arranged to obtain at least a part of the tendered payment and offsetting it against the loan account of the user.

23. A computer program product, the computer program product comprising a computer- readable medium having stored computer-readable program code for performing the steps of: receiving a request for the advancing of the payment of a product or service on credit as a loan to a user, the user being associated with a utility meter; determining that the user is eligible for being advanced the payment of the product or service as a loan; effecting the advance of the payment of the product or service as a loan; recording the amount advanced against a loan account of the user; receiving notification of payment being tendered for either the vending of a prepayment utility voucher for the utility meter or towards the payment of a post-payment utility account associated with the utility meter; and obtaining at least a part of the tendered payment and offsetting it against the loan account of the user.

39