Patent Application
20060259361
The invention relates to systems and methods for implementing mobile loyalty programs for decreasing customer chum and increasing customer spend.
As more customers adopt pre-paid services and mobile phone number portability becomes more commonplace, customer loyalty will become an even bigger problem for mobile carriers and mobile content providers as customer churn is poised to show a significant increase in the coming years.
Ultimately, carriers and content providers want to develop and cultivate their customer relationships to decrease customer churn, decrease the cost of acquiring new customers, and increase customer spend.
Accordingly, there is a need for systems and methods for implementing mobile loyalty programs that achieve these goals.
The present invention provides a Mobile Loyalty and Community Service (MLCS) that decreases customer churn and increases customer spend.
In an embodiment, the MLCS provides an event driven platform based around the concept of sticky accounts. The MLCS issues tokens, currencies, loyalty points and other value assets to customers based on definable user activities (e.g., voice spend, text spend, game purchases, in-game events such as high score, forwarding promotional messages to friends, etc.), and stores these assets into customer accounts. Each of these accounts is made sticky by associating it with the mobile carrier and the customer's phone number, and deleting assets in the account if the customer switches to another carrier. The accumulation of assets in the sticky accounts and the stickiness of the accounts increase customer loyalty to the carrier, thus decreasing customer chum.
In an embodiment, the MLCS issues loyalty points to customers for making purchases (i.e., customer spend) including purchases for voice minutes, text, ringtones, mobile games and other purchases. Customers can redeem these points for valuable prizes from a Web or WAP based prize catalog or entry into sweepstakes. The prizes may include mobile products (e.g., free voice minutes, free games, free ringtones, etc.) as well as physical goods. By issuing loyalty points to customers for making purchases, the MLCS encourages customers to spend more, thus increasing customer spend. In an embodiment, the MLCS is integrated with the billing system of the carrier to receive reports of customer purchases (voice, text and other purchases), and issues points to the customer based on the reported purchases. The MLCS may receive these reports in batches (e.g., once per day) from the carrier.
In an embodiment, the MLCS issues points to customers based on in-game events for mobile games. The in-game events may include game scores, reaching a new level on a game, etc. The customers can redeem these points for valuable prizes from a Web or WAP based prize catalog. By issuing loyalty points based on in-game events, the MLCS motives customers to play the game more and to spend more on games, thereby increasing customer spend, and discourages customers from purchasing games elsewhere, thereby decreasing customer churn.
In an embodiment, the MLCS provides tokens that customers can purchase, store in their accounts, and redeem to play pay-per-play games (e.g., one token per play). The play-per-play games provide revenue to the carrier each time a customer plays a game by requiring one or more tokens for each game play. By issuing points based on in-game events for the pay-per-play games, the MLCS motivates customers to play these games more frequently, thereby increasing customer spend. Further, the pay-per-play nature of the games encourages customers to try out new games at a lower cost than outright purchase of the games.
In an embodiment, the MLCS provides a tournament service for community play with prizes attached. In this embodiment, the MLCS allows carriers or others to setup gaming tournaments for a particular game. During the tournament, the MLCS receives customers' scores for the game, and posts the top scores on a leader board (e.g., on a Web site or in the game on the handset). When the tournament is finished, the customers with the top scores receive points that they can redeem for valuable prizes, e.g., on a Web or WAP based prize catalog. The tournaments motivates customers to play the game for the opportunity to win prizes and gain recognition among their peers, thereby increasing customer spend. The MLCS may invite customers to the tournament by sending (Short Message Service) SMS messages to their mobile handsets.
In an embodiment, events are communicated between peers in the MLCS network based on a publish/subscribe model, in which publishers can publish events to a topic and subscribers to the topic receive the published event via an event router. For example, a game application on a customer's handset can communicate an in-game event (e.g., level reached within the game) to an MLCS server by having the game application publish the event to a specific topic on the event router and the MLCS server subscribe to that topic. Similarly multiple handset users may have expressed an interest in and subscribed to a specific topic. When the MLCS has information relevant to that topic it publishes the event to the topic and each of the subscribed handset application receives the information. The publish/subscribe model is used to communicate events between peers on the MLCS network, including between a customer's mobile handset and an MLCS server.
In an embodiment, the MLCS provides an automatic user registration service that does not require user intervention or manual steps. When a customer downloads an application (e.g., game application) from the MLCS onto his mobile handset and runs the application for the first time, the application looks for a registration flag in storage of the handset to determine whether the customer is already registered with the service. If not, then the application stores a user ID in storage of the handset and sends the user ID and other relevant data to a MLCS server. In response, the MLCS server registers the customer with the MLCS and creates an account for the customer. If the registration is successful, then the server sends a registration confirmation to the handset, and the application sets the registration flag in the storage of the handset.
Once the customer is registered with the MLCS, the MLCS tracks the game playing and buying habits of the customer. This allows the carrier to know the game playing and buying habits of their customers and to up-sell its customers based on their game playing and buying habits. In an embodiment, the MLCS automatically sends SMS messages to customers containing special offers or other promotional information based on their buying habits. The MLCS may also give the customers a reward (e.g., loyalty points) for forwarding these message to friends. The MLCS may also give the customers the option to opt-in to receive promotional information via SMS messages or e-mails, and offer customers a sign-up reward (e.g., tokens) as an incentive to opt-in.
Other systems, methods, features and advantages of the invention will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description.
1 Introduction to the Mobile Loyalty and Community Service (MLCS)
The Mobile Loyalty and Community Service (MLCSS) is a combination point management system and prize catalog management platform that enables application level events for issuing, redeeming and sharing tokens of any type. These tokens may include loyalty points, gaming tokens (for pay-per-play games, subscriptions, tournaments), gaming characters, or coupons that can be redeemed for prizes.
Point Management System—MLCS provides an event driven platform for storing points, currencies, tokens, coupons, etc. based upon definable user activities (e.g., voice spend, text message spend, game purchases, in game events such as a high score, etc). The system manages user loyalty accounts on behalf of the carrier. Rewards are generated for user spend by integrating with carrier reporting systems to do batch based point rewards for reported purchases. Market studies show that this can have a dramatic impact on customer spend (ARPU) for core services (e.g. voice). MLCS integrates with mobile applications like games to issue, redeem or trade these points via application definable events such as high scores, reaching a new level in a game or reaching a certain level on a tournament leader board, etc.
Prize Catalog Management—The system works with carriers to create a customized loyalty marketing solution. MLCS includes a customizable Web or WAP based redemption and prizing catalog system including support for digital and physical goods. Products can range from simple mobile content giveaways like ringtones and games to free voice minutes, text messages and handset upgrades or non-mobile products such as gift certificates, trip giveaways, concert/sporting tickets and special sweepstakes.
As will be discussed more filly below, the MLCS provides:
The MLCS platform serves the carrier by increasing customer spend and decreasing churn. The MLCS provides the following benefits to a carrier:
Increase Customer Spend
Customer spend is increased by issuing points, loyalty points, to customers for making purchasing and allowing the customer to redeem the points for prizes in a catalog or entry into sweepstakes.
Decrease Customer Churn
Customer chum is decreased by creating sticky accounts and rewarding customers for forwarding promotional information to their friends.
This section provides examples of applications of the MLCS. More detailed implementations of these examples are given later.
MLCS Powered Games
1 Points For Purchase (From Within A Game)
User buys a game from a carrier. The game issues an event to the MLCS upon launch to credit the user with points, e.g., 25 points, as a reward for the game purchase (points are only rewarded once per purchase). It is assumed that the carrier is not involved in the point transaction. User receives a text message from the MLCS for the point award.
2 Points For Reaching A Level Within A Game
After the user finished a game, the game issues an event to the MLCS announcing the game's score. If the score qualifies for points based on the game's score, then the user is awarded points and receives a text message for point award.
3 Points For Reaching The Top 100 Players For The Week
Every service enabled game has a top 100 players of the week list, which shows the scores of the top 100 players for the current week. The list is updated in real-time as new scores come in and old scores are pushed off the list. On Monday at 3 AM EST, the Top 100 players for the previous week receives awards points (according to a specific formula) along with a congratulatory text message. Other numbers of top players (e.g., Top 10) and time periods (e.g., a day) may be used.
4 Multi-Player Card Game Via Web
The MLCS allows multi-player card games, e.g., hearts, poker, spades, etc. All player moves are transmitted via a standard event model to the MLCS which then publishes the events back to the players (i.e., subscribers). These games can also be integrated with the SWP or Tournament use cases as defined below.
5 Time. Duration Tournaments With Leader Board And Prizes
Any game described in this document can be turned into a tournament. Every tournament has its own leader board accessible from the web and the mobile game itself. The leader board lists the top scores received from users and is updated in real time as new scores come in. No new scores are accepted on the leader board when the tournament finishes. Every game play results in a score being published to the tournament.
The tournament host can set-up new tournaments and define point prizes via a web based interface.
Comments
1 Buy Tokens
If the user tries to play a game and has no tokens, then the game asks him how many tokens he wants to buy and how he wants to pay (e.g., phone bill, credit card or using existing loyalty points—default is phone bill).
Once the transaction is executed game play can begin and the appropriate number of tokens is deducted form the user's account.
2 Play Mobile SWP Game And Award Points As Prizes
Assuming that the game costs one token. User starts to play a new game:
3 Play Web Based SWP Game
All mobile games can be ported to Flash or HTML with no loss of functionality.
Comments
1 Content Management System (CMS)
Loading new content into a CMS can be done via a simple web interface bulk upload process that identifies bi/handset pairs.
2 Web Site Store Front and Shopping Cart
Back-end functionality includes the ability to create storefronts using content in the CMS.
Front-end functionality includes the ability to sort content by country/carrier/handset and to select check-out payment type via the shopping cart.
3 Billing and Delivery
Billing is supported via PSMS (Carrier Billing), Credit Card, and Loyalty Point programs, the latter being required to build the MLCS's own redemption catalog model.
A WAP PUSH based model is used although SMS/WAP GET is a viable alternative if WAP PUSH is unavailable.
Redeem Loyalty Points Via Web Catalog
The loyalty web catalog utilizes the content web portal described above with extensions for non-mobile content products (e.g., hard goods, broadband digital media, etc.).
1 Browser Based Redemption
Browser based redemption supports all products in the catalog (e.g., mobile content broadband content, hard goods, etc.).
From the Web catalog the user can:
2 WAP Based Redemption
From the WAP browser the user can:
3 Prize Requirements
The following types of Prizes may be available in the catalog:
4 Opt-in Marketing Requirements
Customers should have the option to OPT-IN to receive various promotional information, either through E-mail or SMS. The customer may be given incentives to sign in for OPT-IN marketing by offering sign up rewards such as tokens or reward points in their MLCS account.
MLCS Powered MVNO/Carrier Loyalty & Community Applications
As shown in
The features that make up these four components are presented in order below. The MLCS service stores all forms of tokens such as loyalty points, gaming tokens, gaming characters, digital coupons, etc in the form of digital tokens (see Technology section below for more detail). These tokens are stored in user Loyalty Accounts. The MLCS service facilitates all transaction processing such as redeeming points for prizes, issuing points, etc. Points can be redeemed via a redemption catalog or inside mobile applications (e.g. games) that support such redemptions.
The service provides three integration points into the MLCS for the carrier: 1.) Issue points for spend, 2.) Game level events for issuing/redeeming points, and 3.) Redemption Catalog (Web & WAP). Each area is reviewed in more detail below:
2. Game level events for issuing/redeeming point—The lightweight J2ME and BREW APIs provide MLCS functionality directly from the mobile application/game. The APIs offload processing, such as issue/redeem points, post a high score, receive an alert, etc., to the server, which makes the APIs very small. Strict security policies ensure that points are only being issues/redeemed in accordance with carrier policies.
1. Event
An event is information that is moved between two or more peers in a network. An event can contain notifications/alerts or signal a transaction to be executed. Generally notifications/alerts are not considered transactional when they do not involve any type of token exchange or movement of tokens. For example reporting a high score is a notification event but paying for a pay per play game is a transactional event.
Transaction events involve the exchange or redemption of tokens (see Token below) whereas notifications/alerts simply involve the movement of alerts from the publisher to the subscribers. In the case of transactions, the buyer is the publisher and the seller (or redeemer) is the subscriber. This model allows MLCS to work with many transaction and token management systems that are treated as black boxes to the MLCS by creating an orthogonal view into all token management systems that are hooked into the MLCS.
2. Peer
A peer is the generalization of all-end points in a network. When there is no server and no client everyone in the network is a peer. Peers can communicate directly (p2p) or via an intermediary (publish/subscribe). MLCS utilizes a publish/subscribe model, as several peers may need to know about data residing at a publishing peer at the same time.
3. Premium Short Message Service (PSMS)
PSMS is the application of SMS for mobile commerce. Via PSMS consumers can execute transactions from their mobile phone/handset that get billed via their phone bill. Typically such transactions happen either in the form of “short codes” which are messages that the buyer sends via his phone, for example the message “89134” sent to phone number 8768934 could mean buy a specific ringtone, send it to my phone, and bill me $1.49 via my phone bill.
4. Publish/Subscribe
Enables the movement of data between peers in a network without the need for polling or other high-overhead database style client/server implementations. A publisher makes data available to a “data bus”. The data bus is like a long water house that constantly has lots and lots of molecules moving through it. Subscribers are basically waterspouts that tap into the hose at various end-points and are only allowed to extract those molecules of data that they are allowed to subscribe to. In actuality, the MLCS Publish/Subscribe model does not require the subscriber to view all of the data molecules in the hose as the hose simply knows which molecules the subscriber expects to see and delivers only those molecules to the right water spout (subscriber). This concept is referred to as data routing or application inter-networking.
Publish/Subscribe is generally more efficient for the multi-cast of data to multiple peers than p2p style communications that has a higher overhead when communicating to multiple peers at the same time.
5. Skill With Prize (SWP) Games
A special form of game that involves prizes of monetary value based upon the successful execution of some task requiring skill on behalf of the player. TV Game shows are typical examples of SWP games.
6. SMS
Short-Text Messaging Service whereby short text messages (approximately 120 to 150 characters) can be sent to or sent from a mobile handset.
7. Token (or Asset)
A token is any form of digital asset that has some inherent monetary value to the owner of the token.
3.3 Layered System Design
There are four primary technology layers comprising all of the Mobile Loyalty and Community Services. Together these 4 layers comprise every “Service enabled” application. Referring to
Also shown in
Asset Management Layer
The Asset Management Layer enables the creation of, management of and transactions involving digital assets points, tokens, characters, etc.) from within mobile and Web applications.
Different alternative implementations are possible for the Asset Management Layer. In one embodiment, all assets are stored in the system as “smart contracts.” Smart contracts are a form of digital token with special properties. These properties include: asset definition (e.g., loyalty points), business rules (transferability, copy-ability, etc.), expiration, issuer, redemption value, etc. In addition, every contract has a unique ID associated with it that makes movement of the asset throughout the system secure, fast and efficient. Smart contracts are stored as digitally signed XML documents in individual user accounts (see Identity Management below).
As all assets in the system (points, gaming tokens, gaming characters, etc.) are stored as smart contracts, every transaction (described below) is simply an exchange of contracts. This canonical view of all items of value as a single form of a contract makes it very easy for the service to create new currencies and other forms of tokens such as pay per play tokens.
In another embodiment, assets and their properties are modeled using traditional relational database techniques. Tables are defines that capture the known asset types in the system and their properties (e.g., the reward currency for a given operator, the name of the reward currency for the given operator, convertibility rules for converting such reward currency into rewards or tokens). The relational data model captures the data and their properties. The business roles to govern the integrity and processing of the data are kept as database integrity rules as well as in business logic layer. Tables are also defined to capture the amount of those assets that are in a specific user account. This embodiment can be implemented using Structured Query language (SQL), which is a well known language for managing data on relational database management systems.
While the SQL embodiment is not as flexible in incorporating changes as the XML embodiment, it has the advantage of using widely available technologies where problems of robustness and high performance have already been addressed.
Transaction & Identity Management Layer
All assets are stored in individual user accounts. These accounts can be thought of as digital safety deposit boxes where all assets are stored. Every time the user needs to alter the contents of their box, such as in the case of receiving or redeeming loyalty points, the safety deposit box is opened and the assets are either added to or withdrawn from the box. If an asset is removed from the box an audit trail is maintained in the form of a withdrawal receipt that is left behind.
To execute a transaction such as the purchase of a product in exchange for loyalty points, two assets are swapped via an escrow process. This escrow process basically takes two assets, in this case, one representing loyalty points, and another representing the product being purchased, and swaps them across accounts. One account represents the user redeeming the points and one account represents the company selling the product.
Messaging, Alerts & Real-time Events Layer
The system uses a sophisticated messaging platform to enable the publishing and subscribing of real time events (high scores, instant messages, system alerts) from within mobile and web applications. In the example shown in
Mobile & Web APIs Layer
J2ME/BREW APIs
The API layer is the connection between the service's back end services and the mobile application. All digital assets accessed via the mobile application are accessed via the APIs. The APIs control user authentication, real-time messaging/events, token based transactions, and loyalty point issuance and redemption. As the vast majority of the processing involved is server based the APIs use very little memory.
The service provides a simple registration process for the application publisher to define new events, point schemes, tokens, etc. that are utilized from within any application. The issuer of the points must approve all loyalty point events set up for any given application/game.
Web Services
The service makes integration with traditional mobile services offered by Wireless Operators or MVNOs for loyalty points (voice, SMS, data purchases) very simple. The service offers a set of SOAP/XML based APIs that can take data from any standard reporting system (SQL, XLS, XML/flat files, Business Objects) and generate the appropriate updates to all loyalty accounts. This completely eliminates the need to interface directly with the telecom billing system. This integration can be done rather quickly once the appropriate reporting system is in place.
WEB & WAP Based Prizing and Reward Catalog
The service offers a generous web based catalog of mobile media content (ringtones, games, graphics, etc) that can be offered as loyalty premiums. This catalog can be completely re-branded and extended via third party products, sweepstakes, and other co-marketing arrangements. A direct marketing arm will work with the a catalog web master to continually update the catalog as appropriate.
Users authenticate themselves to the redemption catalog via their cell-phone number and a pin number (e.g., 4-digit pin), which is sent back to their cell-phone via SMS for security authentication.
The service also offers a WAP based version of the redemption catalog available via mobile handsets.
3.4 Auto Registration of Application
The MLCS platform and the Connector technology make it easy for applications to register with the MLCS platform without the user intervention and manual steps. This registration process is handled seamlessly in the following manner. Auto registration is complicated by issues of identification (what is the user ID to be used for the user account), authentication (how the MLCS knows that the user is who they claim to be), and repeat sign on (how does the user identify themselves every time they sign on).
Identification & Authentication
If the handset allows the application to determine the mobile number through an API, then that number is used (e.g. BREW provides an API whereby the application can determine the mobile number). However, in other situations (e.g. J2ME applications) the handset application cannot determine the mobile number.
In both these situations, one of two forms of authentication may be used. In one, the handset application sends both an HTTP request to the MLCS platform but also sends an SMS to the MLCS platform. Both these requests originating from an application contain a unique UID. MLCS matches the two requests and from the SMS request authenticates that the phone number provided on HTTP is correct.
The second form of authentication is when the handset uses WAP connectivity mode. In such mode, the operator WAP Gateway has an authentication system and forwards the MSISDN in a WAP request header. MLCS reads that and trusts such MSISDN number passed after looking at the source IP address and ensuring that it is a valid operator Gateway source IP.
Login
When MLCS identifies and authenticates an application as described above, it creates a user account on the MLCS system. The MSISDN is used as the user ID for the account. Because the login process needs to be as transparent and simple for end user, the MLCS automatically creates a secret key for the account and passes it to the handset application. On future logins the handset passes, in encrypted form where possible, the user ID (MSISDN) and secret key that was created at the time of registration. For applications requiring stronger authentication, e.g. cash transactions, the user could be asked to choose a password and then have to enter that on their mobile phone on each login.
3.5 MLCS Services
The MLCS platform has three core services associated with it that make it an effective solution. A user registration service allows a carrier to know who their customers are and what they are doing. A customer loyalty service establishes rewards policies for user activities of all kinds. The Tournament service enables community gaming with loyalty and prizes attached.
User Registration Service
This service turns every mobile application purchase into an ongoing customer relationship, and allows a carrier to know who is buying their games or ringtones.
The user registration service is completely user transparent and is triggered the first time any new application is run. The MLCS application extension sends the phone number along with any other relevant data to the MLCS server for processing including loyalty points for each purchase. Service details include:
Customer Loyalty Service
A customer loyalty service uses the same technology as the user registration service to add flexible loyalty point capabilities to any mobile application. Applications can be made to issue or redeem points based upon application level events such as reaching a new level in a game, reaching a personal high score, etc. The system offers customized loyalty catalog and partnership marketing capabilities in accordance with publisher or carrier requirements.
Tournament Service
Gaming tournaments (poker, Tetris, hearts, spades, etc) are a great way to increase customer loyalty and spend. With this service any game can be turned into a multiplayer tournament. The system provides the web interface for setting up new tournaments, notifies participants of start and end times, manages the leader board for any running tournament, issues points to the winners, and manages the redemption of points for prizes.
The service fully integrates the loyalty & prizing system to distribute prizes to the winners and to manage ongoing participant communications via SMS, Email and the Web.
A real-time messaging system enables events and alerts (such as instant messages or new high scores) to be transmitted in real-time across phones, browsers and leader board systems.
The service uses the same J2ME API's and BREW extension as the user registration and customer loyalty services meaning that STS does not increase the overall memory footprint of the application.
Loyalty Systems Service
There is a great deal of program design that can and must be accomplished prior to the launch of any new loyalty program. The system can perform a number of program design functions that will significantly strengthen the loyalty program's presentation to prospective subscribers.
Services that can be provided in loyalty systems planning include:
Loyalty Program Design and Implementation
Once the loyalty program has been agreed to conceptually, a series of activities are coordinated that will allow us, in partnership with the carrier, to take the program from concept to execution. This phase of the project includes the following areas of program development:
The Rational Unified Process (RUP) identifies a standard set of views called the 4+1 Architecture Views, which is depicted in
Together, these views provide the development team with the necessary perspective to adequately model and build a complex enterprise system. The +1 refers to the Use Case View, which contains the key use cases that drive the architecture. The other four views are:
This document presents the architecture using a “3+1” view model. The process view included in the more traditional “4+1” view model has been subsumed by the deployment view. Wherever applicable, UML diagrams and constructs are used to represent the architecture.
4.1 Feature Requirements
This section described features of the MLCS network. The format for each feature: Code, Name, Dependencies, Description
M1—Event definition model
Dependencies—None
Description
The event definition model enables new forms of events (scores, messages, alerts, etc) to be transmitted to any peer in the MLCS network. An event consists of:
User, authentication, topic event expiration date and a payload.
A payload can be content or a reference or an object. The return code to the publisher is a message receipt id or error message.
A uniquely published event is defined as the combination of a topic, signifying the event type, and the message receipt ID signifying that the event was successfully published.
Only certain peers are authenticated to publish or subscribe to certain topics (or event types). For example, only the MLCS server may subscribe to transaction events. Certain event types are predefined including:
In the case of a Tetris game where user 6502830367 (user's mobile number) gets a score of 10,730 an event might look like:
In the Case of a Skill with Prize Game (called TriviaOne that costs 3 Tokens to Play), an Event Might Look Like:
Developers will be able to define their own event types. For example, potential event types could include:
The three key advantages of the event model are:
M2—Event publish/subscribe model
Dependencies—M1
Description
The event publish/subscribe model enables the movement of events between peers in the MLCS network without the need for polling or other high-overhead database style client/server implementations. An internet style data routing form of publish/subscribe (as opposed to a “Tibco-like” multicast model which is inefficient for Internet based applications) is utilized. The publish/subscribe API's are extremely simple and represent a way that any MLCS application can communicate with other peers. That means that the public MLCS API's can be learned in a few minutes. They are:
Security within the event pub/sub model is important:
M3—Token definition model
Dependencies—None
Description
As discussed above, at least two different embodiments of assets are possible. One embodiment utilizes the emerging industry standard definition of “smart contracts” or “smart vouchers” as the basis for token based ownership and transactions. As defined by Fujimora and Szabo, tokens (or smart vouchers) are a digital representation of the right to claim goods or services. To clarify the difference between tokens and electronic money/digital certificates, a formal definition of tokens is introduced (as abstracted and modified from the IETF documentation on the subject):
Let I be a token issuer, H be a token holder, and P be the issuer's promise to the token holder. A token is defined as the 3-tuple of <I, P, H>.
Examples of P are as follows:
6. Seat number A-24 has been reserved for “a-concert” on April 2 (Event ticket).
Note that P does not need to be described in terms of a natural language as long as the contents of the tokens are specified. For example, a set of attribute name and value pairs described in XML can be employed to define the contents.
In another embodiment, tokens are defined using relational database and data modeling techniques. The database captures the properties of the asset and the quantity of the asset in the user account. The semantic properties of the asset (e.g., 50 points get one free item) are captures using the business logic layer.
M4—Token ownership (identity management) model
Dependencies—M3
Description
Token ownership simply references the current holder of tokens as issued by MLCS. In addition to holders and issuers, the IETF model also specifies examiners and transactors. An examiner basically is responsible for redemption (as in the case of loyalty points). A transaction guarantees the legal trade of two (or more) tokens.
M5—Token transaction model
Dependencies—M3, M4
Description
There are three types of transaction possible in the standard IETF model implemented by MLCS:
Examples:
M6—Tournament model
Depdencies—M1, M2, M3, M4, M5
Description
A tournament is defined as the collection of scores from a specific game over a specific period of time. The results from this collection can be utilized to distribute prizes to participants via the MLCS.
In addition to the event and transaction models described above, a Tournament Service web site exists. The tournament service serves two purposes:
M7—Loyalty point model
Dependencies—M1, M2, M3, M4, M5
Description
The loyalty points model pre-defines a special form of token, namely Reward Points, that can be utilized as a currency in any transaction that is deemed worthy. These transactions utilize the standard token model and token transaction models defined above.
Reward points have the following characteristics:
1) Non-transferable
2) 18 month expiration (tbc)
3) No cash redemption value
Reward points can be used as the basis for other white label reward points programs for MVNO and Carriers.
M8—Redemption catalog model
Dependencies—M1, M2, M3, M4, M5, M7, M11
Description
A redemption catalog is a standard “go-to” place for consumers to redeem their Reward points. The redemption catalog is implemented using the content retail model described below with extensions to support hard goods and other non-digital products such as gift certificates.
M9—Skill with prize (SWP) model
Dependencies—M1, M2, M3, M4, M5, M7, M9, M11
Description—
The SWP model pre-defines a special form of token (see Token Model), namely Sennari Tokens, that are utilized as payment chips for pay per play games. In addition, a special event type (see Event Model) is created, namely “Score SWP” for publishing scores back to the SWP server after a SWP game has concluded to determine whether or not a player qualifies for a prize (usually loyalty points).
Tokens can be purchased via the SWP game or any web site utilizing the content retail model described below.
M10—Content management model
Dependencies—None
Description
The content management model allows the ability to store, package and deliver content for sale to any supported handset or carrier.
The system supports:
M11—Content retail model
Dependencies—M10
Description—M1, M2, M3, M4, M5
The content retail model utilizes the event and token models to support the purchase of various types of tokens within MLCS. These tokens can be redeemed as: Sennari Token for pay per play (Transfer and Consumption transactions, purchase receipts to download content or ship a product (Consumption transaction), subscription tokens to access an application or portal (Presentation transaction).
Storefronts are built by defining products and purchase prices (utilizing any supported currency/payment type). The shopping cart requires the buyer to authenticate themselves to their token account (wallet) for payment processing. Store fronts and wallets are accessible from the web or the mobile handset.
Purchases can happen via:
MLCS is an architecture that leverages the Java programming language and the APIs and services of the J2EE & J2ME platform. Java, J2ME and J2EE are mature technologies that have gained wide acceptance in both the development community and in the market.
In order to be able to provide solutions to customers with a range of performance and cost constraints, MLCS may require strict adherence to J2EE standards to leverage the portability of JVMs and application servers across several OS platforms.
Further, in order to be portable on variety of mobile handsets, MLCS J2ME integration components, may require strict adherence to J2ME standards.
The MLCS architecture employs the following technologies:
J2EE
J2ME
Component Description
Connector
Connector manages the communication between the MLCS & service enabled J2ME applications. Sennari Connector is divided in following 2 subsystems.
MLCS APIs
API are described below:
MLCS_RegisterApp(AppId)
MLCS_AddUserInfo (name, address, zipcode, optional info)—
MLCS_AddCurrency (AppId, currency type, amount)
Adds currency to user's account. Currency type could be any value from the following:
MLCS_WithdrawCurrency(AppId, currency type, amount)
MLCS_SendMessage (AppId, Message type, message)
MLCS_ReceiveMessage (AppId, Message type, message handler)
MLCS_PublishEvent(AppId, Event Type, Payload)
MLCS_SubscribeEvent(AppId, Event Type, Event handler)
This is the component, which handles the communication with the MLCS. Other than basic functionality of Publish/Subscribe, it also implements other features.
Event Router
This is the component, which routes the events from one peer to another in the system. This router uses HTTP get & post for posting events and sending events.
Topic Space
In the Event Router, a uniquely published event is defined as the combination of topic, signifying the event type, and the message receipt ID signifying that the event was successfully published.
Certain event types are predefined including:
Since MLCS Platform would be used as ASP Service (Application Service Provider), for designing an event type system, where MLCS Platform and other subscribers can subscribe to a topic get all the events of their interest, following approach could be followed.
http://mlcs.xxx.com/<Event Type>/<CompanyName>/<AppId>/<MobileNumber>For Event Type, short codes can be used. Some of the predefined events are listed below Score—score: This is the event type for publishing score of a game to MLCS Platform. SWPScore—swp: This is the event type for publishing score of a SWP game to MLCS Platform.
Transact/Token/Credit—tx/tk/cr: This is the event type for crediting token
Transact/Token/Debit—tx/tr/dr: This is the event type for debiting token
Transact/Bling/Credit—tx/tr/cr: This is the event type for crediting Blings
Transact/Bling/Debit—tx/tr/dr: This is the event type for debiting Blings
Transact/Cash/Credit—tx/csh/cr: This is the event type for crediting Cash
Transact/Cash/Debit—tx/csh/dr: This is the event type for debitingcash
Message—im This is the event type for publishing a message.
So for publishing scores of game Tetris developed by the Sennari Games, from the mobile number 9827349386 topic would be as follows:
http://mlcs.xxx.com/sc/Sennari/Tetris/9827349386
for publishing an event of debiting a token from the mobile number 982660063, for a game application “Bingo” developed by Impetus, topic would be as follows: http://mlcs.xxx.com/tx/tk/dr/impetus/Bingo/9826600063
Other than topics based on event types, following topics will be maintained in the system to support other functionalities.
http://mles.xxx.com/register—Events from the user registration service are published to this topic. This event includes the mobile number of user, sent to sarver through SMS by application. The mobile application subscribes to this topic and gets the event.
MLCS Server
This is the component that provides the MLCS Services. All the business rules are implemented here. It has following subsystems:
User Registration Service
This service is responsible for handling user registration. User registration request comes via SMS. It reads the SMS, checks whether user is already a MLCS registered user or not, and according registers it.
Loyalty Service
This service is responsible for managing user accounts. It handles all the assets of the users.
It uses the Transaction service for managing transactions.
LeaderBoard Service
This service is specific to gaming domain. Responsibility of this service is to maintain the scores of game. Publishing high scores of game to all peers, deciding top 100 of the week and sending notification to winners etc.
Tournament Service
This service is specific to gaming domain. This service is responsible for handling all task related to Tournament Management.
Transaction Service
This service is responsible for talking to the Asset and Transaction Services. It manages all the transactions. It creates the XML-SOAP requests to be passed to the Asset and Transaction Web Services and gets response from it and pass it to other services.
The MLCS server 515 on the server side includes a JAVA connector 516 for communicating with the mobile handset 505 and client browser 512, and runs the services 517-521 for the MLCS. The services include: the User Registration Service 517, the Loyalty Service 518, the Leader Board Service 519, the Tournament Service 520, and the Transaction Service 521, as described above. The Asset & Transaction server 522 conducts the transactions for the user accounts stored in the database 523 based on requests from the Transaction Service 512 on the MLCS server 515.
Use-Case Specification and Flow
As described earlier, MLCS provides an account management system that enables all types of assets to be associated with a mobile phone number or email address. These assets can include loyalty points, gaming tokens, gaming characters used in longlived games (e.g., EverQuest), or coupons used for redeeming prizes. There are four primary services associated with the Mobile Loyalty and Community Service:
User Registration Service
The user registration service allows a simple, seamless and user transparent user registration process to any mobile game or application. The user registration process triggers the first time users start the applications. The carrier and publishers can use the user registration service for up-selling the buyer for services such as entertainment titles, etc.
Actors
The following actors will be involved:
7. Event Router: The event router which routes events from one component to other.
Preconditions/Assumptions
During the startup the mobile application must be able to provide an Application identifier so that the MLCS platform can identify the game of mobile application
Flow of Events
2. User downloads the application to his or her mobile handset.
Alternative Flow of Events
If the user is already registered for the same application with the service, then an alternative flow takes place. It is assumed that the registration flag on handset storage is set for that application, and that the Mobile number of the user is stored on the handset persistent store.
Another alternative flow of events is possible if mobile application has sent the user registration SMS to the MLCS but does not receive a registration confirmation event from the MLCS. In this case, Registration flag on handset storage is set to ST_SMS_SENT (i.e. SMS has been sent for registration) for that application and the following flow takes place.
Customer Loyalty Service
The customer loyalty service provides necessary interfaces and infrastructure for setting up flexible loyalty point capabilities to any mobile application and managing loyalty points.
The loyalty points model pre-defines a special form of token, namely Reward Points that can be utilized as a currency in any transaction. Reward Points have the following characteristics:
A platform is provided that stores points and other assets/tokens in secure accounts. Applications can be made to issue or redeem points based upon application level events such as reaching a new level in a game, reaching a personal high score, etc.
A customized loyalty catalog and partnership marketing capabilities are offered in accordance with publisher or carrier requirements.
Actors
The following actors will be involved:
Points for reaching a new level in a MLCS Enabled Single Player Game:
This use case describes the behavior, when a user reaches a new level in a game. The use case is triggered when a user reaches a new level in a game.
Actors
Mobile Handset User
Mobile Application
Loyalty Service
Transaction Service
Leader Board WEB/WAP Page
Asset & Transaction Service
Event Router
Pre-conditions/Assumptions
Points for reaching a score in a MLCS Enabled Single Player Game:
This use case describes the behavior when a game is finished. The use case is triggered at the end of the game.
Actors
Mobile Handset User
Mobile Application
Loyalty Service
Transaction Service
Leader Board WEB/WAP Page
Asset & Transaction Service
Event Router
Pre-Conditions/Assumptions
Basic Flow of Events
Points for Reaching Top 100 Players for the Week:
Every service enabled game has a top 100 of the week list, which shows the top 100 scores for the current week. The list is updated in real-time as new scores come in and old scores are pushed off the list. This use case is triggered, e.g., on Monday at 3AM EST.
Actors
Mobile Application
Loyalty Service
Transaction Service
Leader Board Service
Leader Board WEB/WAP Page
Asset & Transaction Service
Event Router
Pre-Conditions/Assumptions
The formula for awarding points to top 100 of week is stored in a XML file. (All business rule would be stored in XML files)
Basic Flow of Events
Play MLCS enabled SWP Game:
The SWP model pre-defines a special form of token, namely Tokens, that are utilized as payment chips for pay per play games. In addition, a special event type is created, namely “Score SWP” for publishing scores back to the SWP server after a SWP game has concluded to determine whether or not a player qualifies for a prize (usually loyalty points). Tokens can be purchased via the SWP game or any web site utilizing the content retail model.
Actors
Mobile Application
Loyalty Service
Transaction Service
Asset & Transaction Service
Event Router
SWP Service
Pre-Conditions/Assumptions
Basic Flow of Events
Buying Gaming token for SWP game:
This use case describes the flow of events when user want to purchase gaming tokens from within mobile application.
Actors
Mobile Application
Loyalty Service
Asset & Transaction Service
Event Router
Pre-Conditions/Assumptions
Basic Flow of Events
Tournament Use Cases
Tournament service A tournament can be defined as the collection of scores from a specific game over a specific period of time. The results from this collection can be utilized to distribute prizes to participants via MLCS.
Tournament service provides necessary interfaces and infrastructure for setting up and managing tournaments. Every tournament has its own leader board accessible from web and mobile game itself. The leader boards are updated in real-time as new scores comes in. tournament hosts can set-up new tournaments and define point prizes via web based interface.
Actors
The following actors will be involved:
MLCS Tournament Setup:
MLCS Tournament setup use case allows Tournament administrator to setup and manage Tournaments.
Actors
Administrator or game providers
Tournament service
Basic Flow of Events
Running tournament:
This use case describes the flow of events while the tournament is running.
Basic Flow of Events
End of Game Events:
Turning to
If the user selects option 602a, then the system collects data from the user in step 603. In step 604, the system creates an account for the user and deposits two or more tokens in the user's account. In step 605, the user selects a game to try out, e.g., from a game catalog. In step 606, the selected game is pushed onto the user's mobile phone.
If the user selects option 602b, then the system lists member options for current members in step 608. The options include: getting games 608a, buying game tokens 608b, and browsing the catalog 608c. If the user selects option 608a, then the user selects a game, e.g., from a game catalog in step 609. In step 606, the selected game is pushed onto the user's mobile phone. If the user selects option 608b, then the system gives the user different options for purchasing game tokens in step 610. After the user purchases tokens, the user moves to step 611 and returns to member options in step 608. If the user selects option 608c, then the system presents a catalog for the user to browse in step 612 showing prizes for which the user can redeem “Bling” currency, where “Bling” currency is a brand name for points that can be redeemed for prizes. Other names may be used for the points. In step 613, the user selects a prize from the catalog. In step 614, the system determines whether there is enough “filing” currency in the user's account for the selected prize. If the user has enough “Bling” currency, then the user advances to step 615 to exchange the “Bling” currency in the user's account for the selected prize. In step 616, the selected prize is delivered to the user (e.g., if the prize is a ringtone, then the ringtone is pushed onto the user's mobile phone).
If the user does not have enough “Bling” currency in step 614, then the user advances to step 617, where the system determines whether the user has more then 80% of the “Bling” currency needed for the selected prize. If the user has more than 80% of the “Bling” currency needed, then the system gives the user the option of purchasing “Bling” currency to cover the difference in step 618. If the user selects to purchase “Bling” currency, then the user buys the “Bling” in step 619, and advances to step 615. If the user selects not to purchase “Bling”t currency in step 618, then the system returns the user to step 613. If the user does not have more than 80% of the “Bling” currency needed for the selected prize in step 617, then the system informs the user that he does not have enough “Bling” in step 620, and returns the user to step 613. Another percentage may be used instead of 80%.
If the user selects option 602c, then the system collects data from the user in step 621 to register the user as a new member. The data may include payment information (e.g., credit card information) and delivery information (e.g., address). In step 622, the system creates an account for the user and deposits two or more tokens in the user's account. The user then advances to member options in step 608.
Turning to
In step 636, the user is given different user choices including: play game for cash 636a, and browse prize catalog 636b, view leader board 636c, edit the user's account 636d, and learn about other games 636e. If the user selects to browse the prize catalog 636b, then the user goes through the same steps as shown in
Although the present invention has been described in terms of the presently preferred embodiments, it is to be understood that the disclosure is not to be interpreted as limiting. Various alterations and modifications will no doubt become apparent to those skilled in the art after having read this disclosure. Accordingly, it is intended that the appended claims be interpreted as covering all alterations and modifications as fall within the spirit and scope of the invention.
This application claims the benefit of U.S. Provisional Application Ser. No. 60/679,801, filed on May 11, 2005.
| Number | Date | Country | |
|---|---|---|---|
| 60679801 | May 2005 | US |
