SYSTEM AND METHOD FOR REMUNERATION IN EXCHANGE FOR PARTICIPATION IN QUALIFYING EVENTS
1. A system for providing users/viewers of a qualifying event remuneration by participation in a qualifying event, said system comprising:
- an internet interface for interacting with a plurality of users/viewers of a qualifying event and a plurality of third party advertisers;
an account database; and
a token generation module that generates an authentication token that is delivered to said authentication token to a third party advertiser after a user/viewer logs into said system and encounters said qualifying event presented by said third party advertiser,wherein after said user/viewer completes said qualifying event, said third party delivers an authenticated said authentication token to said system, andwherein said system subsequently remunerates said user/viewer in an account associated with said user/viewer in said account database, said third party advertiser compensating said system for said remuneration.
The present system provides a user remuneration in exchange for participation in a qualifying event. The system has an internet interface for interacting with a plurality of users and a plurality of advertisers, an account database; and a token generation module. The token generation module is configured such that when a user encounters a qualifying event on the internet as presented by the advertiser, the token generation module, upon login by the user, delivers an authentication token to the advertiser. When the user finishes the qualifying event, the authentication token is authenticated by the advertiser and returned to the system, such that the system can account for a remuneration for the user to be credited in an account associated with the user in the account database.
- 1. A system for providing users/viewers of a qualifying event remuneration by participation in a qualifying event, said system comprising:
an internet interface for interacting with a plurality of users/viewers of a qualifying event and a plurality of third party advertisers; an account database; and a token generation module that generates an authentication token that is delivered to said authentication token to a third party advertiser after a user/viewer logs into said system and encounters said qualifying event presented by said third party advertiser, wherein after said user/viewer completes said qualifying event, said third party delivers an authenticated said authentication token to said system, and wherein said system subsequently remunerates said user/viewer in an account associated with said user/viewer in said account database, said third party advertiser compensating said system for said remuneration.
- View Dependent Claims (2, 3, 4, 5, 6, 7, 8)
This application is a continuation of U.S. patent Publication Ser. No. 15/171,590, filed on Jun. 2, 2016, which in turn claims priority to U.S. Provisional Patent Application No. 62/169,866, filed on Jun. 2, 2015, the entirety of which are incorporated by reference.
The present arrangement is directed to a system and method for the exchange of funds and/or remunerative distributions (e.g. coupons). More particularly, the present arrangement is directed to a system and method for the transfer of funds and/or remunerative distributions to a user in exchange for engaging in a participating event.
In the area of advertising, particularly on-line advertisements such as banner advertisements, pop-up advertisements, video advertisements, email distribution advertisements, etc . . . , maintaining the attention of the user is considered critical. Often advertisements are skipped, passed over, or otherwise overlooked. This is particularly true in the on-line environment where, unlike traditional television, the audience is not captive and is easily able to either avoid viewing the advertisement or can move to another screen quickly.
The present arrangement provides a system and method for delivering funds and/or remunerative distributions (e.g. coupons) to a user which in this application is referring to an on-line user that is observing one or more advertisements.
In this respect, the user generates a single remuneration account including an electronic deposit account, possibly denominated in bitcoin or other electronic currency, where a user can collect rewards or otherwise be paid for various advertising views on different applications or websites. The system entails a common account that can be utilized by many different applications and websites, but from the user'"'"'s side only requires maintaining a single account.
Moreover, the method of delivering remuneration and/or funds to the account is able to utilize a token/authorization model, where the system generates a unique user identifying token for each transaction with an advertiser so that when the user has completed the required task with the advertiser the system can receive the token along with a remuneration or given funds amount. This allows the system to properly credit the user'"'"'s account in an authenticated manner. Such a system may moreover be employed to allow many different advertisers to submit payments to users/viewers in an authenticated manner without the system ever disclosing the account information of the user to the advertiser.
The present invention can be best understood through the following description and accompanying drawings, wherein:
The present example shown in
It is noted that nothing in
As explained below, system 10 generates and uses tokens 100 which are provided to advertiser 40 that identify user 30 within system 10. Token 100 is an encoded digital identifier, each of which is unique, and also each uniquely identifying a particular user 30 of system 10. After the requirements of advertiser 40 are met by a particular user 30 visiting a web advertisement, survey or other such material at advertiser'"'"'s web site or an advertisement managed/produced/and-or distributed by advertiser 40 (e.g. user 30 views advertisement), advertiser 40 can return a token 100 to system 10 along with a remuneration amount and system 10 can credit an account of user 30 accordingly.
For example, as shown in
At step 208, once user 30 has completed the reward activity and advertiser 40 authenticates this at step 210, token 100 is returned to system 10 at step 212. At step 214, token 100 is processed by token authentication module 20 along with a remuneration amount and system 10 credits the appropriate user account in user database 14 and debits the appropriate advertiser account in account database 18.
This token process is repeated every time any user 30 logs in with an advertiser 40 with a new and unique token 100 each time. The same process may be used for all advertisers 40 associated with system 10 allowing a user 30 to use one single account with system 10 to receive rewards in a central location rather than with each of the advertisers independently.
In summary, a user 30 may generate an account with system 10 and then view an advertisement managed by advertiser 40, such as at their website. At the advertisement, user 30 logs into their system account and system 10 generates and delivers a user identifying token 100 to advertiser 40. This token 100 is simply an authentication code that will later allow system 10 to account for the remuneration of user 30. Once token 100 is received by advertiser 40, user 30 then proceeds to the advertiser'"'"'s desired activity. Such activity could be filling out a questionnaire, viewing an advertisement during a game etc. . . . . Regardless of what is done, advertiser 40 tracks the completion of the task and returns token 100 to system 10 with a given compensation to be accounted to user 30. System 10 receives token 100, authenticates its validity and then applies the amount of remuneration to the user'"'"'s account linked with the returned token 100. Thereafter system 10 may bill advertiser 40 or otherwise perform the required accounting.
Such a system as described herein allows external services (advertisers 40), programs, websites, mobile apps and in general any device that can run on a regular web browser, to connect to the user accounts of system 10 to request rewards for actions completed on such external platforms.
System 10 may use the “OAuth” authentication protocol to allow users 30 to create system accounts or to use their existing accounts to allow the application/advertiser 40 to use their information and request rewards on their behalf. One advantage of using OAuth authentication is to allow users to grant permissions to request rewards on their behalf to the application/advertiser 40, without disclosing their system credentials to the application/advertiser 40 itself.
When the “OAuth” login process is completed, application/advertiser 40 possesses a token 100 which uniquely identifies user 30 for this application and can be used for further communication with system 10 on behalf of this user 30. An external application 40 may be registered on system 10 to be authorized to request rewards. That application 40 may own a pre-paid budget on the owner'"'"'s account on system 10 which is used to reward users 30.
In some situations there are two kinds of advertiser/applications 40: trusted and not-trusted. A trusted application 40 is an advertiser application 40 that cannot be tampered with and is not subject to a man in the middle style of attack, such as a webserver hosting a website. When a trusted application 40 requests a reward on behalf of their own user 30, the trusted application 40 has the duty of deciding whether it really wishes to reward user 30 for the action taken.
For example: if an advertiser/website 40 wants to reward a user 30 for filling out a questionnaire, it can analyze the data submitted by user 30 and ensure it is complete and thorough. After deciding the reward is due, the trusted application 40 establishes a server-to-server connection to system 10 and requests a reward for user 30 who completed the questionnaire by sending their token 100 and the amount requested. The system only checks the advertiser/application for credit and credit limits and sends the reward to user 30. See for example
In another embodiment, advertiser/applications 40 subject to MITM attacks are considered untrusted. Therefore, their rewards should be authorized by a server. In the example below in
For example: a game advertiser application 40 may request rewards on average every 15 to 20 seconds. Every time a reward is requested, the progress of user 30 is sent along with the request and a server-side service at server 50 that keeps track of it. If a reward is requested too often or the progress is not compatible with the progress of user 30 (skipped levels, high level right after a death, and similar) then the reward is not authorized. This discourages cheating and botting because the results would be just about the same as the ones achievable by not botting at all. This kind of advertiser/application 40 should also set daily limits to gainable rewards, as should all advertiser/applications 40 that try to monetize the rewards API by showing ads and sharing the advertisement revenue, because of limited advertisement inventory and limits on per-user advertisement views.
Although the above examples show system 10 being used for “advertisers” 40 it is contemplated that system 10 can be used by any entity looking to distribute funds or otherwise attract funds for donations etc. . . . . For example an entity 40 that is an advertiser may wish to donate funds to a charity/awareness campaign but simultaneously raise awareness of the donation campaign as a form of advertising. In the prior art, the advertiser/donator would set aside some funds to donate (possibly matching funds to match against donations from the public) but a portion would be used to advertise the donation event so that the public would be aware of the donation campaign. Using the present system 10, users 30 of system 10 may be notified of a campaign of advertiser/donator 40 and may be prompted to participate in a questionnaire or review of a short advertisement about the donation. Using the present system 10, user 30 would log in and a token 100 would be issued to advertiser 40 and after user 30 performs the desired task advertiser 30 would return token 100 to system 10 which would acknowledge to user 30 that the donation has been made on their behalf in exchange for viewing the awareness campaign.
Such an arrangement reduces the need for the advertiser/donator 40 to promote the campaign and it incentivizes users 30 to directly engage in the awareness campaign as they see their donation as a direct feedback to viewing a video or whatever else the advertiser/donator requests.
Such an arrangement as described above:
1) improves the conversion rate of advertiser 40 campaigns (ADs, remarketing and more), resulting in an overall cheaper marketing strategy by rewarding users 30 part of the budget which would otherwise be given to the ad company providing the click;
2) improves usage rates of mobile apps by rewarding users 30 with a fraction of the advertisement revenue of the advertiser/application 40 itself collected from various different sources; and
3) provides users 30 with a centralized wallet where they can receive all their rewards from third party apps 40 and ways to retrieve them in the form of bitcoin, paypal credit, coupons, donations to popular charities and more.
While only certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes or equivalents will now occur to those skilled in the art. It is therefore, to be understood that this application is intended to cover all such modifications and changes that fall within the true spirit of the invention.
Such a system may moreover be employed to allow many different advertisers to submit payments to users/viewers in an authenticated manner without the system ever disclosing the account information of the user to the advertiser.