Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising
  • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/06—Asset management; Financial planning or analysis

Definitions

• 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.
• 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.
• 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.
• other systems may belong to merchandisers and other companies.
• 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.
• 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.
• 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.
• 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.
• a method of maintaining a shadow portfolio 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the shadow portfolio may be associated with a respective transactions system.
• the shadow portfolio may be associated with a respective user of a coupled transactions system.
• the shadow portfolio or the corresponding portfolio value may be viewed as being a designated account of the transactions system and/or user.
• 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.
• 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.
• the portfolio system 100 comprises an input module 102.
• the input module 102 is configured to receive one or more transaction records from a transactions system (not shown).
• the portfolio system 100 further comprises a portfolio module 104 coupled to the input module 102.
• the portfolio system 100 further comprises a backer module 106 coupled to the portfolio module 104.
• 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.
• the portfolio module 104 is configured to maintain a shadow portfolio and to update the shadow portfolio with a portfolio value.
• 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.
• 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.
• the portfolio system 100 may be further connected to or coupled to a financial institution system, such as a bank.
• 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.
• 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.
• 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.
• each transaction record is based on an award/reward process.
• 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.
• each transaction record may comprise a reward/award information indicating a positive or negative increment of a reward/award value.
• 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.
• the portfolio module 104 is configured to update the portfolio value based on the reward information of each transaction record.
• 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.
• 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.
• 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.
• the portfolio module 104 decreases the portfolio value associated with the transactions system.
• 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.
• 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.
• 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.
• the portfolio value thus maintains an asset backing to the shadow portfolio of the transaction system, based on the monetary assets.
• 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.
• 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.
• the portfolio value is associated with the transactions system as a whole.
• the portfolio value may be subjected to earning interest and therefore, may increase over time due to an interest yield.
• 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.
• 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.
• 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.
• 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.
• an identifier may be tagged/appended/encrypted to reward information.
• 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.
• the system framework provides a portfolio system 200 that functions substantially similarly to the portfolio system 100 described with reference to FIG. 1.
• like numerals and/or naming conventions are used for exemplary implementations of similar modules as described in FIG. 1 and FIG. 2.
• the portfolio system 200 is coupled to a transactions system 202 and a merchandisers system 204.
• 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.
• the transactions system 202 may facilitate transactions.
• 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.
• 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.
• the transactions system 202 may be configured to update (or increase) an accumulated/tallied amount of member points. See numeral 210.
• 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.
• 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.
• 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.
• 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).
• the user information may, for example only, be tagged/appended/encrypted to reward information.
• the transactions system 202 may be configured to, upon generating the transaction record, transmit the transaction record to the portfolio system 200.
• 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.
• the portfolio system 200 may be further coupled to a financial institution, such as a bank entity, via the backer module.
• the input module of the portfolio system 200 is configured to receive one or more transaction records transmitted by the transactions system 202.
• the portfolio module 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.
• the portfolio system 200 is configured to update (increase and/or decrease respectively) the portfolio value stored in the portfolio module.
• 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.
• the backer module is thus configured to facilitate an increment (either positive or negative) of the portfolio value.
• 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.
• 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.
• 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.
• 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.
• the transactions system 202 may take no further action. See numeral 214.
• 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.
• the transactions system 202 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.
• 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.
• the portfolio module 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.
• 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).
• 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.
• 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.
• the portfolio system 200 upon receiving a transaction record comprising claim information and destination information, 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).
• the withdrawal is instructed by the portfolio module and facilitated via the backer module.
• the shadow portfolio of the transactions system 202 is viewed or termed as the designated bank account of the transactions system 202.
• the monetary/cash reserve may earn interest.
• 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.
• 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.
• 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.
• 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.
• assets e.g. monetary/cash reserves in e.g. an independent designated bank account (or a shadow portfolio)
• 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.
• 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).
• 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.
• the amount of assets e.g. monetary/cash reserve in the designated bank account may be audited periodically to provide confidence and transparency.
• each portfolio value stored in the portfolio module 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.
• asset backing is in relation to each transactions system.
• 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.
• 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.
• 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).
• the user information may be tagged/appended/encrypted to reward information.
• the portfolio module of the portfolio system may be configured to extract the user information from each transaction record received.
• the portfolio module is configured to update respective portfolio values belonging to respective users/members (e.g. an individual shadow account/portfolio each).
• a portfolio database may be provided at the portfolio module to store the different portfolio values relating to different users/members.
• 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).
• such a portfolio system may provide technical scalability to work with existing transaction systems.
• 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.
• 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.
• 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.
• the asset value may be a value proportional to the reward value indicated in the reward information of the transaction record.
• 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.
• 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.
• 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.
• the portfolio value is correspondingly decreased using the ratio.
• the portfolio module is configured to decrease the portfolio value by $Y according to the pre-determined ratio.
• 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.
• 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).
• a portfolio system 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.
• 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.
• 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.
• 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
• an entity/organisation may no longer be concerned about members (or users) of the entity’s transactions system accumulating excessive reward points.
• 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.
• 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.
• a successful customer loyalty program i.e. implemented with a portfolio system of exemplary embodiments
• an entity/organisation of a transactions system
• reward value or points are backed by assets e.g. a monetary/cash reserve
• more possibilities become available on ways to utilise reward points.
• 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.
• the portfolio system may additionally incorporate blockchain technology to increase the reliability and transparency of the system.
• 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.
• the portfolio system may provide financial benefits to entities/companies by providing a means to reduce at least customer acquisition costs.
• 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.
• 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.
• one issue presented by entities/companies implementing expiry dates on member reward value or points 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.
• assets e.g. monetary assets or cash reserve
• 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.
• assets e.g. monetary assets or cash reserve
• FIG. 5 is a schematic diagram of a system framework to maintain a shadow portfolio in another 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.
• like numerals and/or naming conventions are used for exemplary implementations of similar modules as described in FIG. 1 , FIG. 2 and FIG. 5.
• it is allowed to provide an injection of assets into the portfolio system 500.
• 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.
• 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.
• 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.
• the assets e.g. monetary assets
• the portfolio system 500 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.
• 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)).
• 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.
• 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.
• the injection 502 may be accompanied by a destination shadow portfolio and its corresponding portfolio value.
• 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).
• a corresponding injected reward value (e.g. member or reward points)
• 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.
• every reward point may represent a value of $0.10 in the exemplary embodiment.
• 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.
• 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.
• the input module of the portfolio system 500 may additionally function as an output module.
• 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.
• 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.
• the awarding/allocation/sale of the injected reward value may be performed via a user/member interface at the coupled transactions system(s) e.g. 508.
• the awarding/allocation/sale of the injected reward value is reflected in one or more transaction records and transmitted to the portfolio system 500.
• 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.
• 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.
• the transceiver module 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.
• 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.
• 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.
• the portfolio value maintains an asset backing to the shadow portfolio to the transactions system e.g. 508.
• the portfolio value is associated with the transactions system e.g. 508 as a whole.
• the portfolio value is associated with one or more users of the transactions system e.g. 508.
• 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.
• the coupled transaction system(s) e.g. 508 may transmit reward information included in one or more transaction records.
• 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.
• 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.
• 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.
• 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.
• the backer module 400 is configured to facilitate an increment of a portfolio value.
• 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).
• 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).
• 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.
• 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.
• the backer module 401 is configured to facilitate an increment of a portfolio value.
• 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.
• 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.
• 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.
• 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.
• FIG. 3 is a schematic flowchart for illustrating a method of maintaining a shadow portfolio in an exemplary embodiment.
• the portfolio system 100 described with reference to FIG. 1 may implement the method 300.
• a portfolio module is provided to maintain a shadow portfolio.
• a backer module is provided.
• one or more transactions records is received from one or more transaction systems.
• the shadow portfolio is updated with a portfolio value, the updating being based on reward information included in the one or more transaction records.
• an increment of the portfolio value is facilitated using the backer module.
• an asset backing to the shadow portfolio is maintained with the portfolio value.
• 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.
• the steps described herein may be non sequential and may not be ordered as listed.
• 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 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.
• CTR cathode ray tube
• LCD liquid crystal display
• FED field emission display
• plasma display 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.
• 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.
• 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.
• 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.
• a universal serial bus (USB) interface can be used for coupling a video or digital camera to the system bus 628.
• USB universal serial bus
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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 exemplary embodiments may also be implemented as hardware modules.
• a module is a functional hardware unit designed for use with other components or modules.
• 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).
• ASIC Application Specific Integrated Circuit
• a person skilled in the art will understand that the exemplary embodiments can also be implemented as a combination of hardware and software modules.
• 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.
• the word “substantially” whenever used is understood to include, but not restricted to, “entirely” or “completely” and the like.
• 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.
• 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.
• 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.
• the determination e.g. of how much asset backing to be moved into or out of a shadow portfolio and/or portfolio value
• the transaction record may instead contain an instruction e.g. tagged/appended/encrypted with reward information to increase or decrease the associated portfolio value.
• 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.
• 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.
• 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.
• 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.
• the portfolio system may maintain a shadow portfolio that is associated with a respective transactions system.
• 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.
• a shadow portfolio may be associated with more than one transaction systems.
• 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.
• a backer that is providing asset backing to one or more shadow portfolios may be an entity operating the portfolio system.
• a backer may be separate from the entity operating the portfolio system.
• a plurality of backers may be registered to provide asset backing via the portfolio system.
• the operations of the transactions system(s) may be independent of the operations of the portfolio system.
• 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.
• 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).
• the transaction records may comprise reward information that may include other information such as reward value, user information, claim information, destination information etc.
• 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.
• references to monetary assets are also intended to mean the above, i.e. any matter that has an equivalent monetary value.
• 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.
• 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).

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• Development Economics (AREA)
• Finance (AREA)
• Strategic Management (AREA)
• Game Theory and Decision Science (AREA)
• Theoretical Computer Science (AREA)
• General Business, Economics & Management (AREA)
• Economics (AREA)
• Marketing (AREA)
• Entrepreneurship & Innovation (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Operations Research (AREA)
• Technology Law (AREA)
• Human Resources & Organizations (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (2)

Applications Claiming Priority (1)

Publications (1)

Family

ID=79281628

Family Applications (1)

Country Status (2)

Citations (4)

• 2020
  • 2020-06-26 WO PCT/SG2020/050372 patent/WO2021262085A1/en active Application Filing
  • 2020-06-26 CN CN202080102392.6A patent/CN115943407A/zh active Pending

Patent Citations (4)

Also Published As

Similar Documents

Legal Events