AU2013101675A4 - A Token and Gifting System and Method - Google Patents

Abstract

A token and gifting system and method for a customer to gift rewards, whereby the rewards can be accumulated and redeemed. The system includes a token or gift server application to coordinate and control operation of the token or gifting system and interact with a database to store accounting and identification information in relation to each customer, merchant, gift buyer and gift receiver who are members of the system. The tokens or gift rewards are of different types and have different values, the tokens ad gift rewards being able to be accumulated within an account of the customer on the token or gift server. A merchant application communicates with the token or gift server and provides for administration of a merchant's involvement in the gift system. A printer device is communicated with by the merchant application for printing an order receipt during the invocation of a redemption process. A customer application invokes an instance of operation of the token or gifting system with a particular customer so that the customer can acquire tokens or gift rewards, or be provided with token or gift reward detail and merchant identification and location data, or a selected merchant to redeem a token or gift reward. 17 4' 22 Token server customer PRS server check customer ID retrieve points S-ask {Points} balance points to convert M I update ask {dentifier} account submit beneficiary 20 4 send {Identifier, Tokens) update database

Description

1 A Token and Gifting System and Method FIELD OF THE INVENTION This invention relates to gifting schemes such as loyalty and reward schemes (reward schemes) that may be implemented or deployed by a scheme provider to reward a customer or employee (customer) of a member of the scheme provider. The invention has particular, but not exclusive, utility in use with a token redeeming system and method of the type described in Australian Patent Specification 2012902078, the description of which is incorporated herein by reference. Such a system and method involves a rewarder merchant or service provider (merchants) for converting a prescribed token or number of tokens to a product or service to the benefit of a customer of the merchant. The present invention may find useful purpose with members of the scheme provider who in themselves may be merchants or employers of the customer and who wish to maintain or acquire the custom or service of the customer, or reward the customer in appreciation of services rendered to or for the member. Throughout the specification, unless the context requires otherwise, the word "comprise" or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers. BACKGROUND OF THE INVENTION The following discussion of the background art is intended to facilitate an understanding of the present invention only. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material 2 referred to was part of the common general knowledge as at the priority date of the application. Reward schemes have become commonplace for merchants to adopt in order to attract repeat business from their customers. These schemes have proved to be particularly attractive to customers and have reached the stage where the customer is now discriminating between which merchant to use for the purchase of products or services depending upon the quality of the particular reward scheme employed by the merchant and the benefits ascribed to the customer by way of the scheme. Given the ubiquitousness nature of these schemes and their ability to provide products or services in a cashless manner, there is an opportunity for such schemes to be deployed in a manner to improve customer service or loyalty by the provision of token gifts as a reward for excellent service by the customer, or as compensation for poor or dilatory service by the merchant, and in this manner endeavour to attract or retain the custom of customers. SUMMARY OF THE INVENTION It is an object of the invention for a merchant to conveniently and readily provide gifts to customers in the form of redeemable tokens. In accordance with one aspect of the present invention, there is provided a token system for a customer to redeem tokens representative of a product or service from a merchant in real time, the tokens being accumulated by the customer in a reward scheme of a scheme provider including: a token server to coordinate and control operation of the token system and having a database to store accounting and identification information in relation to each customer and merchant that are members of the token system, 3 the tokens being of different object types and having different values, and which are able to be accumulated within an account of the customer on the token server; application modules, including: (i) a merchant application to communicate with the token server and provide for administration of a merchant's involvement in the token system, and (ii) a customer application to invoke an instance of operation of the token system with a particular customer so that the customer can be provided with token object detail and merchant identification and location data, and a specific instance of operation of the token system with the redemption service and a selected merchant to perform a transaction with the merchant and the token server; a portable customer client having an operative customer application and interactive processing logic to communicate with the token server over a network; a merchant client having an operative merchant application and interactive processing logic to independently communicate with the token server over a network; said token server including a server merchant servicing application for receiving communications from the merchant client and having processes to permit the merchant to register its merchant identification and location data, and specify object detail that it has agreed to provide to a customer invoking a said specific instance to perform a transaction with the merchant; and the merchant application having a coding process for the merchant to access its account on the redemption server and set or reset a security code to verify token transactions provided by it to customers in real time; 4 wherein to invoke said instance: the customer application has a client redemption process for displaying all of the tokens of different object types that may be redeemed and the relative merchants or locations where the tokens may be redeemed from, the client redemption process on invoking by the customer: (a) transmits customer data to the token server; (b) displays all of the different tokens that may be redeemed by the customer and activates the displayed icons for receiving a selection input from the customer; (c) on the customer asserting a selection input, displays further details regarding the selected token object and selectively the merchant and location of the merchant where the particularly selected token object may be redeemed together with an assertable button for invoking said specific instance; and wherein to invoke said specific instance, the client redemption process is invoked for redeeming one or more token objects of a prescribed type in exchange for a product or service provided by a merchant, the transaction process on initiating by the customer: (I) on processing by the token server, receives and displays from the token server the security code of the merchant for verification to the merchant that the transaction is valid; (II) provides for receipt of a confirmatory input by either the merchant or the customer to further verify the authenticity of the transaction; (III) or if not valid, receives and displays a message signifying the invalidity of the transaction; the token server has a server redemption process to receive and process messages from the portable customer client over the network, the token 5 redemption process in response to activating the client redemption process of the portable customer client: (A) receives customer data and the selected token object from the client redemption process at (a) and (c); (B) accesses the database to verify: i. the customer from the customer data; ii. the sufficient balance of accumulated tokens of the prescribed type indicated by the image that are stored in the account of the customer; and obtain the security code of the merchant offering to redeem the selected token object; (C) deducts the token amount of the prescribed type from the balance of accumulated tokens stored in a current account of the customer; (D) transmits the security code of the merchant to the portable customer client, if the verification of the transaction at (B) is valid; or (E) transmits a message signifying an invalid transaction to the portable customer client, if the verification of the transaction at (B) is invalid. In accordance with a further aspect of the present invention, there is provided a gifting system for a member of a reward scheme to provide tokens to a customer or a prospective customer of the reward scheme for subsequent redemption with a merchant as part of the reward scheme, including: a token server to coordinate and control operation of the gifting system and having a database to store accounting and identification information in relation to each member and customer of the gifting system; 6 the tokens being of a type prescribing a specific monetary value for each token of that type, said tokens being capable of accumulation within accounts of members and customers on the token server; application modules, including: (i) a member application to communicate with the token server and provide for administration of the member's involvement in the token transaction to be performed with the customer, the token transaction involving the transfer of a prescribed number of tokens from a token account of the member to a token account of the customer; and (ii) a customer application to invoke an instance of operation of the gifting system with the member and communicate with the token server to provide member data and customer data in respect of the token transaction between the member and the customer; a portable customer client having an operative customer application and interactive processing logic to communicate with the token server over a network; a member client having an operative member application and interactive processing logic to independently communicate with the token server over a network; wherein to invoke said instance: the member application has: (a) a client buy tokens process for the member to access its account on the token server and acquire tokens for use in the token transaction to ensure its account is in credit; and (b) a client give tokens process for the member to gift tokens to the customer; 7 wherein the client give tokens process on invoking by the member: (I) transmits member and customer data to the token server; (II) displays all of the different tokens that may be gifted to the customer and activates the displayed tokens for receiving a selection input from the member; (III) on the customer asserting a selection input sends a message to the token server to transfer the selected tokens from the members account to the customer's account; and wherein the token server has a server gifting process to receive and process messages from the portable customer client over the network, that in response to invoking said token gifting process of the customer application: (A) receives member data and customer data from the customer client transmitted as a consequence of action (I); (B) accesses the database to verify: i. the member from the member data and the customer from the customer data; ii. the sufficient balance of accumulated tokens of the token transaction type stored in a current account of the member; (C) debits the token amount of the token transaction type from the token amount of accumulated tokens stored in the current account of the member and credits a trust account of the member where the gifted tokens are locked from access of the member; (D) credits the token amount to the customer account; and (E) verifies to the member client and the customer client that the token transaction has been performed. Preferably, the portable customer client of the token system incudes a camera; and graphic codes are ascribed uniquely to each merchant using the 8 token system, whereby each graphic code corresponds to a unique merchant identification and a transaction involving a particular token type, each merchant having a representation of its graphic code for a particular token type readable by said camera of any customer client; and wherein the client redemption process on invoking by the customer: (i) invokes operation of the camera on the portable customer client for scanning the representation of the graphic code of the merchant, the graphic code so scanned corresponding to a particular token type of the customer to be exchanged for the provision of the product or service of the merchant requested by the customer; (ii) transmits customer data and merchant data to the redemption server; (iii) on processing by the redemption server, receives and displays from the redemption server the secret code of the merchant for verification to the merchant that the transaction is valid, and invokes a timer to count down a predetermined time period and displays an animation during the predetermined time period; (iv) provides for receipt of a confirmatory input during the predetermined time period to further verify the authenticity of the transaction; (v) or if not valid, receives and displays a message signifying the invalidity of the transaction. In accordance with another aspect of the present invention, there is provided a gifting system for a customer to gift rewards, whereby the rewards can be accumulated and redeemed, including: a gift server application to coordinate and control operation of the gifting system and interacting with a database to store accounting and identification 9 information in relation to each customer, merchant, gift buyer and gift receiver who are members of the gifting system; the gift rewards being of different object types and having different values, the gift rewards being able to be accumulated within an account of the customer on the gift server; a merchant application to communicate with the gift server and provide for administration of a merchant's involvement in the gift system and a printer device for printing an order receipt during the invocation of a redemption process; and a customer application to invoke an instance of operation of the gifting system with a particular customer so that the customer can acquire gift rewards, or be provided with gift reward detail and merchant identification and location data, or a selected merchant to redeem a gift reward. In accordance with another aspect of the present invention, there is provided a method for a customer redeeming points accumulated by the customer in a reward scheme of a scheme provider in real time with a merchant providing a prescribed reward in accordance with the scheme, the method comprising: prescribing a specific monetary value to each token of a token type for which a prescribed number of points accrued by the customer in the reward scheme may be redeemed by the customer from the scheme provider for a token type and accumulated within an account of that customer; transmitting customer data and selected token data of a token selected for redemption by the customer to a token server for processing; the token server: (i) receiving customer data and selected token data; (ii) accessing a database to verify: 10 i. the customer from the customer data and the merchant from the merchant data; ii. the sufficient balance of accumulated tokens of the prescribed type indicated by the image that are stored in the account of the customer; and obtaining the security code of the merchant offering to redeem the selected token; (iii) deducting the token amount of the prescribed type from the balance of accumulated tokens stored in a current account of the customer; (iv) transmitting the security code of the merchant to the portable customer client, if the verification of the transaction at (ii) is valid; or (v) transmitting a message signifying an invalid transaction to the portable customer client, if the verification of the transaction at (b) is invalid; the portable customer client: (a) receiving and displaying the security code of the merchant for verifying to the merchant that the transaction is valid; (b) providing for receipt of a confirmatory input by either the merchant or the customer to further verify the authenticity of the transaction; or (c) if the transaction is not valid, receiving and displaying the message received at (v) signifying the invalidity of the transaction. In accordance with another further aspect of the present invention, there is provided a method for enabling a member of a reward scheme to provide tokens to a customer or prospective customer of the reward scheme for subsequent redemption with a merchant as part of the reward scheme, the method comprising: 11 prescribing a specific monetary value to each token of a token type for which a prescribed number of points accrued by the customer in the reward scheme may be redeemed by the customer from the scheme provider for a token type and accumulated within an account of that customer; transmitting member and customer data to a token server for processing; displaying to the member all of the different tokens that may be gifted to the customer and activating the displayed tokens for receiving a selection input from the member; on the customer asserting a selection input sending a message to the token server to transfer the selected tokens from the members account to the customer's account; the token server: (i) receiving member data and customer data from the customer; (ii) accessing the database to verify: i. the member from the member data and the customer from the customer data; ii. the sufficient balance of accumulated tokens of the token transaction type stored in a current account of the member; (iii) debiting the token amount of the token transaction type from the token amount of accumulated tokens stored in the current account of the member and credits a trust account of the member where the gifted tokens are locked from access of the member; (iv) crediting the token amount to the customer account; and (v) verifying to the member client and the customer client that the token transaction has been performed.

12 BRIEF DESCRIPTION OF THE DRAWINGS The invention will be described with respect to several embodiments which make reference to the following drawings: Fig. 1 is a schematic diagram showing the relative function structure of the token system relative to a points reward scheme. Fig. 2 is a block diagram showing the various components of the token system. Fig. 3 is a schematic diagram showing the different types of tokens that are used within the token system. Fig. 4 is a sequence diagram showing the conversion process of points to tokens for a customer of the points reward scheme. Fig. 5 is a workflow diagram of the client give tokens process using pages of the smartphone to show the workflow. Fig. 6 is a workflow diagram of the client login and join process using pages of the smartphone to show the workflow. Fig. 7 is a sequence diagram showing the login and join process for a customer to become a member of the token reward scheme. Fig. 8 is a workflow diagram of the client buy tokens process using pages of the smartphone to show the workflow. Fig. 9 is picture of a smartphone showing the security page displayed by the client security process on a merchants smartphone.

13 Fig. 10 is a workflow diagram of the client redemption process using pages of the smartphone to show the workflow. BEST MODE FOR CARRYING OUT THE INVENTION The best mode for carrying out the invention may be implemented in one of several embodiments. The first embodiment is directed towards a token system 1 including a redemption system 3, a gifting system 5 and a token purchasing system 7; and methods of operating same as discrete processes. As shown in Fig. 1, the token system 1 of the present embodiment is used in connection with a points reward scheme 9 operated by a points scheme provider 2, but can also be operated entirely independently of the points reward scheme. In the points reward scheme 9, points are accumulated by customers 4 patronising the points scheme provider 2 by purchasing products or services offered by the provider. These points reward schemes 9 are well known in the art, (e.g. frequent flyer rewards programmes) whereby each customer 4 accumulates points over time for prescribed transactions performed by them. The points are held in a customer account managed by the points scheme provider 2 directly or outsourced to another party to manage under the guise of the points scheme provider 2. The points are redeemable by a customer 4 accessing the points reward scheme 9 over the Internet in exchange for various rewards prescribed by the points scheme provider 2. Hence, each point has a value prescribed by the points scheme provider 2, and can be transacted a number of different ways. The token system 1 of the present invention described in this embodiment is a separate offering to the points reward scheme 9 and in fact is operated entirely independently of it. In the present embodiment it is accessible as part of the points reward scheme 9 and is presented to customers 4' of the points reward 14 scheme as one of many options in which points accumulated by them may be redeemed in real time, separate from other offerings of the points scheme provider 2 for redeeming accumulated points. However, the token system 1 can be accessed by customers 4 separately and independently of the points reward scheme 9, where these customers need not necessarily be customers of the points reward scheme at all, and simply become customers 4" of the token reward scheme 11. In the present embodiment, the token system 1 implements a token reward scheme 11 operated by a third party token scheme provider 6 at arms length to the points scheme provider 2. In other embodiments, however, the token scheme provider 6 and the points scheme provider 2 can be the same party. Neither arrangement makes any substantive difference to the best mode of performing the invention from a technical perspective, whereby the customers 4' of the points scheme provider 2, once choosing to take up the offering of the token reward scheme 11, will become customers of the token scheme provider 6, along with customers 4" of the token reward scheme 11 per se. As shown in Fig. 2, the token system 1 of the present embodiment revolves around customers 4" of the token scheme provider making use of their smartphone 13 and downloading a prescribed customer application module 15 tailored to provide access to the token reward scheme 11. This customer application module 15 allows the customer 4 to invoke: " the redemption system 3 for redeeming tokens that have been acquired in various ways, " the gifting system 5 for gifting tokens to another customer, or * the token purchasing system 7. The token system 1 enables the customer 4 to accumulate tokens from different sources in an account, including: 15 * converting accumulated points into tokens from the customer's participation in the points reward scheme 9, " receiving tokens gifted from another member of the token reward scheme 11 using the gifting system 5, or " purchasing tokens outright from the token scheme provider directly using the token purchasing system 7. The different ways in which the token system 1 can be accessed by customers using their smartphone 13 are provided as different selectable options available to the customer on invoking the customer application module 15 on their smartphone, and are displayed along the bottom bar 13a of the smartphone 13. Depending upon the option selected, the customer application will invoke the redemption system 3, the gifting system 5, or the token purchasing system 7. As shown in the drawings, the token system 1 generally comprises: * a token server 17 operated by a token host, who in the present embodiment is the token scheme provider 6, " the downloadable prescribed customer application module 15, which will hereinafter be referred to as the customer application 15' when downloaded and operating on a customer client, " portable customer clients of each customer or member of the token reward scheme 11 for downloading and running the customer application 15', the portable customer client in the present embodiment being the smartphone 13 of the customer, * a downloadable merchant application 16 for running on a merchant client, which in the present embodiment is a personal computer 18 of a merchant 8 with web browser access; and * a points reward scheme (PRS) access process 20 for running on a points reward provider (PRP) server 22 that operates the points reward scheme 9 and which allows a customer to convert points to tokens.

16 In another embodiment, the merchant client instead of being a personal computer is a smartphone. The token server 17, smart phone 13 and personal computer 18 are interconnected via a wireless network, which in the present instance is the Internet 19. In this manner, a number of customers 4 can communicate with the token server 17 independently of each other using their respective smartphones 13 running the customer application 15' downloaded onto same. Similarly, a number of merchants 8 can independently communicate with the token server 13 via their respective personal computers 18 on which their merchant applications 16' are downloaded. As previously mentioned, the utility of the token system 1 involves the use of tokens. In the present embodiment, tokens are classified into a variety of different types and are prescribed a specific monetary value. As shown in Fig. 3 of the drawings, token types include: generic tokens 21, specific value tokens 23, product specific tokens 25 and branded tokens 27. The generic tokens are further divided into three kinds: bronze 21a, silver 21b and gold 21c. For example, a bronze token 21a is ascribed a value typically of three dollars or more, a silver token is ascribed a value of six dollars or more and a gold token is ascribed a value of ten dollars or more. Depending upon the rewards scheme of which the customer is a member, a bronze token may be the equivalent of 300 points, a silver token 600 points and a gold token 1000 points. As can be appreciated, the number of points to be converted into a particular token will differ, depending upon the particular type of rewards scheme of which the customer is a member. The specific value tokens 23 are divided into different monetary values, eg. $10 token 23a, $20 token 23b, $30 token 23c etc. The product specific tokens 25 are of predetermined values corresponding to a designated service value across a number of merchants, and so are not 17 merchant specific. For example product specific tokens may be provided for: a 1 hour massage 25a, a regular car wash 25b, a healthy lunch pack 25c, a beer 25d, a coffee 25e etc, where the value of the token is predetermined for the particular product or service. Branded tokens 27 are designated a prescribed value by a sponsoring merchant 8 and thus are merchant specific. Branded tokens may be the only kind of token that can be used to obtain a reward from a particular merchant 8, or they may be used in addition to other tokens. Branded tokens attract an advertising fee from a merchant 8 adopting same and are typically ascribed a higher monetary value than a similar token of another type. Importantly, every token used by the token system 1 has a creation date and an expiry date. The creation date is automatically assigned by the token server 17 invoking a token dating process 29 once a token is received into the account of a member or prospective member from one of the three ways of accumulating tokens as mentioned above. The token dating process 29 date stamps the token with the date it is credited into the account of a member or prospective member 4" of the token reward scheme 11, which functions as the creation date, and automatically calculates the expiry date using either a default setting that applies to all tokens, or in certain embodiments, a customised user selectable period setting. For example, the default setting may be 6 months from the creation date, and user selectable settings for gifted tokens may be 3 months or 12 months. Adopting tokens in this manner effectively normalises points from different rewards schemes to a common value so that a single token system 1 can be used for a variety of different customers 4 being members of one or more different points reward schemes 9 as previously mentioned. Now describing the function structure of the token system 1 in more detail, the token server 17 includes a database 31 and a simple accounting system (not shown) as well as various processes to communicate with the customer 18 smartphones 13, merchant computer 18 and PRP server 22 of the points reward provider 2. The database 31 stores accounting and identification information in relation to each customer 4 and merchant 8, who are members of and participate in the token reward scheme 11. It also stores accounting and some of the identification information of a prospective member of the token reward scheme 11 to whom tokens may be gifted even though the prospective member has not yet registered with the token reward scheme. Populating the token server 17 with customer information in the present embodiment is achieved in two ways, one being indirectly by way of gifting tokens to a prospective member of the token reward scheme 11, and the other being directly by way of a new member creating an account upon the token server. In the case of the former, the initial information obtained for a prospective member from an actual member needs to be supplemented and completed by way of the latter direct process, before any gifted tokens accumulated for the prospective member can be used. In the case of gifting tokens, this can be done in one of two ways as well, one being by way of a customer 4 choosing to convert points it has accrued on the points reward scheme 9 of which it is a member 4' to tokens for use within the token reward scheme 11 either by them or a third party, regardless of whether they or the third party are members or prospective members of the token reward scheme. The second way is for a member 4" of the token reward scheme 11 to gift some or all of their accumulated tokens to a third party, regardless of whether that third party is a member or prospective member of the token reward scheme. In the first way, the PRS access process 20 is invoked via a selection menu on the website of the points scheme provider 2 by the customer 4' and involves processing a sequence of steps as shown in Fig. 4 of the drawings, interacting with the database 31 for storing account information of customers 4' of the points reward scheme 9.

19 Firstly the PRS access process 20 identifies the customer 4' from their access of the points reward scheme and checks the customer identifier with the PRS server 20 to retrieve the points balance of the customer stored in the database 31 of the points rewards scheme 9. It then sends an ask points message providing the customer with the points balance and asking for how many points the customer wants to convert to tokens at the relevant conversion rate. Depending upon the agreement between the service providers, the tokens available for conversion may be limited to only one token type, or several different token types that are selectable for conversion by the customer. On the customer inputting the number of points/tokens to convert, and the particular token type as applicable, the PRS server 20 updates the database 31 of the points reward scheme deducting the requested number of points/tokens to convert from the previous balance to enter a new points balance in the customer's account. The PRS access process 20 then sends an ask identifier message to the customer 4' for the customer to input a unique identifier of the beneficiary to whom the tokens are to be provided or gifted. In the present embodiment, this unique identifier is the mobile telephone number of either a member or prospective member of the token reward scheme 11. In another embodiment, the unique identifier is an email address of the intended beneficiary, and in a further embodiment it is both the mobile address and the email address. After the unique identifier of the beneficiary is input by the customer 4', the PRS server 22 sends a detail message to the token server 17 providing the details of the beneficiary and the number of tokens and type(s) that have been converted. The token server 17 on receipt of the detail message then invokes a server gifting process 33 as part of the gifting system 5. The server gifting process 33 processes the detail message and from the identifier ascertains whether the beneficiary is an existing member of the token reward scheme or a prospective member, who has not yet joined. If the beneficiary is an existing member, then the gifting process simply updates the account of the beneficiary with the requisite number of tokens of the 20 requisite type(s). If the beneficiary is a prospective member, then a new account is created under the unique identifier, and the requisite number of tokens of the requisite type(s) is stored under that account for subsequent use by the party that ultimately registers with the token reward scheme using the unique identifier In the second way, a client "give tokens" process 35 is firstly invoked by a member 4" of the token reward scheme selecting the "give tokens" option 36 along the bottom bar 13a of their smartphone 13, after activating the customer application module 15, as shown in Fig. 5 of the drawings. The client give tokens process also forms part of the gifting system 5 and operates in conjunction with the server gifting process 33. On the member 4" selecting the give tokens option 36, the client give tokens process 35 opens a page 37 providing different contact list options where the unique identifier of a person to whom tokens are intended to be gifted may be listed. As previously described, the unique identifier in the present embodiment is a mobile telephone number of a person. In the particular embodiment shown, one button 37a when activated selects the contacts list from the smart phone 13 of the member 4" and another button 37b when activated selects a contacts list from a social media site. In the case of the member 4" selecting the contacts list button 37a of the smart phone 13, the give tokens process 35 proceeds to display a listing of the various contacts at 38. On selecting a particular contact the give tokens process 35 opens another token option at page 39 displaying the name of the selected contact for gifting the tokens and the tokens available for gifting. In the case of the latter, the present embodiment provides for two types of tokens to be given, those which are free to give at 39a, arising from, for example a promotional scheme of a business offering a branded token 27, and the member's own accumulated tokens at 39b. It should be noted that each token listed for selection identifies the name of the token type and the expiry date of the token.

21 Upon a member 4" selecting an available token for gifting, the give tokens process 35 proceeds to display the page 40, which lists the selected person at 40a, specific detail of the token on offer to the selected person at 40b, a space to write a message to the selected person at 40c, the number of tokens of the particular type to be gifted, which is user incrementable or decrementable at 40d, and a transaction button at 40e to effect the transaction. After the transaction button 40e is asserted, the give tokens process 35 proceeds to send a transaction message to the token server 17 for actioning the gifting request. The token server 17 then invokes the gifting process 33 as part of the gifting system 5, which then operates in the same manner as previously described in the first way of gifting tokens except for the token server 17 communicating with the smartphone 13 of the member 4" via the give tokens process 35, instead of the PRS server 22 via the PRS access process 20. At the same time, the give tokens process 35 proceeds to display a posting option page for displaying a message on the social media site of the member 4" at 41, this page provides two options to the member, one being a button at 41 a to post the message shown at 41 b on the social media page or select the button 41 c to skip this step. After the member selects either button 41 a or 41 b, the give tokens process 35 displays a confirmation page 42. This page provides a summary of the events that have been undertaken as a consequence of activating the give tokens process 35. In the event of the member 4" selecting the button 37b of the social media contact list at page 37, the give tokens process 35 proceeds to display an introduction page at 43 providing a confirmation button 43a for the member to assert before connecting to the social media page. On asserting the button 43a, the give tokens process 35 proceeds to display a gift tokens home page 44 from the social media site on which the member can log in by asserting button 44a to access a contact list of friends. The social media site is programmed to display 22 the contact list of the particular member who has logged in and display it at page 45. On the member selecting a person to gift tokens to, the social media site transfers the relevant information back to the give tokens process 35 and displays the page 39 to the member on their smartphone 13 in the same manner as previously described. From this point on, the give tokens process 35 continues in the same manner as in the case of selecting a person to gift tokens to from the contacts list of the smartphone. As previously mentioned, the other way of populating the database 31 of the token server 17 with customer information is by way of a new member creating an account that is stored on the database 31 of the token server. This is achieved by a prospective member of the token rewards scheme 11 downloading the customer application 15' to their smartphone 13 and opening the application. On opening the application 15', a login and join process 51 as shown in Fig 6 is invoked on the smartphone 13 that initially displays a login and create account page 53 to the prospective member. The login and create account page 53 provides two options: one being for an existing member to login by pressing the login button 53a; and the other being for a prospective member to create an account by pressing the create account button 53b. Dealing firstly with a new member creating an account, the login and join process 51, upon the user asserting the create account button 53b, proceeds to display a user account input page 55 listing the relevant information to be input for the member to create an account at 55a and a create account button 55b. When the user asserts the create account button 55b, the login and join process 51 checks that all fields have been entered and sends a new member registration message containing a list of entered customer information to the token server 17. Each of the fields are essential for entering, in particular the mobile number field 55c, which as previously described is adopted as the unique identifier of the member. The token server 17 on receiving the message activates a new member registration process 49 on the token server 17, which then proceeds to register the prospective member as a new member of the token 23 reward scheme 11. The new member registration process 49 will be described later but essentially involves checking whether the prospective member already has an account created on the database 31 as a consequence of another member gifting one or more tokens to them by way of their unique identifier, or whether the respective member is new and requires a completely new account to be created for them. In either case, an account for the new member is created in full and readied for activation. Whilst the new member registration process is proceeding, the login and join process 51 displays a timing page 57 on the smartphone 13. When the new member registration process 49 has completed the registration of the new member 4", the token server 17 sends a return message to the smart phone 13, which is processed by the login and join process 51 to step to displaying a verification page 59, which includes a message pane 59a, a verification window 59b and a submit button 59c. In the present embodiment, the token system 1 relies upon sending an SMS text message to the mobile phone number of the smart phone 13 of the new member and displays a message in the window pane 59a explaining how to process the SMS text message on receipt of same. As indicated in the drawings, in the present embodiment the text message is designed with a hyperlink that can be pressed to verify the activation of the member's account. Alternatively, the new member can enter the verification code in the verification window 59b and assert the submit button 59c to send a verification message to the token server 17 for processing by the new member registration process 49 to complete the registration of the new member. The verification window 59 also includes a hypertext message 59c at the bottom of the page for the user to assert in the event that the text message does not arrive. On asserting the hypertext message 59c, the login and join process 51 displays a message page 61 which provides an explanatory message 61a and a "create account again" button 61 b. Activating the "create account again button 24 61 b causes the login and join process 51 to return to displaying the user account input page 55 and send a cancellation message to the token server 17, which then invokes the new member registration process 49 to cancel the registration of the prospective member. Now describing the new member registration process 49 in more detail, reference is made to the sequence diagram at Fig. 7 of the drawings. As shown, when the login and join process 51 sends the new member registration message and list to the token server 17 via the smart phone 13 of the new member, the new member registration process 49 is activated and checks the database 31 to see if the new member registering has a prospective account created as a consequence of other members 4" gifting tokens to the prospective member as previously described. If the new members account already exists, then the account is supplemented with the outstanding customer information supplied in the list. On the other hand, if the member does not have an account, then a new account record is created for the new member using the customer information supplied in the list. In either case, once the customer account is complete with all of the customer information, the new member registration process 49 activates the token server 17 to send message to the smart phone 13 of the new member providing a verification code. Simultaneously, the new member registration process activates the token server 17 and sends an SMS text message via the mobile network to the smart phone 13' of the new member. A text message handler 63 of the smart phone 13' is invoked to process the received SMS text message and update the text message display of the smart phone, simultaneously sending an alert signifying that a new SMS text has been received. The alert is intended to prompt the new member to view the SMS text message, which as previously described includes a hyperlink displaying the verification code. On either the verification code being submitted via the verification page 59 as previously described or activating the hyperlink of the 25 SMS text, the token server 17 will then invoke the new member registration process 49 to update the database signifying that the new member registration is completed and causes the token server 17 to send an acknowledgement message to the smart phone 13 for subsequent processing by the login and join process 51. Alternatively, if the "create account again" button 61 b is asserted, the login and join process 51 causes the smart phone 13 to send a cancel message to the token server 17 which then invokes the new member registration process 49 to cancel the registration process and return the database 31 back to its former state insofar as the prospective member's account was concerned, prior to invoking the new member registration process. With respect to an existing member 4" logging in to invoke the token system 1, as shown in Fig. 6 of the drawings, the login button 53a on being asserted by the member, activates the login and join process 51 to display a login page 65. The login page 65 provides an identification entry window 65a, a password window 65b, a login button 65c and a "forgot your password" hypertext 65d. In the present embodiment, the identifier window 65a requires the email address of the member to be entered and the password word 65b requires the password originally entered during the create account process from the registration display page 55 before the login process proceeds any further. On the login button 65c being asserted, the login and join process 51 checks the relevant entries and sends a message to the token server 17 to invoke the redemption system 3. The redemption system 3, as shown in Fig 1, comprises a server redemption process 71 on the token server 17 operating in conjunction with a client redemption process 73 on the smartphone 13. These processes operate to access the account of the member and display a main page 67 listing the current tokens of the member available for redemption as shown in Fig 10.

26 In practice, this main page 67 is accessed by the login and join process 51 after the member asserts the login button 65c and a login message is sent to the token server 17 for invoking the server redemption process 71 to process the identity of the member and retrieve relevant token information stored on the account of the member on the database 31. The server redemption process 71 formats the token information for display and sends a message back to the smartphone 13 of the member for subsequent processing and display by the client redemption process 73 as the main page 67. As the client redemption process 73 is invoked at this stage, further actioning by the member is undertaken under the operation of the client redemption process 73, which will be described in more detail later. The token purchasing system 7, as shown in Fig1, comprises a server buy tokens process 75 on the token server 17 operating in conjunction with a client buy tokens process 77 on the smartphone 13. The client buy tokens process 77 is invoked by a member 4" of the token reward scheme 11 selecting the add tokens option 79 along the bottom bar 13a of their smart phone 13, after activating the customer application module 15', as shown in Fig. 8 of the drawings. On the member 4" selecting the add tokens option 79, the client buy tokens process 77 is invoked and displays an add tokens page 81 on the smartphone 13. The add tokens page 81 displays a number of options available to the member providing different avenues through which tokens may be acquired. As shown in the drawings, the first and main option is a 'buy gift tokens' selection 83a. Other options include an 'enter a token code' selection 83b, a 'find free tokens' selection 83c, 'a scan a token QR code' selection 83d and a 'scan a product barcode' selection 83e. In summary, these options perform the following functions: 27 * the 'buy gift tokens' selection 83a provides the opportunity for the member to buy gift tokens with a credit card using 256-bit SSL security; " the 'enter a token code' selection 83b provides the opportunity for the member to convert a voucher providing gift tokens by a vendor or merchant to tokens in the members account; " the 'find free tokens' selection 83c provides the opportunity for the member to acquire any free tokens that may be made available by the token scheme provider 6 and convert these to tokens within the members account; * the 'scan a token QR code' selection 83d provides the opportunity to scan a token QR code that may be provided by a vendor or merchant using the camera of the members smartphone and covert this is a gift token to the members account; " the 'scan a product barcode' 83e provides a similar opportunity to convert a promotion involving a token by a vendor or merchant to a token on the account of the member in a similar manner as with the 'scan a token QR code' selection at 83d. Describing firstly the 'buy a gift tokens' selection 83a, upon a member selecting such, the client buy tokens process 77 steps to displaying a Categories page 85 to the member, which provides a summary of the token types and their categories for the user to purchase. As shown in the drawings, these categories include: * Most Popular and Best Value at pane portion 85a; * the number of tokens per Category or type at pane portion 85b; and " the tokens by Price Range at pane portion 85c. Selecting any of the categories follows a typical program flow. Program flow for selecting the Most Popular category will be described in detail as an example, however, it should be appreciated that the program flow will be basically the same for other selections from the Categories page 85 modified according to the particular classification of the category.

28 As shown in the drawings, upon the member selecting the Most Popular category from the pane portion 85a, the client buy tokens process 77 displays the Most Popular page 87 listing the different tokens that have been determined by the token system 1 to be the most popular purchased by members of the token reward scheme 11. Each of the tokens is displayed with a brief description and the price of the particular token. In the present example, the Coffee token 87a is subsequently selected by the member which is displayed having a price of $3.80 for purchase. Upon selection, the client buy tokens process 77 steps to displaying a Details page 89 of the Coffee token which together with details of the token, includes a 'Buy Now' button 89a and a selectable hypertext 89b for indicating where the token is accepted. It should be appreciated that with each selection from a page by a member, the client buy tokens process 77 sends a message to be processed by the server buy tokens process 75 by way of the smartphone 13 and the token server 17. The server buy tokens process 75 then accesses a database management system associated with the database 31 to retrieve relevant information sought by the client buy tokens process 77 that is available from the database 31 and return the requested information in a message to the smartphone 15 for subsequent receipt and processing by the client buy tokens process 75. Appropriate routines are run as part of the database management system to provide relevant information concerning, for example, the token categories and types on the Categories page 85, the most popular tokens on the Most Popular page 87 and details as to where the location of the merchant is to redeem the token via the Details page 89. As shown, if a member selects the hypertext 89b, then the client buy tokens process 77 causes the smartphone 13 to send a message to the token server 17 which invokes the server buy tokens process 75 to access the database management system of the database 31 and return a message listing the locations where the Coffee token can be purchased within a prescribed radius of the location of the smartphone 13 of the member. This message is received by the smartphone 13 and processed by the client buy tokens process 77 in a List 29 and Map page 91. The List and Map page 91 displays the available Coffee tokens in a list by default which is user selectable via a list button 91 a. A map button 91 b is also displayed for selection and display of a map showing the location of the merchant offering to redeem the selected token. This is achieved by the token system 1 being designed to interface with a maps directory provided by a designated service provider over the Internet 19. Once the particular token is selected from the list, the member is able to return to the Details page 89 by asserting a Back button 91c on the List and Map page 91 to access the Buy Now button 89a. The member purchases the selected token by asserting the Buy Now button 89a, whereupon the client buy tokens process 77 steps to display a Buy Token page 93. The Buy Token page 93 provides a Quantity window 93a for the member to increment or decrement the number of tokens to be purchased, a running Price and Service Fee window 93b for showing the calculation involved and the total of the price of the tokens being purchased, and a Next button 93c. Once the member has decided upon the particular quantity and the total price to be purchased, the member is required to assert the Next button 93c which then invokes the client buy tokens process 77 to check the account of the member 4" stored on the database 31 via the server buy tokens process 75 and return relevant account information via the server buy tokens process 75 to the smartphone 13 of the member for processing by the client buy tokens process 77 to determine how the transaction should next proceed. In the present embodiment, this involves initially ascertaining the available credits accrued to the member from expired tokens that is stored in a credit account of the member, and which can be used in the transaction. The credit account will be described in more detail later. Depending upon the state of the member's account, the decision step will result in displaying one of three Buy Token pages 95, 96 and 97. The decision is based upon a comparison of the value of the available credits ascertained from 30 the member's account and the total price of the purchase displayed in the window 93b, as follows: " If there is available credit, and the credit is less than the total price of the purchase, then the client buy tokens process 77 causes the Buy Token page 95 to be displayed. " If the available credit is greater than the total price of the purchase then the Buy Token page 96 is displayed. " If there is no available credit, then the Buy Token Purchase page 97 is displayed. In the Buy Token pages 95 and 96: the available credit is displayed respectively in panes 95a and 96a, showing the available credit from expired gift tokens previously gifted by the member together; and the total amount of the transaction, less the available credit and the remaining balance to be paid is displayed in a calculation pane 95b and 96b respectively. In the case of the Buy Token page 95, a Next button 95c is displayed for progressing the transaction to the Buy Token Purchase page 97. In the present example, the Buy Token Purchase page 97 is titled Buy Coffee Token and provides relevant windows to effect the purchase of the selected coffee token using one of various types of credit cards acceptable for processing by the token system 1. The information sought on this page is standard for online credit card purchases and includes a Pay Now button 97b which when asserted by the member causes the client buy tokens process 77 to process the purchase and step to displaying a Thank You page 99. As is typical of online credit card transaction formats, the client buy tokens process 77 includes a tumbler date entry process to be activated from a tumbler display window 98 that is invoked on the member entering the expiry date for the credit card to be used.

31 In the case of the Buy Tokens page 96 being displayed, a 'pay now using credit balance' button 96c is displayed instead of a Next button. As is apparent from the drawings, the Buy Tokens page 96 is displayed when the available credits ascertained from the member's account exceed the total price of the transaction, there is no requirement for a purchase to be made other than debiting the member's available credit account stored in the database 31 and crediting the total price of the purchase so that it is zero. The member asserting the 'pay now using credit balance' button 96c causes the client buy tokens process 77 to send a message via the smartcard 13 and the token server 17 to the server buy tokens process 75, which completes the transaction by altering the member's account in the manner required and return a message to the smartcard showing that this has been done. On receipt of this message, the client buy tokens process 77 steps to displaying the Thank You page 99 as previously described. The Thank You page 99 includes a 'view my wallet' button 99a for the member to assert and return to the main page 67. Once the member or customer has an account with tokens credited to it, the member can redeem these tokens by way of the redemption system 3. As the redemption system 3 involves direct interaction with a merchant 8, the merchant application 16 will now be described. In the present embodiment, the merchant application 16 is downloaded onto a merchant client in the form of a smartphone 18' as shown in Fig. 9 of the drawings. The downloaded merchant application 16' on invoking by the merchant 8, presents a display window to the user having a bottom bar 103 with various options for the merchant to select, each of which involve invoking processes that interact with a server merchant servicing application 104 on the token server. These options include a transaction option 103a, a security option 103b and a historical reporting option (not shown) accessible by asserting a More button 103c.

32 Selecting the transaction option 103a invokes a client transaction process 105 for displaying a current statement of token redemptions transacted by the merchant. The client transaction process 105 comprises a routine that accesses the account of the merchant held in the database 31 via a server transaction process 107, which operates on the token server 17 as part of the server merchant servicing application 104. The server transaction process 107 retrieves relevant information stored on the database 31 for the merchant and sends it to the merchant application for the client transaction process 105 to display on the smartphone 18' as the current statement of transactions undertaken by the merchant for which payment is provided on a periodical basis by the token scheme provider 6. In the present embodiment, the token scheme provider 6 opts into agreements with all of the merchants 8 to pay them the equivalent value of all redeemed tokens transacted with them as logged by the accounting system and recorded in the current statement of each merchant on, for example, a monthly basis. Selecting the security option 103b invokes operation of a client security process 109 that permits the merchant 8 to set or update a security code 111 stored in the database 31 for verifying redemption of a token by a customer by way of a server security process 113, which forms another part of the server merchant servicing application 104. The client security process 109 causes a security page 101 to be displayed in the display window of the smartphone 18'. The security page 101 includes a merchant pane 101a showing the name and address of the merchant, a security pane 101 b showing the current security code 111 of the merchant and a sequence pane 101 c showing the sequence number for the next redemption. The client security process 109 comprises a routine that permits the merchant 8 to access his account in the database 31 via the server security process 113 on the token server 17 and set or reset their security code 111 in order to verify transactions provided by the merchant to customers using tokens 33 to purchase products or services from the merchant in real time. The security code 111 may be of any prescribed number of characters and is recorded in the database 31 against the merchant's identification number for accessing by the customer application 15' during a token redeeming transaction, which will be described in more detail later. Selecting the historical reporting option invokes a client historical reporting process 115, which comprises a routine that causes the smartphone 18' to communicate with the token server 17 and invoke a server reporting process 117, also forming part of the server merchant servicing application 104 to access a log of past statements and transactions that have been performed and for which the merchant has been paid by the token scheme provider 6, and send these to the smartphone 18' to be viewed by the user. To facilitate operation of the merchant application 16', the token scheme provider 6 hosts a website having a specific page for the merchant to access the server merchant servicing application 104. On registration of a merchant with the token scheme provider 6, which involves the merchant completing a registration form including the merchant's physical address, the merchant 8 is provided with a login and password on which they can access the website. The merchant's address details are converted into geographical coordinates by a map locater process 119 provided on the token server 17, which generates a marker on a locator map signifying the location of the merchant 8. This map is accessible by customers to help identify the geographical locations of merchants 8 that are members of the token reward scheme 11 to facilitate subsequent token redemption by customers. Now describing the redemption system 3 from the customer application 15' perspective, in addition to the client redemption process 73, the customer application is designed to provide three other options that are synthesised by a client transaction history process 121, a merchant map identifying process 123 and a client information process 125. Routines for each of these processes 34 involve displaying pages for the customer to interact with the token server 17 and invoke a corresponding server transaction history process 127, the map locator process 119 and a server information process 129. As shown in Fig. 10, each of these processes are individually selectable via buttons appearing on the bottom bar 13a of the smartphone. In the present embodiment, the client redemption process 73 is invoked by asserting the "My Tokens" button 131 on the main page 67, and the three other options are accessible by buttons appearing as part of a secondary display of the bottom bar 13a, after selecting the "More" button 133. The client redemption process 73 comprises a routine that presents successive pages on the smartphone display and via interactive logic causes the smartphone 13 to communicate with and send messages to the token server 17 over the Internet 19. The server redemption process 71 is programmed to perform various functions in response to these messages, which will be described in turn. Initially, the token server 17 receives customer data including the customer identification number. The token server 17 receives these messages and on decoding same, engages the server redemption process 71 to access the database 31 and receive relevant status information concerning the tokens stored and available in the account of the customer. This information is then returned to the smartphone by a message sent by the server redemption process 71 for receipt and processing by the client redemption process 73 and displayed, as previously described, as the main page 67. This page constitutes the main "My Tokens" page 47A for redeeming tokens as well as the default main page of the token system. The client redemption process 73 is programmed to then receive a prompt to select a token for redemption. The selected token is identified by the client redemption process 73 as a selected token object and is then sent by the client 35 redemption process for receipt by the token server 17, invoking a second level page at 47B. The server redemption process 71 then interacts with the client redemption process to step through successive stages of a workflow in a sequential manner, depending upon the selections of the customer, displaying in sequence: * the second level page at 47B providing more detail on the selected token from the first page 47A and including options invoking third level pages for: o listing a page 47C displaying store locations where the token may be redeemed by selecting the token from page 47B; o listing stores at page 47D providing different token offerings by selecting the "Find Stores" bar; o deleting the token at page 47E by selecting the bin button, and then selecting the "Delete Token" bar presented on page 47E; * a fourth level page at 47F on selecting one of the more detailed tokens from either pages 47C or 47D, which displays amongst other store detail, the number of tokens required to purchase the offering at window 49 and a "Redeem" button required to be asserted to initiate the redemption process (alternative fourth level pages where multiple tokens are required for redemption are shown at pages 47F' and 47F"); * a fifth level page at 47G setting out the conditions for redemption and providing for a "Redeem Now" button 48 to commence a count down for a time period within which the transaction is required to be completed; * a sixth level confirmation page 47H of the transaction, which is substantially similar to the third level page displayed during the token redemption process by displaying the token offer 50a, store name and location 50b, merchant security code 50c, transaction time stamp 50d and transaction sequence number 50e of the 36 merchant, a dynamic count down time message 50f and an OK confirmation button 50g; and a seventh level page 471 acknowledging the transaction and providing a return OK button to allow the routine to return to the main "My Tokens" page at 47A. At the fourth level page 47F, assertion of the Redeem button involves the server redemption process accessing the database and verifying whether there is a sufficient balance of accumulated tokens of the prescribed type corresponding to the selected token object that are stored in the account of the customer and prompting the customer to confirm the transaction by communicating with the client redemption process 73 to step to the display of the fifth level page 47G. At the fifth level page 47G, on the customer asserting the Redeem Now button 48, the client redemption process 73 communicates with the token server 17 to invoke the server redemption process 71 to deduct the token amount of the prescribed type from the balance of accumulated tokens stored in the current account of the customer and transmit a confirmation to the smartphone if the transaction is valid. This confirmation causes the smartphone to invoke the client redemption process 73 and step to displaying the sixth level page 47H with the relevant validation information for the merchant. Setting a time period for the transaction to be completed and displaying a dynamic count down time message 50f of the time period at the sixth level page 47H, provides for a higher degree of security for performing the transaction. For example, it indicates to the merchant that the pane 47H being displayed for the sixth level page on the smartphone of a customer is not simply a reproduction of an image of an earlier transaction. The client redemption process 73 is programmed to invoke a timing means in the form of a count down timer when the Redeem Now button 48 is asserted. As shown in the display of the sixth level page 47H of the token redemption process in Fig. 10, the timing means displays the dynamic time message 50f of 37 the count down over a predetermined time period. Thus, the count down timer provides the window within which the OK confirmation button 50g must be pressed in order for the transaction to be processed by the client redemption process 73 and the token server 17. If the button 50g is not pressed within this time period, then the transaction is aborted. The client transaction history process 121 of the customer application 15' when invoked by pressing a history button from the bottom bar 13a on the secondary display as previously described, simply involves a routine programmed to access the token server 17 and obtain relevant log data from the database 31 and return a prescribed number of previous transactions from the log history stored in the accounting system of the database for the customer for the display on their smartphone 13. The merchant map identifying process 123 on similarly being selected from the bottom bar 13a of the secondary display involves a routine accessing the map locator process 119 on the token server 17 and displaying a portion of the locator map showing the locations of merchants 18 in a prescribed geographical area. The address of each merchant is shown by a flag or other identifier in known manner. Lastly, the client information process 125 on invoking from the bottom bar 13a during the secondary display, provides a series of pages that can be stepped through describing how the token redeeming process works, providing relevant illustrations to assist the customer, which can be scrolled through after selecting the information page option. The present embodiment provides a convenient way of accessing three powerful systems for using tokens, namely the redemption system 3, the gifting system 5 and the token purchasing system 7. In particular, the embodiment provides for a superior way of providing a gift to another person when compared to known gifting systems such as prepaid 38 vouchers or gift certificates. By using the token system of the present embodiment, the financial transaction involving a token that is a taxable supply occurs at the time that tokens are purchased from the token scheme provider and at the time that the token is actually redeemed. So the goods and services tax (GST) on the supply of the purchased tokens is paid by the token scheme provider following a customer purchasing the tokens and is paid by a merchant on the supply of a product or service following a customer redeeming a prescribed value of tokens with the merchant. The merchant then is credited for the full amount of the transaction by the token scheme provider, and the token scheme provider claims a tax credit for the payment to the merchant. In this case, the current account of the customer is simply credited with the value of the tokens purchased and is debited for the value of tokens redeemed at the time of redemption. In the case of a customer gifting tokens to a third party, the current account of the customer is debited for the value of tokens gifted and a trust account for the customer is credited this same amount. The value of the tokens credited to the trust account of the member is locked from access of the member. At the same time, the current account of the third party is credited with the value of the gifted tokens until they are redeemed. As in the previous case, the current account of the third party will be debited for the value of any redeemed gifted tokens at the time that these gifted tokens are redeemed with a merchant. Concurrently, the trust account of the original customer who gifted the tokens will be debited the same value of the gifted tokens that are redeemed. As previously described, each token has designated to it an expiry date at the time that it is acquired by a customer. This date provides an important function in the accounting of tokens. If a token in the current account of a customer expires before it is redeemed, then the value of that token is debited from the current account of the customer and the token scheme provider benefits by this amount as a consequence of that token never being transacted. On the other hand, if a token that has been gifted by a customer to a third party expires 39 before it is redeemed, then the value of that token becomes unlocked from the trust account of the customer who gifted the token originally, and is debited from the customers trust account and the value credited to the credit account of the customer. The balance of the credit account equates to the available credit that is displayed at 95a referred to previously, and is available for deducting from future purchases of tokens using the token purchasing system 7 as previously described. Thus the customer is able to benefit from gifting tokens that are never used by the third party where the value of the gifted token is not treated as a taxable supply until it is redeemed, and thus its value as an available credit can be used to offset a further purchase transaction by the customer without the value being treated as a taxable supply. The second embodiment of the best mode for carrying out the invention is substantially the same as the first embodiment, except that the redemption system 3 involves use of the smartphone's camera and a QR code maintained by a merchant as part of the redemption process. Each pane also includes an activation area, which upon being activated, causes the client redemption process 73 to retrieve further details in order to redeem the particular type of token corresponding to the selected pane. In the second embodiment, the redemption process involves a customer requesting a product or service from a particular merchant that can be exchanged for redemption of a token, for example a bronze generic token. The routine of the client redemption process 73' is modified so that after asserting the Redeem button shown on the fourth level page 47F, the camera of the smartphone 13 is activated at the merchant's store to perform the transaction in real time with the particular merchant.

40 Upon the customer requesting redemption of a bronze token, for example, the merchant provides a representation of the particular type of QR code, in this case the merchant's bronze QR code, to the customer for the customer to scan and snap using the smartphone camera. The snapshot image of the QR code is displayed on the smartphone, the client redemption process 73 invokes a QR code deciphering routine to decode the snapshot of the QR code and extract the token type and merchant identification number from the code In the present example, upon successfully ascertaining that the QR code is for a bronze token and the merchant identification number, the client redemption process 73 then causes the smartphone 13 to send this information to the token server 17. On receipt of this information, the token server 17 invokes the server redemption process 73 to access the database 31 using the merchant identification number and extract the security code of the merchant stored in the database as previously set or reset by the merchant. This security code is then transmitted by the token server 17 to the smartphone 13 in a message, whereupon receipt of the message by the smartphone, the client redemption process 73 is caused to step the customer application to its next state. Simultaneously the server redemption process 73 deducts a token from the bronze account balance of the customer stored on the accounting system of the customer in the database 31. At this same time, the server redemption process 73 completes logging of the transaction in the accounting system to update the current statement of the merchant and send a transaction report to the customer. The routine of the client redemption process 73 then steps to display the confirmation page 47H identifying the merchant's security code and sequence number, together with the relevant name details of the merchant, the date and time of the transaction and the period within which the transaction needs to be completed. Once all parties are satisfied that the transaction is legitimate the 41 'OK' button can be asserted by either the merchant or customer to verify that the transaction has been or is being effected. As before, the security code provides the merchant with a visual indication that the transaction is legitimate, as this code would correspond to that originally set by the merchant during its configuration stage. In addition to the timing means, in order to improve security further, an animation means is included to display a dynamic animation during the count down alongside the dynamic time message. On the transaction being validated and verified, the merchant releases the product or provides the service to the customer as in the preceding embodiment. In the event that the client redemption process is not able to decode the QR code and extract the token type and/or identification number, or the server redemption process indicates that there are insufficient tokens of the required type to redeem, the client redemption process asserts that the transaction is invalid and causes the smartphone to display a transaction invalid message. The token redeeming process is then terminated at this point without any access being made to the accounting system. In summary, the transaction process performed by the customer application for a customer redeeming a token, on initiating by the customer, includes the steps of: * invoking operation of the camera on the smart phone for scanning the representation of the QR code token of the merchant corresponding to the type of transaction to be performed; * transmitting customer data and the image to the token server; * on processing by the token server, receiving and displaying the security code of the merchant for verification to the merchant that the transaction is valid; 42 * providing for receipt of a confirmatory input by either the merchant or the customer to further verify the authenticity of the transaction; * or if not valid, receiving and displaying a message signifying the invalidity of the transaction. Additionally, the customer transaction process performed by the token server receives and processes these transmissions from the smartphone of the customer in response to the transaction process by: * receiving customer and merchant identification data as well as the token type; * accessing the database to verify: i) a customer from the customer identification number and the merchant from the merchant identification number data; ii) the sufficient balance of accumulated tokens of the prescribed type indicated by the image that is stored in the account of the customer; and iii) the security code of the merchant; * deducting the token amount of the prescribed type of the accumulated token stored in the account of the customer; * transmitting the security code of the merchant to the smartphone if the verification of the transaction is valid; or * transmitting a message signifying an invalid transaction to the smartphone if the verification of the transaction is invalid. In a third embodiment of the invention, a token system is provided that is substantially similar to the first embodiment except that the redemption system involves a different way of effecting and confirming the transaction. Moreover the redemption system 3 dispenses with the need for relying upon the merchant's security code as the operative part of effecting the transaction. Instead each merchant has a printer device connected to their merchant computer 18 or point-of-sale device and includes as part of the 43 merchant application 16', an order notification process. The order notification process is prompted by the merchant computer 18 in response to a message received from the server redemption process 71 on a customer asserting the Redeem Now button 48 during the stage of the smartphone displaying the fifth level page 47G. The order notification process and the server redemption process are configured in response to a verified valid transaction by the customer to print out a receipt 151 on the printer device of the merchant 8 as shown in Fig 11 of the drawings, The order notification process causes the printer device to print a transaction code 153 for the transaction, the date and time of the order 155, the location of the merchant's premises 157, the nature of the transaction 159, the pick up time 161, the value of the transaction 163, the cost of the transaction 165 and the amount of cash that will be tended 167, the name of the person redeeming the tokens or gift 169, the mobile number of the person 171, the description of the item and the number of items being ordered 173. At the same time the server redemption process will transmit a confirmation of the order to the smartphone of the customer and invoke the client redemption process to display a sixth level page 47H showing the same information to the customer as in the first embodiment, except omitting the shop security code 50f, which is no longer required. Thus a merchant or staff member will receive the receipt as part of their normal incoming business orders and will process the order in the usual way having regard to the identified pick up time. Usually they will simply rely upon the customer providing their name, and if necessary can request a copy of the confirmation page 47H to be shown in order to verify the order, but generally, this will not be required. As the merchant has already had their account credited for the transaction, there is no requirement for the merchant to wait for payment if and when the customer arrives. So from the merchant's point of view, the transaction has been 44 made and accounted for, leaving the onus upon the customer to attend and pick up their order. In a fourth embodiment of the invention, as shown in Figs. 12 and 13 of the drawings, a different type of gifting system 201 is run using a gifting server 203 operated by a gifting host separately of the token system. The gifting system 201, includes: * a discrete downloadable customer application 203, separate of the customer application for the token system of the first embodiment, which is also run on portable customer clients in the present embodiment being smartphones of user customers; " a merchant application 207 run on a merchant device that includes a printer device, similar to that described in the third embodiment; * a gift buyer process 209 run as part of a gift buyer application on a smartphone that may or may not be the same as the customer application 203 of the customer; and " a digital currency issuer 211 who trades in digital currencies. Each of the applications are on clients that communicate via the Internet 19 with the gifting server 203. The gifting system 201 uses a different formulation of gift rewards than simply the tokens described in the first embodiment. These gift rewards comprise three types: " gift dollars that are formulated in a digital currency and issued by the digital currency issuer 211; " gift points, which are of the type provided by different rewards schemes described in the first embodiment; and " gift tokens, which are of the same type as described in the first embodiment.

45 A gift buyer may buy gift dollars from the digital currency issuer 211 using the gift buyer process 209 in a similar manner as the buy token tokens process 77 would buy tokens as described in the first embodiment, except in this case they are gift dollars. Gift points and gift tokens are bought in a similar manner. In this manner a customer may accumulate gift dollars, as well as gift points and gift tokens, all of which are stored on the customers account by the gift server 203. Once a gift buyer has accumulated any or all of these gift rewards in their account, they can then become a gift giver and gift any or all of these gift rewards in a similar manner to the gifting system 5 of the first embodiment, where the customer 205 is the ultimate recipient of the gift reward. In the drawing, the flow shows giving currency to a user customer. The gifting system 201 also includes a redemption system 3 along similar lines to that described in the third embodiment. As shown in the drawings, when a user customer wishes to redeem their credit rewards, they place an order via the gift server 203, which ultimately communicates with the merchant application 207 of a selected merchant to accept and process the order. Fig 13 shows the redemption process from the client application perspective in more detail. As shown, the client redemption process is invoked by a user customer selecting the "Gift Credit" option 221 along the bottom bar 223 of their smartphone. The client redemption process will then communicate with the gift server 203 and via the server redemption application, access the user customer's account and download current account data to open a gift credit page 225 which will then display showing all of the accumulated credit rewards of the user customer. In the example, accumulated credit dollars are shown at 227, accumulated credit points are shown at 229 and accumulated credit tokens are shown at 231.

46 An option to buy gift credits is also provided, where a "Buy gift credit" button 233 can be asserted to invoke the gift buyer process 209 and buy credits from the digital currency issuer 211, as previously described. On the user customer selecting the gift dollars bar at 227 for the purposes of redeeming gift dollars, the client redemption process opens a page 235 providing information concerning the gift dollars and various redemption options. In the present embodiment, only one option to redeem at a store near to me is provided at button 237, which on asserting invokes the client redemption process to open a next page 239 providing various redemption categories at 241. In the present example, the user customer on asserting the first category being "Local Stores Near Me", invokes the client redemption process to open a page 243 showing those stores nearby where the gift dollars can be redeemed, the location, the distance away and the minimum spend required. On selecting one of the stores at 245, the client redemption process is invoked to display a redeem page 247 with specific details of the store and the amount of gift available to redeem. In addition two options to continue are displayed, namely a preorder and pick up when you arrive option at 249 and a pay any amount option at 251. On selecting one of these options, the redemption process continues in the same manner as described in the third embodiment, invoking an order notification process and having a receipt printed on the printer device of the selected merchant. It should be appreciated that the scope of the present invention is not limited to the specific embodiments described and that various other embodiments may be devised to implement the invention without departing from its scope or spirit.

Claims (9)

1. A token system for a customer to redeem tokens representative of a product or service from a merchant in real time, the tokens being accumulated by the customer in a reward scheme of a scheme provider including: a token server to coordinate and control operation of the token system and having a database to store accounting and identification information in relation to each customer and merchant that are members of the token system; the tokens being of different object types and having different values, and which are able to be accumulated within an account of the customer on the token server; application modules, including: (i) a merchant application to communicate with the token server and provide for administration of a merchant's involvement in the token system, and (ii) a customer application to invoke an instance of operation of the token system with a particular customer so that the customer can be provided with token object detail and merchant identification and location data, and a specific instance of operation of the token system with the token server and a selected merchant to perform a transaction with the merchant and the token server; a portable customer client having an operative customer application and interactive processing logic to communicate with the token server over a network; a merchant client having an operative merchant application and interactive processing logic to independently communicate with the token server over a network; 48 said token server including a server merchant servicing application for receiving communications from the merchant client and having processes to permit the merchant to register its merchant identification and location data, and specify object detail that it has agreed to provide to a customer invoking a said specific instance to perform a transaction with the merchant; wherein to invoke said instance: the customer application has a client redemption process for displaying all of the tokens of different object types that may be redeemed and the relative merchants or locations where the tokens may be redeemed from, the client redemption process on invoking by the customer: (a) transmits customer data to the token server; (b) displays all of the different tokens that may be redeemed by the customer and activates the displayed icons for receiving a selection input from the customer; (c) on the customer asserting a selection input, displays further details regarding the selected token object and selectively the merchant and location of the merchant where the particularly selected token object may be redeemed together with an assertable button for invoking said specific instance; and the token server has a server redemption process to receive and process messages from the portable customer client over the network, the token redemption process in response to activating by the client redemption process of the portable customer client having functions to: (A) receive customer data and the selected token object from the client redemption process at (a) and (c); (B) access the database to verify: i. the customer from the customer data; 49 ii. the sufficient balance of accumulated tokens of the prescribed type corresponding to the selected token object that are stored in the account of the customer; (C) deduct the token amount of the prescribed type from the balance of accumulated tokens stored in a current account of the customer; (D) transmit a confirmation to the portable customer client, if the verification of the transaction at (B) is valid; or (E) transmit a message signifying an invalid transaction to the portable customer client, if the verification of the transaction at (B) is invalid.

2. A token system as claimed in claim 1, wherein the merchant application has a coding process for the merchant to access its account on the redemption server and set or reset a security code to verify token transactions provided by it to customers in real time; and wherein to invoke said specific instance, the client redemption process is invoked for redeeming one or more token objects of a prescribed type in exchange for a product or service provided by a merchant, the transaction process on initiating by the customer: (I) on processing by the token server, receives and displays from the token server the security code of the merchant for verification to the merchant that the transaction is valid; (II) provides for receipt of a confirmatory input by either the merchant or the customer to further verify the authenticity of the transaction; (III)or if not valid, receives and displays a message signifying the invalidity of the transaction; and wherein the server redemption process in response to activating the client redemption process of the portable customer client also includes functions to: 50 (A) access the database to obtain the security code of the merchant offering to redeem the selected token object; (B) transmit the security code as part of the confirmation.

3. A gifting system for a member of a reward scheme to provide tokens to a customer or a prospective customer of the reward scheme for subsequent redemption with a merchant as part of the reward scheme, including: a token server to coordinate and control operation of the gifting system and having a database to store accounting and identification information in relation to each member and customer of the gifting system; the tokens being of a type prescribing a specific monetary value for each token of that type, said tokens being capable of accumulation within accounts of members and customers on the token server; application modules, including: (i) a member application to communicate with the token server and provide for administration of the member's involvement in the token transaction to be performed with the customer, the token transaction involving the transfer of a prescribed number of tokens from a token account of the member to a token account of the customer; and (ii) a customer application to invoke an instance of operation of the gifting system with the member and communicate with the token server to provide member data and customer data in respect of the token transaction between the member and the customer; a portable customer client having an operative customer application and interactive processing logic to communicate with the token server over a network; 51 a member client having an operative member application and interactive processing logic to independently communicate with the token server over a network; wherein to invoke said instance: the member application has: (a) a client buy tokens process for the member to access its account on the token server and acquire tokens for use in the token transaction to ensure its account is in credit; and (b) a client give tokens process for the member to gift tokens to the customer; wherein the client give tokens process on invoking by the member: (I) transmits member and customer data to the token server; (II) displays all of the different tokens that may be gifted to the customer and activates the displayed tokens for receiving a selection input from the member; (III) on the customer asserting a selection input sends a message to the token server to transfer the selected tokens from the members account to the customer's account; and wherein the token server has a server gifting process to receive and process messages from the portable customer client over the network, that in response to invoking said token gifting process of the customer application: (A) receives member data and customer data from the customer client transmitted as a consequence of action (I); (B) accesses the database to verify: i. the member from the member data and the customer from the customer data; 52 ii. the sufficient balance of accumulated tokens of the token transaction type stored in a current account of the member; (C) debits the token amount of the token transaction type from the token amount of accumulated tokens stored in the current account of the member and credits a trust account of the member where the gifted tokens are locked from access of the member; (D) credits the token amount to the customer account; and (E) verifies to the member client and the customer client that the token transaction has been performed.

4. A token system as claimed in claim 1, wherein the portable customer client includes a camera; and graphic codes are ascribed uniquely to each merchant using the token system, whereby each graphic code corresponds to a unique merchant identification and a transaction involving a particular token type, each merchant having a representation of its graphic code for a particular token type readable by said camera of any customer client; and wherein the client redemption process on invoking by the customer: (i) invokes operation of the camera on the portable customer client for scanning the representation of the graphic code of the merchant, the graphic code so scanned corresponding to a particular token type of the customer to be exchanged for the provision of the product or service of the merchant requested by the customer; (ii) transmits customer data and merchant data to the redemption server; (iii) on processing by the redemption server, receives and displays from the redemption server the secret code of the merchant for verification to the merchant that the transaction is valid, and invokes a timer to count down a predetermined time period and displays an animation during the predetermined time period; 53 (iv) provides for receipt of a confirmatory input during the predetermined time period to further verify the authenticity of the transaction; (v) or if not valid, receives and displays a message signifying the invalidity of the transaction.

5. A gifting system for a customer to gift rewards, whereby the rewards can be accumulated and redeemed, including: a gift server application to coordinate and control operation of the gifting system and interacting with a database to store accounting and identification information in relation to each customer, merchant, gift buyer and gift receiver who are members of the gifting system; the gift rewards being of different object types and having different values, the gift rewards being able to be accumulated within an account of the customer on the gift server; a merchant application to communicate with the gift server and provide for administration of a merchant's involvement in the gift system and a printer device for printing an order receipt during the invocation of a redemption process; and a customer application to invoke an instance of operation of the gifting system with a particular customer so that the customer can acquire gift rewards, or be provided with gift reward detail and merchant identification and location data, or a selected merchant to redeem a gift reward.

6. A method for a customer redeeming points accumulated by the customer in a reward scheme of a scheme provider in real time with a merchant providing a prescribed reward in accordance with the scheme, the method comprising: 54 prescribing a specific monetary value to each token of a token type for which a prescribed number of points accrued by the customer in the reward scheme may be redeemed by the customer from the scheme provider for a token type and accumulated within an account of that customer; transmitting customer data and selected token data of a token selected for redemption by the customer to a token server for processing; the token server: (i) receiving customer data and selected token data; (ii) accessing a database to verify: i. the customer from the customer data and the merchant from the merchant data; ii. the sufficient balance of accumulated tokens of the prescribed type indicated by the image that are stored in the account of the customer; and obtaining the security code of the merchant offering to redeem the selected token; (iii) deducting the token amount of the prescribed type from the balance of accumulated tokens stored in a current account of the customer; (iv) transmitting the security code of the merchant to the portable customer client, if the verification of the transaction at (ii) is valid; or (v) transmitting a message signifying an invalid transaction to the portable customer client, if the verification of the transaction at (b) is invalid; the portable customer client: (a) receiving and displaying the security code of the merchant for verifying to the merchant that the transaction is valid; 55 (b) providing for receipt of a confirmatory input by either the merchant or the customer to further verify the authenticity of the transaction; or (c) if the transaction is not valid, receiving and displaying the message received at (v) signifying the invalidity of the transaction.

7. A method for enabling a member of a reward scheme to provide tokens to a customer or prospective customer of the reward scheme for subsequent redemption with a merchant as part of the reward scheme, the method comprising: prescribing a specific monetary value to each token of a token type for which a prescribed number of points accrued by the customer in the reward scheme may be redeemed by the customer from the scheme provider for a token type and accumulated within an account of that customer; transmitting member and customer data to a token server for processing; displaying to the member all of the different tokens that may be gifted to the customer and activating the displayed tokens for receiving a selection input from the member; on the customer asserting a selection input sending a message to the token server to transfer the selected tokens from the members account to the customer's account; the token server: (i) receiving member data and customer data from the customer; (ii) accessing the database to verify: 56 i. the member from the member data and the customer from the customer data; ii. the sufficient balance of accumulated tokens of the token transaction type stored in a current account of the member; (iii) debiting the token amount of the token transaction type from the token amount of accumulated tokens stored in the current account of the member and credits a trust account of the member where the gifted tokens are locked from access of the member; (iv) crediting the token amount to the customer account; and (v) verifying to the member client and the customer client that the token transaction has been performed.

8. A token or gifting system substantially as herein described in any one of the embodiments with reference to the accompanying drawings as appropriate.

9. A method for a customer to be gifted, accumulate and/or redeem gift rewards or tokens substantially as herein described in any one of the embodiment with reference to the accompanying drawings as appropriate. GIFTPAY PTY LTD WATERMARK PATENT & TRADE MARK ATTORNEYS UIP1442AU00