WO2015113519A1

WO2015113519A1 - Method for managing virtual currency and improved virtual currency system

Info

Publication number: WO2015113519A1
Application number: PCT/CN2015/071938
Authority: WO
Inventors: Kinwang Chau
Original assignee: Vcoin Limited
Priority date: 2014-01-30
Filing date: 2015-01-30
Publication date: 2015-08-06
Also published as: HK1203285A2

Abstract

A method for managing a virtual currency comprising the steps of: detecting transaction events (401) in an online exchange whereby each transaction event is performed with a pre-generated virtual currency having a base unit, each base unit having a unique identifier (406); recording trade information associated with each of the transaction event; and processing the trade information to identify one or more transaction trends (414, 416, 418).

Description

A METHOD FOR MANAGING A VIRTUAL CURRENCY AND AN IMPROVED VIRTUAL CURRENCY SYSTEM

TECHNICAL FIELD

The present invention relates to an improved virtual currency system and a method for managing a virtual currency and particularly， but not exclusively， to a virtual currency system and method arranged to track transaction events relating to the usage of a virtual currency.

BACKGROUND

Virtual currency systems have been invented to facilitate online transactions in computer networks such as the Internet. In these systems， users can trade with a virtual currency to purchase specific goods or services. Unlike traditional currencies or other forms of medium of exchange， virtual currencies exist in a virtual space and are considered intangible.

Due to the intangible nature of virtual currency， it is a substantial challenge for administrators of these virtual currency systems to ensure a virtual currency shows sufficient integrity as a medium of exchange in the marketplace. In turn， these challenges relating to security and validity often attract legal and trust concerns from government bodies， such as monetary authorities and merchants which may trade with these virtual currencies.

In addition to these security concerns， despite the fact that a virtual currency exists as data on a computer， it is inherently difficult to trace the usage and transfer patterns of a virtual currency in its marketplace. Due to the vast systems which will allow for an exchange of virtual currency， transaction events for the virtual currency may not be readily made known to individual uscrs or controlling authorities. In turn， the integrity of the virtual currency platform is callcd into qucstion as the authenticity of an individual transaction caumot be corfirmed. For thcsc rcasons， virtual currcncy has been unable to replace traditional mediums of exchange with any great success.

SUMMARY OF THE INVENTION

In accordance with a tirst aspect of the present invention， there is provided a method for managing a virtual currency comprising the steps of：

-detecting transaction events in an online exchange whereby each transaction event is pcrformcd with a prc-gcncrated virtual currency having a base unit， each base unit having a unique identifier；

-recording trade information associated with each of the transaction event； and

-processing the trade information to identify one or more transaction trends.

In an embodiment of the first aspect， the recorded trade information is associated with the unique identifier of each base unit of the pre-generated virtual currency.

In an embodiment of the first aspect， trade information is processed with the associated unique identifier to identi fy one or more transaction trends of each base unit of the pre-generated virtual currency.

In an embodiment of the first aspect， the system further includes the steps of：

-receiving one or more transaction requests for the one or more transaction events from a plurality of parties； and，

-executing the one or more transaction requests to complete the one or more transaction events.

In an embodiment of the first aspect， the one or more transaction requests are received from a plurality of parties in the online exchange.

In an embodiment of the first aspect， the plurality of parties in the online exchange includes administrators， merchants and users.

In an embodiment of the first aspect， the pre-generated virtual currency is electronically stored within accounts held by each administrator， merchant or user.

In an embodiment of the first aspect， the one or more transaction trends are identified by retrieving and processing one or more historical transaction events associated with each unique identifier.

In an embodiment of the first aspect， each of the transaction requests fiom the plurality of parties is validated before execution.

In an embodiment of the first aspect， each of the transaction requests are validated by checking an authenticity status of each of the plurality of parties privy to the transaction request and comparing cach transaction condition associated with each of the transaction requests against a set of predetermined transaction rules.

In an embodiment ofthe first aspect， the each transaction condition associated with each of the transaction requests is further compared against the one or more transaction trends.

In an embodiment of the first aspect， the accounts held by each of the plurality of parties privy to the transaction requirements are audited.

In an embodiment of the first aspect， the account of each of the plurality of parties are audited by retrieving an account balance of the accounts held by each of the parties and comparing the balance against a set of predetermined account balance conditions

In an embodiment of the first aspect， a total balance figure is calculated from the one or more historical transaction events associated with each of the plurality of parties and compared with the account balance of each of the plurality of parties.

In an embodiment of the first aspect， the accounts held the plurality of parties are audited randomly.

In an embodiment of the first aspect， the trade information includes： merchant identification， user identification， date/time stamp， product of exchange， virtual currency exchanged or any one or combination thereof.

In an embodiment of the first aspect， the unique identifier is encrypted.

In an embodiment of the first aspect， the one or more transaction trends include earning and spending pattern of each base unit.

In accordance with a second embodiment of the present invention， there is provided an improved virtual currency system comprising：

-atransaction engine arranged to detect transaction events in an online exchange whereby each transaction event is performed with a pre-generated virtual currency having a base unit， each base unit having a unique identifier；

-atransaction database arranged to record trade information associated with each of the transaction event； and

-adata processor arranged to process the trade information to identify one or more transaction trends.

In an embodiment of the second aspect， the recorded trade information is associated with the unique identifier of each base unit of the pre-generated virtual currency.

In an embodiment of the second aspect， trade information is processed with the associated unique identifier to identify one or more transaction trends of each base unit of the pre-generated virtual currency.

In an embodiment of the second aspect， the transaction engine is further arranged to：

-receive one or more transaction requests for the one or more transaction events from a plurality of parties； and，

-execute the one or more transaction requests to complete the one or more transaction events.

In an embodiment of the second aspect， the one or more transaction requests are received from a plurality of parties in the online exchange.

In an embodiment of the second aspect， the plurality of parties in the online exchange includes administrators， merchants and users.

In an embodiment of the second aspect， the pre-generated virtual currency is electronically stored within accounts held by each administrator， merchant or user.

In an embodiment of the second aspect， the one or more transaction trends are identified by retrieving and processing one or more historical transaction events associated with each unique identifier.

In an embodiment of the second aspect， each of the transaction requests from the plurality of parties is validated by a security module before execution.

In an embodiment of the second aspect， each of the transaction requests are validated by checking an authenticity status of each of the plurality of parties privy to the transaction request and comparing each transaction condition associated with each of the transaction requests against a set of predetermined transaction rules.

In an embodiment of the second aspect， the each transaction condition associated with each of the transaction requests is further compared against the one or more transaction trends.

In an embodiment of the second aspect， the accounts held by each of the plurality of parties privy to the transaction rcquircments are audited by an audit module.

In an embodiment of the second aspect， the account of each of the plurality of parties are audited by retrieving an account balance of the accounts held by each of the parties and comparing the balance against a set of predetermined account balance conditions

In an embodiment of the second aspect， a total balance figure is calculated from the one or more historical transaction events associated with each of the plurality of parties and compared with the account balance of each of the plurality of parties.

In an embodiment of the second aspect， the audit module is arranged to audit accounts held the plurality of parties randomly.

In an embodiment of the second aspect， the trade information includes： merchant identification， user identification， date/time stamp， product of exchange， virtual currency exchanged or any one or combination thereof.

In an embodiment of the second aspect， the unique identifier is encrypted.

In an embodiment of the second aspect， the one or more transaction trends include earning and spending pattern of each base unit.

BRIEF DESCRIPTION OF THE DRA WINGS

Embodiments of the present invention will now be described， by way of example， with reference to the accompanying drawings in which：

Figure 1 is a block diagram illustrating the components of one embodiment of a computer server arranged to operate and manage an improved virtual currency system；

Figure 2 is an operational block diagram of an improved virtual currency system in accordance with one embodiment of the present invention；

Figure 3 is a flow diagram illustrating the transactions between a merchant and a user of the improved virtual currency systcm of Figure 2；

Figure 4 is a flow diagram illustrating the processing of a transaction event by the improved virtual currency system of Figure 2；

Figure 5 is a flow diagram illustrating the operation of a security module of the improved currency system of Figure 2；

Figure 6 is a flow diagram illustrating the processes uudertaken by the audit module of an improved virtual currency system of Figure 2；

Figure 7 is an example screen shot of an application arranged to operate with an improved virtual currency system of Figure 2；

Figure 8 is an example screen shot of an application arranged to operate with an improved virtual currency system of Figure 2； and，

Figure 9 is an example screen shot of an application arranged to operate with an improved virtual currency system of Figure 2.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to Figure 1， an embodiment of a computer system such as a computcr scrvcr 100 implemented to operate as an improved virtual currency system is illustrated. This embodiment is arranged to provide an improved virtual currency system comprising： a transaction engine arranged to detect transaction events in an online exchange whereby each transaction event is performed with a pre-generated virtual currency having a base unit， cach basc unit having a unique identifier； a transaction database arranged to record trade information associated with each of the transaction event； and a data processor arranged to process the trade information to identify one or more transaction trends.

In the example embodiment described herein， the system is implemented by a computer server 100 having an appropriate user interface 201. The computer server 100 may be implemented by any computing architecture， including a standalone PC， a client server architecture， a dumb termin al/mainframe architecture， or any other appropriatc urchitecture. The computing servcr 100 mny also be appropriately programmed withinstructions or code to implement a part or the entire invention.

ln this embodiment， the server 100 is arranged to be operated to manage a virtual currency system such that transactions can take place by use of a virtual currency as a medium of exchange between individual users and merchants. Referring to Figure 1， there is shown a schematic diagram of a computer system arranged to operate as an improved virtual currency system. The system， which includes a server 100 comprises suitable components necessary to receive， store and execute appropriate computing instructions. The components may include a processing unit 102， read-only memory (ROM) 104， random-access memory (RAM) 106， and an input/output device such as disk drives 108， input devices 110 such as an Ethernet port， a USB port etc， a display 112 such as a liquid crystal display， a lighting meeting display or any other suitable display and communication links 114. The server 100 may include instructions that may be included in ROM 104， RAM or disk drives 108 and may be executed by the processing unit 102. There may also be provided a plurality of communication links 114 which may variously connect to one or more computing devices such as a server， personal computer， terminal， wireless or hand or computing devices including Smartphones， tablets or any other portable computing and communication devices. At least one of a plurality of communication links may also be utilized to connect to an external computing network through a telephone or other types of communications link such as the Internet or Ethernet or a combination of both.

The server 100 may also include storage devices such as a disk drive 108 which may encompass solid state drives， hard disk drives， optical drives or magnetic tape drives. The server 100 may use a single disk drive or multiple disk drives. The server 100 may also have a suitable operating system 116 which resides on the disk drive or in the ROM of the server 100.

In this embodiment， the server 100 may be programmed appropriately so as to facilitate the operations of an improved virtual currency system by allowing， executing and monitoring transaction events which take place in an online market environment or online exchange whereby users and merchants are able to meet over a computer network， such as the Internet to conduct an exchange with a virtual currency administered by the improved virtual currency system. Preferably， the server is programmed to include a numbcr of components including a virtual currency generator arranged to generate one or more virtual currency base units which may be referred to as virtual coin or Vcoin. Such a coin generator is arranged to generate individual virtual currencies or individual coins of particular value under a controlled virtual currency regime whereby the number and amount of virtual coins which are generated may be strictly controlled so as to be optimal for the market.

The server 100 may also be implemented to include a virtual currency bank arranged to storc and account for the virtual currencies. In turn， the server 100 may also have a transaction engine which facilitates individual transactions which uses the virtual currency as a medium of exchange. In this way， users who wish to conduct an exchange with another user or merchant can utilize the transaction engine to perform such an exchange.

With reference to Figure 2， there is illustrated a flow diagram of an embodiment of an improved virtual currency system 200. In this embodiment， the term virtual currency may include any type of virtual or electronic medium of exchange such as， but not limited to virtual cash， reward points， redeemable coupons or any other medium of exchange or barter which can be used or converted for use in a virtual or online market place or online exchange， or used to clear or complete a transaction or trade in an electronic trading/clearing environment where part or all of the transaction or trade occurs online， or in person (in real life) . The term virtual currency may also be referenced as a virtual coin or virtual coins or Vcoin or Vcoins which may exist as a data structure that can be exchanged in an online market environment. It should also be noted that the term online market environment or online marketplace is not limited to a forum whereby transactions or trades are performed on a computer network such as the internet， but may include an online exchange， electronic clearing house， online clearing platform or an online exchange whereby an exchange of funds are cleared online for a transaction or trade which may havebeen performed in person between a merchant and a user.

As illustrated in Figure 2， a virtual currency， which may be referred to as Virtual Coins or Vcoins are firstly generated by a Vcoin generator 202. These Vcoins can have different values although in a preferred embodiment， each Vcoin is of a singular value (e.g. each Vcoin is I Vcoin in value) . The Vcoins are firstly generated by a computer implemented virtual currency generation module 202 which may in turned be controlled and operated by an authorized person 203 who has been given approval to generate the Vcoins. As the generation of Vcoins can have a major impact on the value of each Vcoin in the online marketplace， the authorized person 203 is preferably only approved to generate the Vcoins after economic effects have been considered.

In this example embodiment， each Vcoin， may exist as computer readable data and have a unique identification code or identifier which could be used to mark or reference the particular Vcoin. The Vcoin data or its unique identifier may also be encrypted with a specific security key so as protect the authenticity of the Vcoin and thus reducing or eliminating the possibility of the Vcoin being artificially replicated by a non-authorized party.

Once the Vcoins are generated， these Vcoins are stored in a virtual currency bank module 204， referred to as a Vcoin bank module 204. Preferably， as Vcoins are virtual medium of exchange and thus exist as computer data， the Vcoin bank is effectively a computerized module which accounts for an amount of Vcoins.

In one embodiment， the virtual currency bank module 204 will account for an amount of Vcoins held or owned by particular parties. These parties may include users， merchants or administrators of the virtual currency system. In these embodiments， multiple individual Vcoin bank modules 204 having one or more accounts would be implemented for each user that would use the Vcoin as a medium of exchange. However， in a preferred embodiment， the Vcoin bank module 204 is arranged to account for all Vcoins which are used in the online market place， including all Vcoins that are owned by the administrators of the virtual currency system， merchants， Vcoin users or any other stakeholders. Thus in this preferred embodiment， the system will include only one Vcoin bank module 204 with multiple accounts for each user， administrator and merchant， although as a person skilled in the artwould appreciate， the one Vcoin bank module 204can be replicated on different computcr systcms as different modules communicating together to operate as a single module entity， depending on geographic requirements and network design

In these embodiments， each stakeholder and user of the virtual currency system will have an individual account within the Vcoin bank module 204. This account tracks and adjusts the balance of each stakeholder or user after transactions are made between each of the stakeholders. The Vcoin bank module 204 may also be audited by an auditing module 600. An embodiment of the auditing process is discussed in further details with reference to Figures 5 and 6 and provides the function of reducing the likelihood of fraud in the event that the balance of any particular account is accessed by an unauthorized user.

As shown in this embodiment， the Vcoin bank module 204 may also be in communication with a transaction engine 206 which is arranged to control， regulate and facilitate transactions with theVcoin as a medium of exchange. In this embodiment， the transaction engine 206 is ananged to be accessed when a transaction between two or more parties are engaged to perform a transaction and thus allowing a transaction request sent from either party to be detected and processed.

Once a transaction request is dispatched by a merchant， user or any other parties interested in performing a transaction， a transaction request is received by the transaction engine 206. In turn， the transaction engine 206 will process the transaction request so as to allow the transaction to be performed. In order to perform or execute the transaction， the relevant Vcoin balances of each party’s account in the Vcoin bank module 204 are updated to reflect the transfer of the Vcoins between each of the parties. Following the updating of balances of each of the parties privy to the transaction， the transaction details， including any trade information relating to the transactions are recorded. Preferably， the transaction engine 206 is also arranged to perform various security checks (208) of the transactions to validate their authenticity and the nature of the transactions so as to minimize fraud. This isperlormed by a security module 500which is described in more detail with reference to Figures 4 and 5.

As show in Figures 2 and 3， there is also illustrated an example of the process in which a number of stakeholders may perform transactions in an online market environment by use of the virtual currency or Vcoins. In this example， these stakeholders， which may include users 210， merchants 212 or administrators 214， may each in turn interact with the transaction engine 206 by sending transaction requests to the transaction engine 206. As shown， an administrator 214 of the virtual currency system (who may be a person， group or process responsible for operating， managing and administrating the virtual currency system) may firstly provide a number of Vcoins to merchants 212. After this， the merchants 212 may provide rewards， perks or any other items of exchange through a reward channel 216 or any other custo mer communication channels to initiate transactions with users 210. In this example embodiment， the reward channel 216 may also be administered by the administrator 214 of the virtual currency system 200. In turn， this reward channel 216 can then be used by users 210 to exchange their Vcoins for these specific rewards， perks or other items of exchange from merchants 212 who distributes their rewards， perks or other items of exchange through the rewards channel 216.

As illustrated in the example embodiment shown in Figure 3， the users 210 may also be able to earn Vcoins from a nerchant 212 or through a merchant’s Applications developer 212A who can provide a marketing opportunity for the merchant 212 in exchange for sponsorship 302 in the form of receiving in part some Vcoins for later transactions or exchange with users 210. These Applications developers 212A， who will effectively operate as an advertiser or distributer 212A for the merchant 212， may then produce Apps， media or any other items of interests to attract users 210 through a reward channel 216. This reward channel 216 may be an online platform such as an online advertisement portal， or an App which can be deployed on an App store and is arranged for users 210 to access， in part， for the purposes of earning and spending their Vcoins.

In this example， in order to earn Vcoins from a merchant 212 or any other party， a user 210 may be rcquestcd to pcrform a particular task 304 to earn Vcoins. Such a task may include for example，

-Watching a Video Clip；

-Playing a Game；

-Accessing a webpage or App；

-Visiting a Store or any otherPhysical Location；

-Placing a winning bet on a wagering game；

-Voting in a pole；

-Commenting on a Blog；

-Achieving certain goals in a game or applications； or

-Any one or combination of the above.

Once the task is performed 304 by a user 210， the user 210 is then given one or more Vcoins by a payee (such as a merchant 212， App Developer 212A or any other user) depending on the agreed conditions. Once it is decided that a user 210 is given one or more Vcoins， a transaction request is then sent to the transaction engine 206 whereby the balance of the accounts of the payee 212/212A and the user 210 is updated once the authenticity of the transaction is validated.

Although embodiments described with reference to Figures 2 and 3 would indicated that the Vcoins are earned through a merchant 212 and spent through a rewards channel 216， in some embodiments， this may actually not be necessary as Vcoins can be exchanged between any of the users 210 or stakeholders. In these other example embodiments， merchants 212， users 210， administrators 214 can exchange their own items for Vcoins between each other without the use of a reward channel 216. In these instances， each transaction is then made as a request with the transaction engine either by one or all of the parties involved in the transaction so that the correct balance can be updated. Preferably， some level of supervision or authorization may apply， in which case the transaction engine 206 may apply a setof prede termined rules to determine ifthe requested transactionis a lowable before it is performed bythe transaction engine 206.

With reference to Figure 4， there is illustrated a detailed block diagram of the transaction tracking module 400 arranged to track transaction events conducted with the virtual currency. In this embodiment， the transaction tracking module 400 is arranged to operate with the transaction engine 206 to record individual transaction events. In turn， the events and other transaction related data associated with transaction events can be stored in a transaction database 402 for further processing or future reference such as for auditing， marketing or data mining purposes.

As shown in Figure 4， once a transaction event 401 is detected or received by the transaction engine 206， the transaction tracking module 400 is triggered to extract transaction information (404) from the transaction event 401. Preferably， the transaction information extracted includes trade information 406 relating to the trade which is being performed by the merchant， user， administrator or any other stakeholders， including， for example：

-Identity of the Merchant， user or stakeholder participating in the transaction；

-Date and time of the transaction；

-The amount of virtual currency exchanged；

-The goods or services exchange d for the virtual currency；

-The conditions， ifany， as part ofthe transaction or trade； or

-Any one or more of the above.

In addition to the trade information 406 which is extracted from the transaction event， each Vcoin or virtual currency used in this transaction is also extracted (408) and associated with this particular transaction. As mentioned in at least one embodiment above， each Vcoin may include a unique identifier and thus Vcoins used for a particular transaction will have one or more identifiers which can then be recorded to be associated or linked with a particular transaction.

Once recorded， the trade information and Vcoin identifiers can then be stored in a transaction database 402. This database 402 may be any form of data storage device or system including flat files， hash tables etc although preferably a relational or objected oriented database in used. By storing the trade information and Vcoin identifiers on a database 402， the Vcoin identifiers and the transaction event 401 in which the Vcoin was used as a medium of exchange can be associated. By allowing these associations to be formed and recorded into the database 402， transaction records can be retrieved for further analysis or processing. Moreover， an individual Vcoin can also be traced and tracked based on the historical transactions in which it was involved in and thus data mining can also be performed to identify specific transaction trends， such as， but not limited to where and how Vcoins are earned or spent.

In this embodiment， a data processing module 410 may be implemented to interact with the transaction database 402 so as to query retrieve and process records within the database 402 for data mining purposes. The types of data mining that can be performed may include identifying an individual or a group’s Vcoin usage trends 414 such as where or how certain Vcoins are earned or spent， or trends that are evident with certain users or merchants 416/418 as to show the volume or other statistics of their Vcoin exchanges. These trends can all be presented as a graphical presentation 412 in graphical plots or be extracted as a spread sheet. It will be appreciated by a person skilled in the art that various data trends can be extracted by a data mining process performed on the transaction database.

With reference to Figure 5， there is illustrated a flow diagram of a security module 500 in accordance with one embodiment of the present invention. As mentioned with reference to Figure 2， the security module 500 is arranged to operate with the transaction engine 206 so as to authenticate or validate any transaction requests before these requests are performed. This is advantageous in that transaction requests which are against regulations or are fraudulent can be denied whilst legitimate transactions are allowed to be processed.

In this embodiment， once a transaction request 502 has been sent to the transaction engine 206， the transaction engine 206 will initiate a connection with the security module 500 to validate the transaction request 502. The first of these checks may be to determine ifthe parties privy to the transaction request are valid or authentic users of the virtual currency (504) . Preferably， the identities of each of the parties privy to the transaction request is checked such that it can be confirmed that they have a valid account to use the virtual currency. This may include a check of the identity codes of each party followed by a check with the virtual currency bank 204 to determine that the parties can be identified and their accounts are valid and have not been reported stolen， hijacked， deleted or banned.

As shown in this example， the security module 500 may be arranged to perform an optional step of performing an audit check (506) of the accounts of the parties privy to the transaction. The audit module 600， which is arranged to audit the balances of each party’s Vcoin account， may be called upon to perform a real time audit check (506) of each of the parties. The audit module 600 is further mentioned below with reference to Figure 6.

Once the parties privy to the transaction request 502 are deemed valid， the transaction details relaling to the transaction are also validaled before the transaction is approved (508) . In this embodiment， the transaction details are checked (508) against a rules database 510 which stipulates the types or amounts of transactions which are allowed. As an example， the maximum amount traded for a particular type of merchant may be 100 Vcoins per transactions， or， that there is a total of 100 transactions per day. As a person skilled in the art would appreciate， various rules are possible and may include， without limitation：

-Limits as to transaction amounts；

-Restrictions as to the type of commodity or services exchanged

-Restrictions on the time and date of the transaction request；

-Restrictions or limitations placed on the identity of the merchant or user； or

-Any one or combination of the above.

In addition to these restrictions and limitations， the transaction request may also be checked for fraudulent behaviour by checking the transaction request against previous transaction history. In these instances， the security module 500 is arranged to connect with the transaction database 402 so as to determine if the present transaction request would follow within the trends of past historical trends. In events where the transaction request 502 does not fit within past trends， a fraudulent alert may be raised requiring the parties in the transactions to provide additional validations before the transaction is allowed to proceed.

In the exanple embodiments as illustrated in Figure 5， once a transaction request 502 meets with the validation and rules check， it is deemed to be approved 512 and thus allowing the transaction to be performed. In examples where the validation and rule check fails， the transaction request is denied 514 and alerts or alarms may be triggered.

These examples are advantageous in that the by operating the security module 500 to check and validate each transaction request 502， the probability for fraudulent transactions are substantially reduced. This can add the integrity and trustworthiness of the virtual currency system and thus improvc on its usability and adoptability as a preferred medium of exchange.

With reference to Figure 6， there is illustrated a flow chart of an example embodiment of the audit module 600 arranged to operate with the security module 500 of the improved virtual currency system 200. In this embodiment， the audit module 600 is arranged to perform an audit of theindividual accounts belonging to merchants， users or any other stakeholders that have an account 601 in the virtual Vcoin bank 204 to hold their Vcoins. Preferably， the audit module 600 is arranged to be triggered by the security module 500 when a transaction request 502 is made by users in the onlinemarketplace， although periodic or random 602 execution of the audit module 600 will also allow for individual accounts 601 to be audited even when these accounts are not used for transactions and thus improving the overall security of the entire virtual currency system 200.

In this embodiment， the audit module 600 may be triggered deliberately， randomly 602 or when a transaction request 502 is detected by the security module 500. Once the audit module 600 is triggered， the first procedure is that the audit module 600 will firstly retrieve the virtual currency balance of the individual accounts relevant to an individual transaction or of individual accounts randomly chosen (604) . Once the virtual currency balance is retrieved the audit module 600 will then perform a check of the individual account to identify whether the balance is (606) valid in view of existing transactions which have taken place or whether the changes in the balance would follow the rules or regulations 608 in the operation of the virtual currency system.

In one example， in order to facilitate for this auditing process (606) ， the transaction database 402 and the rules database 608 is accessed by the audit module 600 so as to identify existing and historic transactions relating to an individual account 601 to identify whether the balance in the account 601 is correct or has been fraudulently adjusted. In this example， a total of the balance may be calculated based on the historical transaction data so as to model a correct balance of the account. This modelled balance is then compared with the actual balance of the account 601 and where there is a variance， and it is outside predefined tolerances， the account may be flagged to have been tampered with 612. In addition to this check， should there be a variation or change detected to the balance over a particular course of tine， these changes are also checked against the rules database 608 to identify whether there is any possibility of fiaudulent activities.

In some examples， virtual currency accounts can be tampered with through hacking or unauthorized access whereby individual balances or virtual currencies are adjusted artificially by making unauthorized changes to the balance in the virtual Vcoin bank. However， these embodiments are advantageous in that the audit module 600 may check the balance of the individual account against historical transactions and thus if there were any unauthorized access which had manipulated the balance figures， the audit module 600 will identify that there is a problem with this particular account and proceed to lock the account where appropriate. Furthermore， the audit module 600 is also able toidentify exponent or unnecessarily balance growth in an individual account and in turn can identify areas where fraudulent activities may have occurred. Examples of this includes the limitations of the possible growth of an individual account in that the amount of Vcoins held by an account， if it is increased significantly such that it would exceed the normal rules which apply to the regulation of the system then a fraudulent activity may have been detected.

In these examples， the audit module 600 is arranged to audit individual accounts and where fraud is not detected 610， a notification is returned to the security module 500 so that any pending transactions can proceed. However， in the events where there is a fraudulent behaviour detected 612 or that an account 601 does not come up tp audit requirements， the account will be locked and an alert be made to the administrator of the virtual currency system for action.

With reference to Figures 7 to 9， there is illustrated example screenshots as shown to a user when using the virtual currency system in accordance with some embodiments described above. In this example， a user may firstly start trading with Vcoin through a web browser or an applicationcommonly known as an app through a Smartphone or a computer. In this example embodiment， the user is accessing the virtual currency interface 700 by using a virtual currency app which includes alayout of various rewards through a reward channel tab 702 and an app download tab 704 which allows the user to perform specific actions， such as to record a video 702A， play a game 702B and download an app to earn a virtual currency 704A/B. By performing various actions which are available through this app interface 700， a user can earn virtual currency to spend on additional items and utilize the virtual currency as a reward for merchants or the administrators of these apps. This particular app is able to provide merchants， sponsors or interested parties with a marketing opportunity as the app provides a channel to individual Smartphone users.

As shown in Figure 8， the Vcoin balance 802 of an individual user’s account may be shown along with opportunities to look at historical transactions 804 to identify any special deals 806 or areas where they are able to utilize their Vcoin balance 808. In these examples， once a user selects any of these functions， various databases may be queried to return any relevant results desired by the user. In addition to these features， the app may also include an “Earned Vcoin” section 810 which allows the user to perform various tasks， such as to watch videos， play a game or download an application to earn additional Vcoins. Once selected， the user may be directed to various merchants， app developers or rewards channels that may offer Vcoins or rewards.

With reference to Figure 9， there is shown an example screenshot of interface 900 showing that the user has redeemed a paticular item through the use of Vcoins via their smartphone. In this example， the user would have exchanged five of their Vcoin to purchase a paticular item in which case a redeemable QR code 902 is automatically provided to the user. Once the user received this QR code 902， or any other code or receipt number， the user can then proceed to take this QR code 902 on their Smartphone to the relevant merchant and show the QR code for scanning or redemption for the actual item. Preferably， in many examples there will be an expiry date 904 provided for each of these redemptions so as to encourage that the redemption is made as soon as possible. In situations where the redemption is not made within the timeframe， the Vcoin purchase may be refunded back to the user or retfunded back to the administrator or merchant as it would be appropriate.

Some embodiments of the improved virtuaf currency system described above are advantageous in that the system is able to track the usage of a virtual currency. The system， as described in some embodiments， allows transactions to be performed on a transaction engine which can detect and record all transaction events and thus allowing greater control of the transactions through the security and audit modules which regulate and check each transaction and users who initiate the transactions before the transactions are performed. Such a level of control and enhance security allows the virtual currency system to be more resistant to fraud and may improve its adoptability as a medium of exchange.

Although not required， the embodiments described with relerence to the Figures can be implemented as an application programming interface (APl) or as a series of libraries for use by a developer or can be included within another software application， such as a terminal or personal computer operating system or a portable computing device operating system. Generally， as programmodules include routines， programs， objects， components and data fules assisting in the performance of particular tunctions， the skilled person will understand that the functionality of the software application may be distributed across a number of routines， objects or components to achieve the same functionality desired herein.

It will also be appreciated that where the methods and systems of the present invention are cither wholly implemented by computing system or partly implemented by computing systems then any appropriate computing system architecture may be utilized. This will include stand alone computers， network computers and dedicated hardware devices. Where the terms “computing system” and “computing device” are used， these terms are intended to cover any appropriate arrangement of computer hardware capable of implementing the function described.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are， therefore， to be considered in all respects as illustrative and not restrictive.

Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge， unless otherwise indicated.

Claims

A method for managing a virtual currency comprising the steps of：

- detecting transaction events in an online exchange whereby each transaction event is performed with a pre-generated virtual currency having a base unit， each base unit having a unique identifier；

- recording trade information associated with each of the transaction event； and

- processing the trade information to identify one or more transaction trends.
A method for managing a virtul currency in accordance with claim 1， wherein the recorded trade information is associated with the unique identifier of each base unit of the pre-generated virtual currency.
A method for managing a virtual currency in accordance with claim 2， wherein trade information is processed with the associated unique identifier to identify one or more transaction trends of each base unit of the pre-generated virtual currency.
A method for managing a virtual currency in accordance with claims 1， 2 or 3， further including the steps of：

- receiving one or more transaction requests for the one or more transaction events from a plurality of parties； and，

- executing the one or more transaction requests to complete the one or more transaction events.
A method for managing a virtual currency in accordance with claim 4， wherein the one or more transaction requests are received from a plurality of parties in the online exchange.
A method for managing a virtual currency in accordance with claim 5， wherein the plurality of parties in the online exchange includes administrators， merchants and users.
A mcthod for managing a virtual currcncy in accordancc with any one of the preceding claims， wherein the pre-generated virtual currency is electronically stored within accounts held by each administrator， merchant or user.
A method for managing a virtual currency in accordance with any one claims 3 to 7， wherein the one or more transaction trends are identified by retrieving and processing one or more historical transaction events associated with each unique identifier.
A method for managing a virtual currency in accordance with any one of claims 4 to 8， wherein each of the transaction requests from the plurality of parties is validated before execution.
A method for managing a virtual currency in accordance with claim 9， wherein each of the transaction requests are validated by checking an authenticity status of each of the plurality of parties privy to the transaction request and comparing each transaction condition associated with each of the transaction requests against a set of predetermined transaction rules.
A method for managing a virtual currency in accordance with claim 10， wherein the each transaction condition associated with each of the tansaction requests is further compared against the one or more transaction trends.
A method for managing a virtual currency in accordance with any one of claims 9 to 11， wherein the accounts held by each of the plurality of parties privy to the transaction requirements are audited.
A method for managing a virtual currency in accordance with claim 12， wherein the account of each of the plurality of parties are audited by retrieving an account balance of the accounts held by each of the parties and comparing the balance against a set of predetermined account balance conditions
A method for managing a virtual currency in accordance with claim 13， wherein a total balance figure is calculated from the one or more historical transaction events associated with each of the plurality of parties and compared with the account balance of each of the plurality of parties.
A method for managing a virtual currency in accordance with claim 13 or 14， wherein the accounts held the plurality of parties are audited randomly.
A method for managing a virtual currency in accordance with any one of the preceding claims， where in the trade information includes： merchant identification， user identification， date/time stamp， product of exchange， virtual currency exchanged or any one or combination thereof.
A method for managing a virtual currency in accordance with any one of the preceding claims， wherein the unique identifier is encrypted.
A method for managing a virtual currency in accordance with any one of the preceding claims， wherein the one or more transaction trends include earning and spending pattern of each base unit.
An improved virtual currency system comprising：

- a transaction engine arranged to detect transaction events in an online exchange whereby each transaction event is performed with a pre-generated virtual currency having a base unit， each base unit having a unique identifier；

- a transaction database arranged to record trade information associated with each of the transaction event； and

- a data processor arranged to process the trade information to identity one or more transaction trends.
An improved virtual currency system in accordance with claim 19， wherein the recorded trade information is associated with the unique identifier of each base unit of the pre-generated virtual currency.
An improved virtual currency system in accordance with claim 20， wherein trade information is processed with the associated unique identifier to identify one or more transaction trends of each base unit of the pre-generated virtual currency.
An improved virtual currency system in accordance with claims 19， 20 or 21， wherein the transaction engine is further arranged to：

- receive one or more transaction requests for the one or more transaction events from a plurality of parties； and，

- execute the one or more transaction requests to complete the one or more transaction events.
An improved virtual currency system in accordance with claim 22， wherein the one or more transaction requests are received from a pturality of parties in the online exchange.
An improved virtual currency system in accordance with claim 23， wherein the plurality of parties in the online exchange includes administrators， merchants and users.
An improved virtual currency system in accordance with any one of claims 19 to 24， wherein the pre-generated virtual currency is electronically stored within accounts held by each administrator， merchant or user.
An improved virtual currency system in accordance with any one claims 21 to 15， wherein the one or more transaction trends are identified by retrieving and processing one or more historical transaction events associated with each unique identifier.
An improved virtual currency system in accordance with any one of claims 22 to 26， wherein each of the transaction requests from the plurality of parties is validated by a security module before execution.
An improved virtual currency system in accordance with claim 27， wherein each of the transaction requests are validated by checking an authenticity status of each of the plurality of parties privy to the transaction request and comparing each transaction condition associated with each of the transaction requests against a set of predetermined transaction rules.
An improved virtual currency system in accordance with claim 28， wherein the each transaction condition associated with each of the transaction requests is further compared against the one or more transaction trends.
An improved virtual currency system in accordance with any one of claims 27 to 29， wherein the accounts held by each of the plurality of parties privy to the transaction requirements are audited by an audit module.
An improved virtual currency system in accordance with claim 30， wherein the account of each of the plurality of parties are audited by retrieving an account balance of the accounts held by each of the parties and comparing the balance against a set of predetermined account balance conditions
An improved virtual currency system in accordance with claim 31， wherein a total balance figure is calculated from the one or more historical transaction events associated with each of the plurality of parties and compared with the account balance of each of the plurality of parties.
An improved virtual currency system in accordance with claim 31 or 32， wherein the audit module is arranged to audit accounts held the plurality of parties randomly.
An improved virtual currency system in accordance with any one of claims 19 to 33， where in the trade information includes： merchant identification， user identification， date/time stamp， product of exchange， virtual currency exchanged or any one or combination thereof.
An improved virtual currency system in accordance with any one of claims 19 to 34， wherein the unique identifier is encrypted.
An improved virtual currency system in accordance with any one of claims 19 to 35， wherein the one or more transaction trends include earuing and spending pattern of each base unit.