US20120252558A1

US20120252558A1 - Method for distributing promotional offers using an electronic game application

Info

Publication number: US20120252558A1
Application number: US13/219,759
Authority: US
Inventors: Ravi Shankar Mishra; Udaya Nayak
Original assignee: DOBANGO Inc
Current assignee: DOBANGO Inc
Priority date: 2011-03-28
Filing date: 2011-08-29
Publication date: 2012-10-04

Abstract

Methods are provided that allow promotional offers to be distributed through the play of an electronic game application. The method may include use of a handheld device, location-based targeting of offers such as deals, advertisements, and coupons, and offer prioritization based on user playing history. The method may involve a server through which offers are distributed. The method may include receiving requests from sponsors to create promotional offers. In some embodiments, the use of rank in a high score database may help determine which players receive a prize.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention relates generally to computer systems. In particular, the present invention relates to a method for distributing promotional offers using an electronic game application.
2. Description of the Related Art
On handheld computing devices, the play of short, simple games and the use of targeted location-based advertising have become widespread. Many mobile game applications and online browser-based games have a location-based advertising and sponsorship feature. These games allow the user to play, and in between rounds of the game, play is interrupted to display an advertisement.

SUMMARY OF THE INVENTION

A method for distributing promotional offers using an electronic game application is disclosed.
According to one embodiment, a user opens an application or web browser on a user device, preferably a mobile phone. The user device sends a request to a server for currently available potential offers. The server searches its database of potential offers from vendors based on location data for the user's account or device, where at least one of the potential offers from at least one of the vendors has a game associated with it, the play of which allows for a score to be determined that affects the offer to be made, and returns the search results as a list to the user device. Preferably, several of the potential offers have such games associated with them. A game is presented to the user through the user device, and a score is calculated at some point after play as commenced, typically at the conclusion of the game. Preferably, the score is stored in a high-score database, and an activated offer is presented to the user. The activated offer may depend on the user's rank in the high-score database. The activated offer may be presented at the conclusion of play or at a later time such as the end of a tournament, or upon the reach of a suitable score or rank, depending on how the game and potential offer are configured. Activated offers may be redeemed, for example, by way of a numeric code or barcode provided to the user, or by way of a near-field communications link from the merchant's point-of-sale terminal to the user's mobile phone.
According to another embodiment, a first activated offer is presented to players who do not meet a performance bar or rank, and a second activated offer is presented only to players who meet the performance bar or rank. The decision to award the second activated offer could be made during play, immediately after play, or at a later time such as the conclusion of a tournament, competition, or offer period.
Preferably, the server exposes a management interface to sponsors to receive requests to create, read, update, or delete potential offers, or to process redemptions of activated offers, or to view statistics about users who have attempted to receive potential offers, or to view statistics about activated offers, or to view billing information.
Preferably, the server also receives requests made over a telephone by sponsors to process redemptions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a preferred embodiment of a system for distributing promotional offers using an electronic game application incorporating applicant's invention.

FIG. 2 is a connection flow diagram suitable for use in the invention shown in FIG. 1.

FIGS. 3-7 are screen shots of five displays on user terminal 105 of FIG. 1.

FIG. 8 is a connection flow diagram suitable for use in the invention shown in FIG. 1.

DETAILED DESCRIPTION

In the present invention, “potential offer” indicates an offer that is available for one or more users to receive through play of a game. Offers may include, but are not limited to, deals, advertisements, and coupons.
In the present invention, “activated offer” indicates an offer which has been provided to a user through play of a game. “Activated offer” could also reasonably be referred to as a coupon or reward.
In the present invention, “offer code” indicates an identifier corresponding to an activated offer which a user may use to redeem an activated offer.
In the following descriptions, exemplary embodiments of the invention are shown. Reference numerals correspond to numerals from the drawings.
FIG. 1 is an overview illustrating an offer distribution system according to an exemplary embodiment of the invention.
The user terminal 105 corresponds to an Internet-connected computer or interactive device such as a mobile phone, tablet, laptop PC, desktop PC, television, or other electronic device with a web browser or an application for offer distribution. In a preferred embodiment, user terminal 105 is a smartphone. In certain embodiments multiple user terminals will be connected to the network simultaneously.
The user terminal 105 is connected to a network, preferably the Internet, through link 110. This link may be a cellular data link such as GSM (Global System for Mobile communication), GPRS (General Packet Radio Service), 1xEV-DO, UMTS (Universal Mobile Telecommunications System), LTE (Long Term Evolution), or other cellular data systems as will be apparent to one having skill in the art. The link 110 may also be a wired or fiber-optic connection, or it may use a medium-range wireless communication standard such as Wi-Fi™. The link 110 may also use a short-range standard such as Bluetooth® to relay packets through another device using any of the standard connection technologies mentioned above.
The purpose of user terminal 105 is to present potential offers, games, and activated offers to the user, and to allow users to play games to compete for offers. User terminal 105 communicates with server 120 to provide information such as authentication, gameplay, and location information; and to receive information such as lists of potential offers.
Network 115 is a network such as the Internet. In alternative embodiments multiple disparate networks may be used to connect different elements of the system. For example, in certain embodiments vendor terminal 140 is connected to server 120 via a connection involving the PSTN (public switched telephone network), but user terminal 105 is still connected to server 120 via the public Internet.
Server 120 processes offer and user information. In a preferred embodiment it receives and responds to requests for offer and user information and processing from users, sponsors, and vendors. In certain embodiments server 120 may be a cluster of servers, preferably managed by way of a load balancer, or a virtual machine to be run on a grid of servers in a cloud computing-style system. The functionality of server 120 may also be divided into multiple logical units, potentially run by independent systems. For example, social networking services may provide single sign-on functionality on an independent server; captcha services may provide captcha functionality on an independent server; user-, vendor-, and sponsor-facing components may be hosted on different servers or on mirrored servers or on a content distribution network. In a preferred embodiment, server 120 is a Windows™ or Linux™ system running a Java™ virtual machine, Tomcat™ application server to host web services to respond to REST requests using XML messages, and Apache™ web server.
Database 125 represents backend storage for the functionality of server 120. Data stored by database 125 for each user includes name, password, email, phone number, demographics including age, gender, location, sexual orientation, social network affiliation, and type of device used. Database 125 also stores potential offer information, valid locations for potential offers, targeted demographics for a potential offer, one or more games corresponding to a potential offer. For activated offers, database 125 stores information such as redemption codes, flags to indicate viewing, printing, and redemption of potential offers, creation and expiration dates, creator, and last modifier. Database 125 stores a table of high scores for a particular game, tournament, or potential offer. For potential offers, database 125 stores an identifier, sponsor ID, caption, expiration date, game type, category, description, start date, creation date, modified date, winner identification, an image, creator information, modifier information, and a flag to indicate whether the offer is active, pending, or has been won. Database 125 also stores UUIDs (serial numbers) for user devices. Database 125 also stores a table of active user sessions. Database 125 also stores a table of the types of games available. Database 125 also stores sponsor logins and passwords, vendor logins and passwords, and analytics information. Database 125 is preferably a standard relational database, but may also be a flat file or a distributed storage service such as Amazon 53″ (Simple Storage Service) or Amazon SimpleDB™, or another type of database. Database 125 may be divided into multiple locations or functionalities.
Social networking server 135 is preferably a server providing an interface such as the Facebook Connect™ platform. Social networking server 135 may act as an authentication server. Server 120 may send social networking server 135 requests for authentication for users, sponsors, or vendors, and social networking server 135 may send server 120 authentication token replies. Server 120 may also send social networking server 135 requests for posting to a wall or news feed when the user requests that a potential offer, a game, or a user's performance in a game be shared.
Sponsor terminal 130 can be any Internet-connected computer or interactive device, such as a mobile phone, tablet, laptop PC, desktop PC, television, or other electronic device with a web browser or an application. The sponsor uses sponsor terminal 130 to communicate with server 120 using an application or web application. The application or web application allows the sponsor to create, read, update, or delete offers, tournaments, and offer metadata such as demographic and location targeting. The application or web application also provides updated billing data and analytics data to the sponsor.
The vendor and the sponsor are expected to be the same entity in most cases. Sponsor terminal 130 may be used by the sponsor's marketing staff while vendor terminal 140 may be used by the sponsor's retail locations. Vendor terminal 140 is preferably an Internet connected point-of-sale terminal but could also be a PC, a mobile phone, or other device usable for computerized retail sales. Vendor terminal 140 could also be the backend of an e-commerce server. The vendor terminal 140 receives an offer code and sends the offer code to the server 120 for verification and/or redemption, preferably through a web application or XML web services API. Upon verification of the offer code by server 120, server 120 notifies vendor terminal 140, and vendor terminal 140 indicates to the vendor that the offer code is valid. Upon redemption of the offer code by server 120, server 120 notifies vendor terminal 140, and vendor terminal 140 indicates to the vendor that redemption is complete. Redemption of the activated offer using the offer code causes at least part of the value of the activated offer to no longer be usable, and information to this effect is recorded by server 120 in database 125.
Vendor terminal 140 could be replaced in some embodiments by a telephone or text message based redemption system, whereby an activated offer code is sent by the vendor in a phone call, e-mail, or text message to process the verification and/or redemption, and confirmation of the verification and/or redemption is sent back to the vendor over phone, e-mail, or text message. Alternatively, a video call could be used: in such an embodiment, scanner 145 would be a camera, and the barcode read by the camera would be sent over a standard video calling system such as IMS (IP Multimedia Subsystem) to server 120. Server 120 would then decode the barcode and process the verification of redemption. Barcodes used may be one-dimensional or two-dimensional, and may also use a multi-colored data storage system such as the Microsoft® Tag standard.
Scanner 145 is optionally included in a preferred embodiment. It may be integrated with vendor terminal 140 or implemented as a separate unit. This scanner allows the user to present a token such as a printed barcode or user terminal 105 in order to redeem an activated offer. Scanner 145 preferably reads a barcode representing the activated offer code from the user device. Scanner 145 may also optically read from paper, such as a printed email or web page in which the offer code was distributed to the user as a barcode or number. Scanner 145 preferably also has near-field communication functionality, where software on user terminal 105 such as the offer-distribution application provides scanner 145 with an offer code wirelessly. This near-field communication functionality could be implemented using standards such as ECMA-340, ECMA-352, or FeliCa™.
FIG. 2 is a connection flow diagram suitable for use with the exemplary embodiment of the invention shown in FIG. 1. FIG. 2 illustrates the connection between user terminal 105 and server 120 during a typical gameplay scenario.
The user initiates the gameplay process by launching a gameplay application on user terminal 105, or by navigating a web browser on user terminal 105 to a predetermined web address.
Step 205 is executed if the user does not have an account set up. The user enters personal account details such as name, password, phone number, preferred location, and demographic information into user terminal 105, and the user triggers the account creation.
Upon receiving this trigger, the user-entered account creation details are sent to server 120 in step 210. Server 120 creates the account, stores the account details in database 125, and sends an account creation confirmation to user terminal 105 in step 215.
Step 220 is executed when the user already has an account. The user enters a username and password into user terminal 105 and causes the login request to be sent to server 120 in step 225. If the credentials provided are valid, a login confirmation is returned to user terminal 105 in step 230. Alternatively, a third-party social networking service may be used for authentication and identification, in which case a multiparty authentication process involving social networking server 135 would be caused. In the preferred embodiment, user terminal 105 stores a login cookie so that repeating the login process should not usually be necessary.
Step 235 is executed to get device location to send to the server. In some cases this device location may be disabled by the user or unavailable, in which case a request with no location or a request with a location previously entered by the user may be sent. A request for potential offers, preferably including the location, is sent to server 120 in step 240. Server 120 processes this request, searches database 125 for potential offers filtered by the given location, and returns the potential offers in step 245 to user terminal 105. The response of step 245 preferably includes information such as category, description, and an identifier of an associated game. Server 120 may also include offers without a location constraint in the response of step 245. If no location was provided in step 240, server 120 may either return only offers without a location constraint, or alternatively use a previous user location from database 125 or estimate the user's location by sending the user's IP address to a geolocation service. In step 240, the server may also consider the user's playing history and use this data to return prioritization information with the list of offers. This prioritization information would reflect which offers are most likely to be of interest to the user. Prioritization information could be determined by simple techniques such as monitoring which categories of offer the user most commonly plays for over time, or it could use machine learning or other statistical techniques to correlate specific offers to other offers in terms of shared interest by the same user.
In step 250, potential offers are displayed on user terminal 105, preferably in a flickable grid format. Potential offers may be color-coded or sorted by category. If prioritization information was returned by the server, the highest-priority potential offers may be sorted so that they are displayed first or may be shown in a separate area.
In step 255, the user selects a potential offer to pursue. Preferably, the user can select one of these potential offers by tapping, whereupon a detail window opens to display more detail (preferably including information such as a potential offer end time) and the user can decide whether to play the game. In a preferred embodiment, this window also provides a link to a high score list (or “leaderboard”). If this is requested it may be downloaded in steps 260 and 265. In some embodiments the leaderboard is automatically downloaded and displayed on user terminal 105 at the end of a game.
In step 270, a game, preferably time-limited, associated with the selected potential offer is presented to the user. In certain embodiments, user terminal 105 will download skinning images or gameplay customization settings for the game from server 120 specific to the particular offer selected. This is expected to help promote the sponsor and the sponsor's products.
In step 275, a result of the game, preferably including at least one score, is sent to server 120. In step 280, server 120 stores this result in database 125. In step 183, server 120 generates an activated offer and offer code to send to the user terminal 105 in step 285. This activated offer and offer code may be conditional on performance or rank. For example, a pizza company sponsor may provide a free pizza to anyone who scores over 200 points, or who ranks within the top 5 players.
In step 292, generation of an activated offer is postponed until the conclusion of a potential offer time period or tournament. This would occur in situations such as where the sponsor has chosen to give prizes to the top 5 players on Tuesday, and the final results will not be known until the relevant time period has lapsed. In step 295, the delayed offer generated and sent to the user in step 298. User terminal 105 then displays the activated offer in step 299.
In steps 285 and/or 295, the offer code may be sent to the user through several means. It may be sent as a barcode, for example, or as a code for use over NFC connection, or as text, or as a number. It may be sent to the user's email account, as an SMS to a mobile phone, through a notification architecture such as that provided by Apple iOS™, or an XML-based web service connection. In a preferred embodiment, all of the communication links in FIG. 2 take place over an XML-based web service connection.
In one embodiment, multiple users can link their accounts, similar to a social network, to merge their scores in a game or tournament. This allows multiple people to work together to win a game and has the benefit of encouraging viral marketing of the sponsors' products. In this case, the users would indicate to user terminal 105 the account to link to, and this would be sent by user terminal 105 to server 120 and stored in database 125. Server 120 would take these linkages into consideration when determining users' scores and winners of competitions. These linkages may also require confirmation from the user being linked to prior to going into effect; this confirmation could be requested by way of an automatic e-mail, an SMS, or a mobile notification architecture.
In a preferred embodiment, a settings screen is provided on user terminal 105 where location settings can be set. The user can enter a default location, turn real time location reporting on or off, and set a radius in which to search for offers.
In a preferred embodiment, server 120 exposes an XML web service API, or alternatively a web application, for creating, reading, updating, and deleting potential offers. Through this API, server 120 receives a request from sponsor terminal 130 to create, read, update, or delete a promotional offer. Server 120 then stores in database 125 information such as timing information, location information, a selection of one or more games suitable for play by one requesting a promotional offer, game configuration, images to skin a particular game with promotional messages, and offer information such as the discount or reward which comes with the offer. Server 120 also may provide analytics data to XML web service clients upon receiving a request therefor, potentially including information such as number of users playing, time of day playing, location of users, and other analytic information as is typically available in advertising platforms.
In a preferred embodiment, when an offer is displayed, the user is provided an option to share it over a social network. Upon the user's selection of this option, a message is sent to server 120 or social network server 135 to cause this sharing.
In a preferred embodiment, if a user is logged into the user's account, preferably through user terminal 105, and sends a request for pending activated offers to server 120, server 120 will respond with a list of pending activated offers in the user's account.
FIG. 3 is a screenshot of a display on user terminal 105 of FIG. 1 in step 250 of FIG. 2. Area 305 is a tiled display of the potential offers for the present location. Each of these offers preferably shows a category, title, and offer. In addition, in some embodiments each of these offers could show a distance from the user terminal's current location. Button 310 causes user terminal 105 to display a map view of the offers by location. Button 315 causes a category view to be displayed to allow the user to filter potential offers by category. Button 320 opens a view of offers the user has won or competed for. Button 325 opens the settings screen. Button 330 allows the user to change account details.
FIG. 4 is a screenshot of a display on user terminal 105 of FIG. 1 in step 270 of FIG. 2. This figure depicts a slot machine-style game. Area 405 displays an advertisement fetched from a server. Area 410 shows the time remaining to play the game. Area 415 shows the top score as fetched from server 120. Area 420 shows the reels; certain combinations of reels increase the user's score and others (three lemons, for example) decrease the user's score. The user's score is shown in area 425. Button 430 causes the reels to spin and the score to be updated based on the ending position of the reels. Button 435 ends the game and goes back to step 250. If button 435 is not pressed before time expires, the process continues to step 275.
FIG. 5 is a screenshot of a display on user terminal 105 of FIG. 1 in step 270 of FIG. 2. This figure depicts a spinning wheel-style game. Area 505 displays an advertisement fetched from a server. Area 512 shows the time remaining to play the game. Area 510 shows the top score as fetched from server 120. Area 520 shows the wheel; the ending position of the wheel can increase or decrease the user's score based on the markings on the wheel. The user's score is shown in area 515. Button 525 causes the wheel to spin and the score to be updated based on the ending position of the wheel. Button 530 ends the game and goes back to step 250. If button 525 is not pressed before time expires, the process continues to step 275.
FIG. 6 is a screenshot of a display on user terminal 105 of FIG. 1 in step 270 of FIG. 2. This figure depicts a scratch-and-win-style game. Area 605 displays an advertisement fetched from a server. Area 612 shows the time remaining to play the game. Area 610 shows the top score as fetched from server 120. Area 620 shows the scratch card; the numbers under the scratched squares increase or decrease the user's score by the marked amount. The user's score is shown in area 615. To scratch a circle on the scratch card, the user can tap in area 620. Button 630 ends the game and goes back to step 250. If button 630 is not pressed before time expires, the process continues to step 275.
FIG. 7 is a screenshot of a display on user terminal 105 of FIG. 1 after playing a game. In the embodiment depicted, area 715 displays a high-score list fetched from the server in step 360 and 265. Area 710 displays the user's score from playing the game in step 270. Button 720 triggers step 290, display of the activated offer. Area 705 displays an advertisement fetched from a server. Button 725 exits the game screen and goes back to step 250 or step 270, as desired.
FIG. 8 is a connection flow diagram suitable for use with the exemplary embodiment of the invention shown in FIG. 1. FIG. 8 illustrates the connection between vendor terminal 140 and server 120 during a typical redemption scenario. Connections take place preferably through an XML web service API or alternatively through non-web service HTTP connections (such as in a web application) or potentially a remote communication system other than HTTP. In some embodiments, a telephone, SMS, or email interface may accept requests for validation and redemption of activated offers rather than vendor terminal 140.
In step 805, the vendor terminal receives an offer code. For example, this can be input manually by the vendor, or automatically from scanner 145.
In step 810, the vendor terminal receives input specifying that the activated offer should be validated. In some embodiments, validation could be performed automatically in response to receiving an offer code, and in other embodiments the validation may not be performed at all.
In response to the request for validation, in step 815 a request for validation of the activated offer, containing an offer code, is sent to server 120. In step 820, server 120 queries database 125 to see if the offer is valid and what it can be redeemed for. This result is sent back to the vendor terminal in step 825 and is indicated to the vendor in step 830. Step 830 may comprise visual or audio indication of the validity of the offer.
In step 840, the vendor terminal receives input specifying that the activated offer should be redeemed. In some embodiments, redemption could be performed automatically in response to receiving an offer code. In response to the redemption input, a request for redemption of the activated offer is sent to server 120 in step 845.
In response to the request for redemption, in step 850 server 120 queries database 125 to see if there is enough residual value to fulfill the amount of the request for redemption. If there is enough value, server 120 deducts the amount of the request from the value remaining in the activated offer and stores the new value in database 125. This storing causes at least part of the value of the activated offer to no longer be usable.
In step 855 server 120 causes billing of the sponsor. In a preferred embodiment some vendors may elect to pay for the distribution of offers based on the number or value of offers redeemed. In this case, it is important to mark information about redemptions in database 125 so that the sponsor can be correctly billed. This could be accomplished in several ways: the sponsor's account could be updated in database 125 after each redemption, or the redemption of the activated offers could simply be indicated in database 125 after each redemption, with billing calculated at a later stage. In any case, this update of database 125 would cause the sponsor's account to be charged a certain incremental amount, potentially depending on the type of redemption. In an alternative embodiment a vendor may choose to pay based on offers awarded rather than offers redeemed; in such an embodiment server 120 would calculate billing responsive to the activation of offers.
In some embodiments the billing to the sponsor responsive to the redemption comprises either the majority or the entirety of the charges billed to the sponsor for the distribution of offers.
In step 860, server 120 causes an alert to be sent to the user. This could be sent using e-mail, SMS, or a notification mechanism such as that implemented in mobile operating systems such as Apple® iOS. Some embodiments do not include this alert. This alert could be enabled or disabled by a user preference. The alert reduces fraud by alerting the customer if a redemption happens to be made fraudulently by another party who has obtained the user's offer code.
In step 865, server 120 sends a response to vendor terminal 140 to indicate whether or not the redemption was successfully completed. In step 870, vendor terminal 140 indicates to the vendor through a visual or auditory indication whether or not the redemption was successful. If the redemption is successful, the vendor can then provide the product or service offered in the activated offer to the user.

Claims

1. A method for differentially distributing promotional offers, comprising:

a. receiving a request for currently available potential offers for a user;

b. transmitting a list of potential offers from vendors based on location data for the user's account or device, wherein at least one of the potential offers from at least one of the vendors has a game associated with it, the play of which allows for a score to be determined that affects the offer to be made;

c. determining or receiving a resulting score for the user's play of such game; and

d. giving a currently available potential offer to the user wherein the offer given is dependent at least in part on the rank of the user's score in comparison to other users' scores in the play of such game.

2. The method of claim 1, in which said transmitting includes at least two potential offers, each from different vendors, and each having a game associated with it, the play of which allows for a score to be determined that affects the offer to be made.

3. The method of claim 1, which additionally includes the step of giving a delayed offer after a delay.

4. The method of claim 1, in which said transmitting step comprises including category information for at least one of the potential offers.

5. The method of claim 1, in which said transmitting step comprises including information based on the user's playing history.

6. A method for accepting promotional offers for distribution comprising:

a. receiving a request from a sponsor to create a promotional offer;

b. storing in a database

(1) timing information,

(2) location information,

(3) a selection of one or more games suitable for play by one requesting a promotional offer, and

(4) offer information,

all related to the promotional offer; and

c. distributing a promotional offer using data from each category stored in said storing step.

7. The method of claim 5, wherein said storing of the offer information comprises,

storing the offer information to include one offer to be given to game players who do not meet a performance bar, and a separate, second offer to be given only to game players who meet a performance bar.

8. The method of claim 5, wherein said storing of the offer information comprises,

storing the offer information to include one offer to be given to game players who do not meet a performance bar, and a separate, second offer to be given only to game players dependent on their rank relative to other game players.

9. A method for providing a promotional offer to a user, comprising:

a. receiving a list of currently available potential offers from a server;

b. presenting a location-filtered list of currently available potential offers to a user;

c. receiving a selection of a currently available potential offer from the user;

d. presenting a game to the user based on the selection;

e. transmitting a score of the user in the game to a server;

f. receiving an activated offer from the server, wherein the choice of the activated offer is based at least in part on the score; and

g. presenting the activated offer to the user.

10. The method of claim 9, wherein said presenting a location-filtered list takes place through a touchscreen display on a mobile device.

11. The method of claim 10, wherein said mobile device is a cellular phone.

12. The method of claim 9, wherein said presenting a location-filtered list takes place on a map display.

13. The method of claim 9, wherein the choice of the activated offer is determined by whether or not the user had the highest score.

14. The method of claim 9, wherein said presenting a game step comprises presenting a slot-machine-style game.

15. The method of claim 9, wherein said presenting a game step comprises presenting a spinning-wheel-style game.

16. The method of claim 9, wherein said presenting a game step comprises presenting a scratch-and-win-style game.

17. The method of claim 9, wherein said receiving an activated offer step comprises receiving a delayed offer after the game has been concluded.

18. The method of claim 9, wherein the location-filtered list is filtered or sorted based on the user's playing history.

19. A method for accepting promotional offers for distribution comprising:

a. receiving a request from a sponsor to create a promotional offer;

b. storing in a database information related to the promotional offer;

c. distributing an activated promotional offer to a user based on a result of gameplay;

d. receiving a request for redemption of the activated promotional offer from a vendor terminal;

e. processing redemption of the activated promotional offer; and

f. responsive to the redemption, billing a charge to the sponsor.

20. The method of claim 19, wherein said billing a charge to the sponsor responsive to the redemption comprises the majority of the charges billed to the sponsor for the distribution of offers.

21. The method of claim 19, wherein said billing a charge to the sponsor responsive to the redemption comprises the entirety of the charges billed to the sponsor for the distribution of offers.

22. The method of claim 19, wherein in said receiving the request for redemption comprises receiving a request for less than the full value of the activated promotional offer, and a portion of the balance is retained for subsequent redemption.