TECHNICAL FIELD

The present disclosure relates broadly to a portfolio system for coupling to a transactions system to maintain a shadow portfolio and to a method of maintaining a shadow portfolio for a transactions system.

BACKGROUND

With the progression of communications and internet technology resulting in an increasing global coverage for sellers of goods and services, the number of e-commerce stores has been increasing and the amount of digital marketing efforts expended by such sellers/organisations have been increasing. As such, organisations are investing resources including money to acquire and to retain new clients/customers amidst competition with rivals. As a result, customer acquisition cost for e-commerce has been increasing.

One existing method to acquire and to retain customers is through providing incentives and having similar initiatives. One such initiative is typically providing a customer loyalty program/system. A customer loyalty program/system may include an award/reward system that provides an award or reward issued or earned by a user due to consumption on goods and/or services. It is recognised that a successful reward program/system is typically dependent on an amount of awards/ rewards, such as loyalty points, that a user/customer may accumulate and the ease at which a user/customer may accumulate the amount of awards/rewards.

However, the inventor(s) have also recognised that organisations that implement such award/reward systems typically set an expiry date on accumulated awards/rewards to avoid significant exposure to eventual high amounts of awards/rewards that may be accumulated by users/customers/members over time. Such actions may typically cause lowered interest, lowered participation, lowered loyalty etc. from users/members of these award/reward systems. Over time, the cost for customer acquisition would typically increase.

Further, the inventor(s) have recognised that there are difficulties for existing award/reward systems to facilitate or establish communications or link-ups with other systems such as potential partners for the awards/rewards due to the identified deficiencies of the existing award/reward systems. For example, such other systems may belong to merchandisers and other companies. For example, potential partners may not find it attractive or easy to link up with existing award/reward systems due to lowered interest, lowered participation, lowered loyalty etc. from users/members of these award/reward systems.

In view of the above, there exists a need for a portfolio system for coupling to a transactions system to maintain a shadow portfolio and a method of maintaining a shadow portfolio for a transactions system that seek to address at least one of the above problems.

SUMMARY

In accordance with an aspect of the present disclosure, there is provided a portfolio system for coupling to one or more transactions systems to maintain a shadow portfolio, the portfolio system comprising an input module, the input module configured to receive one or more transactions records; a portfolio module coupled to the input module, the portfolio module configured to maintain a shadow portfolio, the portfolio module further configured to update the shadow portfolio with a portfolio value, the update being based on reward information included in the one or more transaction records and the portfolio value maintains an asset backing to the shadow portfolio; and a backer module coupled to the portfolio module, the backer module being configured to facilitate an increment of the portfolio value.

The increment of the portfolio value may comprise a positive increment or a negative increment.

The portfolio module may be configured to update the shadow portfolio with the portfolio value based on a pre-determined relationship rule between a reward value of the reward information and an asset value.

If the increment of the portfolio value is a positive increment, the portfolio module may be configured to extract an amount of asset backing to increase the asset backing, the extraction being via the backer module to the portfolio module.

If the increment of the portfolio value is a negative increment, the portfolio module may be configured to withdraw an amount of asset backing to decrease the asset backing, the withdrawal being via the backer module from the portfolio module.

The shadow portfolio may be associated with the one or more transactions systems.

The shadow portfolio may be associated with a user of the one or more transactions systems.

The input module may be further configured to receive interest information indicating a computed interest yield and upon receipt of the interest information, the portfolio module may be configured to update the portfolio value with the computed interest yield, wherein the update of the portfolio value with the computed interest yield may comprise an interest extraction of an interest amount of asset backing to increase the asset backing, the interest extraction being via the backer module to the portfolio module. The portfolio module may be configured to utilise the asset backing for transfer to one or more merchandisers, the transfer being based on the one or more transaction records.

The portfolio module may be configured to utilise the asset backing for monetary conversion, the monetary conversion being based on the one or more transaction records.

The backer module may be configured to receive an injection of assets and the backer module may be further configured to generate a corresponding injected reward value based on the injection of assets, and wherein the input module may be further configured to transmit the injected reward value for use externally of the portfolio system.

The portfolio module may be further configured to update the shadow portfolio with the portfolio value, the update being based on reward information associated with the injected reward value, the reward information included in the one or more transaction records and the portfolio value may maintain the asset backing to the shadow portfolio with the asset backing being increased based on the injection of the assets.

In accordance with another aspect of the present disclosure, there is provided a method of maintaining a shadow portfolio, the method comprising providing a portfolio module to maintain a shadow portfolio; providing a backer module; receiving one or more transactions records from one or more transactions systems; updating the shadow portfolio with a portfolio value, the updating being based on reward information included in the one or more transaction records; facilitating an increment of the portfolio value using the backer module; and maintaining an asset backing to the shadow portfolio with the portfolio value.

The increment of the portfolio value may comprise a positive increment or a negative increment. The step of updating the shadow portfolio with the portfolio value may be further based on a pre-determined relationship rule between a reward value of the reward information and an asset value.

If the increment of the portfolio value is a positive increment, the step of updating the shadow portfolio with the portfolio value may comprise extracting an amount of asset backing to increase the asset backing, the extracting being via the backer module to the portfolio module.

If the increment of the portfolio value is a negative increment, the step of updating the shadow portfolio with the portfolio value may comprise withdrawing an amount of asset backing to decrease the asset backing, the withdrawing being via the backer module from the portfolio module.

The method may further comprise associating the shadow portfolio with the one or more transaction systems.

The method may further comprise associating the shadow portfolio with a user of the one or more transaction systems.

The method may further comprise receiving interest information indicating a computed interest yield; and the step of updating the shadow portfolio with the portfolio value may comprise an interest extracting of an interest amount of asset backing to increase the asset backing, the interest extracting being via the backer module to the portfolio module.

The method may further comprise utilising the asset backing for transfer to one or more merchandisers, the transfer being based on the one or more transaction records. The method may further comprise utilising the asset backing for monetary conversion, the monetary conversion being based on the one or more transaction records.

The method may further comprise receiving an injection of assets via the backer module; generating a corresponding injected reward value based on the injection of assets; and transmitting the injected reward value for use at the one or more transactions systems.

The method may further comprise receiving reward information associated with the injected reward value, the reward information included in the one or more transaction records; and increasing the asset backing based on the injection of the assets.

In accordance with another aspect of the present disclosure, there is provided a non-transitory tangible computer readable storage medium having stored thereon software instructions that, when executed by a computer processor of a portfolio system to maintain a shadow portfolio, cause the computer processor to perform a method of maintaining a shadow portfolio, by executing the steps comprising providing a portfolio module to maintain a shadow portfolio; providing a backer module; receiving one or more transactions records from one or more transaction systems; updating the shadow portfolio with a portfolio value, the updating being based on reward information included in the one or more transaction records; facilitating an increment of the portfolio value using the backer module; and maintaining an asset backing to the shadow portfolio with the portfolio value.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which: FIG. 1 is a schematic drawing of a portfolio system to maintain a shadow portfolio in an exemplary embodiment.

FIG. 2 is a schematic diagram of a system framework to maintain a shadow portfolio in another exemplary embodiment.

FIG. 3 is a schematic flowchart for illustrating a method of maintaining a shadow portfolio in an exemplary embodiment.

FIG. 4A is a schematic block diagram for illustrating an example backer module in an exemplary embodiment.

FIG. 4B is a schematic block diagram for illustrating an example backer module in another exemplary embodiment.

FIG. 5 is a schematic diagram of a system framework to maintain a shadow portfolio in another exemplary embodiment.

FIG. 6 is a schematic drawing of a computer system suitable for implementing an exemplary embodiment.

DETAILED DESCRIPTION

Exemplary embodiments described herein may provide a portfolio system for coupling to a transactions system to maintain a shadow portfolio and a method of maintaining a shadow portfolio for a transactions system.

A portfolio system for coupling to one or more transactions systems to maintain a shadow portfolio may be provided in an exemplary embodiment. The portfolio system comprises an input module that is configured to receive one or more transactions records. The transaction records may be transmitted from a coupled transactions system. The portfolio system also comprises a portfolio module coupled to the input module. The portfolio module is configured to maintain a shadow portfolio. The portfolio module is further configured to update the shadow portfolio with a portfolio value. The portfolio value is updated using reward information included in the one or more transaction records. The reward information may comprise a reward value that informs the portfolio module to increase or decrease the portfolio value. The portfolio value maintains an asset backing to the shadow portfolio. Such asset backing may be monetary assets, cash reserves, or any matter with an equivalent monetary value etc. For example, with an increase in portfolio value, a monetary asset or cash reserve may be increased as an increased asset backing to the shadow portfolio. For example, with a decrease in portfolio value, a monetary asset or cash reserve may be decreased/withdrawn as a decrease in asset backing to the shadow portfolio. In the exemplary embodiment, the portfolio system further comprises a backer module coupled to the portfolio module. The backer module is configured to facilitate an increment of the portfolio value. For example, the backer module may be an interface between the portfolio system and a financial entity system. The backer module may allow inflow and outflow of assets, asset backing such as monetary assets.

In the exemplary embodiment, the shadow portfolio may be associated with a respective transactions system. In addition, or as an alternative, the shadow portfolio may be associated with a respective user of a coupled transactions system. In such instances, the shadow portfolio or the corresponding portfolio value may be viewed as being a designated account of the transactions system and/or user.

In the exemplary embodiment, the portfolio module may utilise the asset backing for transfer to one or more merchandisers, the transfer being based on the reward information. For example, if a user redeems a good and/or service using an amount of reward points within the transaction system, the asset backing may be used for payment to a merchandiser of the good and/or service via the portfolio system. Such payment may be based on reward information included in a transaction record and sent to the portfolio system. In the exemplary embodiment, the portfolio module may utilise the asset backing for monetary conversion, the monetary conversion being based on the reward information. For example, if a user uses an amount of reward points within the transaction system to convert to cash, the asset backing may be used for the cash conversion via the portfolio system. Such conversion may be based on reward information included in a transaction record and sent to the portfolio system.

FIG. 1 is a schematic drawing of a portfolio system to maintain a shadow portfolio in an exemplary embodiment. The portfolio system 100 may be coupled to one or more transactions systems. Such coupling may be by any wired and/or wireless connections.

In the exemplary embodiment, the portfolio system 100 comprises an input module 102. In the exemplary embodiment, the input module 102 is configured to receive one or more transaction records from a transactions system (not shown).

In the exemplary embodiment, the portfolio system 100 further comprises a portfolio module 104 coupled to the input module 102. In the exemplary embodiment, the portfolio system 100 further comprises a backer module 106 coupled to the portfolio module 104. In some exemplary embodiments, the components of the portfolio system 100 may be coupled to a processing module that may instruct and control the operations of the portfolio system 100.

In the exemplary embodiment, the portfolio module 104 is configured to maintain a shadow portfolio and to update the shadow portfolio with a portfolio value. Thus, the portfolio module 104 is configured to update the portfolio value. The portfolio value may be, for example, a value indicating or relating to an amount of monetary assets available to a coupled transactions system. The portfolio value therefore maintains an asset backing to the shadow portfolio. The portfolio module 104 is arranged to update the portfolio value based on the one or more transaction records received by the input module 102. In the exemplary embodiment, the backer module 106 is configured to facilitate an increment of the portfolio value. The backer module 106 may be an interface between the portfolio system 100 and a financial institution. That is, the portfolio system 100 may be further connected to or coupled to a financial institution system, such as a bank. The linkage may be facilitated by a wired or wireless connection or a combination of both types of connections. In the exemplary embodiment, the backer module 106 may be coupled to a database, an account, and/or a depository component etc. linked to a financial institution such as a bank entity.

In some exemplary embodiments, the backer module 106 may further store and update a backer value. The backer value may be, for example, a value indicating an amount of monetary assets (e.g. overall cash reserve) or a value relating to the amount of monetary assets (e.g. overall cash value) available to a backer e.g. an entity operating the portfolio system 100. The backer value may also comprise a planned outflow of monetary assets from the portfolio module 104, e.g. assets stored in a first buffer of the backer module 106 that functions as a holding platform for scheduled payment to e.g. one or more merchandisers.

In the exemplary embodiment, each transaction record is based on an award/reward process. For example, the transactions system may implement an award/reward process based on e.g. consumption of and/or expenditure on goods and/or services (i.e. transactions) of one or more users/members of the transactions system. In the exemplary embodiment, each transaction record may comprise a reward/award information indicating a positive or negative increment of a reward/award value. Such a reward value may be of any form rewarded or awarded based on one or more transactions that has been performed at the transactions system. Some forms may include, but are not limited to, reward points, loyalty points, coupons etc. The reward value may be determined based on, for example, the value of the one or more transactions that has been performed at the transactions system.

In the exemplary embodiment, the portfolio module 104 is configured to update the portfolio value based on the reward information of each transaction record. In use, the input module 102 receives a transaction record from a coupled transactions system. The input module 102 transmits the transaction record to the portfolio module 104. The portfolio module 104 processes the transaction record to determine a positive or negative increment of a reward value. If there is a positive increment (or an increase) of a reward value, the portfolio module 104 increases a portfolio value associated with the transactions system. The portfolio module 104 determines the portfolio value based on a pre-determined relationship rule. In the exemplary embodiment, the increase in the portfolio value is based on an extraction of an amount of monetary assets instructed by the portfolio module 104 via the backer module 106 from the financial institution to the portfolio module 104. In some other exemplary embodiments, such an extraction results in a decrease in a backer value stored in the backer module 106, i.e. from an overall cash reserve of a backer.

On the other hand, if there is a negative increment (or a decrease) of a reward value, the portfolio module 104 decreases the portfolio value associated with the transactions system. In the exemplary embodiment, the decrease in the portfolio value is based on a withdrawal of an amount of monetary assets instructed by the portfolio module 104 from the portfolio module 104 via the backer module 106. In some other exemplary embodiments, such a withdrawal via the backer module 106 may result in an increase in the backer value stored in the backer module 106, e.g. as an amount of payment to one or more merchandisers. In such exemplary embodiments, the backer module 106 increases or decreases the backer value based on a respective withdrawal of an amount of monetary assets from the portfolio module 104 or an extraction of an amount of monetary assets via the backer module 106 to the portfolio module 104. In the exemplary embodiments, the portfolio value thus maintains an asset backing to the shadow portfolio of the transaction system, based on the monetary assets. In the exemplary embodiment, the input module 102 receives the transaction record at a time. This time may, for example but is not limited to, be a periodic interval, real-time, a system prompted activation time, or a user prompted activation time. In the exemplary embodiment, therefore, the reward value of the transactions system is backed by a monetary value. The transactions system therefore has an associated shadow portfolio that shadows/tracks the reward value of the transactions system. In the exemplary embodiment, the portfolio value is associated with the transactions system as a whole.

In the exemplary embodiment, the portfolio value may be subjected to earning interest and therefore, may increase over time due to an interest yield. Further, in some other exemplary embodiments, the backer value may be subjected to a decrease due to external withdrawal e.g. as payment to one or more merchandisers for provision of goods and/or services related to usage of the transactions system.

In some exemplary embodiments, an audit module may be added to the portfolio system 100 such that one or more audit processes may be performed on the portfolio module 104 and/or the portfolio value to detect any abnormalities with the portfolio module operations.

In some exemplary embodiments, the portfolio system 100 may be connected to or coupled to more than one transactions systems. Each transactions system may be arranged to, based on one or more transactions that has been performed at the respective transactions system, generate one or more transaction records and transmit the transaction records to the input module 102 of the system 100.

In such exemplary embodiments, each transaction record may additionally comprise transactions system information. The transactions system information may comprise an identifier for identifying the respective transactions system from which each transaction record was generated and transmitted from. As an example, such an identifier may be tagged/appended/encrypted to reward information.

In such exemplary embodiments, different respective portfolio values may be stored in the portfolio system 100, for example, in a portfolio database included in the portfolio module 104. As such, each transactions system may be matched with its respective portfolio value and thus, respective shadow portfolio.

FIG. 2 is a schematic diagram of a system framework to maintain a shadow portfolio in another exemplary embodiment. In this exemplary embodiment, the system framework provides a portfolio system 200 that functions substantially similarly to the portfolio system 100 described with reference to FIG. 1. For ease of reference, like numerals and/or naming conventions are used for exemplary implementations of similar modules as described in FIG. 1 and FIG. 2.

In the exemplary embodiment, the portfolio system 200 is coupled to a transactions system 202 and a merchandisers system 204.

In some exemplary embodiments, the portfolio system 200, the transactions system 202 and the merchandisers system 204 may each be provided with a processing module that is configured to carry out the steps described with reference to FIG. 2.

In the exemplary embodiment, the transactions system 202 may facilitate transactions. As an example only, the transactions system 202 may facilitate the purchase of product A (see numeral 206A), product B (see numeral 206B) and product C (see numeral 206C). The transactions system 202 is configured to implement an award/reward process. Based on the expenditure/consumption of the three transactions 206A, 206B, 206C, the transactions system 202 may compute an amount of reward points as a reward value. Such reward points may be termed as member points e.g. rewards/awards to one or more users/members participating in the award/reward process of the transactions system 202. See numeral 208. In such an instance, there is a positive increment (or increase) of the reward value.

In the exemplary embodiment, the transactions system 202 may be configured to update (or increase) an accumulated/tallied amount of member points. See numeral 210. In some exemplary embodiments, the tallied amount of member points may be stored in a users/members database included in the transactions system 202. The tallied amount of member points may be segregated into respective individual members’ accounts maintained at the transactions system 202.

In the exemplary embodiment, at a first time, the transactions system 202 is configured to generate a transaction record that comprises a reward information indicating a positive or negative increment of the reward value.

In some exemplary embodiments, the transactions system 202 may be configured to also include, in the transaction record, an identifier for identifying the transactions system from which the transaction record was generated. In some exemplary embodiments, the transaction record may further include user information (e.g. information to identify each user/member associated with the reward value of the transaction record in the transaction record). In such exemplary embodiments, the user information may, for example only, be tagged/appended/encrypted to reward information.

In the exemplary embodiment, the transactions system 202 may be configured to, upon generating the transaction record, transmit the transaction record to the portfolio system 200.

In the exemplary embodiment, the portfolio system 200 may comprise an input module, a portfolio module and a backer module. Compare portfolio system 100 of FIG. 1 comprising the input module 102, the portfolio module 104 and the backer module 106.

In the exemplary embodiment, the portfolio system 200 may be further coupled to a financial institution, such as a bank entity, via the backer module. In the exemplary embodiment, the input module of the portfolio system 200 is configured to receive one or more transaction records transmitted by the transactions system 202.

Upon receiving a transaction record comprising a positive increment of the reward value, the portfolio module is configured to compute, based on a pre-determined relationship rule, an amount of monetary assets corresponding to the positive increment (i.e. increase) in the reward value indicated in the received transaction record. The portfolio system 200 (compare portfolio module 104 of FIG. 1) is configured to instruct and extract the computed amount of monetary assets via the backer module to the portfolio module. The extracted amount of monetary assets is used to update a portfolio value associated with the transactions system 202, i.e. an increase in portfolio value. This may be viewed or termed as a top-up 218 of a monetary or cash reserve as a top- up to an asset or monetary backing to a shadow portfolio of the transactions system 202. See numeral 218.

In the exemplary embodiment, based on any extraction and/or withdrawal of the monetary assets to and/or from the portfolio module as instructed by the portfolio module via the backer module, the portfolio system 200 is configured to update (increase and/or decrease respectively) the portfolio value stored in the portfolio module. Thus, this may be viewed or termed as an update 220 of a monetary or cash reserve as an asset backing to the shadow portfolio of the transactions system 202. See numeral 220.

As such, the portfolio value maintains an asset backing to the shadow portfolio. The backer module is thus configured to facilitate an increment (either positive or negative) of the portfolio value.

In the exemplary embodiment, the one or more members participating in the award/reward process of the transactions system 202 may be allowed to utilise their respective member points. For example, at a second time (or any time independent of the operations of the portfolio system 200), the transactions system 202 may be configured to prompt and query a member/user on whether the user wishes to claim (or redeem or use) any amount of the user’s accumulated member points. For example, at a second time (or any time independent of the operations of the portfolio system 200), a member/user on the user's own accord may decide or wish to claim (or redeem or use) any amount of the user’s accumulated member points. See numeral 212. In some exemplary embodiments, the transactions system 202 may be provided with an input module/device, such as but not limited to, a touch sensitive screen that is configured to receive such a user input.

In the exemplary embodiment, if the user input indicates that the user does not wish to claim any of the user’s member points, the transactions system 202 may take no further action. See numeral 214.

In the exemplary embodiment, if the user input indicates that the user wishes to claim some or all of the user’s accumulated member points, the transactions system 202 may select from a set of pre-determined units of member points for the claiming (e.g. 5 points, 10 points, 20 points etc.). Alternatively, or additionally, the user may be allowed to provide a user input on the desired amount of member points for the claiming.

In the exemplary embodiment, upon settlement of the claiming (or redemption or usage) of the member points, the transactions system 202 is configured to update (or decrease) the accumulated/tallied amount of member points. See numeral 216.

In the exemplary embodiment, at a third time (or any time independent of the operations of the portfolio system 200), the transactions system 202 is configured to generate a transactions record that comprises a reward information indicating a negative increment of the reward value. The transaction record is transmitted to the portfolio system 200.

At the portfolio system 200, upon receiving a transaction record comprising a negative increment of the reward value, the portfolio module is configured to compute, based on the pre-determined relationship rule, an amount of monetary assets corresponding to the negative increment (i.e. decrease) in the reward value indicated in the received transaction record. The portfolio system 200 (or the portfolio module) is configured to withdraw the computed amount of monetary assets from the portfolio module, instructed by the portfolio module, via the backer module. This may be viewed or termed as a withdrawal 224 of a monetary or cash reserve as withdrawal from an asset or monetary backing to the shadow portfolio of the transactions system 202. See numeral 224. In the exemplary embodiment, a withdrawal such as the above results in an update of the portfolio value, and thus, the asset backing. Refer also to description relating to numeral 220.

In the exemplary embodiment, a user may claim or redeem or use the user’s accumulated reward points e.g. to redeem a product (an item, a voucher etc.) and/or a service from a merchandiser(s). In the exemplary embodiment, the portfolio system 200 when coupled to the merchandisers system 204, may be configured to receive a transaction record that comprises information indicating a negative increment of the reward value and further comprises claim information and destination information. As an example, the claim information and destination information may be tagged/appended/encrypted to reward information. Claim information may indicate whether the transactions system 202 is to have a withdrawal 224 of the asset backing e.g. monetary/cash reserve and destination information (e.g. destination bank account details of merchandisers) may indicate the destination(s) where the withdrawal of the asset backing e.g. monetary asset is to be transferred to in order to perform the redemption from the merchandiser(s). In the exemplary embodiment, upon receiving a transaction record comprising claim information and destination information, the portfolio system 200 is configured to withdraw the calculated asset value from a designated bank account of the transactions system 202 i.e. to withdraw from the asset backing e.g. monetary/cash reserve of the transactions system 202 (see numeral 224) and to transmit the calculated asset value to the indicated destination, e.g. the bank account of the merchandiser(s), and to settle payment to the merchandiser(s) (see numeral 226). For example, the withdrawal is instructed by the portfolio module and facilitated via the backer module. In such instances, the shadow portfolio of the transactions system 202 is viewed or termed as the designated bank account of the transactions system 202.

In the exemplary embodiment, the monetary/cash reserve (or portfolio value) may earn interest. For example, the input module of the portfolio system 200 may periodically (monthly, yearly etc.) receive interest information from a financial entity/system that the portfolio system 200 is coupled to. Interest information may indicate an interest yield. See numeral 222. The interest yield may be computed based on the amount of monetary assets available in each portfolio or portfolio value stored in the portfolio module. For the above, any suitable interest rate may be utilised.

In the exemplary embodiment, based on the computed interest yield in the interest information, the financial entity/system may deposit the computed interest yield into the portfolio of the transactions system 202, i.e. to top up 218 the cash reserve. See numeral 218.

In the exemplary embodiment, based on the cash reserve top up 218, the portfolio system 200 and the portfolio module may be configured to update 220 (or increase) the portfolio value of the transactions system 202. See numeral 220.

In the exemplary embodiments, a reward system that is backed by assets e.g. monetary/cash reserves in e.g. an independent designated bank account (or a shadow portfolio) may be provided. For example, if it is pre-determined that every one (1) reward point corresponds to a monetary value of $0.10, then for every increment of 100 reward points detected (i.e. at a portfolio module based on a transaction record from a transactions system), the portfolio module of the portfolio system may be configured to instruct a deposit of $10.00 into the portfolio value associated with the relevant transactions system. The extraction of such an amount may be instructed by the portfolio module and via a backer module of the portfolio system that is in turn associated with a bank account of a backer e.g. an entity operating the portfolio system. The shadow portfolio and its portfolio value may thus be viewed as a designated bank account of the transactions system. The shadow portfolio is therefore provided that tracks/shadows the reward value (whether increment or decrement) from the transactions system.

In the exemplary embodiments, the asset backing e.g. monetary/cash reserve in the designated bank account of the transactions system may not be withdrawn except when, for example, a member/user of the transactions system instructs to use the member’s accumulated reward points e.g. to redeem or consume a product and/or service, or even to request for cash conversion (from reward points). In other words, the asset backing e.g. monetary/cash reserve may solely be used for payment to a fulfilment centre vendor/merchandiser and/or cash redemption by members/users.

In some exemplary embodiments, the amount of assets e.g. monetary/cash reserve in the designated bank account may be audited periodically to provide confidence and transparency.

In some exemplary embodiments, each portfolio value stored in the portfolio module (compare portfolio module 104 of FIG. 1) may indicate the total amount of asset backing (e.g. monetary/cash backing) available to each transactions system that a portfolio system is connected to/coupled to. In such exemplary embodiments, the asset backing is in relation to each transactions system. Thus, in these exemplary embodiments, accounting for asset backing e.g. monetary/cash backing relating to each user/member of each transactions system is performed within the each transactions system.

In some other exemplary embodiments, a portfolio value may also indicate the total amount of asset backing available to each user/member. That is, the accounting for the asset backing e.g. monetary/cash backing relating to each member of the transactions system(s) coupled to the portfolio system is instead performed at the portfolio system.

In such exemplary embodiments, the transaction records transmitted to the portfolio system (compare portfolio system 100 of FIG. 1) via the input module (compare input module 102 of FIG. 1) may additionally comprise user information. The user information is used to identify each user (for example, using a unique serial ID tagged to each user). As an example, the user information may be tagged/appended/encrypted to reward information. In such exemplary embodiments, the portfolio module of the portfolio system may be configured to extract the user information from each transaction record received. In such exemplary embodiments, the portfolio module is configured to update respective portfolio values belonging to respective users/members (e.g. an individual shadow account/portfolio each). As such, a portfolio database may be provided at the portfolio module to store the different portfolio values relating to different users/members. Thus, in such exemplary embodiments, the updating of the portfolio values follows substantially similarly the other exemplary embodiments, i.e. based on increment or decrement and based on each transaction record received (and further based on user information to identify the respective shadow portfolio and/or portfolio value).

Therefore, there may be provided exemplary embodiments that operate shadow portfolios relating to users/members, rather than to transactions systems as a whole. Aspects such as redemption, interest yield etc. may also apply to the individual portfolio values of the different users/members.

In the described exemplary embodiments herein, by providing a portfolio system as described for coupling to one or more transaction systems, such a portfolio system may provide technical scalability to work with existing transaction systems. For example, the portfolio system may couple to one or more transaction systems as and when required and may add on additional couplings to more transaction systems as the ecosystem of portfolio system-transaction systems scale to a bigger size. Further, in the described exemplary embodiments herein, the portfolio system as described can provide increased reliability and integrity as there is provided a shadow portfolio with a portfolio value and such a portfolio value is used to maintain an actual and reliable asset backing to the shadow portfolio. With an asset backing known to the coupled one or more transaction systems and / or one or more users of the one or more transaction systems, it is relatively more trusted to couple with such a portfolio system.

In the described exemplary embodiments, a portfolio module may be configured to update a portfolio value based on a pre-determined relationship rule between the reward information (in a received transaction record) and an asset value. The asset value may refer to a value indicating or relating to an amount of monetary assets. In the exemplary embodiment, the asset value may be a value proportional to the reward value indicated in the reward information of the transaction record. For example, the pre-determined relationship rule may be a ratio to update the portfolio value, the ratio being based on an increment or decrement of X reward point(s) indicated in the reward information to a value of $Y (the asset value). The ratio of X:Y (reward value : asset value) may be, for example, 100:1 , 1 :1 , or 1 :5. It will be appreciated that the exemplary embodiment is not limited to the above ratios and other ratios may be utilised.

In the exemplary embodiment, if there is a positive increment of the reward value, the portfolio module is configured to increase the portfolio value by a value (the asset value) proportional to the positive increment. For example, for every positive increment of X reward point(s), the portfolio module is configured to increase the portfolio value by $Y according to the pre-determined ratio.

In some exemplary embodiments, for accounting purposes of a backer’s overall cash reserve, the backer value stored in the backer module is decreased correspondingly to the increase in the portfolio value, due to the extraction of monetary assets via the backer module into the portfolio module for the shadow portfolio.

Conversely, if there is a negative increment (or decrease) of the reward value, the portfolio value is correspondingly decreased using the ratio. For example, for every negative increment of X reward point(s), the portfolio module is configured to decrease the portfolio value by $Y according to the pre-determined ratio.

In some exemplary embodiments, for accounting purposes of payment to e.g. one or more merchandisers of goods and/or services redeemed/consumed at the transactions system, the backer value stored in the backer module is increased correspondingly to the decrease in the portfolio value, due to the withdrawal of monetary assets from the portfolio module (from the shadow portfolio) via or towards the backer module. In the above exemplary embodiments, it is recognised that each portfolio or each portfolio value may therefore usefully shadow the transaction records of each transactions system and/or each user/member of one or more transactions systems. As such, there is provided a respective shadow portfolio that tracks the transaction records (and respective reward values) and in turn maintains an asset backing e.g. monetary/cash backing to the transactions system (s) and/or the user(s).

In the described exemplary embodiments, a portfolio system is provided wherein every reward point (or more broadly, reward value) given to members/users may be usefully backed by an equivalent or corresponding/proportional amount of assets e.g. monetary asset or cash in a designated cash reserve account (or shadow portfolio) which is associated to a transactions system in which the members/users are participating. In the described exemplary embodiments, the amount in the designated bank account may not belong to the entity/organisation operating the transactions system but is instead an asset backing to all members (or reward points owners) respectively. The asset backing e.g. monetary/cash reserve may be held on trust and audited from time to time for a relatively high level of transparency. In addition, any interest that may be generated by the assets e.g. cash reserve in the designated bank account may also be reinvested/deposited into the designated bank account (or shadow portfolio). The inventor(s) has recognised that this may create possibilities to generate more value to the reward points accumulated by the members.

In the described exemplary embodiments, by providing a reward system that is backed by assets e.g. a monetary/cash reserve, an entity/organisation may no longer be concerned about members (or users) of the entity’s transactions system accumulating excessive reward points. For example, if the transactions system is combined with a referral program (e.g. members being provided with additional reward value or points when the members successfully introduce new users/members to the transactions system), members are able to accumulate reward points quicker with the additional assurance that their accumulated reward points are backed by assets e.g. monetary assets/cash and are valid (e.g. will not expire). The members may even convert the accumulated points into cash at any time. This may incentivise members to refer more new members, potentially and usefully reducing the cost of customer acquisition for the entity/organisation of the transactions system.

In the described exemplary embodiments, the portfolio system may be licensed to various entities/companies to boost their respective customer loyalty programs and to eventually reduce their overall marketing cost. Alternatively, or additionally, the portfolio system may be utilised to even manage the loyalty programs of such companies. Any company/entity/organisation that wishes to improve their customer loyalty program(s) may be a target licensee.

The inventor(s) have recognised that it may cost five times as much to acquire new members/users/customers than it does to keep current members/users/customers. The inventor(s) have thus recognised that by having a successful customer loyalty program (i.e. implemented with a portfolio system of exemplary embodiments), an entity/organisation (of a transactions system) may be able to reap savings in customer acquisition cost. Based on the described exemplary embodiments, as reward value or points are backed by assets e.g. a monetary/cash reserve, more possibilities become available on ways to utilise reward points. For example only, an entity or a company may allow members to use reward points to purchase stock options in a company pre-IPO (pre- initial public offering) as an incentive to create even more customer loyalty.

In the described exemplary embodiments, the portfolio system may additionally incorporate blockchain technology to increase the reliability and transparency of the system. When blockchain technology is incorporated into the portfolio system, for example, the portfolio module and portfolio value(s) of the portfolio system may function to act as ledger(s) for the portfolio system.

With various exemplary embodiments, the portfolio system may provide financial benefits to entities/companies by providing a means to reduce at least customer acquisition costs. As the entities/companies utilise or integrate the portfolio system with their existing transactions system(s), this may also facilitate or establish communications or link-ups with existing systems belonging to new potential partners for members to earn awards/rewards. Such new potential partners may be more willing to collaborate with the entities/companies as it may be viewed that users/members of the transactions systems may be more interested in participating in the transactions systems due to the assets backing provided to the reward value or reward points. The new potential partners may be merchandisers, fulfilment centre vendors and other companies.

In various exemplary embodiments, one issue presented by entities/companies implementing expiry dates on member reward value or points, e.g. for reasons such as safeguarding cash flow in the event reward points accumulated by members become too large which may expose the entities/companies to large current liabilities, may be mitigated. That is, as the reward points are backed by assets e.g. monetary assets or cash reserve, the entities/companies may be assured of cash flow and therefore, may no longer view it as a need to implement expiry dates on member reward value or points.

With various exemplary embodiments, the portfolio system may also reduce a likelihood for entities/organisations to arbitrarily reduce the number of reward points that may be earned, and/or increase the number of reward points required to redeem/consume goods and/or services. Such actions may otherwise be deemed unfair to consumers/members/users as such actions may devalue the accumulated reward points that members have collected over time and for being loyal members. That is, as the reward points are backed by assets e.g. monetary assets or cash reserve, the entities/companies may be assured of cash flow and therefore, may no longer view it as a need to arbitrarily reduce the number of reward points and/or increase the number of reward points required to redeem/consume goods and/or services.

FIG. 5 is a schematic diagram of a system framework to maintain a shadow portfolio in another exemplary embodiment. In this exemplary embodiment, the system framework provides a portfolio system 500 that functions substantially similarly to the portfolio system 200 described with reference to FIG. 2. For ease of reference, like numerals and/or naming conventions are used for exemplary implementations of similar modules as described in FIG. 1 , FIG. 2 and FIG. 5. In the exemplary embodiment, it is allowed to provide an injection of assets into the portfolio system 500. In the exemplary embodiment, an injected reward value may be produced corresponding to the injection of assets and may be used for e.g. awarding/allocation (or e.g. for sale) externally of the portfolio system 500. For example, with an injection of assets into the portfolio system 500, an injected reward value e.g. a corresponding amount of injected/floating member or reward points may be generated and put up for e.g. awarding/allocation (or e.g. for sale) at e.g. a coupled transactions system(s). The injected assets are contained in the portfolio system 500. In such an example, upon a sale or award of the floating reward points, the coupled transactions system(s) may transmit one or more transaction records that include reward information associated with the sale or award of the injected reward points, i.e. reward information associated with injected reward value. The portfolio module updates the shadow portfolio with a portfolio value, the update being based on the reward information associated with the sale or award of the floating reward points. The portfolio value maintains an asset backing to the shadow portfolio, with the asset backing based on the injected assets that are transmitted to the portfolio module. Thus, in such an exemplary embodiment, the assets, e.g. monetary assets, is already injected/contained in the portfolio system 500 and is utilised to increase the asset backing upon receiving reward information associated with the injected reward value, for example, when the transaction record(s) indicate that the corresponding injected reward points have been e.g. awarded or sold.

In the exemplary embodiment, the portfolio system 500 may comprise a backer module that is additionally configured to allow an injection 502 of assets to a portfolio module via the backer module. The injection 502 of assets may be performed at a fourth time (or any time independent of the operations of the portfolio system 500 and/or coupled transactions system(s)). In the exemplary embodiment, the injection 502 of assets may be from the backer e.g. an entity operating the portfolio system 500 and/or another backer. If another backer, e.g. not the entity operating the portfolio system 500, is providing the injection 502 of assets, the backer module may function as an interface to a financial institution of the another backer. In the exemplary embodiment, the injected assets may be stored in a second buffer of the backer module that functions as a holding platform for increasing an asset backing to a shadow portfolio. The injection 502 of assets may be specified for one or more shadow portfolios e.g. associated with a respective one or more transactions systems. As an example, the injection 502 may be accompanied by a destination shadow portfolio and its corresponding portfolio value.

In the exemplary embodiment, the backer module may be configured to compute an equivalent/corresponding amount of injected asset backing corresponding to the assets injected/received. The computed amount of asset backing (or a predetermined value thereof) may then be used by the backer module to further compute, using a pre-determined relationship rule, a corresponding injected reward value (e.g. member or reward points). In the exemplary embodiment, the computed injected reward value (e.g. member or reward points) may be used for awarding/allocation (or e.g. for sale) 504 to users/members of transactions system(s) e.g. 508 coupled to the portfolio system 500.

For example, under a pre-determined relationship rule, every reward point may represent a value of $0.10 in the exemplary embodiment. When a total of 1kg gold (i.e. an example of an excess asset injected in this instance) is injected into the portfolio system 500 as additional/excess assets, the portfolio module may compute an equivalent/corresponding injected asset backing (e.g. monetary asset/value), e.g. $80,000 in this example. Therefore, for example, according to the pre-determined relationship rule, a total of 800,000 injected member or rewards points may be available to be awarded/allocated/sold to users/members of the coupled transaction system(s) e.g. 508.

Thus, an injection 502 of assets may provide an injected reward value (e.g. reward points) that may be utilised by the coupled transactions system(s) e.g. 508. In the exemplary embodiment, the input module of the portfolio system 500 may additionally function as an output module. In such an exemplary embodiment, the input module may be alternatively named as a transceiver module (compare input module 102 of FIG. 1). The injected reward value to be utilised by the coupled transactions system(s) e.g. 508 may be transmitted from the portfolio system 500 (instructed by the portfolio module) via the transceiver module to the coupled transactions system(s) e.g. 508. In the exemplary embodiment, the ownership of the injected reward value is to the backer providing the injection 502 of assets, prior to the awarding/allocation/sale of the injected reward value.

In the exemplary embodiment, the awarding/allocation/sale of the injected reward value (e.g. reward points) may be performed via a user/member interface at the coupled transactions system(s) e.g. 508.

In the exemplary embodiment, the awarding/allocation/sale of the injected reward value (e.g. reward points) is reflected in one or more transaction records and transmitted to the portfolio system 500. For example, the transactions system(s) e.g. 508 may sell the injected reward value (e.g. reward points) (i.e. transactions) to one or more users/members of the transactions system(s) e.g. 508. In the exemplary embodiment, each transaction record may comprise a reward information indicating a positive increment of a reward value and additionally indicating that the reward value is an injected reward value.

In further use, the transceiver module (compare input module 102 of FIG. 1) receives a transaction record from a coupled transactions system e.g. 508. The transceiver module transmits the transaction record to the portfolio module. The portfolio module processes the transaction record to determine a positive or negative increment of a reward value. In the exemplary embodiment, for an award/allocation (e.g. by sale) of an injected reward value, the portfolio module determines that there is a positive increment (or an increase) of the reward value, and that the reward value is an injected reward value. The portfolio module increases a portfolio value associated with the transactions system e.g. 508. The portfolio module determines the portfolio value based on a pre-determined relationship rule. Thus, it may be that, for example only, only a portion of the injected reward value is utilised at the transactions system e.g. 508. In the exemplary embodiment, as the reward value is an injected reward value, the increase in the portfolio value is based on an extraction of an amount of monetary assets instructed by the portfolio module via the backer module, i.e. from the second buffer of the backer module that contains the injection 502 of assets. The backer module is thus configured to facilitate an increment (in this exemplary embodiment, a positive increment) of the portfolio value. This may be viewed or termed as an update 506 of a cash/asset reserve balance in a portfolio module or as a top-up/update 506 to an asset backing to the shadow portfolio. As such, the portfolio value maintains an asset backing to the shadow portfolio to the transactions system e.g. 508. In the exemplary embodiment, the portfolio value is associated with the transactions system e.g. 508 as a whole.

In some alternative exemplary embodiments, the portfolio value is associated with one or more users of the transactions system e.g. 508. When an awarding or a sale of an injected reward value is completed, the portfolio system 500 may track the amount of awarded/sold injected reward value (e.g. user/member points) via a portfolio database provided therein. In such exemplary embodiments, the coupled transaction system(s) e.g. 508 may transmit reward information included in one or more transaction records. In such reward information, it may additionally be indicated that the corresponding injected asset backing be allocated to one or more users identified in the one or more transaction records. In such an instance, the portfolio module determines that the received reward information is associated/related to injected reward value (e.g. injected member or rewards points) and the portfolio module updates the shadow portfolio associated with the one or more users with the corresponding asset backing from the injected assets already contained in the portfolio system 500, e.g. extracted from the second buffer of the backer module.

Therefore, in the above exemplary embodiments, it is recognised that each portfolio or each portfolio value may therefore usefully shadow the transaction records of each transactions system and/or each user/member of one or more transactions systems. As such, there is provided a respective shadow portfolio that tracks the transaction records (and respective reward values) and in turn maintains an asset backing e.g. monetary/cash backing to the transactions system(s) and/or the user(s). The asset backing may be from a prior injection of assets and the reward values may be based on injected reward values further based on the injection of assets.

FIG. 4A is a schematic block diagram for illustrating an example backer module in an exemplary embodiment. The backer module of this exemplary embodiment is an example of the backer module 106 of a portfolio system described with reference to FIG. 1.

In the exemplary embodiment, the backer module 400 is configured to facilitate an increment of a portfolio value. For example, in the exemplary embodiment, in use, after a portfolio module (compare portfolio module 104 of FIG. 1) processes a transaction record to determine a positive increment of a reward value (based on a reward/award information in a transaction record), the backer module 400 may assist the portfolio module to increase the portfolio value by extracting an amount of monetary assets via the backer module 400 from a financial institution (see numeral 402) to the portfolio module (see numeral 404). As another example, the backer module 400 is configured to allow an injection of assets from a financial institution (see numeral 402) to the portfolio module (see numeral 404).

In the exemplary embodiment, the backer module 400 may be further configured to store and update a backer value. That is, in the exemplary embodiment, the backer module 400 may be further configured to, based on the extraction of the amount of monetary assets from the financial institution to the portfolio module, decrease the backer value. In the exemplary embodiment, the decrease in the backer value may be a decrease in a value indicating an amount of monetary assets (e.g. overall cash reserve) or a decrease in a value relating to the amount of monetary assets (e.g. overall cash value) available to a backer e.g. an entity operating the portfolio system.

FIG. 4B is a schematic block diagram for illustrating an example backer module in another exemplary embodiment.

The backer module of this exemplary embodiment is another example of the backer module 106 described with reference to FIG. 1.

In the exemplary embodiment, the the backer module 401 is configured to facilitate an increment of a portfolio value. For example, in use, after a portfolio module (compare portfolio module 104 of FIG. 1) processes a transaction record to determine a negative increment of a reward value (based on a reward/award information in a transaction record), the backer module 401 may assist the portfolio module to decrease the portfolio value by withdrawing an amount of monetary assets from the portfolio module via the backer module 401. See numeral 406.

In the exemplary embodiment, the backer module 401 may be further configured to transmit an amount of monetary assets to another party (e.g. one or more merchandisers or partners). See numeral 408. As an example, the backer module 401 may be configured to increase the backer value stored in the backer module 401 based on the withdrawal of the amount of monetary assets from the portfolio module via the backer module 401. In such a scenario, the backer value may function as a buffer. That is, the backer value may comprise a planned outflow of monetary assets from the portfolio module via the backer module 401 , e.g. the backer module 401 may function as a holding platform for scheduled payment to e.g. one or more merchandisers. See again numeral 408.

An exemplary method of maintaining a shadow portfolio is described with reference to FIG. 3.

FIG. 3 is a schematic flowchart for illustrating a method of maintaining a shadow portfolio in an exemplary embodiment. In the exemplary embodiment, the portfolio system 100 described with reference to FIG. 1 may implement the method 300. In the exemplary embodiment, at step 302, a portfolio module is provided to maintain a shadow portfolio. At step 304, a backer module is provided. At step 306, one or more transactions records is received from one or more transaction systems. At step 308, the shadow portfolio is updated with a portfolio value, the updating being based on reward information included in the one or more transaction records. At step 310, an increment of the portfolio value is facilitated using the backer module. At step 312, an asset backing to the shadow portfolio is maintained with the portfolio value.

In another exemplary embodiment, a non-transitory tangible computer readable storage medium having stored thereon software instructions may be provided. The instructions, when executed by a computer processor of a portfolio system to maintain a shadow portfolio, cause the computer processor to perform a method of maintaining a shadow portfolio, by executing the steps comprising providing a portfolio module to maintain a shadow portfolio; providing a backer module; receiving one or more transactions records from one or more transaction systems; updating the shadow portfolio with a portfolio value, the updating being based on reward information included in the one or more transaction records; facilitating an increment of the portfolio value using the backer module; and maintaining an asset backing to the shadow portfolio with the portfolio value. It will be appreciated that the steps described herein may be non sequential and may not be ordered as listed.

Different exemplary embodiments can be implemented in the context of data structure, program modules, program and computer instructions executed in a computer implemented environment. A general purpose computing environment is briefly disclosed herein. One or more exemplary embodiments may be embodied in one or more computer systems, such as is schematically illustrated in FIG. 6.

One or more exemplary embodiments may be implemented as software, such as a computer program being executed within a computer system 600, and instructing the computer system 600 to conduct a method of an exemplary embodiment.

The computer system 600 comprises a computer unit 602, input modules such as a keyboard 604 and a pointing device 606 and a plurality of output devices such as a display 608, and printer 610. A user can interact with the computer unit 602 using the above devices. The pointing device can be implemented with a mouse, track ball, pen device or any similar device. One or more other input devices (not shown) such as a joystick, game pad, satellite dish, scanner, touch sensitive screen or the like can also be connected to the computer unit 602. The display 608 may include a cathode ray tube (CRT), liquid crystal display (LCD), field emission display (FED), plasma display or any other device that produces an image that is viewable by the user. The computer unit 602 can be connected to a computer network 612 via a suitable transceiver device 614, to enable access to e.g. the Internet or other network systems such as Local Area Network (LAN) or Wide Area Network (WAN) or a personal network. The network 612 can comprise a server, a router, a network personal computer, a peer device or other common network node, a wireless telephone or wireless personal digital assistant. Networking environments may be found in offices, enterprise-wide computer networks and home computer systems etc. The transceiver device 614 can be a modem/router unit located within or external to the computer unit 602, and may be any type of modem/router such as a cable modem or a satellite modem.

It will be appreciated that network connections shown are exemplary and other ways of establishing a communications link between computers can be used. The existence of any of various protocols, such as TCP/IP, Frame Relay, Ethernet, FTP, HTTP and the like, is presumed, and the computer unit 602 can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Furthermore, any of various web browsers can be used to display and manipulate data on web pages.

The computer unit 602 in the example comprises a processor 618, a Random Access Memory (RAM) 620 and a Read Only Memory (ROM) 622. The ROM 622 can be a system memory storing basic input/ output system (BIOS) information. The RAM 620 can store one or more program modules such as operating systems, application programs and program data.

The computer unit 602 further comprises a number of Input/Output (I/O) interface units, for example I/O interface unit 624 to the display 608, and I/O interface unit 626 to the keyboard 604. The components of the computer unit 602 typically communicate and interface/couple connectedly via an interconnected system bus 628 and in a manner known to the person skilled in the relevant art. The bus 628 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. It will be appreciated that other devices can also be connected to the system bus 628. For example, a universal serial bus (USB) interface can be used for coupling a video or digital camera to the system bus 628. An IEEE 1394 interface may be used to couple additional devices to the computer unit 602. Other manufacturer interfaces are also possible such as FireWire developed by Apple Computer and i.Link developed by Sony. Coupling of devices to the system bus 628 can also be via a parallel port, a game port, a PCI board or any other interface used to couple an input device to a computer. It will also be appreciated that, while the components are not shown in the figure, sound/audio can be recorded and reproduced with a microphone and a speaker. A sound card may be used to couple a microphone and a speaker to the system bus 628. It will be appreciated that several peripheral devices can be coupled to the system bus 628 via alternative interfaces simultaneously.

An application program can be supplied to the user of the computer system 600 being encoded/stored on a data storage medium such as a CD-ROM or flash memory carrier. The application program can be read using a corresponding data storage medium drive of a data storage device 630. The data storage medium is not limited to being portable and can include instances of being embedded in the computer unit 602. The data storage device 630 can comprise a hard disk interface unit and/or a removable memory interface unit (both not shown in detail) respectively coupling a hard disk drive and/or a removable memory drive to the system bus 628. This can enable reading/writing of data. Examples of removable memory drives include magnetic disk drives and optical disk drives. The drives and their associated computer-readable media, such as a floppy disk provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the computer unit 602. It will be appreciated that the computer unit 602 may include several of such drives. Furthermore, the computer unit 602 may include drives for interfacing with other types of computer readable media.

The application program is read and controlled in its execution by the processor 618. Intermediate storage of program data may be accomplished using RAM 620. The method(s) of the exemplary embodiments can be implemented as computer readable instructions, computer executable components, or software modules. One or more software modules may alternatively be used. These can include an executable program, a data link library, a configuration file, a database, a graphical image, a binary data file, a text data file, an object file, a source code file, or the like. When one or more computer processors execute one or more of the software modules, the software modules interact to cause one or more computer systems to perform according to the teachings herein.

The operation of the computer unit 602 can be controlled by a variety of different program modules. Examples of program modules are routines, programs, objects, components, data structures, libraries, etc. that perform particular tasks or implement particular abstract data types. The exemplary embodiments may also be practiced with other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, personal digital assistants, mobile telephones and the like. Furthermore, the exemplary embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wireless or wired communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The exemplary embodiments may also be practiced with other computer system configurations, including handheld devices, multiprocessor systems/servers, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, personal digital assistants, mobile telephones and the like. Furthermore, the exemplary embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wireless or wired communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The terms "coupled" or "connected" as used in this description are intended to cover both directly connected or connected through one or more intermediate means, unless otherwise stated. The terms “configured to (perform a task/action)”, “configured for (performing a task/action)” and the like as used in this description include being programmable, programmed, connectable, wired or otherwise constructed to have the ability to perform the task/action when arranged or installed as described herein. The terms “configured to (perform a task/action)”, “configured for (performing a task/action)” and the like are intended to cover “when in use, the task/action is performed”, e.g. specifically to and/or specifically configured to and/or specifically arranged to do a task/action.

The description herein may be, in certain portions, explicitly or implicitly described as algorithms and/or functional operations that operate on data within a computer memory or an electronic circuit. These algorithmic descriptions and/or functional operations are usually used by those skilled in the information/data processing arts for efficient description. An algorithm is generally relating to a self-consistent sequence of steps leading to a desired result. The algorithmic steps can include physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transmitted, transferred, combined, compared, and otherwise manipulated.

Further, unless specifically stated otherwise, and would ordinarily be apparent from the following, a person skilled in the art will appreciate that throughout the present specification, discussions utilizing terms such as “scanning”, “calculating”, “determining”, “replacing”, “generating”, “initializing”, “outputting”, and the like, refer to action and processes of an instructing processor/computer system, or similar electronic circuit/device/component, that manipulates/processes and transforms data represented as physical quantities within the described system into other data similarly represented as physical quantities within the system or other information storage, transmission or display devices etc.

The description also discloses relevant device/apparatus for performing the steps of the described methods. Such apparatus may be specifically constructed for the purposes of the methods, or may comprise a general purpose computer/processor or other device selectively activated or reconfigured by a computer program stored in a storage member. The algorithms and displays described herein are not inherently related to any particular computer or other apparatus. It is understood that general purpose devices/machines may be used in accordance with the teachings herein. Alternatively, the construction of a specialized device/apparatus to perform the method steps may be desired.

In addition, it is submitted that the description also implicitly covers a computer program, in that it would be clear that the steps of the methods described herein may be put into effect by computer code. It will be appreciated that a large variety of programming languages and coding can be used to implement the teachings of the description herein. Moreover, the computer program if applicable is not limited to any particular control flow and can use different control flows without departing from the scope of the invention.

Furthermore, one or more of the steps of the computer program if applicable may be performed in parallel and/or sequentially. Such a computer program if applicable may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a suitable reader/general purpose computer. In such instances, the computer readable storage medium is non-transitory. Such storage medium also covers all computer-readable media e.g. medium that stores data only for short periods of time and/or only in the presence of power, such as register memory, processor cache and Random Access Memory (RAM) and the like. The computer readable medium may even include a wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in bluetooth technology. The computer program when loaded and executed on a suitable reader effectively results in an apparatus that can implement the steps of the described methods.

The exemplary embodiments may also be implemented as hardware modules. A module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using digital or discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). A person skilled in the art will understand that the exemplary embodiments can also be implemented as a combination of hardware and software modules. Additionally, when describing some embodiments, the disclosure may have disclosed a method and/or process as a particular sequence of steps. However, unless otherwise required, it will be appreciated the method or process should not be limited to the particular sequence of steps disclosed. Other sequences of steps may be possible. The particular order of the steps disclosed herein should not be construed as undue limitations. Unless otherwise required, a method and/or process disclosed herein should not be limited to the steps being carried out in the order written. The sequence of steps may be varied and still remain within the scope of the disclosure.

Further, in the description herein, the word “substantially” whenever used is understood to include, but not restricted to, "entirely" or “completely” and the like. In addition, terms such as "comprising", "comprise", and the like whenever used, are intended to be non restricting descriptive language in that they broadly include elements/components recited after such terms, in addition to other components not explicitly recited. For an example, when “comprising” is used, reference to a “one” feature is also intended to be a reference to “at least one” of that feature. Terms such as “consisting”, “consist”, and the like, may, in the appropriate context, be considered as a subset of terms such as "comprising", "comprise", and the like. Therefore, in embodiments disclosed herein using the terms such as "comprising", "comprise", and the like, it will be appreciated that these embodiments provide teaching for corresponding embodiments using terms such as “consisting”, “consist”, and the like. Further, terms such as "about", "approximately" and the like whenever used, typically means a reasonable variation, for example a variation of +/- 5% of the disclosed value, or a variance of 4% of the disclosed value, or a variance of 3% of the disclosed value, a variance of 2% of the disclosed value or a variance of 1% of the disclosed value.

Furthermore, in the description herein, certain values may be disclosed in a range. The values showing the end points of a range are intended to illustrate a preferred range. Whenever a range has been described, it is intended that the range covers and teaches all possible sub-ranges as well as individual numerical values within that range. That is, the end points of a range should not be interpreted as inflexible limitations. For example, a description of a range of 1% to 5% is intended to have specifically disclosed sub-ranges 1% to 2%, 1% to 3%, 1% to 4%, 2% to 3% etc., as well as individually, values within that range such as 1%, 2%, 3%, 4% and 5%. The intention of the above specific disclosure is applicable to any depth/breadth of a range.

In the exemplary embodiments, it is described that the determining, based on a pre-determined relationship rule (e.g. a ratio), an asset value proportional to a reward value indicated in a reward information of a transaction record may be performed at a portfolio system. However, it is appreciated that the such determining is not limited as such. That is, the determination (e.g. of how much asset backing to be moved into or out of a shadow portfolio and/or portfolio value) may be performed at a transactions system and the transaction record may instead contain an instruction e.g. tagged/appended/encrypted with reward information to increase or decrease the associated portfolio value.

In some exemplary embodiments, a user may utilise the user’s accumulated reward points as conversion into cash, in addition or as an alternative to redeeming/consuming goods and/or services. Such cash conversion may be based on a ratio (i.e. reward points : cash ratio). The cash redemption may be via electronic means to a personal bank account of the user and/or by actual physical cash. For example, a portfolio system may be configured to, based on a computed amount of cash conversion determined by the ratio, instruct a financial system via a backer module to withdraw the calculated asset value or an amount of asset backing from a designated bank account (or shadow portfolio or portfolio value of a portfolio module) associated with a respective transactions system or of the relevant user i.e. to withdraw from the asset backing e.g. monetary/cash reserve (compare e.g. numeral 224 of FIG.2) and to deposit the calculated asset value into an indicated destination, e.g. the personal bank account of the user requesting the cash conversion. Such indication may be provided in e.g. user information, claim information, destination information etc. of a transaction record that is transmitted to the portfolio system.

In exemplary embodiments, the portfolio system may maintain a shadow portfolio that is associated with a respective transactions system. However, it will be appreciated that maintaining a shadow portfolio may also include generating a shadow portfolio e.g. when a transactions system is newly coupled to the portfolio system, and updating the generated shadow portfolio.

In yet other exemplary embodiments, a shadow portfolio may be associated with more than one transaction systems. For example, a shadow portfolio may be shared among more than one transaction systems. The update to the shadow portfolio may then be based on reward information included in one or more transaction records transmitted by one or more transaction systems to the portfolio system.

In exemplary embodiments, a backer that is providing asset backing to one or more shadow portfolios may be an entity operating the portfolio system. However, it will be appreciated that the exemplary embodiments are not limited as such. For example, a backer may be separate from the entity operating the portfolio system. In addition, it may be provided that a plurality of backers may be registered to provide asset backing via the portfolio system.

In exemplary embodiments, the operations of the transactions system(s) may be independent of the operations of the portfolio system. For example, the time or instances for transmitting one or more transaction records from the transactions system(s) to the portfolio system may be determined within the transactions system(s) and independent of the portfolio system. For example, the time or instances for transmitting the one or more transaction records may be determined at the transactions system(s), for example but not limited to, one or more periodic intervals, during real-time operations, one or more system prompted activation times, or one or more user prompted activation time at the transactions system(s).

In the exemplary embodiments, the transaction records may comprise reward information that may include other information such as reward value, user information, claim information, destination information etc. However, it will be appreciated that the exemplary embodiments are not limited to such specific forms of information. The exemplary embodiments may broadly operate as long as there is sufficient reward information to provide the functions of updating one or more shadow portfolios and/or portfolio values. In the exemplary embodiments, asset backing may have an equivalent monetary value and may be one of or a combination of assets such as cash, cryptocurrency, precious metals, commodities etc. That is, asset backing is intended to cover any form of matter or assets that can provide a backing, collateral etc. to the shadow portfolio. That is, such assets may even include precious metals such as gold, silver, rare elements etc. In the description, references to monetary assets are also intended to mean the above, i.e. any matter that has an equivalent monetary value.

In the exemplary embodiments, a financial institution is exemplarily introduced as a bank entity. It is appreciated that such institutions are intended to be broad as long as an asset backing may be provided to a shadow portfolio. For example, such institutions may include other types of entities such as cryptocurrency exchanges, wallets etc. In such circumstances, the assets may be linked to monetary values and may be cryptocurrency.

In the exemplary embodiments, a pre-determined relationship rule is used for determining reward value in association with an asset value. For example, a received reward value in one or more transaction records may determine how much of an asset value is to be increased or decreased at the portfolio module (i.e. for the asset backing to the shadow portfolio). For example, an injected amount of assets having an asset value may determine how much reward value is to be injected (e.g. for allocation/awarding/sale at one or more coupled transactions system(s)). It will be appreciated that the pre-determined relationship rule may be the same for the positive increment of asset backing, for the negative increment of asset backing and/or for the injection of reward value. It will also be appreciated that the pre-determined relationship rule may be different for the above actions and/or different for different transactions system(s) and/or different one or more users of transactions system(s).

It will be appreciated by a person skilled in the art that other variations and/or modifications may be made to the specific embodiments without departing from the scope of the invention as broadly described. For example, in the description herein, features of different exemplary embodiments may be mixed, combined, interchanged, incorporated, adopted, modified, included etc. or the like across different exemplary embodiments. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.