Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND SYSTEM FOR DIRECTING ADVERTISING OF PROMOTIONAL OFFERS
Document Type and Number:
WIPO Patent Application WO/2015/131233
Kind Code:
A1
Abstract:
A system and method for directing advertising, comprising a computing system comprising a controller and an input/output interface, the controller having a processor, an operating system and a memory; wherein the memory is configured to store one or more product offers, each of the offers identifying at least one vendor, at least one store, product information pertaining to at least one, and user information pertaining to each of one or more users; the controller configured to identify matches between one or more of the users and one or more of the offers bycomparing the user information pertaining to each of the users with the product information pertaining to the at least one product of each of the offers; the controller then sends via the input/output interface respective notifications of the matching offers to the respective corresponding users found to match the offers.

Inventors:
GANDEL IAN JEFFERY (AU)
GANDEL DARREN SAMUEL (AU)
LISSAUER JOSHUA YEHUDA (AU)
LISSAUER JONATHAN MOISHE (AU)
Application Number:
AU2015/000123
Publication Date:
September 11, 2015
Filing Date:
March 04, 2015
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SHHOP GROUP PTY LTD (AU)
International Classes:
G06Q30/02
Foreign References:
US20130054343A12013-02-28
US20090298483A12009-12-03
AU5800301A2002-02-21
Attorney, Agent or Firm:
GRIFFITH HACK (Melbourne, Victoria 3001, AU)
Download PDF:
Claims:
CLAIMS:

1. A system for directing advertising, comprising:

a computing system comprising a controller and an input/output interface, the controller having a processor, an operating system and a memory;

wherein the memory is configured to store one or more product offers, each of the offers identifying at least one vendor, at least one store, product information pertaining to at least one product, and user information pertaining to each of one or more users;

the controller is configured to identify one or more matching offers by identifying matches between one or more of the users and one or more of the offers by comparing the user information pertaining to each of the users with the product information pertaining to the at least one product of each of the offers; and

the controller is configured to electronically send with the input/output interface respective notifications of the matching offers to the respective corresponding users found to match the offers.

2. A system as claimed in claim 1 , wherein the user information pertaining to at least one of the users comprises an offer radius and the controller is controlled to match the respective user with one or more of the offers only if the store is closer to the user than the offer radius.

3. A system as claimed in claim 2, wherein the offer radius is definable by the respective user.

4. A system as claimed in claim 1 , wherein the memory comprises a specification of at least one geographical area that includes one or more of the stores, and the controller is controllable to receive data from the users indicative of a location of each of the users, to determine whether the users are within the geographical area and to send to the one or more of the users within the geographical area notification of only those of the matched offers that correspond to one or more of the stores within the geographical area.

5. A system as claimed in claim 1 , further comprising a software application executable on a mobile computing device and configured to control communication with the computing system, wherein the controller is configured to electronically send the respective notifications pertaining to a respective user to the mobile computing device of the respective user.

6. A system as claimed in claim 1 , wherein the controller is configured to track redemptions of the offers.

7. A system as claimed in claim 1 , wherein the controller includes an offer creation module controllable to create a new offer and to add the new offer to the memory.

8. A system as claimed in claim 7, wherein the controller includes an offer emulator configured to emulate an appearance of the new offer, the controller being configured subsequently to receive an input indicative of approval of the new offer before adding the new offer to the memory.

9. A system as claimed in claim 1 , wherein the respective offers include data indicative of a period of offer validity.

10. A system as claimed in claim 1 , wherein the respective offers include data indicative of a maximum number of available offer redemptions.

1 1 . A computer-implemented method for directing advertising of promotional offers, comprising:

storing one or more product offers in a memory, each of the offers identifying at least one vendor, at least one store, product information pertaining to at least one product, and user information pertaining to each of one or more users;

electronically identifying one or more matching offers by identifying matches between one or more of the users and one or more of the offers by comparing the user information pertaining to each of the users with the product information pertaining to the at least one product of each of the offers; and

electronically sending respective notifications of the matching offers to the respective corresponding users found to match the offers.

12. A method as claimed in claim 1 1 , wherein the user information pertaining to at least one of the users comprises an offer radius and the method further comprises matching the respective user with one or more of the offers only if the store is closer to the user than the offer radius.

13. A method as claimed in claim 12, including the respective user defining the offer radius.

14. A method as claimed in claim 1 1 , comprising receiving data from the users indicative of a location of each of the users, determining whether the users are within a predefined geographical area that includes one or more of the stores, and sending to the one or more of the users within the geographical area notification of only those of the matched offers that correspond to one or more of the stores within the geographical area.

15. A method as claimed in claim 1 1 , comprising sending the respective notifications pertaining to a respective user to a mobile computing device of the respective user.

16. A method as claimed in claim 1 1 , comprising tracking redemptions of the offers.

17. A method as claimed in claim 1 1 , comprising electronically creating a new offer and adding the new offer to a digital memory.

18. A method as claimed in claim 17, comprising emulating an appearance of the new offer, and subsequently receiving an input indicative of approval of the new offer before adding the new offer to the digital memory.

19. A method as claimed in claim 1 1 , wherein the respective offers include data indicative of a period of offer validity.

20. A method as claimed in claim 1 1 , wherein the respective offers include data indicative of a maximum number of available offer redemptions.

21 . A computer program product comprising instructions that when executed by one or more processors controls a computing device to implement the method of any one of claims 1 to 10.

22. A computer-readable medium comprising the computer program product of claim 21 .

Description:
Method and System for Directing Advertising of Promotional Offers

Related Application

This application is based on and claims the benefit of the filing and priority dates of US application no. 61/948,109 filed 5 March 2014, the content of which as filed is

incorporated herein by reference in its entirety.

Technical Field

The present invention relates to a method and system for directing advertising of promotional offers, of particular but by no means exclusive application in controlling to whom advertising (especially of special offers) is directed.

Background

There are currently a number of techniques for directing advertising to members of the public. One existing technique is broadcast advertising, in which advertising is broadcast - such as via radio or television - to those members of the public that happen to be listening to or viewing that medium. However, this technique is selective only in so far as the programming is known (such as through surveys) to attract an audience of a particular demographic.

Another technique, typically employed online on the worldwide web, selects advertising for display to a user according to either the content of a web page being accessed by the user, or according to search terms employed by the user of a browser. This approach can be further restricted according to the approximate location of the user, as ascertained from the IP address of the user's computing device.

Summary of the Invention

According to first broad aspect of the invention, there is provided a system for directing advertising, comprising:

a computing system comprising a controller and an input/output interface, the controller having a processor, an operating system and a memory;

wherein the memory is configured to store one or more product offers, each of the offers identifying at least one vendor, at least one store (whether physical or online), product information pertaining to at least one product (where a product should be understood to comprise a good or a service), and user information pertaining to each of one or more users;

the controller is configured to identify one or more matching offers by identifying matches between one or more of the users and one or more of the offers by comparing the user information pertaining to each of the users with the product information pertaining to the at least one product of each of the offers; and

the controller is configured to electronically send with the input/output interface respective notifications of the matching offers to the respective corresponding users found to match the offers.

The controller may send the respective notifications of the matching offers to the respective corresponding users by any suitable mechanism, including by push notification (e.g. email or sms), upon the users accessing their respective offer feeds once updated to include the matching offers, or otherwise. In one embodiment, the user information pertaining to at least one of the users comprises an offer radius and the controller is controlled to match the respective user with one or more of the offers only if the store is closer to the user than the offer radius. The offer radius may be definable by the respective user. In another embodiment, the memory comprises a specification of at least one

geographical area (exemplified herein as a 'geo-fenced domain') that includes one or more of the stores, and the controller is controllable to receive data from the users indicative of a location of each of the users, to determine whether the users are within the geographical area and to send to the one or more of the users within the geographical area notification of only those of the matched offers that correspond to one or more of the stores within the geographical area.

The system may further comprise a software application executable on a mobile computing device and configured to control communication with the computing system, wherein the controller is configured to electronically send the respective notifications pertaining to a respective user to the mobile computing device of the respective user.

In an embodiment, the controller is configured to track redemptions of the offers. In a particular embodiment, the controller includes an offer creation module controllable to create a new offer and to add the new offer to the memory. The controller may include an offer emulator configured to emulate an appearance of the new offer (such as as it would be displayed on a mobile computing device of a user), the controller being configured subsequently to receive an input indicative of approval of the new offer before adding the new offer to the memory.

In one embodiment, the respective offers include data indicative of a period of offer validity (such as start and end dates), and/or data indicative of a maximum number of available offer redemptions. ln one embodiment, the system is configured to store brands followed by one or more of the respective users, and to notify the respective users (whether by push notification, sending a suitably updated offer feed or otherwise) when a new offer is released comprising a product of a followed brand.

In another embodiment, the system is configured to import or be granted access to brands followed or liked by a respective user in that user's account on a social networking website (such as facebook (trade mark)).

According to second broad aspect of the invention, there is provided a computer- implemented method for directing advertising of promotional offers, comprising:

storing one or more product offers in a memory, each of the offers identifying at least one vendor, at least one store, product information pertaining to at least one product, and user information pertaining to each of one or more users;

electronically identifying one or more matching offers by identifying matches between one or more of the users and one or more of the offers by comparing the user information pertaining to each of the users with the product information pertaining to the at least one product of each of the offers; and

electronically sending respective notifications of the matching offers to the respective corresponding users found to match the offers.

The user information pertaining to at least one of the users may comprise an offer radius and the method further comprise matching the respective user with one or more of the offers only if the store is closer to the user than the offer radius. The method may include the respective user defining the offer radius.

In one embodiment, the method comprises receiving data from the users indicative of a location of each of the users, determining whether the users are within a predefined geographical area that includes one or more of the stores, and sending to the one or more of the users within the geographical area notification of only those of the matched offers that correspond to one or more of the stores within the geographical area.

In one embodiment, the method comprises sending the respective notifications pertaining to a respective user to a mobile computing device of the respective user.

In one embodiment, the method comprises tracking redemptions of the offers.

In one embodiment, the method comprises electronically creating a new offer and adding the new offer to a digital memory. The method may comprise emulating an appearance of the new offer, and subsequently receiving an input indicative of approval of the new offer before adding the new offer to the digital memory. In one embodiment, the respective offers include data indicative of a period of offer validity and/or data indicative of a maximum number of available offer redemptions.

According to second broad aspect of the invention, there is provided a computer program product comprising instructions that when executed by one or more processors controls a computing device to implement the method described above. According to this aspect there is also provided a computer-readable medium (such as a non-transitory computer- readable medium) comprising this computer program product.

It should be noted that any of the various individual features of each of the above aspects of the invention, and any of the various individual features of the embodiments described herein including in the claims, can be combined as suitable and desired.

Brief Description of the Drawings

In order that the invention can be more clearly ascertained, embodiments will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of a system for directing advertising according to an embodiment of the present invention;

Figure 2A is a schematic diagram of the controller and user interface of the server of the system of figure 1 ;

Figure 2B is a schematic diagram of the controller and user interface of the mobile communications device of the system of figure 1 ;

Figure 3A is a more detailed schematic diagram of the controller and user interface of the server of the system of figure 1 ;

Figure 3B is a more detailed schematic diagram of the controller and user interface of the mobile communications device of the system of figure 1 ;

Figure 4 is a flow diagram of the user registration and offer category selection process of the system of figure 1 , including a social media website (such as facebook (trade mark)) integration process;

Figure 5 is a flow diagram of interaction with the home screen of the app of the mobile telephone of the system of figure 1 ;

Figure 6 is a flow diagram of the determination and display of certain offer-specific information by the app of the mobile telephone of the system of figure 1 ;

Figure 7 is a flow diagram of the offline offer process of the app of the mobile telephone of the system of figure 1 ; Figure 8 is a flow diagram of the address feature of the app of the mobile telephone of the system of figure 1 ;

Figure 9 is a flow diagram of the map feature of the app of the mobile telephone of the system of figure 1 ;

Figure 10 is a flow diagram of the follow feature of the app of the mobile telephone of the system of figure 1 ;

Figure 1 1 is a flow diagram of the share feature of the app of the mobile telephone of the system of figure 1 ;

Figures 12A and 12B are a flow diagram of the redemption of an offer via the app of the mobile telephone of the system of figure 1 ;

Figure 13 is a flow diagram of the interface for analysing user data of the system of figure 1 ;

Figure 14 is a flow diagram of the operation of a wallet for saving offers of the app of the mobile telephone of the system of figure 1 ;

Figure 15 is a flow diagram of the accessing or adding of the loyalty cards with the app of the mobile telephone of the system of figure 1 ;

Figure 16 is a flow diagram of the retailer registration process of the system of figure 1 ;

Figure 17 is a flow diagram of the campaign creation process of the system of figure 1 ;

Figure 18 is a flow diagram of the campaign approval process of the system of figure 1 ;

Figure 19 is a flow diagram of the process for increasing the time & budget of a live campaign in the system of figure 1 ;

Figure 20 is a flow diagram of the process for adding stores of the system of figure 1 ;

Figure 21 is a flow diagram of the process for adding store permissions of the system of figure 1 ;

Figure 22 is a flow diagram of the process for setting cost per redemption of the system of figure 1 ;

Figure 23 is a flow diagram of the process for targeting push notifications of the system of figure 1 ;

Figure 24 is a flow diagram of a first geo-fencing creation process of the system of figure 1 ; and

Figures 25A and 25B are flow diagrams of the process for integration with facebook 'likes' of the system of figure 1 , for a user and a retailer respectively.

Detailed Description

According to an embodiment of the present invention, there is provided a system for directing advertising, shown generally at 10 in figure 1. System 10 is implemented on a computing device in the form of a server 12 and on a mobile communications device in the form of a mobile telephone 14, as - in both cases - a combination of software and hardware. Server 12 and mobile telephone 14 are in data communication 19 via a combination of existing telecommunications infrastructure including a third-party telephony network and the internet.

Both server 12 and mobile telephone 14 have user interfaces, as discussed below. That of mobile telephone 14 includes a touch screen 16 and a control button 18.

Figure 2A is a more detailed, schematic block diagram 20 of server 12, in which for clarity only the more important operative components of server 12 are shown. Server 12 includes a controller 22 having a processor 24 and an operating system 26. Instructions and data to control operation of processor 24 are stored in a memory 28, which is in data communication with processor 24. Typically, server 12 includes both volatile and nonvolatile memory and more than one of each type of memory, with such memories being collectively represented by memory 28.

Controller 22 of server 12 has an input/output (I/O) interface 30 for communicating with peripheral devices of system 10. Input/output interface 30, the peripheral devices or both may be intelligent devices with their own memory for storing associated instructions and data for use with the input/output interface 30 or the peripheral devices.

Controller 22 of server 12 includes a communications interface in the form of a network card 32. Network card 32 may be used, for example, to exchange data with mobile telephone 14 or with a website (not shown) of system 10 that allows remote interaction with system 10 (as is described in detail below).

In the embodiment shown in figure 2A, server 12 includes a user interface 40 that includes peripheral devices that communicate with controller 22 and hence allow a user to interact with server 12. These peripheral devices comprise a display 42, a keyboard 44 and a mouse 46. Additional hardware may be included as part of server 12, or hardware may be omitted as required for the specific implementation. It is also possible for some of the operative components of server 12 to be distributed; for example, input/output devices 42, 44 and 46 may be provided remotely from controller 22.

Figure 2B is a more detailed, schematic block diagram 50 of mobile telephone 14, in which for clarity only the more important operative components are shown. Mobile telephone 14 includes a controller 52 having a processor 54 and an operating system 56. Instructions and data to control operation of processor 54 are stored in a memory 58, which is in data communication with processor 54. Like server 12, mobile telephone 14 includes both volatile and non-volatile memory and more than one of each type of memory, with such memories being collectively represented by memory 58.

Controller 52 of mobile telephone 14 has an input/output (I/O) interface 60 and a communications interface in the form of a network card 62. Network card 62 may be used, for example, to exchange data with server 12 or with the website (not shown) of system 10. Controller 52 of mobile telephone 14 also includes GPS functionality, and has an antenna suitable for receiving GPS signals and the associated hardware and software for determining the location of the mobile telephone 14 from those signals: these components are shown collectively as "GPS 64".

Controller 52 includes a user interface 70 that includes devices that communicate with controller 52 (via I/O interface 60), and hence allow a user to interact with mobile telephone 14. These devices comprise display 16, control button 18, a microphone 72 and a speaker 74. Additional hardware may be included as part of mobile telephone 14, or hardware may be omitted as required for the specific implementation.

Figure 3A is another schematic view of the user interface 40 and controller 22 of server 12 of figure 2A, with more detail shown in controller 22. Specifically, processor 24 of controller 22 includes a display controller 80 that controls the view that is displayed on display 42 of server 12. Processor 24 also includes a user locator 82, a user-domain comparator 84, a user-offer comparator 86, a website interface 88, a geo-fencer 90, a registrar 92 (for managing the registration of users) and a follower 94 (for tagging or untagging retailers as 'followed'): the functions of these components are described below. Memory 28 of controller 22 includes a database of vendors 100, a database of geo- fenced domains 102 (i.e. zones - specified using geo-fencer 90 - in which a user is generally presented with offers exclusively from vendors located in that domain), a database of vendor offers 104 (i.e. special offers to be advertised by vendors to certain prospective customers) which includes a database of associated offer images 106 (whether still or moving) that illustrate the respective offers, a database of registered users 108 (i.e. of prospective customers), and a database of offer counters 1 10 (i.e.

indicating how many of the items available under each of certain offers remains available). The contents of memory 28 are also described below.

Figure 3B is another schematic view of the user interface 70 and controller 52 of mobile telephone 14 of figure 2B, with more detail shown in controller 52. Specifically, processor 54 of controller 52 includes a display controller 120 that controls the view that is displayed on display 16 of mobile telephone 14. Processor 54 also includes an application in the form of App 140, which itself includes several components including a registration module 142, a category selector 144 (i.e. pertaining to the categories of various offers), an offer radius selector 146, a search module 148, an offer displayer 150, an offer redeemer 152, a wallet manager 154 and a settings manager 156. Processor 54 also includes a map application 158. Map application 158 will vary according to operating system 56. In this embodiment, if iOS, map application 158 is Google Maps (trade mark), while with Android (trade mark) there is a range of map applications 158 that may be employed. However, it will be appreciated that map application 158 may be in the form of any suitable map application.

Memory 58 of controller 52 of mobile telephone 14 includes a database of offers and associated images 160, and a database of user-selected offer categories of interest known as the Consumer Selected Offers (CSO) database 162. Memory 58 also includes a wallet 164 in which the user can save offers for future use, a database of followed brands 166, and a database of loyalty cards 168. The operation of system 10 will now be explained by reference to the various functions implemented by the above-described components thereof.

Figure 4 is a flow diagram 180 of the user registration and offer category selection process of the system of figure 1 , including a social media website (such as facebook (trade mark)) integration process. Referring to figure 4, at 182 a user downloads app 140 by either visiting the website of system 10 (controlled from website interface 88) and following links to an appropriate application store (Apple App Store for iOS users or Google Play Store for Android users), or by going directly to such an application, and - at 184 - downloading an instance of app 140 to mobile telephone 14. Upon starting app 140 for the first time, at 186 app 140 controls mobile telephone 14 to display a welcome slideshow highlighting key features and the main functions of app 140; registration module 142 of app 140 then - at 188 - controls mobile telephone 14 to display a sign up page with two options: either to sign up using his or her email address or to sign up by using his or her facebook (trade mark) account.

If, at 190, the user elects to sign up with an email address, processing continues at 192 where registration module 142 controls mobile telephone 14 to display a registration form that allows the user to sign up, and which requests the user's first name (mandatory), surname (optional), sex (mandatory), birth date (mandatory), email address (mandatory) and password (mandatory) for an account on system 10, and which includes a checkbox that the user must tick to indicate acceptance of the terms of use and privacy policy and a 'Join Now' button. (If a user does not tick this checkbox, a pop up message is displayed to inform the user that he or she must accept the terms of use and privacy policy, or will not be able to register.) The registration form accepts the information inputted by the user when the user clicks the 'Join Now' button, and forwards the user's details to server 12 where registrar 92 saves the user's details in registered users database 108. It should be noted that the registered users' details, though stored on server 12, are accessible by the administrator of system 10, but not by retailers.

At 194, the user is taken to the CSO ('Consumer Selected Offers') page of app 140, at which category selector 144 of app 140 controls mobile telephone 14 to display a grid of icons each of which represents a category of goods or services (which can be updated from time to time by the administrator of system 10) and an invitation to select one or more categories of goods or services concerning which the user would like to receive offers. At 196, the user selects one or more categories of interest, clicks 'Save' at the bottom of the registration page to complete the CSO set up and category selector 144 saves the selected categories to CSO database 162. These category preferences can be altered at any time through the main menu of app 140 (described in greater detail below).

Processing then ends.

System 10 is subsequently able to deliver offers relevant or of interest to each user. When offers are released under a certain category, any individual who has selected that category as part of their CSO will receive that offer, subject to other selection criteria - such a geographic proximity, as described below.

As is also described in greater detail below, when an offer (typically as part of a promotional campaign) is released by a retailer or other vendor, the retailer selects which category that offer falls under. The retailer can also select who their target market is, based on demographic information. System 10 can then match the target criteria set by the retailers when releasing a campaign, matching the right offer with the right customer.

If, at 190, the user elects to sign up via a facebook account, processing continues at 198 where the user is redirected by registration module 142 to an external page (of app 140) with boxes for the user to tick to give server 12 permission to access the user's basic information on facebook, such as first name, surname, age, gender and facebook 'likes' (where these are held by facebook), and agree to associated terms of use and privacy policy. At 200, app 140 integrates with the facebook 'likes' process, then processing passes to 194 as described above.

Hence, the facebook 'likes' process takes brand/companies that the user has 'liked' on facebook and incorporates those liked brands/companies into the user's profile. When a brand/company signs up to system 10, they include their facebook ID in their account. Server 12 responds by creating links between the users that have 'liked' these

brands/companies on facebook and the users that have incorporated these likes into their account on server 12. When these brands/companies release offers, they are presented to the user owing to the aforementioned links, much as occurs when a user has followed a specific brand in app 140. It should be noted that the user's demographics are still taken into account in this process of delivering offers to users who have 'liked' brands/companies on facebook. App 140 then controls mobile telephone 14 to display a home screen on display 16, which is where - as now described - a user-personalized offer feed is displayed to the user and from which the user can view and access offers. The home screen is also the screen that app 140 displays each time app 140 is started or opened. Thus, figure 5 is a flow diagram 210 of interaction with the home screen of the app of the mobile telephone of the system of figure 1 . Referring to figure 5, at 212 the user starts or opens app 140. At 214, user locator 82 of server 12 controls server 12 to ping mobile telephone 14 in order to ascertain the location of mobile telephone 14 (and hence of the user) based on the output of GPS 64 of mobile telephone 14. Server 12 pings mobile telephone 14 on a semi-regular basis to ascertain the location of mobile telephone 14, whether app 140 is open or not (if location services are enabled on mobile telephone 14). When the user opens app 140, mobile telephone 14 pings server 12 to request offers relevant to the user, and server 12 responds by delivering these offers.

At 216, server 12 searches vendor offers 104 for offers around the GPS location of mobile telephone 14. This search pays only coarse regard to the user's location. Thus, it may - for example - identify all offers in the same state of the user, or within some preset distance that is equal to (or greater) than the maximum range of a manual or automatic user-controlled offer search. Next, at 218 server 12 uses an 'offer radius' parameter set by the user (having a default value of 10 km, or set by the user with offer radius selector 146, as explained further below) to identify offers from those found in step 216 within a distance equal to the offer radius of the user's location. (It will be appreciated that steps 216 and 218 may readily be combined.) If, at 218, user-domain comparator 84 determines that offers do exist within the offer radius of the user's location, processing continues at 220 where server 12 recalibrates and excludes from the offers identified at step 218 any offers beyond the offer radius.

At 222, app 140 transmits user preferences (including preferred categories from CSO 162, followed brands from followed brands 166, and any facebook 'likes') and the user's personal details relevant to assessing whether an offer matches the user to server 12. At 224, user-offer comparator 86 identifies matches between the remaining offers, that is, those within an offer radius of the user's location, and these user preferences. If one or more matches are found, processing continues at 226 where server 12 transmits to mobile telephone 14 the matching offers (drawn from vendor offers 104) along with any associated images (from offer images 106), illustrating the offered goods and/or services of the matching offers. At 228, app 140 stores these offers and images in offers and images database 160. At 230, offer displayer 150 controls mobile telephone 14 to display such offers on display 16. Processing then ends.

If, at step 218, user-domain comparator 84 finds no offers within an offer radius of the user, processing continues at 232 where the mobile telephone 14 displays 'no offers found' and, at 234, app 140 prompts the user to enter a new, increased offer radius, if desired. If, at 236, the user enters an increased offer radius (using offer radius selector 146), processing returns to step 218. Otherwise, processing ends.

If, at step 224, no offers are found, processing continues at 232 (described above).

Thus, the procedure implemented by system 10 delivers offers to users based on a combination of their demographics, CSO, Follows, facebook 'likes' and location.

In addition to such offers, the home screen presents other information to the user, but all information presented on the home screen can be categorized as either offer related or app functionality related.

1. Offer Related Information The offer related information is specific to a respective offer. When offer displayer 150 displays an offer, it also controls mobile telephone 14 to display an icon above that offer consisting of a shopping cart and a number followed by the word 'left'. The counter is the number of instances of the offer than remain available for redemption. This number is live and decreases as users redeem (not merely collect) an offer. For example, there could be 10 offers remaining; 100 people might have stored the offer (i.e. in their respective wallet 164) or have viewed the offer (i.e. have it displayed to them as available and suitable, etc) but only 10 will be able to redeem that offer. A second icon is also displayed above each offer, consisting of a clock followed by a number and 'wks', 'days', 'hrs' or 'mins', indicating how long the user has to redeem the offer (i.e. how long until the offer expires).

A third icon is displayed above each offer, consisting of a location symbol (which resembles an inverted teardrop) with a number followed by 'km'. This icon indicates how far the user is from the location where the offer can be redeemed. Often offers will be redeemable at multiple locations: this figure indicates the distance to the nearest location where the offer can be redeemed. The counters associated with the offers, including number remaining, time remaining and distance to nearest location, are stored and maintained in offer counters 1 10 of server 12.

This process is illustrated in figure 6, which is a flow diagram 240 of the process by which this offer-specific information is determined and displayed. At 241 the user starts app 140. At 242, the app 140 opens the home screen.

At 243, app 140 transmits user preferences (including preferred categories from CSO 162, followed brands from followed brands 166, and any facebook 'likes') and the user's personal details relevant to assessing whether an offer matches the user to server 12. At 244, user-offer comparator 86 identifies matches between all offers and these user preferences. If no matches are found, processing ends. If one or more matches are found, processing continues at 245 where server 12 transmits to mobile telephone 14 the matching offers (taking their details from vendor offers 104) along with any associated images (from offer images 106) if not already held in offers and images 160. At 246, app 140 stores these offers and images in offers and images database 160. At 247, offer displayer 150 controls mobile telephone 14 to display such offers on display 16. At 248, the user may elect to perform a manual search for offers. If not, processing ends.

However, if the user elects to perform a manual search by clicking on a 'search' icon, processing continues at 249 where app 140 responds (as described in detail below) by displaying a search screen with a soft keyboard with which the user enters manual search keywords. At 250, these keywords are transmitted by app 140 to server 12 which, upon receiving the keyword or words, conducts the requested search by comparing - at 252 - the keywords with all offers in vendor offers 104. If, at 252, no matches are found, processing ends. Otherwise, processing continues at 254 where server 12 transmits the matching offers with associated images, if not already in offers and images 160, to mobile telephone 14. At 256, app 140 stores these offers and images in offers and images database 160 and, at 258, the matching offers are displayed on display 16 together with the number left, time left, distance to the offer, etc. Processing then ends.

It should be noted that both forms of searching may co-exist, and generally will. A user may have an automatic offer feed in place, while on occasion conduct a manual search.

When an offer is displayed on display 16, beneath the three icons associated with the offer there is also displayed, as described above, a large image relating to the offer. The first time such time a particular image is transmitted to mobile telephone 14 and ultimately displayed to the user, it is stored locally in offers and images 160. This is done so that the next time the user opens app 140, such images do not need to be downloaded again. These images do not remain indefinitely in the mobile telephone 14: each is deleted one month (or other predefined time period, as desired) after being downloaded, to avoid memory 58 being filled by these hidden files.

In the top right hand corner of the image, and overlaying the image, a small square is displayed reading, for example, '40% In-Store only'. This offer square changes depending on the level of offer being given by the retailer and is a quick way for users to identify what each promotional campaign is offering. In another embodiment, the offer square changes depending on the type of offer (e.g. percentage discount versus bonus gift with purchase versus voucher for future purchase, etc), or depending on both the level and type of offer.

Beneath the image are displayed two lines of text. The first is the name of the

store/brand the offer is being provided by and the second line is a brief one line description of the offer, such as '40% off all accessories today'. 2. App Functionality Related Information

The app related functionalities displayed on the home screen are: i) the save button, ii) the wallet, iii) the search function, iv) the offer radius, v) the menu, and vi) entering an offer (such as to view of redeem that offer). The home screen also includes a pull down from the top of the page to prompt the refreshing of the offers, and a pull up from bottom of page to prompt the loading of more offers. i) The Save Button

The save button is located on each offer to the right of the two lines that are below the offer image. When this button is pressed it changes from 'Save' to 'Saved' and changes colour. The offer is then saved by wallet manager 154 to wallet 164 (explained below). To unsave an offer, the user clicks on the button once more and it reverts back to its original state of 'Save', reverts to its original colour and is removed from wallet 164 by wallet manager 154. ii) The Wallet

The wallet icon is located in the bottom right corner of the screen and when pressed takes the user to the wallet section of app 140 from where wallet manager 154 can be controlled. (Note that wallet 164 can also be accessed from the main menu, as explained further below.) This is where the user finds displayed any offers that the user has saved but not yet used/redeemed. The user can order such saved offers by pressing one of the two buttons at the top of the screen, 'Distance' or 'Expiry'. When the user clicks

'Distance', wallet manager 154 displays the saved offers ordered by greatest proximity to the user, and if pressed again, ordered by greatest distance from the user. When the user clicks 'Expiry', wallet manager 154 displays the saved offers ordered by those expiring soonest to last, and if pressed again, ordered by those set to expire last to soonest. The user can also use the search bar at the bottom of the wallet page to control wallet manager 154 to find a particular offer in wallet 164. It should be noted that the search bar that appears within wallet section only searches for saved offers in wallet 164; this search is not that same as the search provided by the search bar on the home page, which searches through all offers in vendor offers 104 and offers and images 160.

Additionally, if the user has saved an offer to wallet 164, that offer and associated information and images is stored locally and can still be accessed even if there is no internet connection. The user returns to the home screen by clicking the 'Back' button. iii) The Search Function

In the bottom left of the screen is displayed a search icon. When clicked, app 140 responds by displaying a keypad and search bar. The user can use this keypad to control search module 148 to search for any offer in vendor offers 104 or offers and images 160, regardless of whether it falls within the user's CSO or not. The user can search based on key words, brands, sale items, locations etc. Once the words have been entered into the search bar, the feed will propagate any offers located in the search. To close the keypad, the user clicks 'Done'. iv) Offer Radius

In the top right of the home screen is displayed a button that at its default setting (i.e. when a user first uses app 140) shows '10 km'. This is the offer radius button. When the user presses it, offer radius selector 146 displays a list of radii the user can select. The offer radius determines the radius from within which they wish to receive offers (as discussed above). When a radius is selected, app 140 recalibrates to show only offers within that distance from the user. If a user selects a radius (e.g. 500 m) and there are no available offers within that distance, then app 140 automatically presents a message to the user that no offers can be found and suggests increasing the offer radius. The maximum distance to which app 140 will search is, in this embodiment, 50 km.

If an offer radius has been set (whether by default or user selection), the procedure shown in figure 6 is followed in a search for offers with the modification that the offer filtering at step 242 also filters by offer radius.

Beneath the radii options, which range as mentioned from 0.5 km to 50 km, the radius list includes a list of geo-fenced domains that fall within a 50 km radius of the current location. A geo-fenced domain is a zone such that, when a user is in that zone, only offers available at vendors' stores in that zone will be presented to the user. That is, when the user is in a geo-fenced domain, the user's mobile telephone 14 is automatically recalibrated to exclude offers outside of the geo-fenced domain.

This can be overridden by the user by controlling app 140 to enforce his or her offer radius, in which case the immediate geo-fenced domain has no effect on what is presented to that user. The user maintains the ability to select the geo-fenced domain from within the radius options, even if the user has changed the radius selection to an alternative option previously. The size and shape of geo-fenced domains is set from server 12 by a system

administrator, using geo-fencer 90. The geo-fenced domains defined in this manner are stored in geo-fenced domains 102.

Geo-fenced domains may correspond to, for example, a shopping centre, shopping mall or shopping district, or shop, or comprise a geographical area defined by, for example, suburb (such as defined by postal code) or a polygon (e.g. square, rectangular, triangle), definable using geo-fencer 90 by the administrator of system 10. Briefly, this is typically done by inputting the latitude and longitude coordinates of the domain; map application 158 converts these coordinates to a specific domain on a map.

Generally, when outside such a geo-fenced domain, the user will be presented with offers available at stores in or outside that domain if such stores fall within the offer radius of that user in the manner described above. That is, when a user is outside a respective geo-fenced domain, the existence of that geo-fenced domain does not affect what is presented to the user. However, if the user selects a geo-fenced domain from the radius list described above, the home screen displays only the offers available within the selected geo-fenced domain (as discussed above, subject to user/offer matching by user- offer comparator 86). That is, even if the user is not within the selected geo-fenced domain, the user can control app 140 to recalibrate to those locations within that geo- fenced domain. As explained above, geo-fenced domains are displayed in this list only if they are within 50 km of the user and they are listed in order of those closest to the user to furthest. When the user closes app 140 and later re- enters it, the offer radius returns to its default value (viz. 10 km) even if the user selected a different value in a previous session. v) Menu

The menu button is located in the top left hand corner of the home screen. This button appears as three horizontal lines stacked vertically. When pressed, the menu button produces a fly out menu (from the left to the right side of the screen) giving several options for the user to choose from, as is explained in further detail below.

Figure 7 is a flow diagram 260 of an optional offline offer process of app 140. There will be times where there is limited network coverage suitable for mobile telephone 14.

System 10 requires, in this embodiment, a connection - such as via a 3G or WiFi connection - to the internet in order to employ all its functions, but even without network coverage the user is able to use app 140 to some degree. Hence, referring to figure 7, in such a case, at 262 the user starts app 140 and at 264 app 140 opens the home screen. At 266, app 140 attempts but fails to send the GPS location of mobile telephone 14 to server 12. At 268, the user is informed by app 140 that there is insufficient network coverage, so the user may choose to access wallet 164 (which contains all previously saved offers, including associated images). At 272, the user views, redeems, etc., the desired offer or offers in wallet 270 (such as by conducting a wallet search).

At 274 the user regains network coverage, and at 276 app 140 controls mobile telephone 14 to update server 12 concerning the accessed offers - such as redemption of an offer - while the user was offline and server 12 updates its databases accordingly (e.g. by marking an offer as redeemed). In the case of offline redemption, at 278 the redemption of the offer is communicated to. Server 12 attempts to ascertain in which store the offer was redeemed, and notes this against the appropriate vendor's store, by determining the closest suitable location (i.e. at which such an offer was able to be redeemed) and linking the redemption to that location; otherwise the redemption is marked as having occurred at an unknown location. Processing then ends. vi) Entering an Offer

In order to inspect an offer and see further details, the user clicks on the offer image as displayed on display 16, and are taken into the offer. All previous details from the home screen (number remaining, time until expiry and distance) are still displayed.

The image associated with a respective offer, and which was displayed on the home screen of app 140, is also displayed on display 16 when the user has entered that offer. Retailers are constrained by server 12 to upload at least one image when releasing an offer, but they can upload up to three images as well as a short video clip. The user is able to view these media files by scrolling across the image. The user will know how many images/videos are there as, at the bottom of each image are displayed small grey dots, indicating the number of images. Moreover, the dot corresponding to the current image is displayed darker than the others. The first time an image is downloaded to mobile telephone 14 (see, for example, step 226 of figure 5), it is stored locally in offers and images 160 for a period of 30 days (or other predefined time period, as desired) and then, along with the offer with which it is associated, is automatically deleted (regardless of whether the associated offer has expired, been deleted or been used). These images, though stored locally, are not visible in the user's gallery on mobile telephone 14.

Also displayed is a physical address of the closest store location where the offer that has been entered can be redeemed, as well as an associated telephone number should the user wish to telephone that store. This is illustrated in figure 8, which is a flow diagram 280 of this address. After an offer has been displayed to the user in the home screen feed or category feed at 282, the user - at 284 - clicks the associated image to access further offer details. At 286, app 140 transits the identity of the offer to server 12, which at 288 determines the closest store location where offer is valid and at 290 returns the details of that store to mobile telephone 14. App 140 then displays - at 292 - the physical address information to the user in the offer details. Processing then ends.

Likewise, while within an offer, a user can obtain directions to a selected store. Figure 9 is a flow diagram 300 of this map feature. After an offer has been displayed to the user in the home screen feed or category feed at 302, the user - at 304 - clicks the associated image to access further offer details. At 306, the user clicks on a map icon and, in response at 308, app 140 prompts the user to confirm that he or she would like directions to the store's location. When the user does so at 310, at 312 app 140 starts map application 158 (passing the store's address to that application as it does so), and closes. At 314, map application 158 - using the user's address from GPS 64 and the store's address received from app 140 - determines and displays directions to the store. Once the user is finished with the map, at 316 the user closes map application 158 and, if desired, at 318 reopens app 140.

Within an offer, app 140 also displays to the user text with greater detail about the offer. Displayed at the bottom of app 140 are three buttons; the first button labelled 'terms' that - when pressed - controls app 140 to flip the screen over and display the offer specific terms and conditions. To return to the offer, the user pushes the same button again.

The second button is labelled 'follow'. When pressed it changes colour and instead reads 'followed'. This controls app 140 to present offers to the user on the next occasion that offers are released by the same brand/company, provided that the user fits the target criteria of the offers at that subsequent release time. Figure 10 is a flow diagram 320 summarizing this follow feature. After an offer has been displayed to the user in the home screen feed or category feed at 322, the user - at 324 - clicks the offer to obtain further details and at 326 clicks the 'follow' button, which responds by changing to 'followed'. At 328, app 140 transmits data identifying the user and the followed brand/company to server 12 where follower 94 add the followed brand to the record in registered users 108 pertaining to the identified user. As 330, app 140 adds that brand/company to followed brands 166. At 332, an offer is released by the followed brand, and - at 334 - follower 94 responds by searching registered users 108 for users following the brand identified in the offer. If at 336 the search is found to be

unsuccessful, processing ends. Otherwise, processing continues at 338 where user-offer comparator 86 determines whether the offer (i.e. its new instance) matches the user according to the criteria discussed above. If not, processing ends. Otherwise, processing continues at 340 where follower 94 alerts app 140 by sending a message indicating that a followed offer has been released. At 342, app 140 notifies the user of the release of the followed offer by displaying the offer on display 16. Processing then ends. Optionally, when offers are presented to a user (such as in that user's offer feed), offers associated with 'followed' brands or companies may be presented with a higher priority than other offers. Also, this prioritization of the offers of followed brands or companies may be done retrospectively. That is, offers associated with a followed brand or company but received by a user or added to that user's offer feed before that user began following the particular brand or company may be elevated in position or priority in response to the user controlling app 140 to record that brand or company as 'followed' by that user.

In short, a user can follow a retailer, a brand, or other characteristics associated with an offer, by clicking on that information and clicking on a 'follow' button displayed in response thereto. Follower 94 responds to a request by a user to follow a retailer, brand, etc, by tagging the user with the retailer, brand, etc. Subsequently, follower 94 also checks for tags of this sort when an offer is released. The third button is labelled 'share'. When pressed it displays four options: facebook, Twitter (trade mark), SMS and email. Pre-written messages are stored in app 140 that extract the relevant information from the offer (i.e. store name, discount, etc) and create a message for sending in the selected platform. Figure 1 1 is a flow diagram 350 of the share feature of app 140. After an offer has been displayed to the user in the home screen feed or category feed at 352, the user - at 354 - clicks the offer to obtain further details and at 356 clicks the 'share' button. At 358, app 140 responds by displaying the sharing options: facebook, Twitter, sms & email. According to which option is selected by the user, app 140 responds by:

• At 360a, if facebook is selected, app 140 creates a message based on offer

information, and the message is posted to the user's facebook wall,

• At 360b, if twitter is selected, app 140 creates a message based on offer

information, and the message is posted to the user's twitter feed,

• At 360c, if sms is selected, app 140 creates a text message based on offer

information; the user then selects addressee, and an SMS is sent to that recipient or

• At 360d, if email is selected, app 140 creates an email message based on offer information; the user then selects addressee and an email is sent to that recipient.

Processing then ends.

The redemption of an offer is performed as follows. Figures 12A and 12B are a flow diagram 370 of the redemption of an offer via app 140. Referring to figure 12A, after a user - at 372 - is presented with an offer, the user at 374 clicks the image of the offer to access further details of the offer. At 376, having decided to redeem the offer, the user clicks on a 'click to redeem offer' button displayed by app 140. Upon clicking this button, at 378 app 140 opens a new page which requests that the user confirm that he or she wishes to redeem the offer. If the user clicks 'No Thanks', processing returns to step 374. Otherwise, if the user clicks 'Yes Please', the offer is regarded as redeemed, and processing continues at 380 where redemption data is transmitted to server 12, which counts this redemption against the allocated budget from the retailer and notes the redemption in the campaign results (and the retailer is charged for the service provided by system 10) and app 140 displays a redemption page. The redemption page includes the name of the store/brand, then the offer title description and below that the offer discount or other benefit scrolling across the screen from right to left. The third line is set to scroll so that a cashier knows that this is a live offer (rather than merely a screen shot), as the offers are exclusive and finite in number. Following this information is an image of the logo of system 10. Following this is the barcode for scanning (should the retailer have chosen to include a barcode). The barcode is a means of keeping track of redemptions for the retailer. If there is no barcode, the user presents the offer at the point of sale to show its validity. Also displayed in a 'scan loyalty card' button if the retailer has added a loyalty scheme, but this 'Scan Loyalty Card' button only appears should the user have previously uploaded their loyalty card to the app 140, such that its details are recorded in loyalty cards 168.

At 382, the user presents the offer barcode for scanning (if available) or display 16 to the cashier so that the cashier can record the offer details, after which - at 384 - the user presses the 'scan loyalty card' button (if desired) and, if so, at 386 the user presents his or her loyalty card for scanning at the POS.

Next, at 388 the user clicks a 'complete purchase' displayed by app 140 and at 390 app 140 displays a screen that says 'Would you like to enter the system's competition?'.

Should the user press 'No Thanks', processing ends. Otherwise, should the user press 'Yes Please' processing continues at 392 where app 140 displays a competition entry page. This page explains that the user should take a photograph of their receipt (for the just-completed redemption) as a means of verifying that a purchase has been made. Once the user has done so, at 394 app 140 accesses the camera of mobile telephone 14 and the user - at 396 - clicks a 'submit' button to control app 140 to transmit the photograph to server 12. At 398, server 12 stores the photograph in registered users 108 associated with the profile of that user. Processing then ends.

App 140 transmits details of every action of the user to server 12, including the saving, viewing and redemption of an offer, and where a redemption has taken place. This information is stored in registered users 108 associated with the profile of that user for later analysis - such as to provide the retailers with useful statistics. This information is accessible to the administrator of system 10. This process is summarized in figure 13, which is a flow diagram 400 of the interface for analysing user data. On the user side, at step 402 the user starts app 140, at 404 the user collects, views, shares and/or redeems offer, and at 406 server 12 receives the user's activity and records it in registered users 108.

On the server side, at step 408 the system administrator logs into server 12, at 410 selects a 'user id' tab, and at 412 filters users by demographics (age, gender, competition participation, etc.). At 414, server 12 displays the users that fit the administrator-selected criterion or criteria, and at 416 the administrator controls server 12 to export data pertaining to a single user or to a group of users to a csv file for later analysis.

Processing then ends.

As described above, the home screen of app 140 includes a 'menu' button, which comprises three horizontal lines. If the user clicks this button, app 140 responds by displaying several options in a list: i) Home, ii) Categories, iii) My Wallet, iv) Loyalty Cards, v) My Favourites, vi) Settings, vii) Logout. At any time within one of these options (except Categories and Settings), the user may swipe (right to left ) to go back to the home screen. Within all of these options, the menu icon is displayed and may be clicked to bring up the menu. In addition, swiping from the home screen (left to right) will bring up the menu. The functions of these options are as follows. i) Home

When this option is selected by the user, app 140 returns the user to the home screen. 2) Categories

When this option is selected by the user, app 140 opens all the categories that have offers available to the user. When a category is selected by the user, app 140 responds by displaying the sub-categories for that particular category with the first option being 'All Sub Categories'. Once the user makes a selection, the offers within that category are presented in the same style as the home screen feed described above. The user can also change the offer radius, access a search function, and access wallet 164. To go back and inspect other categories, the user can click the 'Back' button to go back to the categories list or click the 'system' logo at the top of the screen to return to the home screen. Any category in which there are currently no available offers are not displayed. iii) My Wallet

Figure 14 is a flow diagram 420 of the operation of wallet manager 154 for using and managing saved offers. When 'my wallet' is selected, app 140 directs the user to the My Wallet page, as described above. That is, at 422, the user presses the menu button, then at 424 selects 'my wallet'. In response, at 426 wallet manager 154 displays the My Wallet page including offers previously saved for future use. At 428a, the user may order an offer by distance from the user or by expiry date by selecting the 'distance' or 'expiry' button, respectively, then at 430 wallet manager 154 removes the redeemed offer from wallet 164 and processing ends. Meanwhile, at 428b, wallet manager 154 removes from wallet 164 any offers that have not been redeemed by the user but have either expired or been exhausted by redemption by other users. Wallet manager 154, at 432, indicates the number of saved offers due to expire within the next 24 hours by displaying on the home screen a circled number indicating how many offers are soon to expire. Processing then ends. It should be noted that users also have the ability to delete an offer from wallet 164 by clicking the 'delete' button. When this is done wallet manager 154 removes the offer from wallet 164. If the user later searches for that offer (either through the home feed or through a specific category or through search) the offer will now be displayed with 'save', as the offer is no longer in wallet 164. iv) Loyalty Cards

Figure 15 is a flow diagram 440 of the loyalty card function of app 140. After selecting menu at 442, the user selects - at 444 - 'Loyalty Cards'. App 140 displays at 446 an 'add loyalty card' button and an alphabetized list of loyalty cards that have already been entered by the user and are in loyalty cards 168. If the user selects the 'add loyalty card' button, processing continues at 448a where the user, at 450, selects from list which loyalty card he or she wishes to add. At 450, the user enters the barcode number from the new loyalty card and presses 'generate loyalty card'. At 452, app 140 saves the newly added loyalty card to loyalty cards 168 of mobile telephone 14. Processing then ends.

It should be noted that only loyalty cards that have been approved by the administrator of system 10 can be added to the user's saved loyalty cards. If, at step 446, the user instead selects an existing loyalty card, app 140 responds at 448b by opening the selected loyalty card and at 456 displays its barcode for scanning. This allows the loyalty card to be used other than in the redemption of an offer with system 10, as this displayed barcode can be presented for other purposes in place of the loyalty card itself. Processing then ends. v) My Favourites

When the 'My Favourites' button is selected, app 140 displays a list of all the categories in app 140. The categories selected during CSO set up are highlighted and marked as ticked. However, the user can alter his or her preferences by tapping the categories in which he or she wishes to receive offers, or deselecting those categories in which he or she no longer wishes to receive offers. The user then clicks 'save' at the bottom of the screen and the amended preferences are saved. vi) Settings Likewise, when the 'Settings' button is selected, app 140 displays the various user- operable settings, and allows these to be amended by the user. From this page, the user can change his or her personal details (if desired), email address, password etc. The user can also amend the default offer radius, such that every time the user opens app 140, the offer radius will be set to the chosen default value (rather than the system default of 10 km). From settings, the user also has the ability to turn off the push notifications sent out by server 12. vii) Logout

The last item on the menu is 'Logout'. When a user closes app 140, they remain logged in. A user will only be logged out if they select the logout item on the menu. The app will present a window asking the user if they are sure they want to log out, giving the options of yes or no. If no is selected they will remain logged in, if yes is selected, the user will be logged out. Upon opening the app next time, if the user has logged out, they will need to login. If they have forgotten their password or login name, they can enter their email address and the details will be sent to them.

As described above, users can enter areas known as geo-fenced domains. These are zones where offers from outside are not communicated to users inside the domain. Once a geo-fenced domain has been created by the administrator with server 12, app 140 recalibrates to make sure only offers from within that domain are visible, hence excluding offers from outside the geo-fenced domain. Mobile telephone 14 is pinged on a semi- regular basis to determine where the user is located and whether within a geo-fenced domain (the latter being determined by user-domain comparator 84). When a user enters a geo-fenced domain, server 12 sends mobile telephone 14 a message welcoming the user to that specific domain; when, for example, a user arrives at a geo-fenced Shopping Centre or Mall, server 12 sends to mobile telephone 14 a welcoming message that refers to that Shopping Centre or Mall by name. App 140 then recalibrates mobile telephone 14 to exclude all offers from locations external to that geo-fenced domain, and the name of the geo-fenced domain in the field that otherwise includes the offer radius (hence, for example, "Shopping Centre Name" rather than "10 km"). All other functionality remains the same as described above. If the user so desires, he or she can click the offer radius button and change the offer radius to receive offers according to offer radius rather than the geo-fenced area alone; this has the effect of suspending the application of the geo- fencing for as long as the user remains inside that geo-fenced domain.

The purpose of excluding is so that the administrator of system 10 can charge, for example, a Shopping Centre a fee to create a geo-fenced domain corresponding to that Shopping Centre, for delivering an almost 'captive audience.' Once a user leaves the geo-fenced domain, offers are again sent to mobile telephone 14 according to offer radius, as described above.

Figure 16 is a flow diagram 460 of the retailer registration process of system 10.

Referring to figure 16, at 462 the retailer visits the website of system 10 (maintained in from website interface 88). At 464, the retailer completes an expression of interest (Έ.Ο.Ι.'), by entering a name, the company name or trading name, a contact telephone number and an email address. At 466, the website sends the retailer an email explaining that the expression of interest has been received and that a response may be expected shortly, and the website sends server 12 an email with the expression of interest. At 468, the administrator determines whether the application criteria are met, that is, whether the details in the expression of interest are valid and whether the retailer is suitable for system 10. If not, processing continues at 470 where the application is declined. At 472, server 12 sends an email to the retailer notifying the retailer that the application for an account with system 10 has been declined, and processing ends.

If at 468 the administrator determines whether the application criteria are met, processing continues at 474 where approval is granted. At 476, the administrator logs into server 12 and, at 478, the administrator controls server 12 to send a link to the retailer with a temporary password, to enable the retailer to complete registration as a retailer with system 10. The retailer does not have access to the rest of the functionality of the website of system 10 (described below) until the retailer has completed the remainder of their registration. Hence, upon receipt of this email, at 480 the retailer opens the link and completes a number of mandatory fields in an HTML registration form, then at 482 submits that form. At 484 these details are received by server 12 and registration is complete. Processing then ends, and the retailer can now start creating campaigns by logging into his or her account via the website.

Figure 17 is a flow diagram 490 of the campaign creation process of system 10. At 492, the retailer logs into the account via the website and, at 494, clicks a button marked '+ Create Campaign' which takes the retailer to a campaign creator page of the website. This page displays a range of fields on the left hand side of the screen and on the right, an emulator of a mobile telephone. As the retailer fills out the information pertaining to a new offer on the left, the website also fills the corresponding information in the mobile telephone emulator to give the retailer an indication of how the offer will appear once live. As the retailer scrolls down the page, the emulator follows so that the retailer need not return to the top of the page to inspect the emulator. The emulator allows the retailer immediately to determine whether alterations are required or desirable to the offer or how it is to be displayed to users. At 496, the retailer enters a campaign name (solely for the retailer's reference, and not public viewing) and the start date/time and end date/time of the campaign. At 498, the retailer selects the category that the offer falls into and, if desired, at 500 a sub-category. For example, 'Women's High End Fashion' as the category, and 'Shoes' as sub-category.

At 502, the retailer selects the desired form of the offer (whether a percentage discount, "two for the price of one", or otherwise) and, at 504, the budget to be allocated to the campaign. The budget is the maximum amount that the retailer will be charged by system 10; each redemption is charged to the retailer according to the category the redeemed offer. For example, Women's fashion and accessories might be valued at $1 per redemption but high end women's fashion and accessories might be valued at $2 per redemption. Hence, once the budget has been entered, at 506 the website (after requesting and receiving the current cost per redemption of a specific category from server 12) calculates and displays to the retailer the number of redemptions that can be achieved for a given budget.

At 508, the retailer selects the age group or groups to which the offer is to be targeted, and at 510 the retailer selects the sex or sexes to which the offer is to be targeted. At 512, the retailer enters up to 6 key words the retailer wishes to attach to the offer to make it easy for users to search find.

At 514, the retailer uploads up to three images (but at least one) and optionally a video file. The images must be of a specific size that is made clear to the retailer. At 516, offer information is inputted, including offer title and offer description; the brand name, if any, is automatically entered from the retailer's registration details. There is a 'while stocks last' box that is always pre-checked that will be attached to all offers unless unselected.

At 518, the retailer chooses in which store locations the offer is to be valid, by clicking on a 'Select From Stores' button; this prompts a pop up window to appear that allows the user to search for stores, select all stores, or select stores by state. Once the selection is made, the user clicks the button at the bottom of the window and the selected stores are added to the offer. At 520, the retailer is prompted to indicate whether redemption by barcode is to be supported, to allow the retailer to keep track of the number of offers that have been redeemed so that they can confirm our redemption numbers with their own. If the retailer elects to do so, processing continues at 522, where the retailer enters the barcode number they wish to use and the system generates the barcode and saves it to server 12 for when the offer goes live. The retailer must also load the barcode into their backend system so that when the barcode is scanned or entered manually at the point of sale, it is recognized by the retailers system. Processing then continues at 524. If, at 520, the retailer elects not to use a barcode, processing continues at 524.

At 524, the retailer enters the offer-specific terms and conditions then optionally, at 526, saves the campaign for later submission; at 528, whether after saving the campaign or not, the retailer submits the campaign for approval prompting the website to transmit the campaign's details to server 12. Processing then ends.

Figure 18 is a flow diagram 530 of the campaign approval process. At 532, server 12 sends the submitted campaign to the administrator's account on server 12 for approval. At 534, server 12 emails the administrator to inform him or her that a new campaign has been submitted. At 536, the administrator logs onto server 12 and opens the campaign that is pending approval. At 538, the administrator reviews the campaign. If, at 540, the administrator approves the campaign to go live, processing continues at 542 where server 12 adds the offer defined by the campaign to vendor offers 104 and makes the offer live at the defined start date and time, and visible to those users who meet the offer criteria. Processing then ends.

If, at 540, the administrator does not approve the campaign, processing continues at 544 where the administrator returns comments via email to the retailer indicating the amendments required if approval is to be obtained. At 546, the retailer logs into a portal provided by the website of system 10 (or directly via a link in the email with the required amendment), and at 548 makes the required changes and resubmits the campaign for approval. Processing then returns to step 534.

The administrator can also access the portal. Once a campaign is live, the retailer can still amend certain campaign data and hence offer details and parameters. Figure 19 is a flow diagram 550 of the process for increasing the time & budget of a live campaign. At 552, the retailer logs into the retailer's account via the website of system 10. At 554, the retailer clicks on 'live campaigns' from a drop down menu and, at 556, the website retrieves (from server 12) and displays a list of the live campaigns of that retailer. At 558, the retailer selects a live campaign and, in response at 560, the website retrieves and displays the metrics of the selected campaign including live results, start/end date, budget, amount spent and remaining, total collected, total number of times the offer has been viewed and total number of instances of the offer that have been redeemed. At 562, the retailer may choose either to click on a clock icon or on a '$' icon. In the former case, processing continues at 564, where the retailer enters a new end date (i.e. beyond the previously stored end date, not - in this embodiment - earlier than the previously stored end date) to which retailer wishes to extend the offer, and at 566 the retailer clicks 'ok' to approve change and make them live. If, at 562, the retailer clicks on the '$' icon, processing continues at 568 where the retailer enters an amount by which retailer wishes to increase (not, in this embodiment, to decrease) the existing budget. Processing then continues at 566 where the retailer clicks Ok' to approve the changes and make them live. The retailer can also click a drop down menu and view campaigns that are pending approval, and also filter through past campaigns so that they can - if desired - re-launch successful campaigns. The campaigns that have been released by the head office of a retailer are highlighted in one colour and those released by authorized stores or distributors (as explained below) are highlighted in another colour.

Next to each campaign within this campaigns list (i.e. on the landing page on the retailer portal), there is a bar chart icon. When this is clicked on, it takes the retailer to the results page. This page shows the live results (or past results if campaign is finished) for a campaign. The retailer can view basic information such as how much time is left, how much of the budget has been spent or how many offers have been collected, viewed, shared or redeemed. (As described above, all user activity is saved for such analysis.) The retailer also has the ability to break the results down in great detail. All the graphs allow the retailer to break the results down based on collected, viewed, shared or redeemed offers if they so wish. The largest graph allows the retailer to see the weeks, days or even hours where offers have been most successful. The information is also broken down in other graphs to show male vs. female, activity by age group, new users vs. repeat users of offers, numbers by state/territory and also the top 6 most successful stores. Retailers can also view the results for a specific store. All this information can be exported to a PDF file for printing. Past results are also stored and can be broken down in the same manner. This gives the retailer a powerful tool.

At the top of the retailer webpage of system 10, there is a tab that says 'Account'. When pressed by the retailer, a new page opens with three tabs in the middle of the page. They are i) Company Details, ii) Stores, and iii) Store Permissions. i) Company Details

When the retailer goes into this section, he or she can change the company details, such as billing address, contact information and password. ii) Stores

The second tab is marked 'Stores'. This section shows all the store locations that have been added and allows for stores to be deleted from the account. There is also a search bar at the top of the tab that lets the user search for a specific store if desired.

There are two ways for the retailer to add stores. Figure 20 is a flow diagram 570 of the process for adding stores by either approach. At 572, the retailer logs into the portal via the website. At 574, the retailer clicks on the retailer's account tab and then either on '+ add stores' (if a single store is to be added at a time) or on 'Download CSV Template' (if many stores are to be added at once). If the retailer clicks on the former, processing continues at 576 where the retailer enters the parameters of the new store, then - at 578 - clicks 'save changes' at bottom of page to initiating the saving of the new store to the list of the retailer's stores in vendors 100. At 580, before the store is actually saved, server 12 checks vendors 100 to determine whether the new store is in fact a duplicate of an existing store (according a set of rules in server 12 for identifying such a duplicate), and rejects any duplicates. At 582, the new store or stores (assuming at least one non- duplicate was found) are saved to vendors 100. Processing then ends. However, there is also a button underneath the other fields labelled 'Add Another Store', to allow retailers who do not have a large number of stores to add yet another store; though not shown in figure 20, clicking this button returns the retailer to step 576.

If, at step 574, the retailer clicks 'Download CSV Template', processing continues at 584 where the website responds by downloading to the retailer's computer a csv template (to a location selected by the retailer). At 586, the retailer completes the fields in the template and saves the csv file to their computer. On the same page from which the file was downloaded, there is a button labelled 'Choose File': at 588, the retailer clicks this button and finds and selects the completed csv file. At 590, the retailer then clicks the 'Upload CSV file' button, then processing continues at 578. Subsequently, if the retailer wants to add more stores, they can open the csv file previously saved on their computer (at step 586), add further stores to it and then re- upload the file (viz. step 588) and follow the subsequent steps of flow diagram 570. iii) Store Permissions

The first tab says 'Store Permissions'. When this is clicked, it takes the retailer to a page where they can grant permission to their store managers so that they may release offers within the retailers selected parameters for their particular store. Store permissions can only be issued by the retailer's head office. The head office sets the maximum discount that the store can issue, the maximum expenditure (i.e. Budget) for a single campaign and also to whom the bill will be sent (viz. Head office or individual store).

Figure 21 is a flow diagram 600 of the process for adding store permissions. To grant a store permission, the head office retailer - at 602 - logs into portal and, if server 12 determines at 604 that stores have already been added (as described above), processing continues at 606 where he or she clicks on the retailer's account tab. At 608, he or she clicks on the tab 'head office permissions' and at 610 on the 'Grant Store Permission' button. At 612, a pop-up window is displayed listing all the stores that the retailer has previously added from which the retailer selects one or more stores. At 614 , the retailer can choose to grant store permissions to all stores so that they can release offers on their own, or the retailer can choose individual stores to which he or she wishes to grant permissions; alternatively, the retailer can select stores by - for example - state, province or county. Next, the retailer can choose either to apply global permissions to the selected stores (at 616), in which case the permissions granted are set to global settings which means the retailer can set a universal rule for who the bill is sent to, what the maximum offer is and also the maximum allowable budget, or to change the rules for particular stores (at 618) on a store by store basis. In both cases, processing then continues at 620, where the retailer clicks 'submit changes' to send out a notification email to store managers (at email addresses added when the stores were originally added). At 622, after the stores are granted permission to release offers of their own accord, an email is sent to the managers automatically with a temporary password and information for their account. Processing then ends. However, head office at any time can choose to further amend (including to remove) store permissions. If, at 604, server 12 determines that stores have not yet been added by that retailer, processing continues at 624 where the process for adding stores is followed (according to flow diagram 570 of figure 20), after which processing continues at step 606.

The functions that a branch store is given are limited. Such stores can only release offers for their individual store and can discount only up to the level that the head office has granted and only up to the budget they have allowed. The store that has been granted permission can also view the results for their campaigns only. They cannot alter their company details, and they cannot alter the permissions. There is a link that allows them to contact their head office directly through the website via email should they wish to make a request.

Creating, launching, and monitoring campaigns works in essentially the same manner for an authorized retailer account as it does for a Head office Account. This section describes the admin portal of system 10 and back end control.

A member of the admin staff goes to the website of system 10 and logs in to this admin portal. Six tabs are then displayed: i) Campaigns, ii) Clients, iii) User ID, iv) Sponsored Ads, v) Settings, and vi) Reports. i) Campaigns

The first tab is 'Campaigns'. This allows the retailers to look at all of the live, past and pending campaigns. Next to the campaign title is a field that asks if the retailer has been invoiced yet. There is a button that says 'No' until clicked and then changes to 'yes'. A csv file can then be exported with all the relevant charging information. The system 10 admin staff can click on the live campaigns to see the campaigns details too.

With the past campaigns, the admin staff can review past campaigns in the same way they can inspect live campaigns. With pending campaigns, the admin staff are presented with a list of all the offers that are awaiting approval. The admin staff are also sent an email when an offer is submitted for approval to let them know an offer is waiting to be approved. The admin can click on the offer and see it in greater detail. Once the admin staff member is satisfied that the offer is acceptable, in the pending offer list there are two buttons to the right of the offer, 'Approve' and 'Deny'. If the admin staff approve the offer, it goes live on the date and time set within the offer. If the offer is denied, a pop up window appears where the admin enter the reason as to why the offer was denied. This message is then sent as an email to the retailer informing them of the changes that they must make to the offer in order for it to be accepted and allowed to go live. Once the changes are made and the offer resubmitted, the admin staff go through the same process until the changes meet the criteria and comments set by system 10. ii) Clients

The second tab at the top of the page is labelled 'Clients'. When the admin staff enter this tab, there is a button in the top right of the screen that says "Add New Client". When this button is clicked, it opens up a window that asks the admin staff to enter a name and an email address. This information is provided when a retailer lodges an expression of interest on the website of system 10. When the admin member adds the name and email address and clicks 'Send Now' an email is sent to the retailer with a temporary password and a link to complete the remainder of their registration. When the client tab is clicked, it lists all of the clients and informs the admin of the number live campaigns they have running, the number of pending campaigns they have awaiting approval and the number of past campaigns that have been released. This tab is also where the admin staff can search for a specific client and check on the progress of their live campaigns in greater detail, as well as past campaigns too. It gives a brief snap shot of the campaigns progress (total collected, viewed, redeemed, budget etc.). The company details can also be accessed from this page. iii) User ID

The next Tab is 'User ID'. This is where the admin staff can bring up information about individual users (of app 140). This allows the admin staff to ascertain a user's basic information as well as history, what the user has collected, viewed and redeemed, as well as any competition entries that user has submitted. The users can also be filtered based on age, sex, location, etc. This can then be exported into a csv file for use in a range of places. iv) Sponsored Ads

The next tab is 'Sponsored Ads'. From within this section, the admin staff can control the sponsored sections within the app 140. These sponsored spaces are limited up to the first three spaces of one of; the home screen, a category or a sub-category. These three spaces bypass CSO, follows, facebook 'likes', etc. Within this section, the admin staff can deliver an existing campaign and ensure that it appears within one of the first three spaces of any given feed. Once the 'sponsored ads' tab has been selected, the admin staff first selects where the sponsored ad will appear in (which may be home screen, a specific category or a sub-category). Next, a list of dates is displayed (appearing from Monday to Sunday in 7 day blocks). The admin staff can click on the 'Add Campaign' button next to specific date(s) and select from a list of approved campaigns. The

Sponsored ads are done in 24 hour blocks but a specific campaign can appear in a sponsored block for as many days as the admin staff choose. This service is either organized through correspondence with various retailers or can be requested through the retailer portal. Available dates and blocks are presented to the retailers who can select the blocks they wish to purchase and admin then approve the purchase. If all or some of these spaces are not allocated. v) Settings

The next tab is 'Settings'. From within this section, the admin staff can view the cost per redemption price for a category or subcategory, general settings , send out targeted push notifications, release images and videos for the internal controlled offer spaces of system 10, set up geo-fences, and add new categories.

Figure 22 is a flow diagram 630 of the process for setting cost per redemption, as an example of the use of the 'Settings' tab. At 632, a member of the admin staff of system 10 logs into server 12. At 634, the admin staff goes into the category settings, where there is displayed a button in the top left hand corner labelled 'Add Category'. At 636, the admin staff clicks 'Add Category' and, in response at 638, a window opens asking for the title of the new category. At 640, the admin staff enters the title and server 12 adds it to, and displays, the list of categories with - below the added category - a button labelled 'Add Sub Category'. Next to each category and sub-category listed there is a drop down menu with prices: at 642 the admin staff selects the price as the new price for redemption within that category or sub-category. At 644, the cost per redemption thus set is applied to the campaign creator when subsequently used to create an offer, and server 12 informs the retailer (as described above) of the number of redemptions the retailer can achieve based on the cost per redemption. (However, if a campaign has already been approved or is live, the price remains that set by the admin staff when the campaign was submitted for approval by the retailer.)

Subsequently, at 646, the retailer is charged accordingly per redemption. Processing then ends.

From the 'Category Settings Tab' admin staff can also delete categories. This does not require an update on the user end, as the change will update live when a user refreshes app 140. An 'ads' tab allows the admin staff to release images and video into the feed. The admin staff can choose where these media appear by selecting one or more categories or sub-categories, or the home screen. The images and video are inserted at predefined intervals.

From the settings tab, admin can also select 'General Settings'. This allows admin to set a global cost per redemption price. This sets a price per redemption across all categories and sub categories and overrules the existing individual prices per redemption. In order to change the individual prices per category/sub category, admin must go back into the 'Category Setting' tab and change each category redemption price manually.

From within the 'Settings' tab, the 'Targeted Push' tab allows the admin staff to send out targeted or automated push notifications to users. App 140 includes rules concerning when a user can receive a push notification. These rules are periodically updated to optimize the service to the users.

Figure 23 is a flow diagram 650 of the process for issuing targeted push notifications to users. After admin staff logs into server 12 at 652, and selects the 'targeted push' tab at 654, he or she filters users by target age group, sex and location (typically selected by state, province or county) at 656. At 658, server 12 responds by displaying how many users fall within the chosen demographics. At 660, the admin staff may send out a push based on either those who have 'liked' a category or according to retailer. If the former, processing continues at 662, where the admin staff chooses a category from a list of parent categories. At 664, server 12 informs the admin staff how many users accord with the selected parameters, then at 666 the admin staff composes the push notification. At 668, the admin staff clicks 'send' to send the push notification. At 670, server 12 provides feedback to the admin staff as to whether the push was sent successfully or failed.

Processing then ends.

If, at 660, the admin staff chooses to direct the push by retailer, processing continues at 672 where he or she selects a particular retailer; at 674 a list of retailers' campaigns is displayed for the admin staff to select one or more thereof. At 676, the admin staff can choose one or more offer criteria for the push, including viewed, followed, save, redeemed, shared, and facebook 'liked'. Processing then continues at 664.

From within the 'Settings' tab, the 'Geo-fencing' tab allows the admin staff to create a geo-fenced domain (a described above), with geo-fencer 90. This can be done in two ways. Figure 24 is a flow diagram 680 of the first geo-fencing creation process, which is typically employed upon the request and payment of, for example, a shopping centre or mall. Referring to figure 24, at 682 the admin staff logs into server 12, at 684 selects the geo-fencing tab and at 686 enters the name of the new geo-fenced domain (to be displayed in place of a distance in app 140 in the top right hand corner when the user enters the geo-fenced domain or within the offer radius selection of app 140 to be discussed in detail later).

At 688, the admin staff defines the boundary of the geo-fenced domain. This can be done by selecting plural points on a map and selecting a function to joins the points - generally with straight line segments. Alternatively, the admin staff can enter a base point (as latitude or longitude, or by selection on a map) and selects a radius for the geo- fenced domain (with a modified offer radius button, in which the name of the geo-fenced domain appears followed by the distance options), or select a polygon from a menu and locate, rotate and size the polygon as desired on the map.

In still another alternative, an irregularly shaped geo-fenced domain can be defined by a plurality of circles of various sizes and locations, where in some cases the circles may overlap. All the retailers in the geo-fenced domain are then associated with all the circles, even though most will be in only one or two of them. The user may then be alerted of offers from any of these retailers in the entire geo-fenced domain even though the user is in only one or two of the circles that define the domain. This allows the administrator quickly to define the domain to a highly accurate degree. Also, even though plural determinations of a user's location are then required (i.e. relative to each of the circles that define the domain), computing overhead in doing so is low owing to the ease of determining whether a user is within a circle, since this can be done merely by determining whether the user's distance to the centre of the circle is less than the radius of that circle.

At 690, the admin staff sets up the notification to be displayed to a user when that user enters the new geo-fenced domain, and at 692 the admin staff saves the newly created geo-fenced domain to geo-fenced domains 102. Processing then ends. According to the second technique for creating a geo-fenced domain, the admin staff controls server 12 to allow a geo-fenced domain to be visible to users, even when the user is not within that geo-fenced domain. As described above, when the user clicks on the Offer Radius' button, beneath the radius options, all geo-fenced domains within 50 km of the user are displayed in order of distance from the user (nearest to furthest). This feature is also only set up only if requested and paid for by, for example, a shopping centre or mall. vi) Reports Tab

From within the admin portal, the 'Reports' tab allows admin to generate data collating results from all campaigns. This data is not broken down into individual campaigns. It represents all metrics/results from every single campaign collated into a simple report. It includes total number of campaigns, total number of views, total number of

collections/saves, total number of redemptions, total number of shares, total number of follows. Data can be broken down to represent age brackets, different locations, gender, dates, times etc. and presents this data in graph format. This data can also be exported into a pdf file.

Each time a retailer adds a store to their account, a micro geo-fence with a predefined radius is created for each store location. This allows destination push notifications to be issued to users when close to a store of interest. Pinging between mobile telephone 14 and the server 12 occurs periodically, and the user is sent a push notification should the user be found by server 12 to be in the proximity of (i.e. within the micro geo-fenced domain of) a store that they have followed, like on facebook or selected through their CSO. Rules are enforced to ensure that users are not sent push notifications on too frequent a basis. One such rule could be, for example, that users are not sent more than one destination push notification in a 24 hour period, to ensure that the app 140 does not harass the users.

As described above by reference to figure 4, app 140 can integrate with the facebook 'likes' process. Figures 25A and 25B are flow diagrams 700 and 710 respectively of the process for integration with facebook 'likes' for a user and a retailer, respectively.

Referring to figure 25A, at 702 the user signs up to system 10 through facebook. At 704, the user approves system 10 to access facebook 'likes' through the API provided by facebook. At 706, the brands the user has 'liked' on facebook are added to the user's profile via server 12 (in registered users 108), thereby enabling system 10 to deliver those brands' offers to users that have 'liked' them on facebook, and - as with 'followed' brands and companies - the 'liked' brands are given a higher priority, such as in the user's home feed of offers.

Processing then ends.

Referring to figure 25B, at 712 the retailer signs up to system 10 and, at 714, enters their facebook ID during the sign up process. At 716, the facebook ID of the retailer is linked to all offers released by that retailer. Subsequently, at 718, server 12 releases (or makes live) the retailer's offers tailored to a desired demographic, and at 720 - for each respective offer - user-offer comparator 86 determines whether the user's demographics match the desired target audience of the respective offer as determined by the retailer. If so, processing continues at 722 where server 12 sends the respective offer that the user 'liked' on facebook to the user. Processing then ends.

If, at 720, user-offer comparator 86 determines that there is not such a match between the user and a respective offer, processing ends.

It should be understood to those persons skilled in the art of the invention that many modifications may be made without departing from the spirit and scope of the invention. It should also be understood that the reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that such prior art forms part of the common general knowledge in any country.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.