Currently, there are many different virtual bonus points and credits available over the Internet, such as airline miles, ICOKE points, MICROSOFT points, YAHOO points, QQ coins, mobile phone minutes, coupons, advertising discount codes, etc. These various points, bonuses, and credits are referred to interchangeably herein both as “points” and as “digital micro-payments” depending on the context. Digital micro-payments or points are not issued in the form of cash or currency of any country or government.
One characteristic of points is that they are conventionally limited in their issuance and their redemption to a single service provider, such as a business entity, a company, corporation, advertiser, etc. As shown in
Currently in the U.S. there are some conventional services that enable users to convert, exchange, or swap their bonus points and credits. But the conversion must be done manually and individually for each transaction, and the product or service to be obtained must be still be redeemed by the corresponding type of points. For example, www.points.com enables users to convert their awarded AMERICAN airline miles to NORTHWEST airline miles. But this service does not enable the user to directly obtain a NORTHWEST airline ticket with AMERICAN miles. Additionally, the exchange program is very limited.
In another conventional exchange scenario, when a user redeems miles or points, the user does not directly receive gift cards or certificates for various merchants of the redeemable products and services, much less to the products or services themselves. Instead, the user receives a reward that can be exchanged, online, for gift cards and certificates-but only in preset denominations, such as $10, $15, $20, $25, $50, $100, $250, $500, $750, $1000, etc. When the user's redemption transaction completes, the user receives an e-mail with a link to the exchangeable reward. This e-mail typically takes three to five days to arrive. Once the email arrives, the user follows the instructions to choose gift cards and certificates. Then, after selecting a gift card or certificate, it is printed and shipped to the address specified by the user. The amount of time this takes can vary-normal shipping takes 7-10 business days.
Moreover, typically the gift cards or certificates cannot be returned or exchanged. They cannot be reissued if expired, lost, or stolen. They are fulfilled only to the address supplied on the award redemption form. The broker is not responsible for lost certificates as a result of non-delivery due to incorrect or illegible addresses or other occurrences outside of their control, etc.
Further, service providers and product vendors of the goods to be redeemed typically do not have a payment gateway for directly charging a user's points, especially points that are not issued by that service provider. There are some payment techniques, such as a FIRST DATA CORPORATION gateway, that enable service providers to collect money from users. (FDC, Greenwood Village, Colo.). But this is limited to real currency. There is no payment gateway for digital micro-payments.
Systems and methods establish a virtual points clearinghouse. The clearinghouse redeems heterogeneous digital micro-payments-such as bonus points received from various points issuers-across diverse service providers. Points meant for exclusive redemption at one service provider may be directly redeemed for non-corresponding goods of a different service provider. In one implementation, the clearinghouse includes contracts between points issuers, service providers, and a clearinghouse, including intervening conversion rates. A user interface enables a user to manage multiple point balances from a computing device, cell phone, or other mobile device. The user interface enables the user to find diverse goods and to directly obtain the goods by redeeming diverse heterogeneous points. The clearinghouse includes an invoicing engine to enable money flow between users, points issuers, service providers, and the clearinghouse.
This summary is provided to introduce the subject matter of a virtual points clearinghouse, which is further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
Overview
This disclosure describes systems and methods for implementing an exemplary virtual points clearinghouse. As shown in
As introduced above, virtual points and other bonuses such as airline miles are referred to herein as “digital micro-payments” or just “points” in some contexts. “Virtual” in the present context just means that the points are digital and/or electronic, not dependent on a physical artifact, such as cash. For example, a point or digital micro-payment can be a purchase point, referral point, reward point, bonus point, airline mile, mobile phone minute, coupon discount, promotional discount, discount code, or other virtual credit that is capable of being issued to a user or participant of a good or service, and that is not in the form of cash or a currency of any country or government.
“Digital micro-payment issuer”—a points issuer that is typically, but not always a goods provider—refers to an entity that issues points, bonuses, credits, promotional discounts, etc. Usually the digital micro-payment issuer is the same entity as the provider of the goods or service obtainable by redeeming the issued points. For example, ALASKA airlines issues ALASKA airline miles in an ALASKA AIRLINES MILEAGE PLAN. The exemplary clearinghouse, however, enables the digital micro-payments issuer and the service provider accepting redemption to be different.
“Service provider” refers to an entity that offers a “good” (i.e., a product or service) in exchange for a corresponding redemption of a predetermined type of digital micro-payment. As just mentioned, the digital micro-payment issuer and the service provider are conventionally one and the same-as the points are typically issued to promote a product or service. The exemplary clearinghouse, however, enables the digital micro-payments issuer and the service provider to be different as a matter of course.
In one implementation, the exemplary system to be described herein includes the exemplary clearinghouse that accepts numerous types of digital micro-payments in order to enable the user to directly and immediately obtain various types of products and services that do not necessarily correspond to the products and services of the points issuer. The exemplary clearinghouse also provides common/standard interfaces, e.g., for merchants to charge users.
Exemplary System
The exemplary clearinghouse 200 may also include various user interfaces 202 deployed at the user's side and suited to the user's devices (e.g., 306, 308). The user interfaces 202 facilitate secure communication, and are used for redeeming points and managing user accounts, including balances of various digital micro-payment accounts under the same user 108.
The illustrated clearinghouse 200 serves numerous users 108 and numerous service providers 102. The clearinghouse 200 includes a redemption engine 402, a user accounts manager 404, a procurement engine 406, a user interface engine 408, a goods inventory engine 410, and contracts 412 between various service providers 102 and/or between one or more service providers 102 and the exemplary clearinghouse 200.
The redemption engine 402 may further include an order input 414, which further includes a goods identifier 416 with an identifying code receiver 418 and a confirmation code manager 420; and a payment engine 422 that may further include a micro-payment identifier 424 to identify a type 426 and an amount 428 of a micro-payment.
The user accounts manager 404 may further include a user authenticator 430, a balances manager 432, a security manager 434 for protecting account transactions and changes; and user accounts 436, including points balances 438 and transaction histories 440.
The procurement engine 406 may further include an inventory querier 442, and a cost identifier 444 to determine a type 446 and an amount 448 of points needed to be redeemed to obtain a good, and/or a value 450 of the good.
The user interface engine 408 may further include a web services interface 452, and a mobile communications manager 454, including, for example, a short messaging service agent (SMS) 456 for text messaging.
The goods inventory engine 410 may further include available goods links 458-i.e., links to available goods and services to be obtained by redeeming points; an advertising engine 460, and a search manager 462.
The contracts 412 may specify conversion rates 464 between types of digital micro-payments and goods and may contain other agreements regarding scope, revenue sharing rules, etc., between service providers 102 and the clearinghouse 200.
The clearinghouse 200 includes a value translator 466 that is based on the contracted conversion rates 464 for converting costs in one type of digital micro-payment into a corresponding cost in another type of digital micro-payment.
If revenue sharing rules in the contracts 412 call for fees to be extracted from transactions or if maintenance of the clearinghouse 200 is based on a fraction of value of redeemed points (i.e., instead of determined in some non-transaction-based manner by the contracts 412), then the clearinghouse 200 may include a transaction fee administrator 468 and charge service fees. Also, a first points issuer 102 may charge a tiny surcharge of points for redeeming the points of a second points issuer 104, as specified in a contract 412 between the first points issuer 102, the second points issuer 104, and the clearinghouse 200.
In one implementation, the clearinghouse 200 also includes an invoice engine 470. The invoice engine 470 tracks point flow and redemption to enable real money exchange between users 108, points issuers 102, service providers 110, and the clearinghouse 200. The invoice engine 470 may further include point issuer accounts 472, service provider accounts 474, and a clearinghouse account 476. The invoice engine 470 has access to the user accounts 426, including point balances 438 and histories 440, in order to track users' transaction histories 440 including point redemption and refilling. The money flow is described in greater detail below.
Operation of the Exemplary System
From the standpoint of a merchant or service provider 102 offering goods 110, the service provider 102 can accept more types of digital micro-payments through the exemplary clearinghouse 200. From the standpoint of a user 108, the user 108 enjoys a variety of digital micro-payment types to obtain many different kinds of products and services not associated with the service providers 102 that issued their respective digital micro-payments. This increases the effective value each type of digital micro-payment, because each type may be used to obtain many more types of goods. Each user 108 has a larger scope for redeeming points. For example, a can of COKE can conventionally be redeemed only by 10 ICOKE points. The exemplary clearinghouse 200 may enable the user 108 to use 15 MICROSOFT points (hypothetical example) to redeem the same can of COKE. The hypothetical redemption rate that 10 ICOKE points equal 15 MICROSOFT points would be agreed on by COKE and MICROSOFT in a contract 412.
The exemplary clearinghouse 200 enables users 108 to have a central platform to redeem various digital micro-payments for a vastly improved variety of goods, compared with conventional redemption scenarios. As a gateway, the exemplary clearinghouse 200 enables a service provider 102 to charge whatever points the user 108 has on hand in his user account 426, while users 108 have a one-stop location to obtain a variety of goods using their points.
Each service provider 102 may use a single interface 310 to the clearinghouse 200 to charge a myriad of different digital micro-payments. The service provider 102 does not have to implement a different interface for each different type of point to be redeemed. The clearinghouse 200 also assists the service provider 102 to collect more points.
As shown in
The contract 412 includes conversion rates 464, i.e., between the type of digital micro-payments issued (e.g., by a points issuer 102) and the type of goods capable of being redeemed (e.g., by a second service provider 112). The value translator 466 of the clearinghouse 200 can use these conversion rates 464 to enable the direct redemption of goods that do not correspond to the type of points issued. The clearinghouse 200 may exact a transaction fee or service fee as part of the contract 412, and in one implementation collection of such service fees is executed by the transaction fee administrator 468 associated with the user accounts manager 404. As introduced earlier, conversion rates 464 also allow conversion between different types of points (e.g., a hypothetical conversion rate of 15 MICROSOFT points for 10 ICOKE points); and/or between a type of point and a currency (e.g., hypothetical conversion rate of 95 MICROSOFT points=$0.95 U.S. dollars).
In
In a typical redemption transaction, the user 108 selects goods 112 to obtain and selects points to redeem for the transaction via the user interface 202. Different user interfaces 202 may be employed depending on whether the user 108 is transacting through a computing device 306, through a mobile communications device 308, or through some other device. Example user interfaces 202 will be described in greater detail below.
The redemption engine 402 receives the user's 108 communication at the order input 414, where the goods identifier 416 signals the goods inventory engine 410 in order to identify the product or service selected by the user 108. In one implementation, the user 108 is only exposed to those goods that can be redeemed through the clearinghouse 200, while in another implementation the user 108 is free to enter any good, and the clearinghouse 200 consults the goods inventory engine 410 to determine if the proposed good is redeemable through the clearinghouse 200.
In one implementation, the goods identifier 416 can receive an identity code 418 of the desired good. The identity code 418 may be a string of alphanumeric characters entered from a website into the user's 108 user interface 202, or may be keyed in by the user 108 on the keypad of the computing device 306 or mobile communication device 308. The identity code may also be a visual code 418, such as a QR code that the user 108 captures with a cell phone camera and transmits to the identity code receiver 418. In one implementation, the identity code receiver 418 converts the QR code image into a string that identifies the product or service. In one implementation, a confirmation code manager 420 returns a code to the user 108 to verify the user 108 and/or the product 110. For example, the confirmation code manager 420 may send a code to the user's 108 mobile device 308 by SMS 456. The user 108 then enters the received code into the user interface 202 to complete the confirmation.
The payment engine 422 of the redemption engine 402 has a micro-payment identifier 424 that determines the type 426 and the amount 428 of the digital micro-payments to be redeemed by the user 108 to complete the transaction. The type 426 of points to be redeemed may depend on the user's 108 account 436, and more specifically on which type of points the user 108 has designated as highest priority for being redeemed first, i.e., when there are several types of point balances 438 in the user's account 436. It may be that the user 108 does not know how many of a given type of point to pay for a selected good. In such a case, the micro-payment identifier 424 may retrieve or calculate the amount 428 of points needed to complete a transaction-in a given denomination of points-and return the amount 428 for display on the user interface 202. The micro-payment identifier 424 can request the procurement engine 406 to obtain the cost of a good in a given denomination of points.
In one implementation, the procurement engine 406 includes an inventory querier 442 that searches a database of information about the goods. A cost identifier 444 can retrieve or calculate the cost of a good, i.e., in an amount of a particular type of points. A good may be advertised as costing a certain amount of a particular type of points, in which case the cost identifier 444 may return a type 446 and an amount 448 of points. Or, the cost identifier 444 may access information about the underlying value 450 of a good in units adopted as standard by the clearinghouse 200, and from this underlying value 450 calculate an amount 448 of points needed for a given denomination or type 446 of points. In one implementation, the value translator 466 translates the underlying value of a good into a particular denomination of points, using the conversion rates 464 in the contracts 412. Or, the value translator 466 may convert directly between different types of points using the conversion rates 464 (without resorting to the underlying value of the good stored in a database of information about the good).
The goods inventory engine 410 may compile a list of links to available goods 458 that the advertising engine 460 can post to a user interface 202. In one implementation, when the user 108 wants to procure a certain good, the advertising engine 460 sends the user 108 to a webpage of such goods that can be obtained by points redemption. The advertising engine 460 may offer more detailed pages describing goods when the user clicks or selects one of the available goods links 458. The advertising engine 460 may also post a list of friends or buddies on the user interface 202, who have purchased a type of good that the user 108 is considering for purchase.
The goods inventory engine 410 may also include a search manager 462 accessible from the user interface 202. That is, the user 108 may search from his computing device 306 or mobile device 308 to find a good to obtain.
When the redemption engine 402 has identified the good to be obtained and has identified the types 426 and amounts 428 of digital micro-payments needed to complete the redemption, then the points are withdrawn from the balances 438 in the user's account 436. Multiple types of points may be redeemed in the same transaction.
In one implementation, the user accounts manager 404 allows the user 108 sophisticated and comprehensive control over his user account 436. First, a user authenticator 430 secures the identity of the user 108. For example, a user 108 may submit a password into the user interface 202 on a mobile device 308 to gain access to his user account 436. The user 108 can program the balances manager 432 to administer the balances 438 of various points in the user account 436. The user 108 can designate a priority for each balance 438 of points in the account 436. For example, the user 108 may specify that in a redemption transaction, MICROSOFT points are to be used first, followed by UNITED airline miles, followed by COKE points, followed by mobile phone minutes. Further, the user 108 can specify automatic minimum balances 438 and/or automatic balance refilling. That is, the user 108 may specify that when MICROSOFT points get below the level of 100 points, then mobile phone minutes in a different balance 438 are to be converted to MICROSOFT points at the contracted conversion rate 464 to keep the MICROSOFT points above a threshold minimum level. Or vice versa, the user 108 might specify that MICROSOFT points are to be converted to keep the mobile phone minutes above a pre-specified minimum. The user account 436 may also allow the user 108 to view a transactions history 440.
Referring again to
Exemplary User Interfaces
The user interface engine 408 can control numerous types of user interfaces 202 in order to achieve redemption transactions through the exemplary clearinghouse 200. Those described below are examples to show some user interfaces 202 that can be extended by the exemplary clearinghouse 200. The examples shown are not meant to portray a comprehensive set of user interfaces 202 for the clearinghouse 200, because a myriad of user interfaces 202 are usable with the clearinghouse 200. For example, user interfaces 202 are available for desktop computers, pocket PC's, PDAs, cell phones, smart phones, pocket controllers for managing a mobile device at a desktop computer, etc. Combinations can also be used, such as ordering a good via an Internet marketplace website participating with the clearinghouse 200, while receiving product and payment confirmation codes over an SMS service that is active on a cell phone.
Exemplary Methods
At block 1202, a micro-payment issued for obtaining goods of a first goods provider is received. Such digital micro-payments, such as bonus points, airline miles, and other non-cash credits, are typically issued by a points provider for exclusive redemption at a specific service provider. In other words, the bonus points are meant to be redeemed only for intended products and services associated with the bonus points.
At block 1204, the micro-payment is redeemed to obtain a good offered by a different service provider than the service provider intended by the points issuer. In one implementation, since the micro-payments are typically issued for exclusive redemption to obtain intended goods, the exemplary method 1200 includes creating contracts between points issuers, service providers, and a clearinghouse in order for the points issuers and the service providers to accept each other's micro-payments. The contracts may also include conversion rates between points and services or even between the different denominations of micro-payments of each participating service provider. The exemplary method 1200 not only includes redeeming heterogeneous micro-payments for non-intended goods, but in various implementations also includes enabling the user to prioritize and charge goods to multiple bonus point balances, e.g., within a user account at the exemplary clearinghouse.
Conclusion
Although exemplary systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed methods, devices, systems, etc.