US20100223110A1

Movatterモバイル変換

Info

Publication number: US20100223110A1
Application number: US12/714,722
Authority: US
Inventors: Daniel Slavin; Pero Smrzlic
Original assignee: Individual
Current assignee: CodeBroker LLC
Priority date: 2009-03-02
Filing date: 2010-03-01
Publication date: 2010-09-02
Also published as: US20170039586A1; US10410236B2

Abstract

A method for delivering customized data items to users of electronic privilege cards includes receiving a customized data item to be delivered to a user having an electronic privilege card, identifying the electronic device storing the targeted user's electronic privilege card, and transmitting the customized data item to the electronic device. In one embodiment, the data item is an offer or coupon that the user may redeem from an entity associated with the electronic privilege card, such as a retailer or service provider. In another embodiment, the electronic device storing the electronic privilege card is a mobile telephone.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. provisional patent application Ser. No. 61/156,684, Slavin et al.,Techniques for delivering offers to users of electronic privilege cards,filed Mar. 2, 2009.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A SEQUENCE LISTING, A TABLE, OR COMPUTER PROGRAM LISTING COMPACT DISC APPENDIX

Not applicable.

BACKGROUND OF THE INVENTION

The invention relates generally to electronic privilege cards, and more specifically to a method and system for delivering customized offers to users of electronic privilege cards. Electronic cards, in particular electronic cards that correspond to already issued non-electronic cards, are issued by a card issuing party (the card issuer) to a party to which the card issuer is granting a privilege. Such cards will be termed in the following privilege cards. Common examples of privilege cards include coupons, loyalty cards, gift cards, identification cards, credit or debit cards, membership cards, tickets, and licenses.

Electronic privilege cards (“eCards”) can provide significant convenience advantages to consumers over non-electronic privilege cards (“Cards”) such as easy accessibility and being more environmentally friendly than their paper and plastic counterparts. These eCards, including any associated barcodes, can be stored in an electronic version of a wallet and can be displayed on a device such as a mobile telephone that has access to the wallet. When displayed, eCards can be used with barcode readers in the same fashion as their physical counterparts.

Unlike prior art systems that either i) deliver a set of offers to mobile phone regardless of whether the phone stores an eCard, or ii) deliver identical offers to all mobile phone users, the invention describes a method of associating offers with specific privilege cards and delivering customized or unique offers to end users. Today, it is difficult and expensive for privilege card issuers to communicate with and deliver offers to their card holders outside of email and snail mail. General text alerts have also not caught on as consumers do not want spam and do not want to be inundated with text alerts.

BRIEF SUMMARY OF THE INVENTION

The invention relates to method for delivering customized data items to users of electronic privilege cards. The data items may be offers, coupons, notices regarding special events or promotions, alerts, polls, queries, news items, or any other type of information that an entity may desire to transmit. The eCards may be stored on electronic devices such as mobile phones, personal digital assistants, Blackberry® devices, iPhone® devices, or other such mobile device that has access to the internet or that may communicate wirelessly. The method includes receiving a customized data item to be delivered to a user having an eCard, identifying the electronic device storing the targeted user's eCard, and transmitting the customized data item to the electronic device. In one embodiment, the data item is an offer or coupon that the user may redeem from an entity associated with the electronic privilege card, such as a retailer or service provider.

The invention also relates to a system for delivering a data item to a user having an eCard associated with an entity. The system includes a client computer, an eCard privilege manager, an eCard server, and at least one mobile device storing an eCard associated with an entity. In one embodiment, the eCard privilege manager and eCard server are the same. The eCard server stores a data item to be delivered to a user having an eCard associated with the entity. The user stores the eCard on a mobile device. The availability of the data item is presented to the user through a first communications channel, such as a sign in a store. The user instructs the mobile device to request the data item from the eCard server. The mobile device transmits a request for the data item to the eCard server through a second communications channel, such as by text message or email. The eCard server receives the request for the data item from the user's mobile device. The eCard server then transmits the data item to the mobile device, and the mobile device receives the data item and associates the data item with the eCard. In one embodiment, the data item is an offer capable of being redeemed from the entity associated with the eCard. In another embodiment, the mobile device is a mobile telephone. In another embodiment, the eCard server may also transmit the data item of offer to a server at a given retailer who has issued the privilege card represented by the eCard and that retailer's server will be updated to note that the offer should be added to the particular Card/eCard account. Therefore when the user attempts to redeem the offer by presenting the eCard, the server knows to allow the redemption. This process is also referred to as “load to card”.

In another embodiment, a user instructs the mobile device storing the user's eCard to request all data items available to the user from the eCard server. The eCard server receives the request for the available data items from the user's mobile device and determines whether it is storing any data items related to the entity associated with the eCard and customized for the user. The eCard server then transmits the available customized data item(s) to the mobile device. The mobile device receives the data item(s) and associates the data item(s) with the eCard. In one embodiment, the data item is an offer capable of being redeemed from the entity associated with the eCard and the mobile device is a mobile telephone. In one such embodiment, the mobile phone sends a text message to the eCard server requesting the data items available for the user.

One object of the present invention is to make it convenient for retailers to deliver and for consumers to obtain coupons and offers on their mobile devices, such as mobile phones. Another object of the invention is for retailers to deliver offers and coupons that are designed to be unique to individual consumers in association with a privilege card that is carried on the consumer's mobile device. The present invention is an eCard-based system that makes it easy for retailers to deliver offers/information to issued eCards.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is pointed out with particularity in the appended claims. The above and further advantages of this invention may be better understood by referring to the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1 is a flowchart representation of a prior art technique for providing consumers with non-electronic privilege cards and then making eCards corresponding to the non-electronic cards

FIG. 1A is a block diagram of an embodiment of a system for generating and delivering customized data items to eCard users;

FIG. 1B is a block diagram of another embodiment of a system for generating and delivering customized data items to eCard users;

FIG. 2 is a flowchart representation of an embodiment of a process for delivering offers to users of eCards;

FIG. 3 is a flowchart representation of an embodiment of a process for enabling an offer for distribution to users of eCards;

FIG. 4 is a flowchart representation of an embodiment of a process for delivering offers to users of eCards and the user redeeming the offers at a point of sale system;

FIG. 5 is a flowchart representation of an embodiment of a process for delivering customized offers to users of eCards;

FIG. 6 is a flowchart representation of an embodiment of a process for authenticating a user;

FIG. 7 is a flowchart representation of an embodiment of a process in which a user may issue a text message in order to add an offer to their validity checking wallet and;

FIG. 8 is a block diagram of an embodiment of a system for allowing a user to use a web interface on a computer to manage their eCards that are stored on a mobile device.

Like reference characters in the respective drawn figures indicate corresponding parts.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows a number of ways in which today's consumer can obtain a physical Card at flowchart101: by applying for one via a web form (105), phone (103), or paper form (103). In all cases, the issuer collects information about the applicant and enters the information into a database (111,109,115). The consumer obtains a physical Card either immediately or via service such as US mail (107,113,115). Once the consumer has a physical copy of the card, he/she can then create an electronic version of the card (117). Currently available ways of doing this include:

- Consumers fill out a form using an application running on a mobile device in which the consumer selects the type of Card from a pre-defined list and then enters the required information for that Card. The application can then present all of this information at a single time in tabular form, or place it on some type of background image to have it appear more like the original physical Card.
- Consumers fill out a form using a desktop application running on a personal computer in which the consumer selects the type of card from a pre-defined list and then enters the required information for that Card. The desktop application then transfers this information to an application running on the mobile device which then presents all of this information at a single time, or places it on some type of background image to have it appear more like the original physical Card.
- Consumers send a text message in to an electronic card issuing service which then transmits the electronic card to the mobile device.

Some of the above-identified methods incorporate the use/display of a barcode as part of the eCard. The eCards made as described above are stored in an electronic file or wallet for easy access by the user. To use either the physical card or the eCard made from it, the user presents the card or the image of the eCard (119) to a representative of the issuer, who validates the card and provides the privilege represented by the card (121).

All kinds of eCard versions of privilege cards have a number of advantages over physical privilege cards. For example, a consumer can carry any number of eCards in a mobile phone; and the eCards, if used as full replacements for non-electronic privilege cards, can reduce printing and delivery costs.

Privilege cards that are originally issued as eCards, that is no physical card is ever issued, have a number of additional advantages over eCards made as indicated at117 ofFIG. 1. Validation of a privilege card that is originally issued as an eCard can be automated and more kinds of validation are possible with eCards than with physical privilege cards. With eCards, validation checks can be performed when the eCard is issued and/or before/after they are to be displayed. The latter checks can determine things such as whether the eCard has expired, whether a fixed number of uses has been exceeded, whether use of the card has resulted in further privileges, or whether the eCard is being used in the proper location. An additional advantage is that eCards with automated validation can be used with clerkless point of sale systems.

A particularly effective technique for automating the validation of an eCard in a mobile device is the validity-checking wallet, described in detail in U.S. patent application publication US 2007/0241189, Slavin, et al.,Using validity events to control the use of coupons containing barcodes in mobile devices that display the barcodes for reading by barcode readers,which is hereby incorporated in its entirety by reference into the present patent application. The validity checking wallet responds to validity events, i.e., events which possibly affect the validity of a card or coupon stored in the wallet. The validity-checking wallet also controls the provision of the card or coupon's barcode to a point of sale device. The validity checking wallet divides eCards and/or coupons into at least two sets; a set of the cards or coupons known to be currently valid and a set of the cards or coupons whose current validity is unknown. The wallet permits provision of a card or coupon's barcode to a point of sale system only if the card or coupon is on the list of currently valid cards or coupons. When a validity event that affects a card or coupon on the list of currently valid cards or coupons occurs, the wallet moves the card or coupon to the unknown list until the effect of the validity event on the card or coupon can be determined. If the wallet determines that the event invalidates the card or coupon, the card or coupon is discarded from the wallet or moved to a set of invalid cards or coupons; if the wallet determines that the effect of the event is that the card is valid, the card is moved to the currently valid set; if the wallet can determine neither, the card remains in the current validity unknown set.

Examples of validity events include but are not limited to

- providing the barcode to the POS system;
- reaching the expiration date of the coupon;
- providing the barcode at a particular location; and
- receiving information which defines or redefines the coupon's validity, for example, new control data for a coupon.
  In most cases, the validity checking wallet can make a validity determination in response to a validity event at a time other than the moment the user selects to redeem the coupon, and consequently, validation may be separated from redemption and the redemption process need not be burdened by the time required for the validation process. For further details, see FIGS. 6 and 7 of US 2007/0241189 and the discussion of those figures at [0059]-[0081] of the patent application publication.

Once the eCard has been delivered to a mobile phone or other electronic device, the next step is for the retailer to generate a data item to be delivered to an eCard use. Referring toFIG. 1A and in brief overview, an embodiment of asystem150 constructed in accordance with the present invention includes aclient computer152, aneCard privilege manager154, aneCard server156, andmobile devices_1-N158. In the embodiment shown,client computer152,eCard privilege manager154,eCard server156, andmobile device158 are connected by acommunications link160. In one embodiment, the communications link160 is a global communications network (i.e. Internet or World Wide Web). In other embodiments, the communications link160 may be any system or group of systems by which theclient computer152,eCard privilege manager154,eCard server156, andmobile device158 may communicate. For example, in one embodiment, theclient computer152,eCard privilege manager154, andeCard server156 may communicate via an intranet. In another embodiment, theeCard server156 andmobile devices_1-N158 communicate via amobile communications protocol162, such as text messaging. In yet another embodiment, theeCard server156 andmobile devices_1-N158 communicate via a near field communications method (NFC), such as by using radio frequency identification technology (RFID). In yet another embodiment, themobile devices_1-N158 may communicate directly with theeCard privilege manager154 via the Internet, an intranet, a NFC method, or any other communications protocol.

Theclient computer152 is capable of executing a web browser. In other embodiments, theclient computer152 may also be capable of executing other applications, such as word processing, spreadsheet and email applications. Theuser164 uses the web browser on theclient computer152 to access a web page hosted by theeCard privilege manager154. The terms user, author, composer, retailer, etc. when used in connection withreference number164 all mean the individual entering the customized data item to be sent to predetermined eCard holders. Theuser164 may be a retailer that issues eCards to purchasers, or may be any other entity who issues eCards to individuals or entities that have a relationship with the issuing entity. The user may also be an individual or second entity that does not have a relationship with the first entity associated with the eCard, but desires to deliver a customized data item to one or more users having an eCard associated with the first entity. For example, Supermarket B may wish to send customized offers to consumers who have an eCard associated with Supermarket A. In one embodiment, theeCard privilege manager154 comprises aprocessor166 and adatabase168. TheeCard privilege manager154 comprises tools for theuser164 to create data items that theuser164 or eCard issuer may select to deliver to individuals or entities having eCards. TheeCard privilege manager154 may be used to create data items for particular eCards, or for all eCard holders, or for a subset of all eCard holders. The data items that auser164 may create will be discussed in more detail below. In one embodiment, thedatabase168 stores information regarding the eCard issuer, information regarding individuals authorized by the eCard issuer to create data items, and unique identifiers for each individual or entity having an eCard from the eCard issuer. In another embodiment, thedatabase168 stores information for a plurality of eCard issuers and the individuals and entities having eCards from one or more of the eCard issuers.

In the embodiment shown inFIG. 1A, theeCard server156 comprises aprocessor170 and adatabase172. In one embodiment, thedatabase172 stores information for the eCard issuer and unique identifiers for each individual or entity having an eCard. The unique identifier may or may not be the same unique identifier stored by theeCard privilege manager154. TheeCard server156 communicates with themobile devices158 and delivers the data items created in theeCard privilege manager154. In one embodiment, the functions of theeCard privilege manager154 and theeCard server156 are performed by a singleeCard data manager180 as shown inFIG. 1B. Themobile devices_1-N158 may be mobile phones, personal digital assistants, Blackberry® devices, iPhone® devices, or other such mobile devices that have access to the internet or that may communicate wirelessly.

The operation of thesystem150 is described with reference toFIG. 2. For purposes of example only, the operation of thesystem150 will be described having auser164 who is acting on behalf of a retailer and a data item which is an offer. In other embodiments, theuser164 can be any type of individual or entity who communicates data items to eCard holders. The eCard holders may have a pre-existing relationship with such individual or entity, such as customer/retailer, patient/doctor, client/service provider, member/club, etc., the eCards being associated with the individual or entity desiring to deliver a data item. In other embodiments, the eCard holders may have no pre-exiting relationship with the individual or entity desiring to communicate a data item to the eCard holders, the eCards being associated with a different individual or entity. Data items may be offers, coupons, notices regarding special events or promotions, alerts, polls, queries, news items, or any other type of information that an entity may desire to transmit. While thesystem150 may be used to provision eCards tomobile devices158, the discussion assumes that at least one eCard has previously been distributed tomobile devices_1-N158. At this point, theretailer164 logs into theeCard privilege manager154 to access their account stored indatabase168, as shown atstep202 inFIG. 2. Using a standard web interface, instep204, anoffer author164, who may be an employee of the retailer or service provider acting on behalf of the retailer, creates one or more offers in theeCard privilege manager154 which are to be associated with the retailer's privilege card. Each offer can contain information such as the name of the offer, the details of the offer, the terms and conditions of the offer, an image which represents the product/service being offered, optionally audio or video clips associated with the offer, categories that offer falls into (such as entertainment, food, etc.) and usage validity information such as the start and expiration date of the offer and the number of times the offer can be used. Once an offer is created, it is saved in thedatabase168.

In one embodiment of thesystem150, theretailer164 may prepay for a predetermined quantity of offers to be delivered tomobile devices_1-N158. Each time an offer is delivered to amobile device158, a predetermined amount is deducted from the prepaid amount. Once the prepaid amount is depleted, thesystem150 will discontinue delivering offers tomobile devices_1-N158 until additional funds are received.

Instep206, theauthor164 tests offers by inputting the phone number of his/hermobile phone158 and selects an option which instructs thesystem150 to test the offer. In order to test the offer, theeCard privilege manager154 communicates the offer and the author's identification information to theeCard server156. Next, in step108, theauthor164 runs the validity checking wallet on his/herphone158 and selects to update the offers in the validity checking wallet. Instep210, the validity checking wallet communicates with theeCard server156 via http and includes information about which privilege cards are stored in the validity checking wallet and the mobile phone number of the mobile phone on which the wallet is installed.

TheeCard server156 receives this message atstep212 and then looks to see if any new offers are available for any of the privilege cards associated with this phone number atstep214. In this case, there will be a new offer available (the offer being tested) and theeCard server156 proceeds to step218 and transmits the newly created offer back to the validity checking wallet via http. Next instep222, theauthor164 will receive an alert from the wallet application that new offers have arrived and can then view the test offer(s) by selecting an option which with display the offer. In one embodiment, theauthor164 may click on a screen icon on the author'smobile device158 next to the logo associated with the privilege card. Clicking this icon will show the test offer along with any other existing offers for the selected eCard. In the embodiment shown inFIG. 2, theauthor164 then uses the phone's cursor motion keys to highlight the test offer and then view it instep224. If theauthor164 wishes to make any changes to the offer, s/he logs back into theeCard privilege manager154, locates the test promotion from the list of promotions, clicks edit, and makes any necessary changes. At this point, theauthor164 may repeat the test process as outlined above.

It should be noted that in addition to viewing the offers after clicking on an icon next to an eCard logo, the validity checking wallet of themobile device158 also allows the user to view offers by category. If theoffer author164 has attached a category to the offer, then selecting such category as an option in the validity checking wallet will display all of the offers in the wallet, including the test offer, sorted by offer category.

In one embodiment, once theauthor164 has completed his/her testing, s/he will next enable the offer for general distribution as shown atstep302 inFIG. 3. To do this, s/he will select a command presented on theclient computer152 to request that the offer be reviewed and enabled for general release. Once the author has selected this option, in one embodiment, atstep304, thesystem150 will notify individuals who have been identified as reviewers that they must now review the offer(s) prior to final release. Such notifications may be done via email. When the reviewers receive the notifications atstep306, they log into theeCard privilege manager154 atstep308. In one embodiment in which the notification is an email, the email contains an embedded link that the reviewer may select. Next instep310, the reviewer is brought to a page where they can review the offer, send it to a validity checking wallet on their own phone using the same method the author used, and instep312 determine whether to approve the offer. Once all of the required reviewers have approved the offer, it is enabled atstep316 and made available to the users who have the associated eCard in their validity checking wallet through theeCard server156. If the offer is rejected, then theauthor164 is informed via email atstep314 and may return to step202 to perform further edits on the offer.

Once a new offer is made available, theeCard server156 sends out a text alert as shown atstep404 inFIG. 4 alerting the mobile devices's_1-N158 users that new offer(s) are waiting. In another embodiment, thesystem150 is a location-based service. That is, theeCard server156 sends a message alerting a mobile devices's₁158 user that new offer(s) are waiting upon detecting the proximity of the user to a predetermined location. For example, theeCard server156 may send a message alerting a mobile devices's₁158 user that new offer(s) are waiting upon detecting the user entering a retailer's physical location. In one such embodiment, the offers are customized to each eCard holder, and theeCard server156 only sends a message alerting a mobile devices's₁158 user that new offer(s) are waiting if theeCard server156 is storing any offer(s) that are customized or personalized to that user.

The user of themobile device158 then runs the validity checking wallet on his/her phone and selects to update the offers in the validity checking wallet atstep406. Instep408, the validity checking wallet communicates with theeCard server156 via http and includes information about the device on which the validity checking wallet is running such as screen dimensions or phone make/model, which eCards are stored in the validity checking wallet, and the mobile phone number of the mobile phone on which the validity checking wallet is installed. This enables theeCard server156 to send the offer in a format that will be recognized by the user'smobile device158.

TheeCard server156 receives this message atstep410 and looks to see if any new offers are available for any of the eCards associated with the received phone number atstep412. In this case, there will be a new offer available (the new offer(s) that have just been approved), and so that offer will be transmitted back to the validity checking wallet via http atstep416 alongpath418. Next instep420, the user will receive an alert from the validity checking wallet application that new offers have arrived. Instep422, the user can then view the offer(s) by running the wallet and viewing the list of eCards contained in the wallet and then looking for indicia next to a loyalty card logo indicating that a new offer has arrived. In one embodiment, the indicia is an icon. If the user sees an offer indication icon, in step423 s/he clicks on the offer indication icon next to the logo associated with the privilege card. Clicking this icon will show the new offer(s) along with any other existing offers. The user then uses the phone's cursor motion keys to highlight the test offer and then view it instep424.

To take advantage of the offers in the validity checking wallet, the user uses one of two methods:

- 1) In one usage case, theretailer164 will have already associated the offers entered into theeCard privilege manager154 with the user's privilege card. This would be done in the retailers POS system by using the various features of their POS software. In order for the user to take advantage of any of the offers associated with his/her privilege card, while the cashier is ringing up the sale, the user presents theeCard425 by running thevalidity checking wallet428 on his/her mobile phone, selecting the privilege card, and displaying theeCard426. Once displayed, the cashier either scans the associated barcode from theeCard using scanner428 or manually inputs the privilege card number. Once the number has been accepted by thePOS system430, thePOS system430 checks to see if any of the items purchased by the user have corresponding offers in the POS system. If there are corresponding offers, then the user receives any appropriate discounts.
- 2) In another usage case, theretailer164 will have entered the offers into their POS system, but will not have associated them with a specific eCard. In order for the user to take advantage of any of the offers associated with his/her eCard, while the cashier is ringing up the sale, the user runs thevalidity checking wallet428 on his/hermobile phone158 and selects theprivilege card426 they wish to display. Once displayed, the cashier either scans the associated barcode from the eCard or manually inputs the privilege card number. Next, the user selects the offer they wish to redeem from the list of offers associated with the eCard and requests that thevalidity checking wallet428 display the offer and associated barcode/offer number. The cashier then either scans the barcode from themobile phone158 or manually enters the offer number. Once the number has been accepted by the POS system, the POS system checks to see if any of the items purchased by the user have corresponding offers in the POS system. If there are corresponding offers, then the user receives any appropriate discounts. The POS system may optionally only accept such offers if they are used in conjunction with the eCard, meaning that if the user does not first display and have the cashier enter his/her privilege card, then the POS system will not validate the offer and the user will not receive any discounts.

In either of the above two cases, thevalidity checking wallet428 will check to ensure that an offer is still valid either prior to the display of the offer or just after the display of the offer. For example, thevalidity checking wallet428 might compare the start and end date of an offer with the current date on themobile phone158. If the current date is outside of the range of the start/end date for the offer, then thevalidity checking wallet428 will not display the offer. Similarly, if the offer can only be used a limited number of times, thevalidity checking wallet428 temporarily invalidates the offer and prompts the user to contact the server following the display of the offer. Use validation of this type is discussed in more detail in U.S. patent application Ser. No. 12/371,130, Slavin, et al.,Techniques for providing an electronic representation of a card,filed 13 Feb. 2009. The description in U.S. patent application Ser. No. 12/371,130 is hereby incorporated in its entirety by reference into the present patent application for all purposes. While communicating with thewallet428, theeCard server156 communicates with the retailer's POS system in real time and determines of a particular offer is still valid for additional uses. If it is valid for additional uses, then such information is communicated to thewallet428 and thewallet428 will allow for another display of the offer. If the offer is no longer valid, then thewallet428 will not re-enable the display of such offer. Alternatively, theeCard server156 may exchange information with the retailer's point of sale system on a batch basis (once per day, for example) to determine if offers are still valid.

In one embodiment according to the present invention, thesystem150 is able to deliver unique or customized offers to eCard users via thevalidity checking wallets428 on themobile devices158. In one example, theoffer author164 inputs a series of offers into theeCard privilege manager154 via the web interface on theclient computer152, as shown atstep502 inFIG. 5 or programmatically via http post using a standard program interface defined as a feature of theeCard privilege manager154. TheeCard privilege manager154 assigns a unique identifier to each offer atstep504. As shown inFIG. 5,Offer1506 is assigned unique identifier XYZ123,Offer2508 is assigned unique identifier ABC321 andOffer3510 is assigned unique identifier CBA321. In one embodiment, theauthor164 may assign a category such as food or entertainment for each offer. In another embodiment, any system generated identifiers are i) displayed on the screen of the web interface ofclient computer152 if anauthor164 is using the web interface or ii) returned to theclient computer152 via http post using the program interface when a new program is defined programmatically. When it is time to deliver offers, themerchant164 then provides theeCard privilege manager154 with a database of information containing privilege card numbers and the offer identifiers associated with each privilege card number atstep512. For example, blocks514,516 and518 identify the unique offer identifiers associated withMember1,Member2 andMember3, respectively. Such information could be provided to the system programmatically via http post or via a flat text file such as a CSV file. In step520, theeCard server156 then delivers only those offers to each user that are associated with that user's privilege number. In one embodiment, mobile phone number is used as the unique way to identify the users in place of privilege card number.

It should be noted that the data item composer/retailer154 determines how to personalize or customize offers for each eCard holder or group of eCard holders. There are many analytical systems known for generating personalized or targeted ads and offers. One such system is described in US Patent Application Publication No. 2005/0289006 to Cividini et al. One purpose of these systems is to provide commercial offers that will be of interest to a particular consumer. The customization may be based on the consumer's purchase habits or tastes, or other personal information. In one embodiment of such a system, the system includes a historical archive of data related to offers already redeemed by a specific user, and/or past purchases made by the specific user. The present invention may be used to deliver the customized ads once the per-eCard customization has been determined The present invention may also store information regarding each eCard holder. Theuser164 may direct that a customized data item be delivered to all eCard holders who have a particular characteristic, such as gender, age, purchase history, user specified preferences such as baby, electronics, or home, loyalty clubs or other clubs they are members of, location, or any other characteristic that may be shared by multiple eCard holders.

FIG. 7 shows one embodiment of a system according to the invention in which a user having an eCard may send in a text message to add an offer to their validity checking wallet. As an example, a user might see a sign at their local retailer offering a discount on a product for texting a keyword to a shortcode. By displaying a sign regarding an offer, the retailer presents the availability of an offer to an eCard holder through a first communication channel. To obtain this discount, atstep702 the user would text the keyword in to the shortcode. The server receives the text message and determines atstep704 if the offer is valid/available for that user/mobile number. If the offer is valid/available, instep708 the user receives back a notification that the offer has been added to their privilege card. Next instep710, the user runs the validity checking wallet, which in turn connects to the server to check for updates and then downloads this offer instep714. See for example, blocks718 and720. The server thus downloads the offer to the eCard holder's mobile device via a second communication channel. Depending upon the sophistication of the merchant's POS system, the offer could be automatically loaded to the user's privilege card account instep722 so that by simply presenting the privilege card, the user could take advantage of the offer. If the merchant's POS system was not as sophisticated, then the offer might be returned with its own unique offer identifier or barcode which could then be presented to the cashier in conjunction with the privilege card.

In another embodiment of a system according to the invention, a user having an eCard may send in a text message to add all offers available from the entity associated with a particular eCard to the user's validity checking wallet. As an example, a user might enter a physical location of retailer and desire to obtain all offers available to the user. The user may text a keyword or a shortcode to request the offers. The keyword may be associated with a location, such as store number. By texting to request the offers, the user communicates with the server through a first communication channel. The server receives the text message and determines if there are any valid/available offers for that user/mobile number. If there is at least one offer that is valid/available, the user receives back a notification that the offer has been added to their privilege card. Next, the user runs the validity checking wallet, which in turn connects to the server to check for updates and then downloads the offer(s). The server thus downloads the offer(s) to the eCard holder's mobile device via a second communication channel. In other embodiments, the first and second communications channels may be the same. Depending upon the sophistication of the merchant's POS system, the offer(s) could be automatically loaded to the user's privilege card account so that by simply presenting the privilege card, the user could take advantage of the offer. If the merchant's POS system was not as sophisticated, then the offer might be returned with its own unique offer identifier or barcode which could then be presented to the cashier in conjunction with the privilege card.

In one embodiment, once a user has elected to have an eCard on theirmobile device158, the system provides such users with a web interface to manage the preferences of one or more of the privilege cards on their mobile phone. In another embodiment, they users may access the web interface prior to having any eCards. For example, the user could start with no eCards and access the site to add eCards. The user could also add the eCards by using a mobile phone based application.

If the user has not visited the site before, then the user enters his/her mobile phone number, as shown atstep602 inFIG. 6. If such mobile number is unrecognized, then atstep606 the user is asked to try again or to create a new account on the system. If such mobile number is recognized, then the user must be authenticated for the first time following the steps inblock650. The reason for this is that the user may have one or more eCards on their mobile phone, but not yet have a formal account on the system because they have not previously visited the web interface. In this case, atstep608 the user will press a button to send a text message to his/her mobile phone. Such message will contain a unique code as indicated atstep610. Instep612, the user then reads this code from his/her phone and enters it into the web interface. If the unique code is correct, then the user is authenticated and given access to the interface at instep616. If not, the user is not admitted to the web interface and followspath620 to re-enter his/her mobile phone number.

In another embodiment, the web interface presents a unique code to the end user and requests that the end user run the validity checking wallet application, enter the unique code, and then request the wallet to communicate that code to the server. If done successfully, the user is authenticated and will be granted access to the web interface. In either case, once the user has been authenticated, s/he is provided with the opportunity to access the web interface with a username and password of his/her choosing upon future visits to the web interface.

It should be noted that the methods described in

steps

608,610, and612 are similar to the methods required to connect a first time user's mobile phone number with the validity checking wallet on his/her mobile phone. If the validity checking wallet has just been installed on the phone for the first time, the server will need to ensure that the proper phone number is assigned to the user's particular wallet because many mobile phones do not allow applications to determine the phone's mobile number. Thus, in the case where the validity checking wallet has been installed on a mobile phone prior to requesting an eCard and prior to creating an account using the web interface, there is a need to accurately and securely have the wallet learn the mobile phone number of the mobile phone. In order to do this, the wallet asks the user to enter his/her mobile phone number. The wallet then stores this number and communicates it back to the server via a first communication method such as http. The server then uses the mobile phone number to communicate a secret code back to the phone via a second communication method such as SMS/text. The user then enters the secret code into the wallet application and the wallet application communicates that code back to the server via the first communication method to confirm that it was the code corresponding to the previously sent phone number. At this point, the wallet has securely matched the phone number to the user's phone. The above methods could use an email address and email instead of a mobile phone number and SMS.

Once authenticated, the user will be able to manage privilege cards and preferences from one or more card issuers. Examples of the type of information the user can manage using the interface are: time preference for text alerts, maximum number of alerts per month, maximum number of offers for each privilege card, whether to update all cards or only individual cards when updating the validity checking wallet, which eCards to receive offers for, categories of offers desired, phone model, name, address, phone number and other personal information, username, password, and types or categories of offers the user would prefer to receive. Once the user has entered such information, s/he presses the Save button to update the information in the system. The system can then use this information to more effectively deliver offers to such user.

In another embodiment, a web interface enables the user to enter new cards that s/he wishes to have delivered to the validity checking wallet as eCards and provides the ability to remove eCards from the validity checking wallet.FIG. 8 shows a block diagram of an embodiment of asystem800 for allowing auser802 to use a web interface on acomputer804 to manage their eCards that are stored on amobile device806. Thesystem800 comprises auser computer804, aneCard manager808, a user'smobile device806 and acommunications link810, such as the Internet. TheeCard manager808 comprises aprocessor812 and adatabase814. Thedatabase814 stores data for all of the eCards stored on the user'smobile device806. Theuser802 may use the web interface presented on theuser computer804 to send one or more newly entered privilege cards to the validity checking wallet stored on themobile device806 as eCards at by selecting the appropriate command. In one embodiment, to do this, theuser802 selects an icon on the web interface displayed on theuser computer804 requesting that such new cards be delivered to the wallet stored on themobile device806. TheeCard manager808 then sends a message to themobile device806 associated with the user's web account indicating that there are new eCards available. This message could be sent via thesame communication channel810 or by adifferent communication channel816 using SMS. Theuser802 then runs the validity checking wallet on themobile device806 which connects to theeCard manager808 and adds any new eCards to the validity checking wallet stored on themobile device806. Theuser802 is thus able to employ thesystem800 to use a web interface to manage multiple eCards which will in turn be sent to the user'sphone806. In yet another embodiment, the user may add eCards directly from themobile device806.

Having described various embodiments of the invention, it will now become apparent to one of skill in the art that other embodiments incorporating the concepts may be used. For example, although the contents of this document describe the application of this invention to mobile phones, it is potentially applicable to a variety of mobile devices. It is felt, therefore, that these embodiments should not be limited to the disclosed embodiments, but rather should be limited only by the spirit and scope of the following claims.